KVキャッシュとは?
KVキャッシュは、言語モデルがテキストを生成している間に保持するアテンションデータです。プロンプト、会話履歴、応答内のトークンについて、すでに計算したキーとバリューのベクトルを含みます。
LLMは、一度に一つずつトークンを生成して応答を作ります。次のトークンを出す前に、アテンション層が既存のコンテキストのどの部分に関連性があるかを判断します。各アテンション演算では、次の情報を使います。
- クエリ(Q)は、現在のステップで必要な情報を表します。
- 過去の各トークンには、そのクエリとの関連度を測るためのキー(K)があります。
- そのトークンのバリュー(V)は、結果に寄与する情報を持ちます。
モデルは現在のクエリを過去のキーと比較し、その関連度スコアに応じて対応するバリューを組み合わせます。過去のトークンについて計算したキーとバリューは、その後の各ステップでも使えるため、モデルはメモリに保持し、トークンを生成するたびに新しい組を追加します。
このようにTransformerの各層で個別に保持するキーとバリューのテンソルの集合が、KVキャッシュです。クエリは現在のアテンション処理に使い、キーとバリューは今後のステップのために保持します。
KVキャッシュの動作
ユーザーが1,000トークンのプロンプトをモデルに送るとします。モデルは続きを生成する前に、まずプロンプトを処理し、それから応答の生成を始めます。
- まず、モデルがプロンプトを処理します。各アテンション層が1,000トークンすべてのキーとバリューを計算します。これらが最初のKVキャッシュになります。
- 次に、最初の出力トークンを生成します。モデルは処理済みのプロンプトのアテンション結果を使って、1,001番目のトークンを生成します。
- キャッシュを拡張します。新しいトークンをモデルに通してキーとバリューを追加し、キャッシュは各層で1,001エントリーになります。
- 生成を続けます。モデルは拡張されたキャッシュを再利用して次のトークンを生成します。トークンが一つ増えるたびに、各層にキーとバリューが一つずつ加わります。
KVキャッシュが性能を向上させる仕組み
KVキャッシュが主に高速化するのは生成段階です。キャッシュがなければ、モデルは新しいトークンを出すたびに、長くなったシーケンス全体のキーとバリューを再計算します。キャッシュがあれば、その計算結果を再利用し、新しいトークンの表現だけを計算します。
Hugging Faceの実演では、特定のモデルとGPUで差を測定しています。
| モデルとテスト | KVキャッシュなし | KVキャッシュあり | 報告された高速化率 |
|---|---|---|---|
| SmolLM2-1.7B、NVIDIA T4で最大300の新しいトークンを生成 | 61秒 | 11.7秒 | 5.21× |
KVキャッシュがメモリを使い切る理由
性能の向上にはメモリの負担が伴います。保存したキーとバリューは、そのトークンがコンテキスト内にある限り、RAMやVRAM上で利用できる状態にしておく必要があります。
Prompt: tokens 1 ... 1,000 KV cache: [K1 ... K1000] + [V1 ... V1000] After one generated token: KV cache: [K1 ... K1001] + [V1 ... V1001]
保持するトークンが一つ増えると、Transformerの各層にキーとバリューが加わります。ほかの設定が同じなら、コンテキストが2倍になるとKVキャッシュのメモリもおおむね2倍必要です。
コンテキスト長は、キャッシュが保持するエントリー数を決めます。各エントリーに必要なメモリは、さらに次の三つの要因で変わります。
- アクティブなシーケンス数:同時に処理する会話やリクエストは、通常それぞれ別のキャッシュを保持します。
- モデルのアーキテクチャ:層やKVヘッドが多いモデルほど、トークン当たりに保存するデータが増えます。
- キャッシュの形式:FP16、8ビット、さらに低いビット数の形式では、各値の保存に必要なメモリ量が異なります。
KVキャッシュは、モデルの重みとは別のものです。重みが占めるメモリはモデルの読み込み後はほぼ一定ですが、キャッシュはプロンプトから始まり、セッション中に増えていきます。そのため、GGUFファイルが変わっていなくても、4,096トークンのコンテキストでは収まるモデルが、32,768や131,072トークンではメモリ不足になる場合があります。
以下の計算ツールは、これらの要因を組み合わせ、指定したモデルとコンテキストに必要なキャッシュのサイズを見積もります。
KVキャッシュのメモリ計算ツール
KVキャッシュにどのくらいメモリを割り当てるべきか知りたい場合は、以下の対話型計算ツールを使ってください。
注意:計算ツールが示すのはKVキャッシュだけに必要なメモリであり、モデルを実行するための総メモリではありません。たとえば4 GiBという結果なら、モデルの重み、ランタイムのバッファー、OS、ほかのアプリとは別に、キャッシュが約4 GiB必要になるという意味です。ハイブリッドモデルやスライディングウィンドウモデルでは、公開されている各モデルの設定に基づき、コンテキストとともにキャッシュが増える層を見積もります。
見積もりがハードウェアの容量を超える場合、主な選択肢は三つあります。
- コンテキストを短くする。
- 同時に実行するシーケンスを減らす。
- KVキャッシュの精度を下げる。
キャッシュの精度を下げる場合は、コンテキストを短くする場合よりも注意が必要です。圧縮がモデルの品質と生成速度の両方に影響することがあるためです。TurboQuantは、このトレードオフを抑えるために設計されています。
TurboQuantとKVキャッシュの圧縮
TurboQuantは、2025年の論文TurboQuant: Online Vector Quantization with Near-optimal Distortion Rateで発表されたオンラインベクトル量子化手法です。著者のAmir Zandieh、Majid Daliri、Majid Hadian、Vahab Mirrokniは、Google Research、Google DeepMind、New York Universityに所属していました。
従来の低ビットのKVキャッシュ量子化は、キーとバリューを少ないビット数で表すことでメモリを減らします。ただし、精度を極端に下げると、少数の非常に大きい値によって量子化誤差が増える場合があります。TurboQuantは、まず各ベクトルを回転させ、情報を座標間でより均等に分散させてから、スカラー量子化を適用します。目的は、アテンションが依存する内積を保ちながら、使うビット数を減らすことです。
では、TurboQuantには実際にどのような効果があるのでしょうか。
以下の表は、NVIDIA A100上でLlama 3.1 8B InstructとMinistral 7B Instructを使ってKVキャッシュ圧縮を評価した結果から、長いコンテキストでの生成に関わるものをまとめています。
| ベンチマーク | モデルと設定 | フル精度のキャッシュ | TurboQuant | 差 |
|---|---|---|---|---|
| Needle-in-a-Haystackの再現率 | Llama 3.1 8B Instruct、コンテキスト4K-104K。圧縮キャッシュは非圧縮時のメモリの25% | 0.997 | 0.997 | 0.000 |
| LongBench-E平均 | Llama 3.1 8B Instruct、チャネル当たり3.5ビット | 50.06 | 50.06 | 0.00 |
| LongBench-E平均 | Llama 3.1 8B Instruct、チャネル当たり2.5ビット | 50.06 | 49.44 | -0.62 |
| LongBench-E平均 | Ministral 7B Instruct、チャネル当たり2.5ビット | 49.89 | 49.62 | -0.27 |
この実験では、3.5ビットの構成はフル精度と同じ総合スコアを維持し、さらに圧縮した2.5ビットの構成ではわずかに低下しました。詳細は論文全文をご覧ください。別のカーネルテストでは、Google Researchが、NVIDIA H100上の4ビットTurboQuantで、最適化済み32ビットJAXのキーと比べてアテンションのロジット計算が最大8倍高速化したと報告しています。
実際には、KVキャッシュが小さくなると、生成する各トークンについてGPUが読み出すデータ量が減ります。コンテキストが長くなるほど、この効果は重要になります。GPUメモリから転送するデータが少なくなり、アテンションをより速く計算できるためです。
Atomic ChatのTurboQuant
Atomic Chatは、TurboQuantベースのKVキャッシュ形式を備えた改変版llama.cppエンジンを使用します。Metal、CUDA、Vulkan、HIP/ROCm、CPU向けの実行経路があり、TurboQuantのキャッシュ形式は三つあります。
| キャッシュの種類 | ドキュメント記載のF16に対するサイズ比 | リポジトリの推奨事項 |
|---|---|---|
turbo2 | 約6.4分の1 | 最も強い圧縮。コンテキスト用の余裕を最大化 |
turbo3 | 約4.3分の1 | バランス重視の推奨設定 |
turbo4 | 約3.8分の1 | より高い精度が必要な場合の代替 |
Atomic Chatでは、システムとモデルの組み合わせに応じて、最適なKVキャッシュの圧縮レベルが自動的に選ばれます。
Apple SiliconにおけるKVキャッシュ圧縮の速度への影響だけを確認するため、40コアのM4 Max GPUと48 GBのユニファイドメモリを搭載したMacBook Proで、Qwen 3.6の二つのモデルをテストしました。各実行ではMetalを使い、一度に一つの応答を生成しました。結果は次の表のとおりです。
| モデル | 出力長 | F16基本構成(トークン/秒) | turbo3基本構成(トークン/秒) | turbo3の変化率 |
|---|---|---|---|---|
| Qwen 3.6 27B デンス型 | 128 | 21.3 t/s | 19.7 t/s | -7.5% |
| Qwen 3.6 27B デンス型 | 512 | 20.8 t/s | 18.7 t/s | -10.1% |
| Qwen 3.6 35B-A3B MoE | 128 | 70.1 t/s | 61.8 t/s | -11.8% |
| Qwen 3.6 35B-A3B MoE | 512 | 69.6 t/s | 62.0 t/s | -10.9% |
これらの実行では、turbo3の毎秒の生成トークン数はF16より7.5-11.8%少なくなりました。ベンチマーク全体の一覧と測定環境の詳細は、Atomicのリポジトリで公開しています。
よくある質問
LLMのKVキャッシュとは何ですか?
KVキャッシュは、LLMが処理済みトークンについて保持するキーとバリューのテンソルの集合です。生成時にこれらを再利用すると、新しいトークンを出すたびに同じアテンションデータを再計算する必要がなくなります。追加のRAMやVRAMを使う代わりに、計算の繰り返しを減らせます。
KVキャッシュはLLMの推論をどのように高速化しますか?
KVキャッシュは、各トークンのキーとバリューを一度だけ計算して再利用することで、デコーディングを高速化します。Hugging Faceの実演では、NVIDIA T4上のSmolLM2-1.7Bが最大300の新しいトークンを生成するのに、キャッシュありでは11.7秒、なしでは61秒かかりました。報告された高速化率は5.21倍です。
コンテキストが長くなるとKVキャッシュのメモリが増えるのはなぜですか?
保持するトークンが一つ増えるたびに、Transformerの各層にキーとバリューのベクトルが一つずつ加わります。モデル、アクティブなシーケンス数、キャッシュ形式が同じなら、コンテキスト長が2倍になるとKVキャッシュのメモリもおおむね2倍になります。
KVキャッシュはRAMやVRAMをどのくらい使いますか?
KVキャッシュのメモリ使用量は、コンテキスト長、アクティブなシーケンス数、モデルのアーキテクチャ、キャッシュ精度で変わります。目安として、Llama 3.1 8Bで131,072トークンのシーケンスを一つ使う場合、FP16キャッシュでは推定16 GiB、Atomicのturbo3では3.72 GiBが必要です。モデルの重みやランタイムの追加メモリは含まれていません。
KVキャッシュのメモリ使用量はどうすれば減らせますか?
コンテキストを短くする、同時に動かすシーケンスを減らす、KVヘッドや層の少ないモデルを選ぶ、キャッシュの精度を下げる、といった方法で減らせます。KVキャッシュの量子化は、各キーとバリューを少ないビット数で保存しながら、コンテキスト長を維持する方法です。
KVキャッシュの量子化とGGUFの量子化は同じですか?
いいえ。GGUFの量子化は通常、モデルの重みを圧縮します。重みのメモリ使用量は読み込み後はほぼ一定です。一方、KVキャッシュの量子化は、推論中に作られ、使用中のコンテキストとともに増える一時的なアテンションデータを圧縮します。両方を併用できます。
TurboQuantとは何ですか?
TurboQuantは、LLMのKVキャッシュを圧縮できる低ビットのベクトル量子化手法です。量子化前にキーとバリューのベクトルを回転させ、情報をより均等に分散させることで、少ないビット数と小さな歪みで表現できるようにします。
TurboQuantはモデルの品質に影響しますか?
論文のLlama 3.1 8BによるLongBench-Eテストでは、TurboQuantはチャネル当たり3.5ビットでフル精度と同じ総合スコアを維持しました。2.5ビットでは、報告された総合スコアがわずかに低下しました。そのため、品質への影響は圧縮レベル、モデル、タスクによって変わります。
TurboQuantでLLMの生成は速くなりますか?
TurboQuantは、メモリから読み出すKVキャッシュのデータ量を減らすことで、特に長いコンテキストでアテンションを高速化できます。生成全体の速度は量子化カーネルやハードウェアにも左右されます。GoogleはH100でアテンションのロジット計算が最大8倍速くなると報告しましたが、AtomicのM4 Maxベンチマークでは、turbo3の生成はF16より7.5-11.8%遅くなりました。
まとめ
KVキャッシュは、モデルが何度も再計算することになるアテンションデータを保存し、トークンごとの生成を実用的にします。これにより、特に長いコンテキストを扱う場合に生成が速くなります。ただし、コンテキストが増えるにつれて、KVキャッシュはシステムで使用可能なRAMやVRAMをより多く使います。Atomic ChatのTurboQuantのようなKVキャッシュ量子化で、このメモリ使用量を減らせます。
要点:
- KVキャッシュは、言語モデルがテキストを生成している間に保持するアテンションデータです。
- KVキャッシュは、プロンプト、会話履歴、応答内のトークンについて、すでに計算したキーとバリューのベクトルを含みます。
- 過去のトークンのアテンション計算をモデルが再利用するため、KVキャッシュによってテキスト生成が速くなります。
- プロンプトや会話が長くなるほど、KVキャッシュは大きくなります。モデルとキャッシュ形式が同じなら、コンテキストを8,000から16,000トークンに増やすと、キャッシュのメモリはおおむね2倍必要です。
- AtomicのTurboQuant形式
turbo3は、F16の約4.3分の1のキャッシュメモリを使います。当社のM4 Maxテストでは、毎秒の生成トークン数も7.5-11.8%少なくなりました。

