KVキャッシュ管理の教科書 - yuuk1's Digital Garden

# KVキャッシュ管理の教科書本教科書は wiki に蓄積された 40 近いソースと 17 のコンセプトページを横断し、KV キャッシュ管理を体系化したものである。初学者が第 I 部から順に読めば「なぜ KV キャッシュが必要か」から「本番クラスタでどう運用するか」までたどれるように構成した。実践者は第 V 部以降、研究者は第 XI 部と第 XIII 部を起点にできる。 > [!note] 第 2 版(2026-07-31)について > 初版(2026-07-30)の後に wiki へ取り込まれた MLSys 2026 系のソース群を反映した。 > 章立てと図版は初版のまま保ち、各章の内部を書き足す形で改訂している。 > 主な追加は、量子化という第 3 の削減軸(第 3 章、第 22 章)、オフライン一括推論という別レジーム(第 7 章、第 8 章)、GPU と CPU を密結合したスーパーチップ上の粒度問題(第 14 章、第 33 章)、PD 分離の適用条件の定量化(第 16 章)、そしてバッチサイズという操作点の導入(第 2 章)である。 KV キャッシュ管理という主題には、一つの技術体系には収まらない広がりがある。出発点は 1 GPU のメモリ断片化という局所的な問題だが、行き着く先はクラスタ横断のデータ移動、障害時の状態復旧、電力制約下の広域配置である。この拡大の過程そのものが本書の縦軸になる。 --- ## 第 I 部　基礎 ### 第 1 章　KV キャッシュが存在する理由 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch01.png|900]] *図1　「KV キャッシュが存在する理由」の概観* Transformer の自己注意は $\mathrm{softmax}(QK^\top/\sqrt{d_k})V$ で定義され、同じ長さの系列に対して $O(n^2)$ の位置対を評価する(Source: [[注意機構]])。柔軟な大域アクセスによって長距離依存のパスを短くする代わりに、位置対の計算量を払う設計交換になっている。自己回帰生成では、この計算を毎ステップ最初からやり直すと系列全体で $O(N^2)$ の重複が生じる。過去トークンの key と value を保存しておけば、新しいトークンについては 1 本のクエリだけを計算し、キャッシュ済みの K と V と掛け合わせればよい(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]])。これが **KV キャッシュ**であり、1 トークンのデコードにおける注意計算を $O(N)$ に落として系列全体の再計算を回避する。 > [!note] 複雑度の表記について > 「$O(N^2)$ から $O(N)$ へ」という要約(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]])は、トークンあたりの計算量と系列全体の計算量を混ぜた緩い表記である。 > 厳密には「1 トークンのデコードにおける注意計算が $O(N)$ になり、系列全体を再計算する $O(N^2)$ を回避する」と述べるべきである。技術系譜の起点としては Megatron-LM(2019 年から 2020 年)が挙げられる(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]])。分散システムの語彙で言えば、KV キャッシュは CDN や分散データベースのキャッシングに対応する。 ### 第 2 章　プリフィルとデコードの非対称性 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch02.png|900]] *図2　「プリフィルとデコードの非対称性」の概観* 推論は 4 段階に分かれる(Source: [[@2026__Zenn__MLエンジニアのための本質から理解するLLM推論]])。プロンプト投入、キューイング、プロンプト全体を処理して KV キャッシュを構築する**プリフィル**、キャッシュを参照しながら 1 トークンずつ生成する**デコード**である。この 2 相は資源特性が正反対であり、本書のほぼ全ての設計判断がここに帰着する。 | 段階 | 主な処理 | 資源特性 | 主指標 | |---|---|---|---| | プリフィル | 埋め込み参照、QKV 計算、KV キャッシュ構築 | 計算バウンド、テンソルコア律速、並列性が高い | TTFT | | デコード | KV 取得、$QK^\top$、加重和、トークン生成 | メモリバウンド、HBM 帯域律速、並列性が低い | ITL / TPOT | デコードがメモリ律速であることは実測でも裏づけられる。行列ベクトル積では CPU サイクルの半分以上がメモリ待ちで消費され、4 スレッドでは停止サイクルが全 CPU サイクルの 80% を超える(Source: [[LLM推論]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])。エッジ環境の演算子レベル計測では、デコード速度がおおむね 2 スレッドまでしか伸びずメモリ帯域の限界に達する(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])。同じ GPU に両相を同居させると、計算バウンドなプリフィルとメモリバウンドなデコードが同じコアと HBM 帯域を取り合う。極端な場合には利用率が 0.2% まで落ちる(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]])。この干渉が第 VI 部の Prefill-Decode 分離の動機である。同じ演算子レベルの計測は、KV キャッシュのコストが連続的でなく階段状に現れることも示す。 KV キャッシュ機構によってデコードのスループット自体は安定するが、キャッシュの成長に伴って各反復の経過時間は増え、劣化への寄与は KQ と KQV の 2 演算子に局在する(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])。ここで注意すべきは、上の表がバッチサイズという操作点を持たないことである。「デコードはメモリバウンド」という命題は、バッチサイズ 1 の近傍で最も強く成り立つ。バッチを積むほど 1 回の重み読み出しに対して処理されるトークンが増え、演算強度が上がるため、この性質は相対化されていく。間接的な指標が投機的復号の測定にある(Source: [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]])。投機的復号はデコードステップに余っている計算資源を使って複数トークンを一括検証する手法なので、その利得の大きさは「どれだけ計算が遊んでいるか」の代理変数になる。本番相当の vLLM 上での横断比較では、EAGLE の速度向上が Llama3.1-8B と GSM8K でバッチサイズ 1 の 1.73 倍からバッチサイズ 128 の 1.21 倍へ縮む。縮小の度合いはモデルが大きいほど顕著で、ShareGPT でバッチサイズを 1 から 32 へ上げたときの低下率は Llama3.1-8B が 4.3%(1.68 倍から 1.61 倍)、Llama3-70B が 14.0%(1.96 倍から 1.72 倍)である。 > [!note] 「メモリバウンド」の適用範囲 > ここで引いた投機的復号の測定は、原論文がメモリバウンドと計算バウンドの語で議論した結果ではない。 > 論文が報告するのはバッチサイズに対する速度向上の縮小であり、律速要因の遷移という機構説明は本書側の解釈である。 > 本書は以降も「デコードはメモリバウンド」という前提で議論を進めるが、これは小から中程度のバッチサイズを想定した記述だと理解してほしい。 ### 第 3 章　容量の見積もり ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch03.png|900]] *図3　「容量の見積もり」の概観* KV キャッシュの要素数は次式で与えられる(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]], [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]])。 ``` 2 × batch_size × num_layers × sequence_length × head_dim × num_heads ``` batch=16、layers=96、seq=32768、head_dim=128、heads=8、float16 という条件では **192 GiB** に達する(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]])[^kvsize]。より小さなモデルでも量は無視できない。 OPT-13B は 1 トークンあたり約 800 KB を要し、2048 トークンで 1 リクエスト 1.6 GB になる(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]])。 Llama-3.1-405B に 8k トークンを入力すると 1 リクエストあたり約 4 GB である(Source: [[LLM推論]])。 [^kvsize]: 192 GiB という値は勉強会資料の見積もりであり、発表者の所属は資料から確定できない。桁感を掴む例として扱うのが安全である。この式が本書の残りを規定する。要素数は系列長、層数、ヘッド数、バッチサイズのいずれに対しても線形なので、削減の道は「どれかの因子を小さくする」か「保存場所を GPU の外へ広げる」かの二択になる。前者が第 VII 部と第 VIII 部、後者が第 V 部の主題である。ただし式が数えているのは要素数であって、バイト数ではない。 1 要素あたりのビット数を下げるという第 3 の道が残っている。上の見積もりはいずれも float16 を前提としているが、KV キャッシュを 2 ビット級まで量子化できれば同じ物理メモリに数倍の文脈が載る。混合精度で実効ビット幅を系列長 32K のとき約 2.44 ビットまで下げた報告があり、これは float16 比で約 6.6 倍の圧縮にあたる(Source: [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]])。ビット幅を下げる道は第 VIII 部で扱う。因子を増やす方向の話もある。投機的復号でドラフトモデルを別に置く方式は、トークンあたりの KV キャッシュを増やす。 Qwen3-8B に Qwen3-0.6B をドラフトとして組み合わせると、トークンあたり 144 KiB が 256 KiB へ、1.77 倍になる(Source: [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]])。同じ投機的復号でも方式によって桁が違い、EAGLE の静的オーバーヘッドは Llama3.1-8B で 3.1%、EAGLE-3 で 5.3%、n-gram では生成履歴を CPU に置くため GPU メモリのオーバーヘッドがゼロである。投機的復号を導入するかどうかは、速度だけでなく容量計画の変数でもある。同じ入出力長のプロファイルでも用途によって要求は大きく変わる(Source: [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]])。 | 用途 | ISL | OSL | 特徴 | | --- | -------- | ---------- | ------------- | | 翻訳 | 500〜2000 | 500〜2000 | 入出力比がほぼ 1 対 1 | | 生成 | 〜100 | 〜1000 | 短いプロンプトから長い出力 | | 要約 | 〜1000 | 〜100 | 長い入力から短い出力 | | 推論 | 〜100 | 1000〜10000 | 思考連鎖で出力が極端に長い | この表は用途を特定すれば入出力長が一定の範囲に収まるという前提に立っている。混在トラフィックを受ける本番プラットフォームでは、この前提が成り立たない。月間 10 億人規模の Llama 運用の実測では、入力トークン長の分布は 0 から 1,200 付近と 5,000 から 6,500 付近に 2 つの峰を持ち、12,000 超まで裾を引く(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]])。出力トークン長は 150 付近を中心とする単峰で急峻に減衰する。にもかかわらず 1 分間の平均を取ると入力トークン数は約 2,000 で安定して見える。平均値で容量を設計すると、第 2 の峰と長い裾に対する KV キャッシュの確保が破綻する。容量計画の入力は点推定ではなく分布であり、設計すべきは平均ではなく裾である。同じ運用報告は、サービス種別ごとの要件も示す。テキストエージェント、マルチモーダルエージェント、リアルタイムエージェント、安全性判定、データ拡張、データ採点の 6 種で、入力長は 50 から 32K 超、出力長は 100 から 1K 超、TTFT 要件は 200 ミリ秒未満から数秒、モデルサイズは 10B から 500B 超に及ぶ。上の表の「推論」行が出力側の長さを問題にするのに対し、エージェント系は入力側が桁違いに長い別の領域である。 KV キャッシュ容量は系列長に線形なので、この差はそのまま容量要求の差になる。 --- ## 第 II 部　単一 GPU 内のメモリ管理 ### 第 4 章　連続割当の破綻 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch04.png|900]] *図4　「連続割当の破綻」の概観* KV キャッシュは巨大であるうえに、生成が進むにつれて動的に増減する。連続領域を前提とした管理では 4 種の浪費が生じる(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]])。最大長を見込んだ予約領域、割当ブロック内で使われない内部断片化、合計空き容量はあるのに連続領域が取れない外部断片化、そして並列サンプリングやビーム探索で共通部分を共有できないことである。結果として、実際に使われるトークン状態は KV キャッシュ領域の **20.4% から 38.2%** にとどまる(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]])。容量の 6 割から 8 割が捨てられている。 ### 第 5 章　PagedAttention ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch05.png|900]] *図5　「PagedAttention」の概観* **PagedAttention** は OS の仮想メモリとページングを KV キャッシュへ移植する(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[PagedAttention]])。各シーケンスの KV キャッシュを固定サイズの KV ブロックに分け、論理ブロックを非連続な物理ブロックへ写像する。注意計算をブロック単位に変形し、カーネルが必要なブロックを個別に読み出す。構成要素は物理ブロックのプールと、リクエストごとのブロックテーブルである。新しいトークンが生成されるたびに必要なブロックだけを追加するので、浪費は最後の 1 ブロックに限られる。並列サンプリングやビーム探索では共通プレフィックスをブロック単位で共有し、分岐後に書き込みが必要な箇所だけ複製する(copy-on-write)。メモリが枯渇したときはリクエストをプリエンプトし、再計算または CPU への退避で復帰させる。ブロックサイズは多くのワークロードで **16** が既定値として選ばれる。 GPU の並列性を活かせる程度に大きく、内部断片化を招かない程度に小さいという釣り合いである。プリエンプト時に再計算と退避のどちらが有利かもブロックサイズに依存する。小さなブロックでは退避が多数の小転送を生んで PCIe 帯域を使い切れないため、再計算が相対的に有利になる。効果は FasterTransformer と Orca に対して同等レイテンシで **2 倍から 4 倍**のスループットである。長い系列、大きなモデル、複雑な復号方式でより顕著になる。 Orca が反復レベルのスケジューリングで GPU 利用率を上げるのに対し、PagedAttention はメモリ利用率を上げて同時にバッチできる本数を増やす。両者は競合ではなく補完関係にある。 > [!warning] 「メモリ効率 96%」という数値の出所 > 原典は「ほぼゼロの浪費」と「既存システムでは有効利用が 20.4% から 38.2%」を述べるが、96% という数値は出さない。 > この値は二次資料の記述であり(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]])、原典に帰してはならない。 PagedAttention には適用範囲の限界もある。テンソル形状が静的な訓練ワークロードでは、非連続アクセスと間接参照のコストが利得を上回りうる(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]])。また層ごとにキャッシュサイズや更新規則が異なるハイブリッドアテンションのモデルは、均質な KV キャッシュを仮想ページ管理するという基本前提を破る(Source: [[LLM推論]], [[ハイブリッドアテンションアーキテクチャ]])。 ### 第 6 章　計算側の最適化との役割分担 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch06.png|900]] *図6　「計算側の最適化との役割分担」の概観* KV キャッシュ管理と並走して、注意計算そのものの最適化も進んだ。両者は直交するので、混同しないために整理しておく。 GPU のメモリ階層では SRAM と HBM の帯域差が支配的である。標準的な注意実装は中間行列 $S=QK^\top$ を HBM に書き戻すため、SM は計算よりも HBM 待ちで時間を使う(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]])。 FlashAttention はタイルを SRAM に載せてこの往復を最小化する。 FlashAttention-2 は 3 つの改良で効率を上げた(Source: [[@2023__arXiv__FlashAttention-2 - Faster Attention with Better Parallelism and Work Partitioning]])。非行列積 FLOPs の削減(スケーリングの先送りと、統計を `L = m + log(ℓ)` の logsumexp 一本に統合)、系列長次元への並列化、そしてワープ間分割を split-K から split-Q へ改める変更である。 A100 では非行列積 FP32 が行列積 FP16 の 16 倍のコストを持つため、第 1 の改良が効く。結果として GPU 効率はフォワードで **50% から 73%**、実測ピークは約 230 TFLOPs/s に達した。この系列では律速点が世代ごとに移動している。 HBM 帯域から非行列積演算へ、さらに指数関数ユニットへ移った(Source: [[LLM推論]])。 > [!note] SRAM 容量と HBM 帯域の数値のばらつき > 共有メモリ容量は SM あたり 192 KB (Source: [[@2023__arXiv__FlashAttention-2 - Faster Attention with Better Parallelism and Work Partitioning]]) と 128 KB (Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]]) で食い違う。 > HBM 帯域も 1.5 から 2.0 TB/s、1.5 TB/s、1 から 3 TB/s と資料ごとに幅がある。 > いずれも GPU 世代を明示していないため、引用時は世代を特定する必要がある。計算側の第 2 の軸が投機的復号である。デコードステップに余っている計算資源を使い、複数のトークン候補を一括で検証する。本番相当の vLLM 上で n-gram、EAGLE と EAGLE-3、ドラフトモデル、MTP を横断比較した測定では、実行時間の内訳が明快に出る(Source: [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]])。ターゲットモデルによる検証段階が全方式で 42% から 95% を占め、サンプリングは 1.7% 未満である。ドラフト生成のコストは方式で桁が違い、n-gram はバッチサイズによらず 2% 未満だが、EAGLE 系はバッチサイズ 1 で 12% から 20%、ドラフトモデル方式は Qwen3-8B の構成でバッチサイズ 1 に約 47% を占める。棄却されるトークンの検証は本質的に無駄な計算であり、これが理論上限との差を生む。この軸が KV キャッシュ管理と直交しない点は 2 か所に現れる。容量については第 3 章で見たとおり、ドラフトモデル方式がトークンあたりの KV を 1.77 倍にする。状態管理については、EAGLE の提案ヘッド用 KV キャッシュの管理コスト、とくにリクエストが一時停止して再開したときの部分的な再充填が、理論上限の計算から抜け落ちていると著者自身が認めている。第 21 章で扱う「投機的復号と状態の部分破棄の相性」は、線形注意の側だけの問題ではない。 OS のページングを「仮想メモリを管理するフルアソシアティブキャッシュ」と見る視点は(Source: [[メモリ階層とキャッシュ]])、PagedAttention の類比を古典的なキャッシュ理論へ橋渡しする。レイテンシ改善が本質的に困難であり、キャッシュ階層と HBM が実用的な対策になるという構図も共通する(Source: [[メモリウォール]])。 --- ## 第 III 部　リクエスト間の再利用 ### 第 7 章　プレフィックス共有と RadixAttention ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch07.png|900]] *図7　「プレフィックス共有と RadixAttention」の概観* 第 II 部までは 1 リクエスト内の管理だった。同じプレフィックスを持つ別のリクエストが来るなら、計算済みの KV を使い回せる。 **RadixAttention** は KV キャッシュを radix tree に格納し、共通プレフィックスの検索、挿入、退避を扱う(Source: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]])。 LRU 退避と参照カウンタ、そしてキャッシュ認識スケジューリングを持つ。 KV キャッシュをリクエスト固有の状態ではなく、プログラム実行全体のプレフィックス木として扱う点が転換である。効果は最大 6.4 倍のスループットと最大 3.7 倍のレイテンシ削減で、キャッシュヒット率は 50% から 99% に及ぶ。管理オーバーヘッドは、再利用が生じない条件でも全体 74.3 秒に対して 0.2 秒(0.3% 未満)にとどまる。 Chatbot Arena での 1 か月の配備では LLaVA-Next-34B で 52.4%、Vicuna-33B で 74.1% のヒット率を記録した。再利用の対象は固定的なシステムプロンプトに限らない。 PagedAttention は並列サンプリングとビーム探索の共有を扱い、SGLang は ReAct、Tree-of-Thought、RAG、マルチターン対話といったプログラム構造からヒットを得る(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]])。プレフィックスキャッシュは、アプリケーションの制御フローとルーティングに依存する設計対象になった。ここまでの前提は、リクエストが逐次到着し、どれが将来再利用されるかは事前にわからないことだった。オフラインの大規模一括推論ではこの前提が崩れる(Source: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]])。検索エンジンのスニペット生成、オフラインランキング、広告タイトルの書き換えといった用途では、数千から数万のプロンプトが処理開始前に出そろい、長さ分布もプレフィックス共有関係も既知で、指標はレイテンシではなくスループットである。この設定では LRU の暗黙的なキャッシュ管理が構造的に不利になる。大域的な視点を持たないため、これから再利用されようとしている KV コンテキストを早期に退避してしまう。あるワークロードでは理論上の最適なトークン節約率 58.1% に対し、vLLM の実装は 35.8% しか達成できない。共有プレフィックス長 16,000 トークン、共有度 16 という極端な条件では差がさらに開き、トークン再利用率は vLLM 6.3%、SGLang 5.2% に対し BatchLLM は 92.6% に達する。このとき vLLM と SGLang のスループットはベースラインの 0.49 倍と 0.56 倍へ**劣化**する。再利用機構が働かないだけでなく、その管理コストが純損失になる領域がある。 BatchLLM の解法は、推測をやめて事前に解くことである。一括分全体から compact prefix tree を構築し、動的計画法で第 1 階層のプレフィックスを拡大する。子ノードと孫ノードを統合するかどうかは、利得 `(leaves(gchild) - 1) × tokens(gchild)` が代償 `tokens(child)` を上回るかで判定する。時間計算量は O(nc²)、空間計算量は O(n) であり、8,000 リクエストの実業務ワークロードでは識別処理 1.51 秒に対し全体の実行時間が 919.54 秒で、約 0.16% にとどまる。同じ radix tree という道具が、オンラインでは退避ポリシー付きの動的キャッシュとして、オフラインでは事前最適化の入力として使われる。名前が同じでも機能が違う点は混同しやすい。 SGLang の radix tree は LRU と参照カウンタを持つが、BatchLLM の prefix tree は退避を持たない静的な計画立案の入力である。 ### 第 8 章　キャッシュ認識スケジューリングと公平性 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch08.png|900]] *図8　「キャッシュ認識スケジューリングと公平性」の概観* ヒット率を上げる順序と、利用者ごとの公平性や SLO 達成は同じ目的関数ではない。最長共有プレフィックス優先は平均で最適ヒット率の 96% に近づくが、SGLang の著者自身が starvation の可能性を今後の課題として残している(Source: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]])。この緊張への回答は systems ごとに分かれる。 Mooncake は推定 TTFT を単一の目的関数として一元的に解く(第 15 章)。 P/D-Serve はシナリオ単位のグループでプレフィックスの局所性を分離する(第 14 章)。 AIBrix は `prefix-cache-aware` と `least-kv-cache` などを別ポリシーとして並置し、統合最適化はしない(第 16 章)。 KVShare のスケジューラは別の角度から入る(Source: [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]])。到着リクエストのヒット率を計算してキューを降順にソートし、上位をバッチに送る。 TTFT はバッチ平均ヒット率に対して凹型の関係を示すため、高ヒット率優先が全体の TTFT を最小化する。 FCFS 比で最大 33.8% の TTFT 削減を得た。 BatchLLM はこの緊張そのものを回避する(Source: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]])。スケジューリング対象の集合が事前にすべて既知なら、ヒット率を上げる順序は推測ではなく計算の対象になる。同じプレフィックスを共有するリクエストを 1 つのグループにまとめ、リクエスト粒度ではなくグループ粒度でスケジューリングすることで、共有プレフィックスの KV メモリの生存期間を短縮する。グループの優先度は復号長と事前充填長の比 $R = L_{decode} / L_{prefill}$ を正規化した $R_{group} = 1 / (L_{prefix} + \sum L_{distinct})$ で定め、比の大きいグループを先に流す。実業務ワークロードでは実行中の KV スワップも再計算も発生せず、ピーク KV 使用率は約 50% にとどまった。もう 1 つの変更がバッチ構成の制約である。既存システムはリクエスト数の固定閾値でトークンバッチを制限するため、復号が支配的な反復では GPU メモリに余裕があってもバッチを広げられない。 BatchLLM はリクエスト数の制約を撤廃し、KV メモリ上限と固定チャンクサイズだけを制約にする。 KV キャッシュ容量そのものがバッチサイズの制御変数になる。ただし starvation が問題にならないのは、公平性を解いたからではない。個々のリクエストのレイテンシを目的関数から外したからである。著者自身、この設計はレイテンシ重視のワークロードには不向きであり、ストリーミングと一括処理を動的に切り替える構成は将来課題だと述べる。第 8 章のヒューリスティクスは情報が足りないなかでの最善であり、BatchLLM は情報が足りている場合の別解である。同じ問いへの 2 つの回答ではなく、問いの前提が違う。 > [!note] 倍率の条件依存 > BatchLLM の「vLLM と SGLang 比 1.3 倍から 10.8 倍」のうち 10.8 倍は共有プレフィックス長 16,000・共有度 16 という極端条件の値である。 > 実業務ワークロード(8,000 クエリ、共有プレフィックス平均約 1,570 トークン、共有度平均約 3)での実測は A100 で 1.30 倍、MI200 で 1.26 倍にとどまる。 > 共通プレフィックスが存在しない環境では、優位はトークンバッチングの改善分(約 3.8%)まで縮む。 --- ## 第 IV 部　完全一致を超える再利用 ### 第 9 章　プレフィックスでない位置の再利用 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch09.png|900]] *図9　「プレフィックスでない位置の再利用」の概観* RAG では検索された 2 番目以降のチャンクがプレフィックスにならないため、プレフィックスキャッシングの恩恵がほとんど得られない(Source: [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]])。チャンクを独立に事前計算して連結する方式(PromptCache)はチャンク間のクロスアテンションを完全に欠き、検索チャンク数が増えると品質が大きく落ちる。 **CacheBlend** はこの中間を取る。各レイヤーで **KV 偏差** $\Delta kv$ が大きいトークンだけを選んで再計算し、残りは事前計算値を再利用する。根拠は 2 つの観察である。 KV 偏差が大きいトークンを優先再計算すると、同じ計算量で最もアテンション偏差を減らせる。そしてあるレイヤーで偏差が高いトークンは次のレイヤーでも高い(連続レイヤー間で Spearman 相関が高い)。そこで最初のレイヤーでランク付けし、以降は前レイヤーの選択済みトークンから絞り込む漸次フィルタリングを行う。再計算比率は実用上 10% から 15% であり、計算量はこの比率に比例する。遅延の設計も巧妙である。 Llama-7B で 4K コンテキスト、15% 再計算のとき、1 レイヤーの再計算が 3 ms に対し NVMe SSD からのロードが 16 ms を要する。ロード遅延が再計算を完全に隠蔽するので、コントローラは「再計算遅延がロード遅延と等しくなる比率」と「品質保証の下限 15%」の大きい方を選ぶ。結果は TTFT を 2.2 倍から 3.3 倍削減し、品質損失は F1 と Rouge-L で最大 0.01 から 0.03 以内である。再計算比率 5% から 18% の範囲では損失は最大 0.002 以内にとどまる。 ### 第 10 章　スコア式の精緻化とデコード段への拡張 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch10.png|900]] *図10　「スコア式の精緻化とデコード段への拡張」の概観* **KVShare** は CacheBlend の 2 つの限界を突く(Source: [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]])。第 1 はトークン選択の基準である。 KV 再利用が出力へ伝播する経路をテイラー展開の一次近似で書くと、アテンション行列自体がヤコビアン($\partial H/\partial V = A$)として働く。つまり偏差の影響はアテンション重みに依存する。そこで **DHD** スコアは累積アテンション $\alpha$ と偏差の積 $\mathrm{Score} = \alpha \cdot \|\Delta V\|_1$ で上位 r% を選ぶ。偏差が大きく、かつアテンションが高いトークンを優先する点が、偏差の絶対値だけで選ぶ CacheBlend との差である。第 2 はデコード段である。 CacheBlend はプリフィル時の選択的再計算のみを扱うが、デコード中はアテンション分布が動的に変化してプリフィル時の重要度スコアが陳腐化する。 KVShare はこの**アテンション・ドリフト**を定式化し、各ステップで重要度を再評価する。デコードステップごとに 3 トークン程度の追加再計算でパープレキシティが大きく改善する。さらにチャンクマッチングを固定長からローリングハッシュによる可変長へ改め、リクエスト間の非連続な共通部分も捕捉する。チャンクサイズが小さいほどヒット率は上がるが選択アルゴリズムの精度は下がるため、一律の最適値は存在しない。精度はプリフィルのみの再計算で CacheBlend 比平均 9.48% 向上、両段の再計算で SOTA 比平均 20.38% 向上である。代償は明示されている。デコードステップごとの追加再計算により **TPOT が約 2 倍に増加**する。 ### 第 11 章　コンテキストレベルへの遡上 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch11.png|900]] *図11　「コンテキストレベルへの遡上」の概観* **ContextPilot** は問題を一段上流へ動かす(Source: [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]])。再利用の機会は KV 値のレベルではなくコンテキスト(検索文書やメモリ)のレベルに現れるという主張である。前提となる観察は実ワークロードの重複である。 MultihopRAG では質問の 79.2% が上位 20% の頻出文書から来ており、MT-RAG ではターンあたり平均 40% が既出文書と重複する。にもかかわらず完全一致方式の実測ヒット率は極端に低い。 MultihopRAG と Qwen3-32B の組で **4.6%**、NarrativeQA と Llama3.3-70B で 5.5% である。手法は 3 つからなる。コンテキスト距離関数で階層的クラスタリング木を作り、既存のプレフィックスキャッシュと共有部分が先頭に来るようコンテキストを**整列**する。整列だけでは精度が 0.1% から 3.3% 落ちるので、質問の直前に優先順位を伝える**注釈**を挿入して回復させる。さらに再取得された文書を位置注釈へ置き換える**重複排除**を行う。総オーバーヘッドは 1 リクエストあたり約 0.7 ms である。この設計が成り立つ前提は、現代のモデルが入力順序に鈍感になったことである。順序感度研究を再現すると、GPT-3.5 では 82.9 から 83.0、GPT-5.1 では 86.9 から 86.7 で、順序による差はほぼ消えている。モデル世代の交代がもたらした副次的性質を、システム設計者がキャッシュ最適化に転用した例と言える。逆に言えば、この前提が崩れれば整列戦略自体が成立しない。効果はヒット率の改善として最も明瞭である。 SGLang と Qwen3-32B で 8.49% が整列後 20.56%、スケジューリング後 33.97% へ上がった。 DeepSeek-R1(671B)では MultihopRAG のヒット率が 5% から 60% へ改善した。 ### 第 12 章　近似再利用の精度をめぐる不一致 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch12.png|900]] *図12　「近似再利用の精度をめぐる不一致」の概観* 同じ CacheBlend の精度について、3 つのソースが 3 通りの結果を報告している。本書で最も注意を要する箇所であり、どれか 1 つを正解として採ることはできない。 > [!contradiction] CacheBlend の精度劣化 > 原論文は品質損失を F1 と Rouge-L で最大 0.01 から 0.03 と報告する(Source: [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]])。 > ContextPilot は同種の近似 KV マッチングで F1 が 9% から 11% 劣化し(約 60% から約 50% へ)、NarrativeQA と Qwen3-4B の組では 34.8 から 11.3 へ急落したと報告する(Source: [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]])。 > SCBench は第三の測定として、マルチターン平均 49.3(フルアテンション 48.7 を上回る)、マルチリクエスト平均 34.8(同 37.2 を下回る)という条件依存性を示す(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])。診断も食い違う。 KVShare は CacheBlend の欠点を固定長チャンクによるヒット率の低さというシステム側の問題として捉える。 ContextPilot は「KV 値の浮動小数点類似度は再利用可否の信頼できる指標ではない」という原理的な問題として捉える。評価条件の違いが説明の候補になる。再計算比率、チャンクサイズ、比較対象のベースライン設定がいずれも異なるため、数値を並置して比較することはできない。 CacheBlend の下限値 15% はモデルごとのオフラインプロファイリングを前提としており、かつプリフィルのみの評価である点も見落とせない。長い生成を伴う条件での妥当性は検証されていない。デコード段の偏差については、KVShare と SCBench が独立に同種の現象を同定している。 KVShare がアテンション・ドリフトと呼ぶものを、SCBench はアテンション分布シフト(分布外化)として報告し、O(n) メモリを保つ RetrievalAttention でも劣化が起きるとする。現象の存在は 2 ソースで裏づけられていると見てよい。 --- ## 第 V 部　階層化と退避 ### 第 13 章　GPU の外へ ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch13.png|900]] *図13　「GPU の外へ」の概観* 保存する KV キャッシュの総量は、時間とともに GPU メモリ容量を大きく上回っていく(Source: [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]])。そこで GPU、CPU、SSD、リモートストレージ、オブジェクトストレージを階層として扱う層が必要になる。 **LMCache** は推論エンジンの内側ではなく外側の層として置かれる(Source: [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]])。コネクタ層がエンジンから KV のメタデータと GPU アドレスを取得することで、エンジンの進化から独立を保つ。制御 API として pinning、lookup、cleanup、movement、compression を提供する。 GPU の外で KV を扱う必要が生じる場面は、CPU 退避、プレフィックスキャッシング、PD 分離の 3 形態に整理できる(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]])。計算と入出力の重畳が要になる。レイヤ単位のパイプライン、別 CUDA ストリーム、キュー待ち時間を使った先読みで KV の読み込みを推論計算に重ねる。効果は vLLM との組み合わせで最大 15 倍のスループット改善である。設計の置き場所には分岐がある。 LMCache が推論エンジンの外側に層を置いてエンジンの進化から独立を保つのに対し、エンジンの内側で KV キャッシュのメモリレイアウト自体を書き換える侵襲的な設計もある(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]])。同じ「GPU の外へ出す」目的でも、独立性を取るか性能を取るかで実装の位置が変わる。後者の帰結は第 14 章で扱う。先読みが効く階層化と、効きにくい階層化があることも押さえておきたい。本章の重畳は、実行していないリクエストの KV をどこに退避しておくかという問題であり、転送の契機はスケジューラが握っている。だからキュー待ち時間を先読みに使える。これに対し、各復号ステップで必要な KV エントリが top-k 選択の結果として初めて判明する設計では、転送はミスの事後処理になる(Source: [[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory]])。取得レイテンシはクリティカルパス上に残り、著者らも重畳の改善を未解決の課題として挙げる。この形の階層化は第 22 章で扱う。 ### 第 14 章　二重粒度という構造的制約 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch14.png|900]] *図14　「二重粒度という構造的制約」の概観* GPU 内で最適なページ粒度は、ネットワークやストレージの転送では小さすぎる。この不一致は 3 つのソースで独立に現れる、本書で最も再現性の高い知見である。 vLLM の 16 トークンページは内部断片化を抑えるが、LMCache はこの単位では帯域を使い切れないため既定 256 トークン程度のチャンクにまとめる(Source: [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]])。 P/D-Serve も、PagedAttention の離散ブロックを RDMA で 1 個ずつ送ると制御オーバーヘッドで帯域を使い切れないと報告し、送信側で連続バッファにまとめ受信側で RecvScatter により復元する **block-free 転送**を採る(Source: [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]])。これだけで平均転送時間が 46% 減った。つまり KV キャッシュ管理は、GPU 内のページと外部転送のチャンクという二重の粒度を持つ。 GPU 内で有利な設計判断はクラスタ全体のデータ移動へ一般化できない(Source: [[PagedAttention]])。粒度の不一致は、GPU の外へ出る経路のすべてに現れる。 GPU と CPU を NVLink-C2C(公称 900 GB/s、PCIe の 14 倍から 28 倍)で直結した GH200 でも同じ問題が起きる(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]])。 PagedAttention のブロックは同一レイヤーかつ同一ブロック内しか連続でないため、Qwen2.5-32B(64 層、16 トークン/ブロック)ではセグメントが 64 KB にとどまる。 C2C が高帯域を発揮するのは 8 MB 以上であり、4 MB 以下ではカーネル起動時間が転送時間を上回る。結果として、既存のサービングシステムをそのまま移植すると C2C 帯域の 5% 未満しか使えない。 **密結合になるほど、要求される粒度は大きくなる**。 PCIe 時代の LMCache は 256 トークン程度のチャンクで足りたが、C2C は 8 MB 級を要求する。帯域を増やせばオフロードが楽になるという直観とは逆向きである。対処の方向も、本章で見た 2 例と逆になる。 LMCache と P/D-Serve は転送時に小片をまとめる。 SuperInfer は KV キャッシュのメモリレイアウトを layer-first から block-first へ変え、1 ブロック内の全レイヤーを連続領域に置くことで、セグメントを 64 KB から 4 MB へ拡大する。さらに個々の `cudaMemcpyAsync` を 1 方向あたり 1 回の `cudaMemcpyBatchAsync` に統合し、カーネル起動のオーバーヘッドを実質的に排除する。 16 GB の双方向転送で、素朴な実装の 1,556.15 ミリ秒に対し 46.80 ミリ秒であり、理想値 41.66 ミリ秒の 94% に達する。つまり粒度の不一致には、転送側で吸収する解と、発生源のレイアウトで解消する解の 2 つがある。後者が成立するなら「二重粒度は構造的制約である」という本章の主張は弱まるが、block-first レイアウトが GPU 内の注意計算や断片化に与える影響は原典で測定されていない。この論点は未決である。 > [!note] C2C の公称帯域と実測の理想上限 > 同じ資料に 900 GB/s と 192 GB/s(片方向の理想値)という 2 つの数値が現れる。 > 前者は相互接続の公称値、後者は転送マイクロベンチマークの理想上限であり、差の理由は資料内で説明されていない。 > 混同して引用してはならない。 ### 第 15 章　転送の抽象化 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch15.png|900]] *図15　「転送の抽象化」の概観* 異種のネットワークとストレージを同じ意味論で扱うには抽象が必要になる。 **NIXL** は North-Bound API と South-Bound Backend API の間に Transfer Agent を置き、UCX、GDS、POSIX、OBJ、HF3FS などのバックエンドを接続する(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]])。 Memory Section は `mem_type`、`addr`、`len`、`devID`、`info` の記述子リストで DRAM、VRAM、BLK、FILE、OBJ を対称に管理する。ここから見えるのは、KV キャッシュ管理が「どの大きさで送るか」だけの問題ではないことである。どのメモリ空間をどの識別子で登録し、どの制御プレーンで相手に知らせるかも管理の一部になる。 UCX を使う例では、両ノードがそれぞれ agent と backend を作って GPU バッファを登録し、対象ノードのメタデータと受信バッファリストを開始側へ渡してから、複数の転送要求を非同期に投稿する。階層化の効果は入力が長いほど大きい。 Qwen3-235B を 8 基の H100 と VAST Storage で動かした例では、ISL が 224K 付近のとき再計算の TTFT が約 36 秒に対しストレージ取得は約 4 秒弱である[^slidenum]。 [^slidenum]: この 2 値は資料の図から読み取れる範囲の概数であり、正確な測定表は資料内にない。 --- ## 第 VI 部　クラスタ規模の管理 ### 第 16 章　Prefill-Decode 分離 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch16.png|900]] *図16　「Prefill-Decode 分離」の概観* 第 2 章で見た資源特性の衝突を、実行場所の分離で解く。 **DistServe** はプリフィルとデコードを別 GPU に置き、per-GPU の goodput(TTFT と TPOT の両 SLO を 90% 超のリクエストで満たす率)を最大化する(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]])。効果は vLLM 比で 2.0 倍から 4.6 倍のリクエストレート、条件次第で 12.6 倍厳しい SLO の達成である。分離の代償は KV キャッシュの転送である。ここで 2 つのソースが正反対の見立てを示す。 > [!contradiction] KV 転送コストは無視できるか > DistServe は OPT-175B でも KV 転送が総レイテンシの 0.1% 未満、95% 超のリクエストで 30 ms 未満だと報告する(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]])。 > P/D-Serve は数万 NPU 規模で転送時間の削減自体を主要な貢献として掲げる(Source: [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]])。 > 矛盾ではなく、配置の違いである。 > DistServe は低帯域クラスタでは同じパイプライン段階のセグメントを同一ノードへ置き NVLink 経由で転送する設計を採るため、転送が無視できる条件を自ら作っている。 > モデル規模、入力長、ネットワーク配置によって、KV 転送は無視できるものにも律速にもなる(Source: [[Prefill-Decode分離]])。 > > 第 3 の証言が、この対立を解析的に整理する(Source: [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]])。 > 転送帯域の要件は式で与えられる。プリフィル側の出方向は KV サイズを FTL(初トークンまでの時間)で割った値、デコード側の入方向は KV サイズを TTL × OSL で割った値である。 > 分母に SLA が入る以上、転送が無視できるかどうかは帯域の絶対量ではなく **SLA の厳しさ**で決まる。 > そして入力長は直観と逆に働く。プリフィルの注意計算は入力長の二乗で増えるのに対し KV キャッシュは線形にしか増えないため、**入力が長いほど GPU あたりの出方向帯域要件は下がる**。 > DeepSeek-R1 の試算では、入力 16k・出力 2k で約 1.2 GB/s/GPU から約 0.4 GB/s/GPU へ低下し、入力 1M・出力 2k でも約 0.65 GB/s/GPU 付近で底を打つ。既存のデータセンター帯域で吸収できるという結論である。 > ただしこれは KV キャッシュを層ごとに生成と同時に転送し、プリフィル計算と重ねる実装を前提とした値である。また TTL を締めていくと入方向が再上昇する。 > つまり DistServe の「無視できる」は配置と実装の前提を満たした結果であり、P/D-Serve の「削減が主要貢献」はその前提が成り立たない規模と配置の証言である。 > 数値を引くときは、SLA・入出力長・重畳の有無を必ず併記する。小規模でも分離が効く実測もある。 GPU 合計 4 枚を揃えた比較で、入力 8k と出力 1k、32 同時接続のとき、同居構成は ITL の P99 を 100 ms 以内に収められないが、PD 分離は 30 ms 以内に収める(Source: [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]])。 SLO にテイルレイテンシを含め、長い入力が継続的に発生する環境なら、サーバー 1 台規模でも分離が選択肢になる。この観測は条件に合致している。数十万の設計点を掃いた評価によれば、分離の恩恵が最大化されるのは入力長が出力長を大きく上回るプリフィル主体のトラフィックと、10B パラメータ超の大規模モデルである(Source: [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]])。入力 8k・出力 1k はまさにプリフィル主体である。逆に出力が入力を大きく上回る生成主体のトラフィックでは、同居にチャンク化プリフィルを重ねた構成が競争力を保つ。 DeepSeek-R1 では入力 16,384・出力 2,048 で分離が明確に上回る一方、入力 1,024・出力 32,768 では同居が競争力を持つ。ここで「小規模では分離が効かない」と読み替えてはならない。 Llama-3.1 の 8B・70B・405B はいずれも分離が同居を上回っており、規模とともに拡大するのは差の**大きさ**である。適用条件はもう 1 段細かい。このトレードオフの向きは注意機構によっても変わる。潜在表現に圧縮する MLA では、チャンク化プリフィルのたびに射影計算の重複が生じるため同居側の不利が大きく、GQA ではその不利が小さい。分離するかどうかは、クラスタ構成の問題であると同時にモデルアーキテクチャの問題でもある。もう 1 つの軸が SLO の厳格さである。月間 10 億人規模の Llama 本番運用の構成探索では、厳格な SLO を持つオンライン推論で分離が継続的バッチング比 70B で 1.5 倍から 1.8 倍、405B で 1.8 倍から 2.2 倍の QPS を達成する(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]])。ところがレイテンシ非制約のオフライン生成では両者の差がほぼ消え、深いパイプライン並列と大バッチという同一の構成へ収束する。 70B のある GPU 構成では継続的バッチングがわずかに分離を上回る場合すらあった。利得の源泉の分解が、本書の主題に直接つながる。分離の QPS 優位は、プリフィルとデコードの並列化を独立に最適化できることと、TTIT を犠牲にせず大きなデコードバッチを取れることの 2 要因に分かれる。後者は数値で示されており、70B のある構成でデコードバッチサイズが分離 112 に対し継続的バッチング 28 である。第 3 章の容量式はバッチサイズに線形なので、これは **KV キャッシュ容量を積極的に使い切れる構成が取れること**が分離の利得だという読み方になる。実運用では、オンラインサービスの大半を分離ランタイムへ移行して約 30% の容量削減を得たと報告されている。分離を選んだ後にも決めることが残る。プリフィルとデコードのアクセラレータ比は構成依存で大きく動き、同一 GPU 種の組で 0.88、別種の組で 3.14 という差が出る(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]])。固定比率では Pareto 最適に届かない。比率 3.5 対 1 の固定構成は緩いレイテンシ目標で高性能だが厳しい TTL で大きく劣化し、比率 0.5 対 1 はその逆になる(Source: [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]])。動的なレートマッチングは、FTL の SLA を満たすプリフィル構成のうち GPU あたりスループットが最大のものを選び、デコード構成とのスループット比を整数に丸めて配分を決める 2 段の手続きとして定式化されている。本書の構成上とくに重要なのは、この最適比率が**再利用最適化の導入によって動く**ことである。プレフィックスキャッシュはプリフィル側の GPU を減らす方向へ、投機的復号はデコード側の GPU を減らす方向へ最適比率を押す。第 III 部と第 IV 部で扱った再利用の最適化は、第 VI 部の資源配分と独立ではない。分離の対象は KV キャッシュに限らない。 DeepSeek を 96 基の H100 で動かした事例では、プリフィルサーバが Normal Dispatch、デコードサーバが Low-Latency Dispatch という異なる通信モードを使う(Source: [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]])。統一エンジンでは両立できない通信最適化を同時に実現する点で、分離は KV キャッシュ以外へも及ぶ。分離しない路線も残る。 Niyama は同一レプリカに同居させたまま QoS クラスを協調スケジューリングし、SOTA のサイロ構成比で GPU を 13% から 32% 削減した(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]])。 KV 転送コストを払うか、チャンクサイズ制御の複雑性を払うかというトレードオフの両極である。 ### 第 17 章　KVCache を独立プールにする ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch17.png|900]] *図17　「KVCache を独立プールにする」の概観* **Mooncake** は KVCache を Prefill と Decode に並ぶ第 3 のプールとして切り出す(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]])。 CPU DRAM を主記憶として位置づけ、GPU VRAM は使い終われば退避されるバッファとして扱う。この昇格によって、スケジューラは「どこのキャッシュを使うか」を中心的な目的関数にできる。 Conductor のプリフィルスケジューリングは、各インスタンスとのプレフィックス一致長を照合し、キュー待ち時間と実行時間から TTFT を推定して最小のインスタンスを選ぶ。ベスト一致との差が閾値を超えるならリモートから転送してでも最長プレフィックスのインスタンスで実行する。効果の分解が示唆的である。 8P+8D 構成で 2.3 万件を処理した平均 TTFT は、無作為 92.07 秒、負荷分散 60.41 秒、キャッシュ認識 14.36 秒、ホットスポット複製を含む KVCache 中心 6.26 秒である。負荷分散だけでは足りず、キャッシュ認識が支配的に効き、両者の統合が最良になる。ホットブロックの複製は精密な需要予測なしに達成される。「代替インスタンスへの転送コストが追加のプリフィル計算コストより小さいとき転送して保存する」という規則だけで、ホットブロックがルーティングの副作用として複製される。急成長する利用者数のもとで将来需要が予測できない事業者に固有の設計選択である。長いコンテキストへの対策として、入力を 1000 トークン超のチャンクに分けて複数ノードでパイプライン処理する Chunked Pipeline Parallelism を持つ。 Ring Attention による系列並列が層ごとに少なくとも 1 回の通信を要するのに対し、パイプライン段の境界だけで通信が済むため、KV 転送とのネットワーク競合が少ない。またプリフィルが層ごとの処理であることを使い、KV のロードと保存を各層の注意計算と非同期に重ねる。これにより VRAM には単一リクエスト分が収まればよくなる。 ### 第 18 章　過負荷制御と制御プレーン ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch18.png|900]] *図18　「過負荷制御と制御プレーン」の概観* 分離システムには非分離システムに存在しない失敗様式がある。プリフィル後にデコードが拒否すると、プリフィルの計算が丸ごと無駄になる。そこで到着時に両プールの負荷を予測して早期に拒否する。ところが単純に実装すると、プリフィルとデコードの間で逆位相の振動が生じる(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]])。負荷予測と実行の間の時間差が原因で、プリフィル満杯、デコード満杯、プリフィル閑散、デコード閑散のサイクルを描く。各リクエストのデコードが均一時間かかると仮定してシステムレベルで予測することで、拒否件数を 4,183 件から 3,589 件へ減らした。過負荷への応答方針はシステムごとに分岐する。 | システム | 方針 | 結果 | |---|---|---| | Mooncake | 予測に基づき入口で拒否 | 拒否 4,183 件から 3,589 件へ | | P/D-Serve | 拒否を再試行の合図として使い、ゲートウェイが他の空きへ回す | 成功率を最悪 57% から 99% 以上へ | | AIBrix | 拒否せず自動スケールで吸収 | ただし起動に 2 分から 3 分を要する | | SuperInfer | SLO 進捗に基づき能動的に CPU DRAM へ退避 | TTFT SLO 達成率を最大 74.7% 改善 | 最後の行は他の 3 つと層が違う。 Mooncake と P/D-Serve と AIBrix がクラスタ規模の入口制御と資源増減を扱うのに対し、単一ノードの内部でリクエストを回す設計である(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]])。既存システムのプリエンプションは受動的で、GPU メモリ需要が容量を超えたときだけ後着リクエストを止める。 SuperInfer は待機、実行、退避の 3 状態を能動的に遷移させ、GPU メモリに余裕があっても SLO 違反リスクが高いリクエストを先回りしてプリエンプトする。判断の入力は仮想遅れ時間(Virtual Lag Time)であり、OS のスレッドスケジューラ EEVDF の lag に着想を得ている。実行中は負、待機と退避は許容時間内なら 0、超過すると正に転じて増加する。各反復で、まず HBM に全リクエストの KV が載るなら FCFS へ戻し、載らないときだけ遅れの大きい順に並べて転送予算の範囲で優先実行対象を選び、不足分をリスト末尾から退避させる。第 25 章の退避優先度が再利用確率と空間局所性で決まるのに対し、ここでの優先度は SLO 進捗の遅れで決まる。「どのブロックを HBM に残すか」に対して、再利用性と SLO 切迫度という直交する 2 系統の優先度が独立に提案されている。 **AIBrix** はコントロールプレーンとデータプレーンの二層で、既存のクラウドエコシステム上に KV キャッシュ管理を載せる(Source: [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]])。ルーティングポリシーを `random`、`throughput`、`least-request`、`least-kv-cache`、`least-latency`、`prefix-cache-aware` の 6 種として並置し、スキャン耐性の退避ポリシーでホットな KV テンソルを選択的に永続化する。分散 KV キャッシュの効果は、プレフィックスキャッシュを有効にした vLLM 比でスループット 52% 向上、平均 TTFT 65% 削減、P99 TTFT 77% 削減である[^aibrix]。 [^aibrix]: [[KVキャッシュ管理]] は AIBrix について「Kubernetes CRD レベルで扱い」「低トラフィック条件で 4.7 倍のコスト削減」と記すが、いずれも wiki のソースページからは裏づけられない。ソースページが報告するのはコスト約 10% 削減(レイテンシ最大 20% 増、SLO 内)である。原論文で再確認するまで前者の数値は使わない。自動スケーリングが難しい理由も明示されている。 DCGM のメトリクスの制限により、KV キャッシュのメモリ圧迫のような GPU バウンドのパターンを QPS ベースのスケーラでは捉えられない。ルーティングポリシーの選択そのものが SLA の安定性を左右することも実測されている(Source: [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]])。 8 基の L40S 上で 8B モデルを入力 14K・出力 200、プレフィックス群 20 個で動かし、プレフィックス比率を 0.1 から 0.9 まで振ると、ラウンドロビンはキャッシュの断片化により FTL が不安定になる一方、キャッシュ認識ルータは比率 0.3 付近から一貫して低い FTL を保つ。比率 0.9 では約 1,160 ミリ秒に対し約 880 ミリ秒である。起動時間そのものを潰す路線もある。モデルの転送と推論の実行を協調設計し、モデル全体の到着を待たずに分散推論を開始する方式では、50 リクエストすべての処理開始までが 1.1 秒である(Source: [[@2026__MLSys2026__FaaScale - Unlocking Fast LLM Scaling for Serverless Inference]])。実トレースの再生で P90 の TTFT を 2.4 倍から 5 倍改善し、GPU コストを 17.8% から 31.3% 削減した。ただし前提条件は重い。 24 台の H800 と単一 400 Gb/s の InfiniBand、かつ RDMA でアクセスできるメモリ上に完全なレプリカが最低 1 つ存在することを要する。そして本書の主題から見て最も重要な点として、**この方式は KV キャッシュを運ばない**。スケール時に転送するのは中間活性化のみで、KV キャッシュのような動的な実行時状態は推論エンジン側の管理に残す。 KV キャッシュ再利用の機構との統合は自然にできると論じられているが、実装も評価もされていない。 > [!note] コールドスタート時間の桁が資料ごとに違う > 本章の AIBrix は 2 分から 3 分、第 32 章の PreServe は数十秒から数百秒、ここで挙げた例は 1.1 秒である。 > 測っている対象が違う可能性が高い。 > 最後の値はホストメモリ上のレプリカから高速ファブリックで台数を増やす操作であり、コンテナ起動を含む一般的なインスタンス立ち上げとは別物である。 > 1.1 秒を根拠に「反応的なオートスケーリングは機能する」と結論してはならない。 --- ## 第 VII 部　アーキテクチャによる削減 ### 第 19 章　K と V を共有する ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch19.png|900]] *図19　「K と V を共有する」の概観* 第 3 章の式のうちヘッド数を削るのが最も直接的である。 **Grouped-Query Attention** は複数のクエリヘッドのグループごとに 1 組の K と V を共有する(Source: [[Grouped-Query Attention]])。グループ数がヘッド数に等しいとき Multi-Head Attention、1 のとき Multi-Query Attention になり、KV キャッシュの削減は共有数に比例する。 MQA ほどの性能劣化がなく MHA と同等という釣り合いから、Llama 4、Gemma 3/4、Qwen3、Mistral、GPT-OSS など広く採用された。運用上の差も現れる。 MHA のモデルはトークンあたりの KV が大きく大容量のキャッシュを要するが、GQA のモデルでは GPU HBM の 4 倍程度のキャッシュ容量で理想ヒット率に近づく(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])。 ### 第 20 章　潜在表現に圧縮する ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch20.png|900]] *図20　「潜在表現に圧縮する」の概観* **Multi-Head Latent Attention** は K と V を低次元の潜在ベクトルに圧縮して保存し、推論時に元の次元へ戻す(Source: [[Multi-Head Latent Attention]])。 DeepSeek-V3 では圧縮次元 $d_c = 512$ に対しヘッド数 128、ヘッドあたり次元 128(積は 16,384)であり、キャッシュするのは潜在ベクトルと RoPE 用の分離キーのみである(Source: [[@2024__arXiv__DeepSeek-V3 Technical Report]])。 hidden_dim を 512 へ低ランク化した見積もりでは計算量が 3/8、KV キャッシュ容量が 1/8 になる(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]])。 GQA でなく MLA を選ぶ理由は削減率だけではない。 DeepSeek-V2 のアブレーションでは、GQA が MHA より性能を落とすのに対し MLA は MHA を上回る(Source: [[Multi-Head Latent Attention]])。それでも普及は DeepSeek 系と Kimi K2、GLM-5 などに限られており、実装の複雑さが釣り合いになっている。 KV キャッシュを分散配置する道もある。 **Decode Context Parallelism** は MLA の KV キャッシュを複数 GPU にシャーディングし、GPU あたりのメモリ負担を下げた分だけ実効コンテキスト長を伸ばす(Source: [[Decode Context Parallelism]])。対応の有無で同じ GPU 構成でも実効コンテキスト容量に最大 8 倍の差が生じたと報告されている。 ### 第 21 章　KV キャッシュを持たない道 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch21.png|900]] *図21　「KV キャッシュを持たない道」の概観* 線形注意は $\exp(\langle c_i, q\rangle)$ を有限次元の特徴マップで近似し、注意出力を固定次元ベクトル状態の再帰型ネットワークとして実装する(Source: [[線形注意]])。 KV の代わりに直前の隠れ状態を持つので、系列長に対して線形時間で動き KV キャッシュが不要になる。ただし代償は小さくない。純粋な状態空間モデルは正確な文字列検索でほぼ機能せず、SCBench の Retr.String では 0.0 から 3.9 にとどまる(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])。固定サイズの状態への圧縮は、高精度な記憶と本質的に相容れない。実装面でも、採択トークン数に応じて途中までの状態を破棄する投機的復号との相性が悪い(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]])。現実的な折衷が**ハイブリッドアテンション**である。フルアテンション層と効率的注意モジュールを交互に積み、1 対 1 から 1 対 3 程度の比率を採る(Source: [[ハイブリッドアテンションアーキテクチャ]])。長距離検索を担うのは主にフルアテンション層であり、効率的注意の受容野を 2048 に制限しても長コンテキスト性能への影響は軽微だが、フルアテンションを同様に制限すると大きく劣化する。この路線の評価は定まっていない。 MiniMax-M2 は Lightning Attention を廃止してフルアテンションへ回帰した(通常のプロンプトでは問題ないが推論とマルチターンで精度が落ちるため)。一方 Kimi Linear は Gated DeltaNet と MLA の 3 対 1 構成で 48B を実現している(Source: [[線形注意]])。第 3 の位置にあるのが**スパース注意**である(Source: [[スパース注意]], [[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory]])。線形注意が KV を持たず固定次元の状態に潰すのに対し、スパース注意は全 KV を持ったまま読み出しだけを疎にする。記憶の精度を落とさない代わりに、容量は減らない。本章の分類で言えば、線形注意が容量を諦めて精度を失う道、スパース注意が精度を保って容量を諦める道である。後者の容量問題をどう始末するかは第 22 章で扱う。なお DeepSeek Sparse Attention を用いる系統でハイブリッドモデルへの対応は進行中であり、まだ実装されていない。 --- ## 第 VIII 部　破棄と圧縮の限界 ### 第 22 章　4 段階の分類 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch22.png|900]] *図22　「4 段階の分類」の概観* KV キャッシュに関わる最適化は、どの段階に介入するかで整理できる(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])。 | 段階 | 処理内容 | 代表手法 | |---|---|---| | 生成 | プリフィルの注意計算を効率化 | 疎アテンション(A-shape、Tri-shape、MInference)、SSM、プロンプト圧縮 | | 圧縮 | 復号前に KV を刈り込むか量子化する | StreamingLLM、SnapKV、PyramidKV、KIVI | | 検索 | プレフィックスに基づき既存キャッシュを再利用 | CacheBlend | | ローディング | 各復号ステップで KV の一部だけ動的にロード | Quest、RetrievalAttention | 圧縮系の代表的な数値としては、KIVI がチューニング不要の 2 ビット量子化でピークメモリを 2.6 倍削減し、H₂O が退避を動的劣モジュラ問題として定式化し、StreamingLLM がアテンションシンクとスライディングウィンドウで一定メモリの無限系列長を実現する(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey]])。ただしこの記述は「削減できる」で止まっており、精度の代償に触れていない。 KIVI 系の均一 2 ビット量子化は、推論系のタスクで大きく崩れる。 Qwen3-8B では 4 ビットから 2 ビットへ落とすと GSM8K が 5.66 ポイント、MATH-Algebra が 40.97 ポイント低下する(Source: [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]])。 4 ビットならほぼ保てるのに 2 ビットで壊れるという段差がある。診断は Key キャッシュのチャネル間にある量子化感度の偏りである。一部のチャネルは恒常的に高いマグニチュードを持ち、その感度パターンはクエリヘッドやレイヤーを問わず一貫している。そこを 2 ビットに潰すとアテンションスコアの誤差が支配的になる。 Kitty はチャネルごとのトークン方向の平均マグニチュードで上位 12.5% から 25% だけを INT4 へ昇格させる。この 1 手で Qwen3-8B の平均精度は 61.39 から 76.18 へ回復し、FP16 の 77.15 との差は 0.97 ポイントに縮む。注目すべきは介入の粒度である。 StreamingLLM や SnapKV が「どのトークンを捨てるか」を問うのに対し、Kitty は「どのチャネルを厚く持つか」を問う。トークン単位で外れ値を高精度保持する KVQuant 系とも直交する軸であり、両者の併用効果は未検証のまま残る。システム側の工夫も第 II 部の主題と呼応する。混合精度のページを扱うと逆量子化が不揃いになるため、全チャネルの下位 2 ビットを持つ密なテンソルと、昇格チャネルの上位 2 ビットだけを持つ疎なテンソルに分解し、読み出しを一様に処理する。量子化グループ 128 トークンを 1 ページとして PagedAttention と互換に保つ。重い量子化処理は 128 ステップに 1 回へ償却され、1 ステップあたりのオーバーヘッドは 0.17% になる。同一メモリ予算下で最大 8 倍のバッチサイズ、FP16 比 2.1 倍から 4.1 倍のスループットである。 > [!note] 圧縮率という語が指すもの > 本章と第 23 章には 3 系統の数値が混在する。 > サーベイの「2.6 倍」はプロセス全体のピークメモリ、SCBench 表の「1/8」は KV の理論圧縮率、Kitty の「約 8 倍」と「実効 2.44 ビットで 6.6 倍」は KV メモリである。 > Kitty の論文内部でも要約の 8 倍と実効ビット幅由来の 6.6 倍が併存し、その調停は明示されていない。 > 同じ表に並べてはならない。表のローディング段には別の副作用がある。この段の手法はフルコンテキストの KV を保持したまま、各復号ステップで一部だけを動的に読む。精度の観点では有利だが(第 23 章)、読み出しが疎でも保持は密なので **KV キャッシュのフットプリントは縮まない**。本番サービングでは、この性質がそのまま容量律速として現れる。スパース注意を有効にしたベースラインのスループットは、GLM-5.1-FP8 を 8 基の H200 で入力 32k・出力 8k で動かすと、並行数 32 付近の約 780 トークン/秒で頭打ちになる(Source: [[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory]])。計算が足りないのではなく、フルコンテキストの KV が HBM を埋め尽くしてバッチが組めない。 HiSparse の処方は圧縮でも破棄でもなく、配置の変更である。フルコンテキストの KV をホスト DRAM に置き、GPU HBM 上には頻繁にアクセスされる領域だけを持つホットバッファを維持する。専用の CUDA カーネルが、各ステップの top-k 選択に対してバッファ上のミスを特定し、LRU で退避候補を選び、ページテーブルを更新してホストからエントリを取得する。同じ条件で並行数 256 まで線形に伸び、約 2,650 トークン/秒に達する。 2 基の H20 の PD 分離構成では、入力 60k・出力 20k で 352 トークン/秒から 1,720 トークン/秒へ改善する。つまりローディング段の手法は、第 V 部の階層化と組み合わせて初めて容量上の利点を得る。読み出しを疎にする判断と、保持する場所を選ぶ判断は独立に設計でき、後者がなければ前者の利益は容量の壁に吸収される。適用条件つきである点も押さえたい。並行数 8 から 32 の低並行領域では、追加の入出力がメモリ節約の効果を上回ってベースラインを下回りうる。第 13 章の階層化が一方向の改善を報告するのとは性格が違う。 > [!note] LRU の評価が章によって逆になる > 第 25 章は本番トレースに基づき「LRU は再利用確率の空間的な偏りを捉えられない」とし、より精緻な優先度がヒット率を 8.1% から 23.9% 改善すると述べる。 > ここでは LRU が FIFO や乱択より一貫してミスが少ないと報告されている。 > 矛盾ではなく、時間の粒度が違う。 > 前者はリクエスト間のブロック再利用、後者は単一の復号中における top-k アクセスの局所性である。 > 「LRU は不十分」という記述をそのまま一般化してはならない。 ### 第 23 章　マルチターンで露見する破綻 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch23.png|900]] *図23　「マルチターンで露見する破綻」の概観* SCBench の貢献は、共有コンテキストを前提にした評価でこれらの手法を並べたことである。 931 のマルチターンセッションと 4,853 クエリ、平均入力長 227K トークンという規模で測ると、単一リクエストの評価では見えなかった差が現れる。 Llama-3.1-8B での平均スコアを抜粋する(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])。 | 手法 | 圧縮率 | マルチターン | マルチリクエスト | |---|---|---|---| | FullAttention | 1 | 48.7 | 37.2 | | MInference | 1/32 | 42.5 | 36.4 | | Tri-shape | 1/32 | 30.3 | 25.9 | | StreamingLLM | 1/32 | 15.5 | 14.5 | | SnapKV | 1/32 | 20.9 | 15.2 | | KIVI | 1/8 | 32.0 | 24.8 | sub-O(n) メモリの手法は圧縮率 1/4 で急激に劣化する。 StreamingLLM と SnapKV はそれぞれ 26 ポイントと 19 ポイント落ち、KV 破棄系はリクエストが増えるほど急落して第 2 リクエスト以降でほぼゼロになる場合すらある。一方 O(n) メモリを保つ手法は高圧縮率でも比較的安定する。より深い観察は符号化と復号の非対称性である。疎な符号化と密な復号(O(n) メモリ)を採る A-shape と Tri-shape は、リクエストが増えるほど精度が向上する。密な符号化と疎な復号(sub-O(n) メモリ)を採る StreamingLLM 系は大幅に劣化する。復号が生成の因果接続に本質的な役割を担うため、疎な復号は複雑な注意関数の形成を制約する。したがって KV キャッシュ管理は「保持するか破棄するか」の 2 値判断ではない。どのフェーズでどの粒度を保つかを設計する問題である。動的な疎性が静的なパターンより一貫して優れることも示された。 MInference は 1/32 の予算で A-shape の 1/4 予算に相当する性能を出す。圧縮可能性はタスクに依存する。 NIAH の反復ノイズや要約は高い圧縮に耐えるが、ランダムなキー値対の検索や前後一致検索は本質的に圧縮できず厳密な O(n) を要する。単一ターンの評価、とくに NIAH は、モデルの能力を過大評価してきた可能性がある。ところが量子化系の評価は現在も単一ターンが主流である。第 22 章で見た Kitty は、Qwen3 と LLaMA3 の 5 モデル・7 タスクで 2 ビット量子化の精度を FP16 との差 1 ポイント以内まで戻したが、評価は思考連鎖を伴う単一ターンの推論タスクであり、長文脈といっても最大生成長 32,768 トークンという**出力方向**の長さを指す(Source: [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]])。上の表の KIVI の値が Kitty で改善するかは検証されていない。分類の上では、KIVI も Kitty も O(n) メモリを保つ手法である。捨てずに精度を落として全部持つので、本章が示した sub-O(n) の破綻とは別の系統に属する。とはいえ「O(n) 側だから安全」と言い切れる根拠もない。量子化の精度回復とマルチターンの破綻は、いまのところ別々に報告されているだけである。 --- ## 第 IX 部　本番ワークロード ### 第 24 章　実トレースが崩す前提 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch24.png|900]] *図24　「実トレースが崩す前提」の概観* ここまでの設計判断の多くは、合成ワークロードでの評価に依拠している。大規模クラウド事業者の本番トレースを分析すると、いくつかの前提が崩れる(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])。理想キャッシュヒット率は消費者向けで 62%、事業者向け API で 54% であり、合成ワークロードで報告される 80% 超を大きく下回る。 Mooncake が実運用で報告する約 50% とも整合する(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]])。さらに強い反証がマルチターンの位置づけである。事業者向けワークロードでは KV 再利用の **97% がシングルターンのリクエストに起因**し、マルチターンのターン数は中位値が 1 である。マルチターンが再利用を支配するという通説は、少なくともこの環境では成立しない。 > [!contradiction] ベンチマーク設計と本番実測のずれ > SCBench は実世界のパターンをマルチターンとマルチリクエストの 2 モードと捉えてベンチマークを設計する(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])。 > 本番トレースは事業者向けでシングルターンが支配的だと報告する(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])。 > 評価の前提そのものが食い違っている。寿命も短い。 KV ブロックの寿命は消費者向けトレースで P90 が 612 秒、事業者向けで P99 が 97 秒である。再利用までの時間は、消費者向けで 80% が 10 分未満、事業者向けで 80% が 10 秒未満に収まる。ヒットは偏在し、消費者向けでは上位 19% の利用者が 90% 以上のヒットを生む。 > [!note] ヒット率という語の二義性 > 「理想(オラクル)ヒット率」と実測ヒット率は桁が違う。 > 前者は 54% から 62%(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])、後者は RAG やエージェントの条件で 4.6% から 10.7%(Source: [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]])である。 > ワークロードも対話系と RAG 系で異なるため、同じ語で並置してはならない。 ### 第 25 章　ワークロード対応の退避 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch25.png|900]] *図25　「ワークロード対応の退避」の概観* 寿命が短いという事実は、退避ポリシーの設計に直結する。過去に高頻度でアクセスされたことは将来の再利用を示唆しないので、LFU 型の頻度情報はノイズを蓄積して死んだブロックでキャッシュを汚染する。 LRU も再利用確率の空間的な偏りを捉えられない。そこで優先度を次の辞書式順序で定める(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])。 ``` Priority = (ReuseProb_w(t, life), -Offset) ``` 第 1 要素は、リクエスト種別とターン数でカテゴリ分けし、カテゴリごとに直近の再利用ログへ指数分布を当てて求めた再利用確率である。ブロックの予想寿命を考慮して、短命なブロックが長時間高優先度を保たないよう調整する。第 2 要素は空間局所性であり、プレフィックスの先頭に近いブロックを優先する。計算量は素朴には O(N) だが、指数分布の単調性からワークロード内ではブロックが最終アクセス時刻でソート済みと見なせるため、ワークロードごとの優先度キューを持てば O(W)(W は典型的に数十)で済む。実測のポリシー遅延は退避 1 回あたり 79 マイクロ秒で、vLLM のスケジューリングオーバーヘッドの 1.2% にとどまる。効果は LRU と LFU 比でヒット率 8.1% から 23.9% 向上、QTTFT 削減 28.3% から 41.9% である。 ### 第 26 章　導入の判断とコスト ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch26.png|900]] *図26　「導入の判断とコスト」の概観* KV キャッシュ再利用はワークロードの規模にかかわらず有効だが、ストレージと高速ネットワークのコストを負う(Source: [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]])。コストメリットを出すには一定以上の利用者ワークロードを受け入れる環境が望ましい。判断の順序も示されている。まず利用者体験を反映する SLO を定義し、継続計測に基づいて GPU の増減、同居から分離への構成変更、プリフィルとデコードの資源配分、KV キャッシュストレージの導入を検討する。 KV キャッシュストレージの導入が、他の構成変更と並ぶ計測駆動の運用判断として置かれている点が実務的である。同じ資料は未解決の観察も率直に残す。 8k 入力がほぼ全てキャッシュヒットする条件でも、KV キャッシュの読み込み時間が TTFT の約 1/4 を占める。原因は特定されていない。この判断順序は事後の計測に駆動される。これと補い合うのが、事前の構成探索である(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]], [[LLM推論設計空間探索]])。手動の判断が破綻する規模は定量化されている。ランタイム構成だけで約 1,000 通り、5 次元の並列化(TP・PP・EP・CP・DP)だけで約 1,000 通りあり、総組合せはしばしば 100 万を超える。 KV キャッシュのポリシーはこの構成ベクトルの 1 次元として置かれ、探索空間の刈り込みでは「メモリ容量の制約に違反する構成を早期に破棄する」が第 1 段のフィルタになる。解析モデルでは足りない理由も示されている。 LLM の演算子の種類は数十程度に限られるため、ハードウェアあたり 10 万件超のマイクロベンチマークから演算子性能モデルを作り、多次元の区分線形補間で埋めるほうが精度が高い。実機との誤差は ±5% 以内で、シミュレーションは数分で回る。 > [!warning] 事前探索で決められない部分が残る > この ±5% は中央値と平均値に対する精度であり、ネットワークジッタ等に由来する P99 のテールは主眼でないと原典が明記している。 > ところが第 16 章と本章はいずれも P99 の ITL を判断基準に使っている。 > 事前探索で初期構成を絞り、テールの検証は実測に戻すという二段構えが要る。 > なおこのシミュレータは非公開であり、他組織が同等の演算子ベンチマークデータベースを構築する費用は原典から読み取れない。構成を変えること自体のコストにも差がある。品質分布や負荷水準や資源の可用性が変わった場合は約 30 秒の再スケジューリングで済み、切り替えはローリングアップデートで無停止に行える(Source: [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]])。これに対し**リクエスト長の分布が変わった場合だけ**は性能データベースの再構築を要し、24.5 分(32 スレッド並列で 54 秒)かかる。 KV キャッシュ管理の文脈で言えば、入出力長の分布の変化が最も再設計コストの高い事象である。 --- ## 第 X 部　耐障害性 ### 第 27 章　失われる状態としての KV キャッシュ ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch27.png|900]] *図27　「失われる状態としての KV キャッシュ」の概観* ここまで KV キャッシュは性能最適化の対象だった。 GPU 障害の観点から見ると、これは障害で失われるリクエストごとの動的状態である(Source: [[@2025__arXiv__FailSafe - High-performance Resilient Serving]])。障害が生む負担は 2 種に分かれる。 KV キャッシュ喪失によるプリフィル全面再計算というレイテンシスパイクと、障害後も残り続ける計算とメモリの不均衡である。後者はテンソル並列のアテンション層がヘッド数という離散的な粒度でしか分割できないために生じ、復旧が完了しても次に GPU が補充されるまで持続する(Source: [[耐障害LLMサービング]])。訓練ジョブが完全な GPU 数で再起動するのに対し、サービングは不規則な GPU 数のまま稼働し続けるため、この区別が要る。対策は 3 つある。 **Cyclic KVCache Placement** はアテンションヘッドと対応する KV ブロックを層ごとに周期的に割り当て、層数が並列度を大きく上回るという性質を使って偏りを均す。 KV メモリ利用が約 50% 改善し、副作用として復旧時の PCIe 転送帯域も均衡する。 **Hybrid Attention** は各ワーカーに同数のヘッドを割り当て、余りをデータ並列で処理する。 **Proactive KVCache Backup** は稼働中に非同期でホストメモリへバックアップし続ける。根拠は「GPU サーバーの CPU メモリは HBM より大容量で、GPU 障害でも無傷である」という物理的性質である。復旧レイテンシの改善は劇的である。 | 方式 | レイテンシ | 高速化 | |---|---|---| | 再計算 | 22 秒 | 1.00 倍 | | ホストメモリから復旧 | 530 ミリ秒 | 41.5 倍 | | 重み復旧も併用 | 120 ミリ秒 | 183 倍 | ここで注目すべきは、第 V 部で見た「ホストメモリへの退避」という同じ物理設計が、通常運用では再利用のヒット率向上、異常時には復旧レイテンシ削減という別の目的で二重に使われることである。 KV キャッシュの配置問題は「どこにあれば速く引けるか」に加えて「どこにあれば障害後も均等か」という第 2 の軸を持つ。寄与の分解には非対称性がある(Source: [[@2025__arXiv__FailSafe - High-performance Resilient Serving]])。プリフィルでは計算の均衡化が支配的でメモリ配置の効果は僅少だが、デコードではメモリ均衡化が 1.29 倍、計算均衡化を加えて 1.63 倍になる。 **KV キャッシュ配置の均等化が効くのはデコード段に限られる**。第 2 章で見たプリフィルが計算バウンド、デコードがメモリバウンドという性質の直接の帰結である。 ### 第 28 章　配置構造が動く場合の移行 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch28.png|900]] *図28　「配置構造が動く場合の移行」の概観* これまでの KV 移動は「同じ層を別の場所へ複製する」操作だった。パイプライン並列で層のステージ割当が実行時に変わる場合、「担当が変わった層の KV キャッシュを新しい担当へ引き渡す」という性質の異なる操作が生じる(Source: [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]])。 DynaPipe はこれを非同期に行う。ソースステージは対象層の計算完了後に非同期送信し、ターゲットステージは影響を受けない層の計算を継続して、新規割当層に到達したときだけ到着を待つ。単層移行の追加遅延はバッチサイズが小さい場合でも 100 ミリ秒以内で、大きい場合はフォワード計算との重畳でほぼ隠蔽できる。運用設計として見るべきは発火の制御である。短期変動による頻繁な再配分を避けるため、スライディングウィンドウ内で一貫して同じ配分が現れたときのみ発火させる(既定値 25)。閾値が小さすぎると頻繁な再調整で E2E レイテンシが最良の静的戦略比 35% 増加する。 KV 移行がコストを伴う操作である以上、その発火は安定化フィルタを通す必要がある。 ### 第 29 章　アプリケーション層への漏れ ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch29.png|900]] *図29　「アプリケーション層への漏れ」の概観* KV キャッシュのメモリ管理を純粋な性能問題として扱えない直接の証拠が、本番運用の報告にある(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]])。制約付き復号を状態機械として実装したところ、メモリ圧迫下で vLLM が部分的に完了したリクエストの KV キャッシュを退避し、後で異なるプロンプトと出力列で再スケジュールすることが問題になった。これは出力トークン列が単調に増加するという状態機械の前提を壊す。対処として、トークン履歴が縮んだことを検知して状態機械をリセットする実装を追加した。第 18 章で見た Niyama の設計は、この漏れを生む側の機構である。プリフィルキューのリクエストをプリエンプトする判断が、デッドライン制約と「KV キャッシュの保持時間を最短化してメモリ圧を抑える」目的の両方から導かれる(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]])。メモリ圧の緩和とアプリケーション層の正しさが、同じプリエンプション機構を通じて衝突する。 --- ## 第 XI 部　計測と制御 ### 第 30 章　指標定義の落とし穴 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch30.png|900]] *図30　「指標定義の落とし穴」の概観* KV キャッシュの効果を語る前に、指標の定義を揃える必要がある。 ITL は連続するトークン間の平均生成時間だが、TTFT を含めるかどうかがツールで異なる(Source: [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]], [[LLM推論]])。 LLMPerf は含め、GenAI-Perf は含まない。 TPS の分母も「最初のリクエストから最後のレスポンスまで」か「テスト全体の壁時計」かで分かれる。異なるツールの結果を直接比較するには正規化が要る。負荷試験と性能ベンチマークも別物である。前者は「どの並列数で破綻するか」を、後者は「この最適化でレイテンシが何ミリ秒改善するか」を問う。 > [!contradiction] TTFT が伸びる原因 > ある資料は「ISL が長くなるほど TTFT が増加するが、その原因は KV キャッシュのサイズが増大するためである」と述べる(Source: [[@2026__Zenn__MLエンジニアのための本質から理解するLLM推論]])。 > 他の資料はプリフィルを計算バウンドと定義し、TTFT を計算量側に帰する(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]], [[LLM推論]])。 > プリフィルの FLOPs が ISL に対して二次で増えることを主因と見るのが整合的であり、前者の因果説明は注記付きで扱うべきである。 ### 第 31 章　KV キャッシュ挙動を測る ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch31.png|900]] *図31　「KV キャッシュ挙動を測る」の概観* KV キャッシュのオフロードと PD 間転送を標準化された実行トレースとして定量化した例がある(Source: [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]])。計算、メモリ、通信のノードからなる DAG として表現し、モデル重みやデータセットを開示せずに移植可能なベンチマークを作る設計である。最も示唆的な数値がオフロードのコストである。 Llama3-8B でホストへの Memcpy が、ベースラインの 387 回と 0.895 ミリ秒から、オフロード有効時に 5,958 回と 216.484 ミリ秒へ増える。 **KV キャッシュのオフロードは、容量問題を入出力問題へ変換する**。 PD 分離間の KV 転送も層単位で測られている。 32 層で送信側が約 143 から 187 マイクロ秒、受信側が約 108 から 145 マイクロ秒であり、送信が一貫して高い。この種の計測基盤は、最適化アルゴリズムを提案しない代わりに、既存システムの挙動をベンダー非依存に比較可能にする補完的な役割を担う。エッジ側では eBPF による演算子レベルの計測がある(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])。ソース改変も再コンパイルもなく uprobe を差し込み、トークン、グラフ、演算子、スケジューラの 4 粒度で測る。オーバーヘッドはトークンとグラフ粒度のみなら 0.1%、演算子粒度を含めて 1.7% から 4.0% である。プロファイラ自身が QoS 要件の未達を検知して一部機能を無効化する自己縮退の設計も持つ。第 3 の粒度として、カーネル実装そのものを比較する基盤がある(Source: [[@2026__arXiv__FlashInfer-Bench - Building the Virtuous Cycle for AI-driven LLM Systems]])。 Chakra が DAG レベル、ProfInfer が実行時の演算子レベルであるのに対し、こちらは同じ入出力仕様に対する複数の実装を、実サービストラフィック由来のワークロード分布の上に並べる。 GQA のページド事前充填とページド復号と ragged 事前充填、MLA のページド事前充填とページド復号、DSA のページド top-k 索引とページド疎注意が、それぞれ独立した演算子族として立っている。 KV のレイアウトに直結する区分がベンチマークの一級の軸になっている点が、本章にとっての価値である。最も示唆的なのは、ページド KV を前提とする注意カーネルが**自動生成の最も効かない領域**として実測されていることである。 LLM が生成したカーネルは GQA のページド構成で最良 6.1 倍(平均 2.4 倍)を出す一方、MLA のページド構成では 0.36 倍、GQA の ragged 構成では 0.53 倍と既存実装に届かない。事例分析では、ブロック単位のタイリングと非同期実行とパイプライン化を明示的に指示しても、10 回の試行でそれらを正しく組み込めなかった。第 II 部で見た PagedAttention 系の実装が手作業の蓄積に支えられていることの、外部からの裏づけになる。ただし守備範囲は狭い。この基盤は単一 GPU のカーネルを対象とし、マルチ GPU と通信カーネルを含まない。本章の冒頭で引いた PD 分離間の層単位 KV 転送のような計測は、原理的に得られない。 3 つの計測基盤は互いに置き換えられず、測れる層が異なる。 ### 第 32 章　KV 利用率を制御信号にする ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch32.png|900]] *図32　「KV 利用率を制御信号にする」の概観* KV キャッシュ利用率は、管理される対象であるだけでなく制御ループへの入力にもなる。 **PreServe** は各インスタンスに KV メモリ使用率の先読みマップを持たせる(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]])。行がリクエスト、列が将来の反復に対応し、各セルがその反復での KV トークン数を保持する。新リクエストのプリフィル完了時に予測応答長から更新し、予測より早く完了すれば残りを減算し、遅れれば応答長を仮想延長して調整する。今後 100 反復分の使用率を予測してスケーラとルータへ渡す。判断規則は閾値で与えられる。次の 100 反復で KV メモリ 95% 超過が 10% 以上と予測されるインスタンスを過負荷リスクありと判定して 1 台追加する。ルーティングでは、80% を超える KV 使用見込みにペナルティを課す項を負荷関数に加える。この予測が必須になる理由も明示されている。インスタンスのコールドスタートは数十秒から数百秒を要するため、反応的なオートスケーリングは実質的に機能しない。効果は平均 TTFT を 4.26 秒から 2.24 秒へ(47.4% 削減)、SLO 違反率を 7.26% から 2.44% へ(66.58% 削減)である。 **XWind** はさらに踏み込み、KV キャッシュ利用率をメモリ帯域飽和の**先行指標**として使う(Source: [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]])。周波数が閾値を下回ると KV 使用率が急増し、これが TBT 劣化に先行する(A100 40GB で 20%、H100 80GB で 35%)。そこで KV 超過には 2Δf、TBT 超過には 1Δf という非対称な補正を当てる。 KV クリフが急峻であることが非対称性を正当化する。信号としての価値は検証で裏づけられている。 KV 信号のみを除くと P99.9 が 72 秒から 120 秒超へ悪化し、TBT 信号のみを除いた場合の 96 秒より影響が大きい。 KV キャッシュ利用率が TBT より制御に効いている。とはいえ、この知見は現時点で単一のソースに依存している。同時期に周波数制御を扱った別の系統は、KV キャッシュ利用率をまったく観測しない(Source: [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]])。チャンクサイズとマイクロバッチ数と GPU クロックをミリ秒粒度で同時制御する設計で、制御ループの入力は TTFT と TBT の予測値のみである。それでも Llama-3.3-70B を 8 基の A100 で動かし、TTFT の SLO 遵守率 94.9%、TBT で 94.5% を保ちながら vLLM 比 49% のエネルギーで動く。 KV クリフの再現報告はまだない。もっとも、この対比から結論を引き出すことはできない。一方は再生可能エネルギー農場をまたぐ広域ルーティングでレイテンシ SLO を守る問題、他方は単一ノードでエネルギーを最小化する問題であり、目的関数も時間スケールも異なる。 KV 利用率を観測しない設計が成立したという事実は、クリフが存在しないことの証拠にはならない。現状で言えるのは、KV クリフという知見の検証状況が弱いということだけである。 > [!important] 観測できないものは制御できない > PreServe と XWind が制御の要とする KV キャッシュ利用率は、既定のツール構成では見えないことがある。 > ある本番環境では、Triton の組み込みブリッジが 40 以上ある vLLM メトリクスのうち 9 個しか橋渡しせず、トークンスループット、KV キャッシュ利用率、プレフィックスキャッシュヒット率が欠けていた(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]])。 > 対処は両者を単一エンドポイントに統合する軽量プロキシの追加である。 > 制御機構の研究と本番の配管の間にはこの落差がある。 --- ## 第 XII 部　ハードウェアと広域化 ### 第 33 章　容量で押し返す ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch33.png|900]] *図33　「容量で押し返す」の概観* ここまでのソフトウェア的対処は、いずれも GPU HBM の容量を所与としてきた。ハードウェア側の容量増強という第 2 の軸がこれに加わる。 Rubin 世代は GPU あたり最大 288GB の HBM4 と 22 TB/s のピーク帯域を提供する(Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。容量と帯域の役割分担が明示されている。容量はモデル常駐、より大きなコンテキストウィンドウ、より大きな KV キャッシュ、そして**KV キャッシュのオフロードを不要にする高並行性**を支え、帯域はトークンごとの生成フェーズを支える。同じ資料はデコードの性質も述べる。デコードは本質的にメモリサブシステム律速であり、ピーク帯域の仕様よりも「メモリサブシステム全体をどれだけ効率的に使い切れるか」が支配的になる。長いコンテキストと大容量 KV キャッシュを伴うエージェント型のワークロードはこの制約を増幅する。第 31 章のオフロードコストと突き合わせると構図が見える。オフロードが Memcpy を 387 回から 5,958 回へ増やすなら、容量を増やしてオフロード自体を発生させない方向に押し返せる。ただし容量の増加はコンテキスト長と並行性の要求も押し上げるため、どこまで実現するかは長コンテキスト化の速度と容量拡大の速度の競争に依存する。本番トレースが示す構造的なワークロード特性(シングルターン支配、短い寿命)は容量増加だけでは解消しない。押し返し方には第 3 の軸がある。容量がオフロードの発生自体を減らす方向だとすれば、相互接続はオフロードのコストを下げる方向である。 GH200 NVL2 は 144 GB の HBM と 480 GB の Grace DRAM を NVLink-C2C で結ぶ(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]])。第 14 章で見たレイアウトの作り直しを施すと、16 GB の双方向転送は 46.80 ミリ秒であり理想値の 94% に達する。争点は「オフロードを発生させないか」から「発生した入出力を計算の裏へ隠しきれるか」へ移る。実測では、転送がモデル推論の完了前に終わらずストールした反復は 0.021% にとどまる(平均でスケジューリング 7.63 ミリ秒、KV 転送 15.8 ミリ秒に対しモデル実行 69.82 ミリ秒)。ただしハードウェアだけでは足りない。同じ検証は、GH200 のハードウェア管理による統合メモリに任せる方式が LLM サービングには不適だと結論する。 CPU DRAM 側の帯域が C2C 経由でも 384 GB/s(GPU HBM の 4 TB/s に対し約 1/10)に制限される段差があり、かつアクセス頻度が蓄積する前にリクエストが完了するためページ移送が発火しない。 **透過的な機構は明示的なブロックテーブル管理を代替しない**。この観察は容量方向にも刺さる。公称 900 GB/s の相互接続があっても素朴な移植では 5% 未満しか使えなかったのだから、HBM4 の 288 GB もソフトウェアスタックの協調設計なしには性能へ転換しない可能性がある。容量と帯域はどちらもソフトウェア側の粒度設計を免除しない。 ### 第 34 章　広域共有 ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch34.png|900]] *図34　「広域共有」の概観* KV キャッシュ共有を単一クラスタの外へ広げる構想もある(Source: [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]])。動機は電力インフラの制約であり、集中型データセンターだけでは需要と送配電の制約に追いつきにくいため、小規模データセンターを再生可能電源の近傍に分散配置する。ここでは再利用と共有が区別される。再利用は同一利用者内、共有は利用者間の共通文書やコンテキストの利用である。利用者情報を含むシステムプロンプトが先頭に入るため、通常のプレフィックスハッシュだけでは利用者間の共有が難しい。そこで CacheBlend のような手法が補助になり、複数断片の再利用が可能になると KV キャッシュ母集団の大きさがヒット率に効くため、共有される大容量ストレージを Cold 層として置く設計が有効になりうる。距離の影響は実測されている。 Llama-3.1-8B で平均約 65K トークン入力、KV キャッシュ約 8 GB の条件で、**100 km 離れても TTFT 短縮効果の変化は 8% に留まる**。電力効率はデータセンター内で 2.53 倍、100 km 離れても 2.31 倍である。ただし条件依存性に注意が要る。帯域の影響を測った別の検証は入力 1K トークン、KV キャッシュ 120 MB という条件であり、距離耐性を測った検証とは規模が大きく異なる。距離耐性が高く出るのは入力が長くプリフィル削減効果が大きい条件であり、短い入力での距離耐性は資料から読めない。クロスサイトのルーティングを実装した例では、KV キャッシュ利用率を含む実時間の信号のみでサイト設定を変更する(Source: [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]])。静的な配分比に対して P99 の E2E レイテンシを 546 秒から 7.9 秒へ改善した。大域最適には中央集権的な制御とオフラインプロファイリング、出力長予測が必要で本番では現実的でないため、本番で取れる信号だけで動く反応型を選ぶという判断である。 --- ## 第 XIII 部　研究のフロンティア ### 第 35 章　未解決の問い ![[Attachments/KVキャッシュ管理の教科書/kv-cache-textbook-ch35.png|900]] *図35　「未解決の問い」の概観* **容量と構造** - HBM4 の容量拡大は、本番トレースが示す再利用率の低さ(事業者向け 54%)やホットブロックの短命性(P99 97 秒)をどの程度緩和するか。容量増加だけでは解決しないシングルターン支配のような構造的特性は残るか。 - MHA から GQA や MLA への移行が進むと SSD 階層は不要になるのか、それとも長コンテキスト化で相殺されるのか。 - GPU 内のページ、ネットワークの転送チャンク、ストレージのオブジェクトの最適な対応関係は、モデルサイズ、層数、並列構成、入出力長、ヒット率にどう依存するか。 - block-first レイアウトは、GPU 内の注意計算の性能と断片化を損なわずに成立するか。損なわないなら「二重粒度は構造的制約である」という第 14 章の主張自体が弱まる。 - 密結合の相互接続ほど大きな転送粒度を要求するという向きは、次世代のファブリックでも続くのか。 - 量子化による有効容量の増加は、本番トレースが示す再利用率の構造的な上限(事業者向け 54%)そのものを引き上げるか、それとも別の軸の改善にとどまるか。 **再利用の限界** - 近似再利用の精度劣化について、3 ソースが 3 通りの結果を報告している(第 12 章)。評価条件を突き合わせ、どの条件が実運用に近いかを検証する必要がある。 - CacheBlend の選択的再計算と KVShare の DHD を組み合わせた場合、両フェーズでの最適な再計算比率は入出力長のプロファイルにどう依存するか。 - ContextPilot の整列戦略は、コンテキスト重複率が低いワークロードでどこまで有効か。距離関数の重み α の感度は十分に検証されていない。 - SCBench が示した sub-O(n) 手法のマルチターン破綻は、マルチテナント環境で近似再利用と組み合わせるとどう変化するか。 - チャネル単位の混合精度量子化(Kitty)とトークン単位の混合精度(KVQuant 系)は直交する軸である。併用したときの精度とメモリの釣り合いはどうなるか。 - 2 ビット級の量子化は、単一ターンの推論タスクでは精度を回復できた。共有コンテキストのマルチターン評価でも同じ回復が得られるか。SCBench の評価軸で量子化系を測り直す必要がある。 - 量子化と階層退避を同一システムで組み合わせると、ホスト DRAM や SSD の階層は不要になるのか、それとも長コンテキスト化に相殺されるのか。 **スケジューリングと公平性** - キャッシュ認識スケジューリングと公平性を両立する標準的な目的関数はあるか。最長共有プレフィックス優先、SLO 認識ルーティング、テナント隔離をどう組み合わせるべきか。 - Niyama の積極的降格は「5% 程度の犠牲で残り 95% の SLO を守る」トレードオフを明示的に選ぶ。この選択の妥当性はマルチテナントの課金体系とどう整合するか。 - オフライン一括推論の大域最適化(BatchLLM)は、リクエストが継続的に到着するオンライン環境へどこまで持ち込めるか。一括の境界を区切って準リアルタイムに解き直す方式は、どの程度の追加レイテンシで成立するか。 - グループ単位のスケジューリングが個別レイテンシを犠牲にする構造は、最長共有プレフィックス優先の starvation と同じトレードオフなのか、質的に異なる制約なのか。 - 退避優先度には再利用確率で決める系統(第 25 章)と SLO 進捗の遅れで決める系統(第 18 章)がある。両者を単一の優先度スコアへ統合できるか。同じ HBM を「将来再利用されそうなブロック」と「SLO 違反が切迫したリクエスト」が奪い合う。 - プレフィックスキャッシュのヒットとドラフトモデルの追加 KV は同じ GPU メモリを奪い合う。KV 利用率を制御信号とする設計に、投機的復号の有無と提案長をどう組み込むか。 - 分離構成の最適な P:D 比は、プレフィックスキャッシュと投機的復号の導入によって逆向きに動く。再利用最適化と資源配分を同時に解く定式化はあるか。 **耐障害性と計測** - プロアクティブなホストバックアップは単一ノード構成を対象とする。クラスタ横断の KV 管理層と統合した場合、「通常時の再利用のための配置」と「障害復旧のためのバックアップ配置」という 2 つの目的関数はどう調停すべきか。同じホストメモリ容量を奪い合う可能性がある。 - パイプラインステージ間の非同期移行と、再利用や退避や障害復旧のための KV 移動は同一システムで競合しうる。層再配分の発火とプレフィックスキャッシュの退避が重なった場合、どちらを優先すべきか。 - KV キャッシュ利用率を制御信号として使う研究が増える一方、その信号が既定のツール構成で欠落する状況がある。計測の可用性を前提にした制御設計はどう検証すべきか。 - 8k 入力がほぼ全てキャッシュヒットする条件でも読み込み時間が TTFT の約 1/4 を占めるという観察の原因は特定されていない。 - KV キャッシュ利用率をメモリ帯域飽和の先行指標とする知見(第 32 章)は、いまだ単一のソースに依存している。同時期の電力制御系はこの信号を採用していない。独立した再現はどう設計すべきか。 - ページド KV を前提とする注意カーネルは、LLM による自動生成が最も効かない領域として実測された。この困難は KV レイアウトの本質に由来するのか、それとも学習データの偏りに由来するのか。 **広域化と電力** - 100 km 圏内の共有で効果が維持されると示されたが、実ネットワーク上の輻輳、マルチテナント隔離、障害時ルーティング、キャッシュ整合性を含めた評価はどう設計すべきか。 - 距離耐性は入力長に依存する可能性がある(第 34 章)。短い入力での距離耐性を測る必要がある。 **品質と安全性** - KV キャッシュの圧縮、量子化、損失のある保存は、TTFT や ITL だけでなく出力品質、再現性、安全性にどう影響するか。 - NIXL の登録とメタデータ交換の抽象は、マルチテナント環境で最小限の情報公開とキャッシュ共有効率をどう両立すべきか。 --- ## 付録 ### A. 用語集 | 用語 | 定義 | |---|---| | KV キャッシュ | 過去トークンの key と value を保存し、デコード時の再計算を回避する機構 | | プリフィル | プロンプト全体を処理して KV キャッシュを構築する段階。計算バウンド | | デコード | KV キャッシュを参照して 1 トークンずつ生成する段階。メモリバウンド | | TTFT | プロンプト投入から最初のトークンまでの時間。キューイングとプリフィルを含む | | ITL / TPOT | 連続するトークン間の平均生成時間。TTFT を含めるかはツール依存 | | ISL / OSL | 入力トークン長と出力トークン長 | | Goodput | TTFT と TPOT の両 SLO を満たすリクエストの処理率 | | PagedAttention | KV キャッシュを固定サイズブロックに分け、論理ブロックを非連続な物理メモリへ写像する手法 | | RadixAttention | KV キャッシュを radix tree に格納しプレフィックスを共有する手法 | | 二重粒度 | GPU 内のページと外部転送のチャンクで最適な粒度が異なる構造 | | PD 分離 | プリフィルとデコードを別の計算資源へ分離する構成 | | KV 偏差 | 事前計算済み KV と完全再計算時の KV の差。選択的再計算の指標 | | アテンション・ドリフト | デコードの進行に伴い再利用済み KV のバイアスが蓄積し伝播する現象 | | HKVD トークン | KV 偏差が高く選択的再計算の対象となるトークン | | DHD | 累積アテンションと偏差の積で再計算対象を選ぶスコア | | GQA / MQA | クエリヘッドのグループごとに K と V を共有する注意方式 | | MLA | K と V を低次元潜在ベクトルへ圧縮して保存する注意方式 | | DCP | MLA の KV キャッシュを複数 GPU へシャーディングする並列化 | | ワークロード対応退避 | カテゴリ別の指数分布による再利用確率と空間局所性で優先度を決める退避方式 | | Cyclic KVCache Placement | ヘッドと KV ブロックを層ごとに周期的に割り当て、障害後の偏りを均す配置 | | KV クリフ | 周波数が閾値を下回ると KV 使用率が急増し TBT 劣化に先行する現象 | | チャネル単位精度ブースト | Key キャッシュのチャネルのうち量子化感度の高い少数だけを高精度へ昇格させる混合精度量子化 | | 実効ビット幅 | 混合精度と FP16 保持分を含めた、KV 1 要素あたりの平均ビット数 | | スパース注意 | 全 KV を保持したまま、各ステップで上位 k 件のみを読み出す注意方式 | | ホットデバイスバッファ | フルコンテキストをホストに置き、GPU 側に頻繁アクセス領域だけを保持する構成 | | block-first レイアウト | 1 ブロック内の全レイヤーを連続領域に置き、外部転送の粒度を拡大する KV 配置 | | 仮想遅れ時間 | SLO に対する進捗の遅れを符号付きで表し、退避と優先実行の判断に使う量 | | プレフィックス共有グループ | 同じプレフィックスを共有するリクエストの集合。オフライン一括推論でのスケジューリング単位 | | レートマッチング | 分離構成でプリフィル側とデコード側のスループットを揃えるよう GPU 比率を決める手続き | ### B. 推奨読書リスト **基礎** - Kwon et al.: Efficient Memory Management for LLM Serving with PagedAttention (SOSP 2023) - Zheng et al.: SGLang — Efficient Execution of Structured Language Model Programs (NeurIPS 2024) - Dao: FlashAttention-2 (arXiv 2023) **クラスタ規模** - Zhong et al.: DistServe (OSDI 2024) - Qin et al.: Mooncake — A KVCache-centric Disaggregated Architecture (arXiv 2024) - Liu et al.: LMCache (arXiv 2025) - AIBrix Team: AIBrix (arXiv 2025) - Mitra et al.: Beyond the Buzz — A Pragmatic Exploration of Prefill-Decode Disaggregation (MLSys 2026 Industry Track) - Optimizing Deployment Configurations for LLM Inference (MLSys 2026 Industry Track) **再利用と圧縮** - Yao et al.: CacheBlend (EuroSys 2025 Best Paper) - KVShare (arXiv 2025) - ContextPilot (MLSys 2026 Oral) - Li et al.: SCBench (ICLR 2025) - Zheng et al.: BatchLLM — Global Prefix Sharing and Throughput-oriented Token Batching (arXiv 2024 / MLSys 2026 Industry Track) - Xia et al.: Kitty — Accurate and Efficient 2-bit KV Cache Quantization (MLSys 2026) - HiSparse — Turbocharging Sparse Attention with Hierarchical Memory (LMSYS Blog 2026) **ハードウェアと計測** - SuperInfer — SLO-Aware Rotary Scheduling and Memory Management on Superchips (MLSys 2026) - Speculative Decoding: Performance or Illusion? (MLSys 2026) - FlashInfer-Bench — Building the Virtuous Cycle for AI-driven LLM Systems (MLSys 2026) **本番と運用** - KVCache Cache in the Wild (arXiv 2026) - FailSafe / RaidServe (arXiv 2025) - PreServe (ICSE 2026) - XWind (arXiv 2026) - MLCommons Chakra (MLSys 2026 Oral) ### C. ソースマッピング | 章 | 主要ソース | |---|---| | 1-3 | [[注意機構]], [[LLM推論]], [[@2026__SpeakerDeck__LLM高速化(勉強会)]], [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]], [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]], [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]] | | 4-5 | [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[PagedAttention]] | | 6 | [[@2023__arXiv__FlashAttention-2 - Faster Attention with Better Parallelism and Work Partitioning]], [[メモリ階層とキャッシュ]], [[メモリウォール]], [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]] | | 7-8 | [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]], [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]] | | 9-12 | [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]], [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]] | | 13-15 | [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]], [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]] | | 16-18 | [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]], [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]], [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]], [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]], [[@2026__MLSys2026__FaaScale - Unlocking Fast LLM Scaling for Serverless Inference]] | | 19-21 | [[Grouped-Query Attention]], [[Multi-Head Latent Attention]], [[線形注意]], [[ハイブリッドアテンションアーキテクチャ]], [[Decode Context Parallelism]], [[スパース注意]] | | 22-23 | [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]], [[@2024__TMLR__Efficient Large Language Models - A Survey]], [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]], [[KVキャッシュ量子化]], [[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory]] | | 24-26 | [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]], [[LLM推論設計空間探索]], [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]] | | 27-29 | [[@2025__arXiv__FailSafe - High-performance Resilient Serving]], [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]], [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]] | | 30-32 | [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]], [[@2026__arXiv__FlashInfer-Bench - Building the Virtuous Cycle for AI-driven LLM Systems]], [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]] | | 33-34 | [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]], [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]], [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]], [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]] | ### D. 数値を引用するときの注意本書の執筆で確認した、ソース側の不確かさを列挙する。 - **「メモリ効率 96%」**は PagedAttention 原典にはなく、二次資料の記述である(第 5 章)。 - **SRAM 容量と HBM 帯域**は資料間で食い違う。GPU 世代を明示せずに引用できない(第 6 章)。 - **CacheBlend の再計算比率**は本文で 10% から 15%、感度分析で 5% から 18%、下限値として 15% と複数の値が現れる。用途ごとに区別する。 - **KVShare の TPOT 劣化**は原文が「約 1 倍(2 倍)に増加」と両表記する。 - **KV ブロック寿命**は「P99 が 97 秒」と「P90 が 0.3 秒」の 2 表記が並記されている。 - **192 GiB という KV キャッシュ容量**は勉強会資料の見積もりであり、発表者の所属も確定できない。 - **Mooncake の実験**はすべて LLaMA2-70B 相当のダミーモデルによる。実モデルでの検証はない。 - **AIBrix について [[KVキャッシュ管理]] が記す「4.7 倍のコスト削減」と「Kubernetes CRD」**は、wiki のソースページから裏づけられない(第 18 章の脚注)。 - **スライド資料の数値**(IOWN APN の 1,000 km 以上の値、推論基盤スライドの並列度別パーセンタイル、LMCache と NIXL の TTFT)は図からの読み取りであり概数である。 - **FailSafe** は本文に "Under Review" 表記があり、MLSys 2026 Oral では RaidServe 名義である。 - **Niyama** は Microsoft Research のページで QoServe に改題され ASPLOS 2026 採録となっている。 - **ContextPilot の倍率**は比較対象(LMCache、RadixCache、CacheBlend)ごとに大きく異なるため、必ず対象を併記する。第 2 版で追加した分を続ける。 - **Kitty の圧縮率**は要約の「約 8 倍」と実効ビット幅由来の「6.6 倍」が併存し、調停は示されていない。KIVI の「2.6 倍」はプロセス全体のピークメモリ、SCBench 表の「1/8」は理論圧縮率であり、3 者は別の量である。 - **Kitty の比較対象**にある KIVI-K2V2\* は Kitty 著者による強化ベースライン(Sink を FP16 保持)であって KIVI 原典の構成ではない。「KIVI が」と一般化して引いてはならない。また平均精度 77.15 等は 4 ベンチマークの平均値である。 - **Kitty の vLLM 統合**はソースに記述がない。あるのは PagedAttention と互換なページ設計、Triton によるカーネル、HuggingFace 実装との比較までである。 - **BatchLLM の 10.8 倍**は共有プレフィックス長 16,000・共有度 16 という極端条件の値であり、実業務ワークロードでは 1.26 倍から 1.30 倍である。ソースは 6.71 や 8.67 といった値の単位を明記していない箇所が多く、req/s と確定できるのは一部にとどまる。理論最適 58.1% と実測 35.8% の比較対象ワークロードも特定されていない。 - **Beyond the Buzz の帯域値**(約 1.2 GB/s/GPU、約 0.4 GB/s/GPU 等)は図からの読み取りであり、いずれも NVIDIA 独自の非公開シミュレータによる試算である。P/D-Serve の実運用計測とは測定の性質が違う。実機検証は 8B 級のモデルに限られる。 - **Beyond the Buzz の「最良の静的構成比 2 倍」**は、掲載された生の値では goodput 18.64 対 12.27(約 1.5 倍)、GPU あたり 3.96 対 3.07(約 1.3 倍)にとどまる。倍率ではなく生の値を引くのが安全である。 - **同論文はタイトルが 2 つある**。arXiv プレプリントは "A Pragmatic Take on Inference Disaggregation"、MLSys 2026 の camera-ready は "Beyond the Buzz: ..." である。Dynamo のプランナーと KV ルーティングの節は camera-ready のみに存在する。 - **Meta の運用報告のハードウェアは匿名化**されており(GPU-A/B/C)、メモリ容量の絶対値が出ない。「H100 では」と書き換えてはならない。またシミュレータ精度 ±5% は中央値と平均値に対するもので、P99 のテールは対象外である。 - **SuperInfer の 900 GB/s と 192 GB/s** は公称帯域と転送マイクロベンチマークの理想上限であり、差の理由は示されていない。「5% 未満」(既存システム移植時の帯域利用率)と「5.6%」(素朴実装の理想比)もフレームが違う。評価は GH200 NVL2 の単一構成のみで、GB200 や MI300A の評価はない。入出力長の条件はソースに記載がない。 - **SuperInfer の 74.7%** は SLO 達成率の改善であり、レイテンシの削減率ではない。パーセントポイント差か相対改善かはソースから確定できない。33 倍は 16 GB 転送の合成マイクロベンチマークであって、エンドツーエンドの改善幅とは別物である。 - **HiSparse は査読論文ではなく技術ブログ記事**である。780 や 2,650 トークン/秒といった値はグラフからの読み取りで、キャッシュミスは順序関係のみが示され絶対値もミス率も公開されていない。対応モデルは DSA 系に限られる実験的機能である。 - **投機的復号の理論上限 4.9 倍**は位置ごとに最良手法を完璧に選べるという仮定と、EAGLE の提案ヘッド用 KV 管理コストの無視という 2 つの非現実的な前提に依存する。達成値ではない。また同論文は棄却時の KV ロールバック機構を扱っていない。 - **FaaScale の 1.1 秒**は、ホストメモリ上のレプリカから 400 Gb/s の InfiniBand で台数を増やす条件下の値である。AIBrix の 2 分から 3 分、PreServe の数十秒から数百秒とは測定対象が違う。GPU コスト削減率はベースライン名を併記しないと誤読される(FaaSNet 比 17.8%、NCCL 比 18.1%、ServerlessLLM 比 31.3%)。 - **BEAM は KV キャッシュを一度も扱っていない**。KV クリフの裏づけにも反証にも使えない。Window-DVFS は著者らの自前実装であり DynamoLLM 本体ではないため、「DynamoLLM 比 30% 削減」と書いてはならない。 - **FlashInfer-Bench の GEMM 116 倍**は PyTorch 参照比であり、注意カーネルの FlashInfer 比とは尺度が違う。本番置換の実測は正規化カーネル 1 種のみで、注意カーネルの本番置換は評価されていない。 - **BOute には KV キャッシュへの言及がない**。異種 GPU のメモリ容量差が KV キャッシュにどう効くかは論じられていないため、そこから KV キャッシュ論を引き出してはならない。