# What are KV Caches Really? [[Glenn K. Lockwood]] の個人ブログ記事（2026-09-18）。KV キャッシュの仕組みを数式に頼らず平易に説明し、AI インフラベンダーが謳う「KV キャッシュオフロードで最大 20〜75 倍高速化」という宣伝文句を、prefill/decode の技術的性質から批判的に検証する内容。 ## 要旨 LLM 推論には prefill（プレフィックス全体をモデルに通す下準備）と decode（1 トークンずつ出力を生成するループ）の 2 段階がある。KV（key・value）キャッシュはこの両段階の速度差を生む核であり、その仕組みを正しく理解すると、ベンダーの派手な高速化訴求の多くが「極端に長いコンテキストでの prefill 再計算」という不利な比較対象を選んだ結果に過ぎないことが分かる。 ## Prefill と decode - **Prefill**: ユーザーの入力（プレフィックス。可視のクエリ＋不可視のシステムプロンプト等）をモデルに通し、次トークン予測ができる状態にする処理。ここでかかる時間が Time to First Token（TTFT）。 - **Decode**: プレフィックスと計算済みの key・value を使って次トークンを予測し、それを入力に追加してまた次トークンを予測する、というループ。1 トークンあたりの生成時間が Time Between Tokens（TBT）。 - **Key・Value**: prefill/decode の裏側で各トークンごとに計算される内部表現。トークンごとに一意で、他のトークンと共有されない。 プレフィックスが長いほど（長文の質問、外部コンテキストの取り込み、長いシステムプロンプトなど）prefill にかかる時間、つまり TTFT が伸びる。 ## KV キャッシュが機能する理由 各出力トークンは、それ以前の全トークンの key・value だけに依存し、まだ生成されていない未来のトークンには一切依存しない。この性質から、key・value には次の 2 つの特徴がある。 1. 一度生成された key・value は以降変化しない。 2. 生成された key・value は、後続のすべてのトークン生成で繰り返し使われる。 この 2 点によって key・value はキャッシュに理想的であり、これが KV キャッシュの存在理由である。KV キャッシュはプレフィックスと生成済み出力トークンすべての key・value を保持し、decode の各反復でGPUコアのレジスタへ繰り返しロードされる。新しい出力トークンが生成されるたびに、その key・value も計算されてキャッシュに追記される。 ![[_attachments/what-are-kv-caches-really/fig01-decode-loop-kv-dependency.png]] (decode ループの模式図。出力トークン N は、プレフィックスおよびそれ以前の出力トークン 1〜N-1 の key・value にのみ依存することを示す。) KV キャッシュがあるからこそ、prefill（TTFT）は decode の反復間の遅延（TBT）よりずっと長い。prefill はプレフィックス全体のトークン分の key・value を計算しなければならないのに対し、decode の各反復は新規トークン 1 個分だけを計算すればよく、残りはキャッシュから読み込むだけで済むためである。同じ理由で、prefill は計算律速（GPU FLOPS の恩恵を受ける）、decode はメモリ帯域律速（HBM の帯域の恩恵を受ける）という性質差が生まれる。 ## KV キャッシュなしでは指数的に劣化する KV キャッシュによる高速化があまりに大きいため、実質的に全ての推論システムが decode で KV キャッシュを使っている。KV キャッシュがなければ、出力トークンが増えるたびに再計算対象のプレフィックス長も伸び続け、1 トークン分の key・value 計算に 1 秒かかると仮定すると、2 トークン目で 4 秒、3 トークン目で 9 秒、4 トークン目で 16 秒と再計算コストが二乗で悪化する。KV キャッシュなしのチャットボットは、応答を最後まで出し切る前に事実上停止してしまう。 ## 低速 KV キャッシュはオフロード用途に限って有効 KV キャッシュが有効に機能するための条件は「再計算より読み込みの方が速いこと」である。プレフィックスが長いほどこの条件が満たされやすくなる。ここから次の帰結が導かれる。 - **decode で使う KV キャッシュは必ず GPU HBM に置かれる。** 新規トークンを生成するたびに GPU の外へ出るようでは GPU を使う意味がなくなる。これが decode の性能が FLOPS よりメモリ帯域に依存する理由である。 - **低速 KV キャッシュ（SSD やリモートストレージ）が有効なのは prefill だけであり、decode には使えない。** しかもプレフィックスが長い場合に限られる。 さらに prefill 用途でも次の制約がある。 1. **プレフィックスの完全一致が必須。** 各出力トークンはそれ以前の全トークンに依存するため、プレフィックスのどこか一箇所でも違えば、それ以降の key・value はすべて無効になる。例えば "What are the key takeaways..." と "Tell me the key takeaways..." は、大部分の文字列が共通していても先頭が異なるため、KV キャッシュを一切共有できない。 2. **ユーザー間での KV キャッシュ共有はセキュリティリスクを伴う。** 共通プレフィックスを持つ 2 人のユーザーが理論上は互いの KV キャッシュから恩恵を受けられるが、これは同時に「自分のクエリが誰か他人と共通のプレフィックスを持つ」ことを推測できてしまう情報漏洩経路になる。このため本番のマルチユーザー推論環境では、ユーザー間で KV キャッシュを共有しない。唯一の例外は全ユーザーで共通のシステムプロンプトで、これは元々秘匿性がないため共有しても安全である（例: Anthropic が公開している Claude の長いシステムプロンプト）。 3. **decode 用の KV キャッシュを低速ストレージへ移すことはできない。** GPU メモリに収まっていることが前提であり、これを崩すとキャッシュの意味自体が失われる。 ## 低速 KV キャッシュが有効な 2 つの場面 1. **会話をまたいだプレフィックス共有**: 長いシステムプロンプトや共通の質問文など、同一の key・value が複数リクエストで再利用でき、毎回再計算するよりストレージから読み込む方が速い場合。 2. **ターン間の長い待機時間でのオフロード**: ユーザーが応答を読んでいる数十秒〜数分の間 GPU が遊んでしまうのを避けるため、そのセッションの KV キャッシュを低速ストレージへ退避（KV cache offload）して GPU を他ユーザーに明け渡し、次の質問が来たら再ロードする。これは純粋な性能最適化というより、GPU 稼働率を上げるためのユーザー間のやりくりである。 [[Prefill-Decode分離|disaggregated inferencing]] のようなより高度な手法も、この低速 KV キャッシュをより多くのユーザー・クエリのやりくりに使っており、主にハイパースケーラー規模の本番環境で採用される。この条件が特に当てはまるのは次の 2 ケースである。 - **コードベースやリッチメディアとのやり取り**: 大きなコードベースや動画のような大容量コンテキストを読み込んだままの長時間セッション。 - **ツール呼び出し（tool calling）**: エージェントが外部ツールを呼ぶたびに応答を待つ必要があり、その待機が長い場合、KV キャッシュオフロードで別セッションに GPU を明け渡せる。エージェント的ワークフローは巨大なコンテキストを生みやすく、オフロードを正当化しやすい。 ## ベンダーの宣伝文句を読み解く 著者は AI インフラベンダーが謳う派手な高速化訴求を批判的に検証する。 | # | 訴求内容 | 実態 | |---|---|---| | 1 | 112K トークンコンテキストの再計算 57 秒 → KV キャッシュ読み込み 2.1 秒で 27 倍高速 | プレフィックスが約 4K トークン（112K ÷ 27）以下なら、素の再計算の方がこの KV キャッシュ製品より速い。本記事自体は約 2,600 トークンで、この製品からロードするより素で prefill する方が速い規模。 | | 2 | 長コンテキストの prefill 時間を最大 75 倍高速化 | 128K トークン（The Hobbit 一冊相当）の prefix での TTFT 比較。 | | 3 | 推論効率を 90%、TTFT を 20 倍改善（KV キャッシュオフロード使用） | 同じく 128K トークンでの計測。 | | 4 | 大規模・マルチ GPU モデルで最大 20 倍・6 倍の高速化 | 同じく 128K トークン（The Hobbit）の prefill。ベンダー自身が示した図でも、プレフィックスが短くなると高速化率が急落することが確認できる。 | いずれも「素の prefill 再計算」対「ベンダー製品での KV キャッシュ読み込み」という prefill 限定の比較であり、decode やエンドツーエンドの推論速度については何も述べていない（decode 用 KV キャッシュは必ず GPU HBM に収める必要があるため）。訴求 #3 と #4 の 20 倍という一見同じ数字も、モデルサイズやGPU構成が異なれば単純比較できない（#2 は 70B パラメータモデル、#3 はより大きいモデルを使用しており、パラメータ数・KV量・必要 GPU メモリが違う）。 著者は「見栄えの良い KV キャッシュのベンチマークを作るレシピ」を次のように整理する。 1. prefill 性能だけを見る（低速 KV キャッシュが意味を持つのは prefill だけであり、decode で使えば必ず悲惨な結果になる）。 2. パラメータ数の多いモデルを選ぶ（prefill・decode双方の計算量が増える）。 3. 非常に大きなコンテキストウィンドウを目一杯埋めて計測する（プレフィックスが長いほど prefill が長くなる）。 4. GPU を低電力モードで動かす（FLOPS は下がり prefill 時間は伸びるが、PCIe 帯域は変わらないため I/O 時間は変化しない）。 この組み合わせにより、ストレージからのキャッシュ読み込みに対して意図的に遅い prefill ベースラインが作られ、派手な倍率が生まれる。 ## 結論（著者の立場） prefill/decode/KV キャッシュの技術的な仕組みを理解していれば、ベンダーの宣伝文句を誤読せずに済む。decode で使う KV キャッシュは必ず GPU メモリに収まっていなければならず、これにより低速な（オフロード・リモート）KV キャッシュ解決策は多くのユースケースで実用的ではない。有効なのはプレフィックスが長い、あるいは複数ユーザーのやりくりが必要な限られたシナリオに限られる。 ## 関連 - エンティティ: [[Glenn K. Lockwood]] - 概念: [[LLM推論]] / [[Prefill-Decode分離]] / [[High Bandwidth Memory]] - 生データ: [[.raw/articles/what-are-kv-caches-really-2026-09-22.md]]