前編：KV Cacheの仕組みと最適化手法 ── LLM推論を速くする技術を整理する

こんにちは。Acompany エンジニアのハルカです。

Acompanyでは「秘密を守れるAI」をテーマに、機密コンピューティング技術を活用したAIサービスを開発しています。コンテキスト長の拡大やマルチエージェント化が進むなか、KV Cacheをいかに効率よく管理・共有するかが推論基盤の設計を左右するようになっています。KV Cacheは推論の高速化を支える中核的な仕組みですが、その共有・再利用はセキュリティリスクにつながります。

この記事（前編）ではKV Cacheの仕組みと最適化手法を、後編では攻撃と防御を整理します。

LLM推論とKV Cacheの基礎

まず KV Cache がなぜ必要で、なぜ問題になるのかを押さえます。

推論の2つのフェーズ：Prefill と Decode

LLM の推論は、大きく Prefill と Decode の2つのフェーズに分かれます。ChatGPT や Claude に質問を投げたとき、まず入力を処理する Prefill があり、その後に回答を1トークンずつ生成する Decode が続きます。

この2つは計算特性がまったく異なるため、最適化のアプローチも異なります。

Prefill は入力トークンすべてを並列処理し、各層の Key と Value を計算してキャッシュに格納します（Compute-bound）。Decode はそのキャッシュを読み出しながら1トークンずつ生成します。生成が進むほど読み出すデータ量が増えるため、メモリ帯域がボトルネックになります（Memory-bound）。

KV Cacheの役割とメモリ消費

Attention 計算$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{Q{K}^{\top }}{\sqrt{d}}\right)V$では、Q は現在のトークンから生成しますが、K と V は過去の 全トークン分 が必要です。KV Cache がなければ毎ステップで K/V を再計算し $O(T^2)$ になるところを、計算済みの K/V を再利用することで $O(T)$ に抑えます。

ただし KV Cache はすべての層・ヘッド分を保持するため、メモリ消費は $\text{Mem}=2\times L\times H_{kv}\times d\times S\times B\times \text{bytes}$ で増大します。GQA モデルでは KV ヘッド数が Query ヘッド数より大幅に少ない点に注意が必要です（Llama-3 8B: Query 32, KV 8）。

Llama-3 70B × 128K なら1件で H100 80GB の半分が埋まります。長コンテキスト・大規模モデル・同時リクエストが組み合わさると、KV Cache のメモリ管理は避けて通れない課題になります。

KV Cacheの最適化手法

ここからは、KV Cache が抱える課題とその解決策を一つずつ見ていきます。

メモリ断片化という根本問題

KV Cache を素朴に管理すると、3種類のメモリの無駄が発生します。

• 予約過多: 最大生成長分を事前確保するため、実際の使用量との差が無駄になる
• 内部断片化: ブロックの割当単位が最大長基準のため、パディング領域が大量に発生する
• 外部断片化: 確保・解放の繰り返しで連続した空き領域がなくなり、割当不能になる

これらが重なると、確保したメモリの 60〜80%が無駄 になることがあります。この問題は OS のメモリ管理でも古くから知られており、同じアプローチが LLM にも持ち込まれました。

PagedAttention ── OSの仮想メモリをLLMへ

この問題を解決したのが PagedAttention です（Kwon et al., 2023）。OS の仮想メモリと同じ発想で、KV Cache を固定サイズの「ブロック」に分割し、論理ブロック（シーケンス上の位置）と物理ブロック（GPU メモリ上の実位置）をブロックテーブルで対応づけます。

必要になったときに初めて物理ブロックを割り当てるため予約過多が解消され、非連続配置により外部断片化もほぼなくなります。

この手法を実装した vLLM の公式ベンチマークでは、次の改善が報告されています。

PagedAttention は LLM 推論基盤の転換点であり、以降の Prefix Caching や分散 KV ストアも、このブロック管理を前提として設計されています。なお、24× というスループット改善は HuggingFace Transformers との比較であり、FasterTransformer 等との比較では 2〜4× です。

Prefix Caching ── システムプロンプトの再利用

チャットボットを運用していると、大量のリクエストが同じシステムプロンプトを共有していることに気づきます。たとえば「あなたは親切なAIアシスタントです...」というプレフィックスがすべてのリクエストに付くなら、その部分の KV Cache を一度計算してしまえば、以降のリクエストではそのまま再利用できるはずです。

これが Prefix Caching です。共通プレフィックスの KV Cache を保持しておき、新しいリクエストではプレフィックス部分の Prefill をまるごとスキップします。

効果は特に TTFT（Time To First Token） に表れます。システムプロンプトが長い場合や、Few-shot プロンプト・RAG で長い参照文書を挿入する場合、Prefill 計算を丸ごと省略できるため、初回応答までの時間が劇的に短縮されます。

ただし注意点が2つあります。

• 完全一致が必要: プレフィックスが1トークンでも異なるとキャッシュは効きません。たとえばシステムプロンプトの末尾にタイムスタンプやユーザー ID を含めている場合、毎回異なるプレフィックスになるためキャッシュヒットしません。Prefix Caching を活かすなら、可変部分をプレフィックスの後ろに配置するなどの設計上の工夫が必要です
• テナント間共有にはリスクがある: 複数ユーザーでキャッシュを共有すると、「あるユーザーが送ったプレフィックスがキャッシュに存在するか」を他のユーザーが応答時間の差から推測できるようになります。これがサイドチャネル攻撃の入口です（後編で詳しく扱います）

vLLM や TensorRT-LLM がこの機能を公式にサポートしています。

KVComm ── マルチエージェント間のKV共有

Prefix Caching はプレフィックスが完全一致するリクエスト間で有効でした。では、マルチエージェントシステムのように複数のエージェントが同じ文書を参照するが、各エージェントのプレフィックス（システムプロンプトや会話履歴）が異なる場合はどうでしょうか。同じ文書でも、前に来るトークン列が異なれば Attention の計算結果が変わり、KV の値も変わるため、そのままでは共有できません。

KVComm（Ye et al., 2025）は「アンカープール」方式でこの位置ずれを補正します。代表的なプレフィックスで事前に KV の偏差を観測しておき、新しいエージェントのプレフィックスに最も近いアンカーの偏差を適用して KV を変換する、という training-free な手法です。

NeurIPS 2025 で発表され、平均 6.7倍 の Prefill 高速化、精度劣化 2.5%以下 を達成しています。

分散KVストア ── KV CacheをGPUの外へ逃がす

先ほどのメモリ消費の表で見たとおり、大規模モデル × 長コンテキストでは1件あたりの KV Cache が巨大になります。たとえば Llama-3.1 405B を 128K コンテキストで動かすと、KV Cache だけで1件あたり約 68 GB です。同時に数件処理しようとすれば、あっという間に数百 GB に達します。

この限界を突破するために、KV Cache を GPU の外に退避・分散させるアプローチが生まれています。

KV Cache のストレージには階層構造があります。

帯域と容量のトレードオフがあり、高速な階層ほど容量が小さいのは一般的なストレージ階層と同じです。KV Cache を「今使っているもの」「すぐ使うかもしれないもの」「しばらく使わないもの」に分類し、適切な階層に配置する── これが分散 KV ストアの基本的な考え方です。

この階層構造を活用する代表的なシステムが LMCache と Mooncake です。両者はアプローチが異なりますが、いずれも「GPU メモリだけでは足りない」という同じ課題に取り組んでいます。

LMCache

LMCache は vLLM と統合して動作する KV Cache 管理レイヤーです。KV Cache の保存・退避・共有を透過的に処理します。

• Token-level Indexing: 部分マッチでもキャッシュヒットさせる（RAG で有効）
• Tier-aware Eviction: LRU に基づき GPU HBM → CPU DRAM → NVMe SSD へ段階的に退避
• P2P Cache Sharing: 他ノードから RDMA/TCP で KV を取得（TTFT 54.7%短縮）

OSS として公開されており、vLLM に組み込みやすいのも利点です。

Mooncake

Mooncake（Moonshot AI, 2024）は、推論アーキテクチャそのものを KV Cache 中心に再設計したシステムです。最大の特徴は Prefill と Decode の物理的な分離 です。Compute-bound な Prefill と Memory-bound な Decode を同じ GPU で混在させると互いに干渉するため、それぞれに最適化された GPU プールを用意します。

Prefill Pool（高 FLOPS）で生成された KV Cache は RDMA/NVLink で Decode Pool（高 HBM 帯域）にゼロコピー転送されます。さらに KV-Centric Scheduling により、KV Cache が存在するノードにリクエストをルーティングし、転送を最小化します。

Moonshot AI の「Kimi」で実運用され、シミュレーションで最大 525%、実ワークロードで 75% のスループット改善を達成しています。

LMCache と Mooncake を比較すると、アプローチの違いが見えます。

まとめ

PagedAttention でメモリ浪費率を抑え、Prefix Caching で共通部分を使い回し、KVComm でエージェント間の共有を実現し、分散 KV ストアで GPU の壁を超える。どの手法も、KV Cache を 共有・再利用 することで性能を引き出しています。

PagedAttention（2023）を起点に、Prefix Caching、KVComm（NeurIPS 2025）、LMCache、Mooncake と、KV Cache の最適化は急速に進んでいます。2年足らずの間に、メモリ断片化の解消 → プレフィックス共有 → エージェント間共有 → インフラ全体の再設計と、最適化の範囲が広がり続けています。

これらの手法に共通するのは、KV Cache を「閉じ込めておく」のではなく「共有・移動させる」方向に進化している点です。PagedAttention はブロック単位の共有を可能にし、Prefix Caching はテナント間でキャッシュを共有し、LMCache はネットワーク越しに転送し、Mooncake は物理的に分離されたノード間で受け渡す。効率を追求するほど、KV Cache は「外に出ていく」のです。

しかし、KV Cache にはユーザーの入力情報がそのまま embedding として格納されています。共有と再利用は、攻撃者にとっての情報漏洩チャネルにもなり得ます。KV Cache を狙ったサイドチャネル攻撃やプロンプト復元手法、そしてその防御策については、後編で詳しく扱います。

参考文献

• Kwon et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv:2309.06180
• Ye et al. (2025). KVCOMM: Online Cross-context KV-cache Communication for Efficient LLM-based Multi-agent Systems. NeurIPS 2025. arXiv:2510.12872
• Moonshot AI (2024). Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving. arXiv:2407.00079
• LMCache ── vLLM 用 KV キャッシュ管理レイヤー