Transformerモデルの推論時に過去のKey-Valueペアをメモリに保持し、同じ計算の繰り返しを回避して生成速度を高速化するメカニズム。
KVキャッシュ(Key-Value Cache)は、Transformerベースの大規模言語モデル(LLM)が自己回帰的にトークンを生成する際、過去に計算したAttentionのKeyベクトルとValueベクトルをメモリ上に保持する仕組みである。新しいトークンを生成するたびに過去の全トークンのK/Vを再計算する必要がなくなり、推論速度が劇的に向上する。
Transformerの自己回帰生成では、各ステップで現在のトークンのQueryと過去全トークンのKey/Valueを使ってAttentionスコアを計算する。KVキャッシュがない場合、トークン数Nに対して計算量はO(N²)で増大するが、KVキャッシュを使えばステップあたりの新規計算はO(N)に抑えられる。
具体的な動作フロー:
KVキャッシュのメモリ使用量は以下の式で算出できる:
メモリ(bytes) = 2 × レイヤー数 × ヘッド数 × ヘッド次元 × シーケンス長 × バッチサイズ × データ型サイズ
| モデル | レイヤー数 | ヘッド数 | ヘッド次元 | 最大長 | FP16 KVキャッシュ |
|---|---|---|---|---|---|
| Llama 3.1 8B | 32 | 8 (GQA) | 128 | 128K |
| 約4GB/リクエスト |
| Llama 3.1 70B | 80 | 8 (GQA) | 128 | 128K | 約10GB/リクエスト |
| GPT-4 (推定) | 120 | 96 (MHA) | 128 | 128K | 約150GB/リクエスト |
| Mistral 7B | 32 | 8 (GQA) | 128 | 32K | 約1GB/リクエスト |
| Qwen2.5 72B | 80 | 8 (GQA) | 128 | 128K | 約10GB/リクエスト |
Llama 3.1 8Bでも128Kコンテキストを満杯にすると約4GBのKVキャッシュが必要となり、モデルパラメータ自体(FP16で約16GB)に匹敵する規模になる。バッチサイズ8で同時処理すると32GBを超え、A100 80GBでも余裕がなくなる。
2026年時点でLLMのコンテキスト長は128K〜1Mトークンに拡張されており、KVキャッシュのメモリ消費が推論コストの最大要因となっている。NVIDIA H100(80GB HBM3)でもLlama 3.1 70Bの128Kコンテキストを8バッチ同時処理するとメモリ不足に陥る。
KVキャッシュが大きくなるとメモリ帯域幅がボトルネックになる。Attention計算時にキャッシュ全体をGPUメモリから読み出す必要があり、HBM3の帯域幅3.35TB/sでも長コンテキストでは数ミリ秒のレイテンシが発生する。
動的なリクエスト処理では、各リクエストのシーケンス長が異なるためメモリが断片化する。最大長を事前確保する方式では80〜90%のメモリが無駄になるケースがある。
| 技術 | カテゴリ | 効果 | 代表的実装 |
|---|---|---|---|
| Paged Attention | メモリ管理 | メモリ利用率95%以上 | vLLM, SGLang |
| GQA/MQA | アーキテクチャ | KVサイズ1/4〜1/8 | Llama 3, Mistral |
| KV圧縮 (INT4/INT8) | 量子化 | メモリ50〜75%削減 | KIVI, Atom |
| トークン刈り込み | エビクション | 動的メモリ削減 | H2O, SnapKV |
| Prefix Caching | 再利用 | プリフィル時間90%削減 | SGLang, vLLM |
KVキャッシュ最適化は、LLM推論最適化スタック全体の一部である:
Q1: KVキャッシュはなぜGPUメモリに保持するのですか?CPUメモリではダメですか? A: Attention計算はGPU上で実行されるため、KVキャッシュもGPUメモリ(HBM)に配置するのが最速である。CPUメモリに退避(オフロード)する手法も存在するが、PCIe 5.0の帯域幅(64GB/s)はHBM3(3.35TB/s)の約1/50であり、レイテンシが大幅に増加する。FlexGenなどのオフロードフレームワークはスループット重視のバッチ処理向けに使われる。
Q2: GQAとMQAはKVキャッシュにどう影響しますか? A: Multi-Head Attention(MHA)では各Attentionヘッドが独自のK/Vを持つが、Grouped Query Attention(GQA)では複数のQueryヘッドが1組のK/Vを共有する。Llama 3.1 8Bは32 Queryヘッドに対し8 KVヘッドで、KVキャッシュサイズはMHA比で1/4になる。Multi-Query Attention(MQA)はさらに全ヘッドで1組のK/Vを共有し、最大1/32まで削減できるが品質低下リスクがある。
Q3: KVキャッシュの最適化なしでLLMを本番運用できますか? A: 短いコンテキスト(4K以下)かつ低バッチサイズなら可能だが、128Kコンテキストや高スループット環境ではKVキャッシュ最適化なしでは実用的なコストで運用できない。vLLMのPaged Attentionだけでもスループットが2〜4倍向上する実測値が報告されている。