中規模モデルの重みは快適に収まるが、同時アクセスによりCUDAメモリ不足エラーが発生し、GPU使用率は低いままであった。キーバリューキャッシュ、モデルサイズではなく、ヘッドルームを消費していた。GPUを追加する前に、著者はページドアロケーションとプレフィックスキャッシングを有効にし、上限を引き上げてメモリレイアウトの問題を露呈させた。

ナイーブなサービングスタックは、最大シーケンス長に対してリクエストごとに連続したブロックを予約する。4,096トークンの予約に対して200トークンを生成するリクエストは、その大半を未使用のまま残す。v LLMの分析によると、ナイーブなKVキャッシュ管理は予約済みメモリの60から80パーセントを無駄にする。キャッシュは同時リクエストとともに増加するため、トラフィックのスパイク — プロンプトの長さではない — がサーバーをメモリクリフの先に押し進める。

GPUメモリは、固定されたモデルウェイト、一時的なアクティベーション、および可変のKVキャッシュによって共有される。Llama 3.1 70BのBF16において、1トークンあたりのコストは約320 KBであり、80層、8つのキー/バリューヘッド、ヘッド次元128である。グループドクエリアテンションは、キー/バリューヘッドの数とキャッシュサイズを削減する。

128の同時リクエストが4Kトークンのコンテキストを保持している場合、キャッシュのみで約160 GB必要となる。70BのウェイトはBF16で140 GB必要であり、そのためキャッシュがモデルを上回る可能性がある。v LLMはキャッシュを、最大同時シーケンス数と最大シーケンス長の積として予約する；いずれかを増やすと予約が乗算され、起動時のOOMを引き起こす可能性がある。

主要エンティティ: 企業: NVIDIA, Towards Data Science