# KVキャッシュ管理 ## 定義 KVキャッシュ管理とは、LLM 推論で過去トークンの key/value テンソルを保存・再利用・退避・転送・共有するためのメモリ/ストレージ/ネットワーク管理である。単一リクエスト内の Decode 高速化から始まり、[[vLLM]] の PagedAttention では GPU 内のページ化メモリ、[[SGLang]] の RadixAttention では prefix 木によるリクエスト間共有、[[LMCache]] では GPU 外階層ストレージと推論エンジン間転送、[[P-D-Serve]] では RoCE 上の D2D KVCache 転送へ広がる。(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) ## 横断的知見 - **KV キャッシュ最適化は GPU 内ページ化からクラスタデータ管理へ拡張した**: PagedAttention は KV キャッシュを固定サイズブロックへ分け、非連続 GPU メモリ上で注意計算を可能にした。SGLang は同じ KV キャッシュを radix tree に保存し、複数 LM call やマルチターン履歴をまたいで prefix 共有する。LMCache はさらに GPU 外の CPU/SSD/リモートストレージへ退避・再読込し、P/D-Serve は RoCE 越しの D2D 転送を end-to-end サービング制御に組み込む。最適化対象は「1 GPU のメモリ断片化」から「クラスタ全体の AI ネイティブデータ移動」へ移っている。(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) - **GPU 内で有利な page 粒度は、ネットワーク/ストレージ転送では小さすぎる**: vLLM の小さな KV ブロックは内部断片化を抑えるが、LMCache は 20-63 KB 程度のページ単位転送では帯域を使い切れないため 256 token 程度の chunk にまとめる。P/D-Serve も PageAttention による離散ブロックを RDMA で 1 個ずつ送ると制御オーバーヘッドが大きく、連続バッファへまとめてから RecvScatter で復元する。したがって KV キャッシュ管理は、GPU 内 page と外部転送 chunk の二重粒度を持つ。(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) - **KV キャッシュ転送はメモリ登録とメタデータ交換の問題でもある**: LMCache + NIXL の PyTorch Conference 2025 資料は、KV キャッシュ層が GPU-GPU 転送、GPU-CPU 退避、CPU-CPU 転送、ストレージ退避を同じセマンティクスで扱う必要を示す。NIXL は DRAM/VRAM/BLK/FILE/OBJ を `mem_type` と記述子リストで登録し、Remote Agent info をローカルにキャッシュして、UCX や GDS などのバックエンドで非同期 Xfer request を投稿する。これは「chunk をどの大きさで送るか」だけでなく、「どのメモリ空間をどの識別子で登録し、どの制御プレーンで相手に知らせるか」が KV キャッシュ管理の一部になることを示す。(Source: [[@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]]) - **Prefix 再利用は固定 system prompt から動的ワークフローへ拡大した**: PagedAttention は parallel sampling や beam search の共有を扱い、SGLang は ReAct、Tree-of-Thought、RAG、multi-turn chat のプログラム構造から cache hit を得る。LMCache は実運用で、coding assistant、chat、RAG の「dynamically reusable contexts」が増えていると述べる。Prefix cache は単純な system prompt reuse ではなく、アプリケーションの制御フローとルーティングに依存する設計対象になった。(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **PD 分離の成否は KV キャッシュ転送の遅延・帯域・配置に支配される**: DistServe はノード内配置で KV 転送を総レイテンシ 0.1% 未満に抑えた一方、P/D-Serve は数万 NPU 規模で block-free D2D transfer により転送時間を 46% 削減した。LMCache は PD 分離を cross-engine/GPU KV cache transfer として扱い、NIXL や RDMA などの転送層と接続する。これは [[Prefill-Decode分離]] がスケジューリング問題であると同時に KV データ移動問題でもあることを示す。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **KV キャッシュ共有は広域低遅延ネットワークの設計問題にも拡張する**: LMCache はリモートストレージや RDMA/NVLink を含む KV キャッシュ転送層を定義し、P/D-Serve は本番データセンター内の D2D 転送を最適化する。田仲顕至の MPLS JAPAN 2025 資料はさらに、[[IOWN APN]] で小規模データセンターを束ね、100 km 圏内で KV キャッシュ共有を行っても TTFT 短縮効果の変化が 8% に留まるという評価を示す。KV キャッシュ管理は単一クラスタ内のデータ移動だけでなく、電力制約と地理分散配置を含む広域推論基盤の制御対象になりつつある。(Source: [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]], [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]]) - **Cache-aware scheduling はスループットと公平性の緊張を生む**: SGLang は longest-shared-prefix-first により平均 96% の最適 cache hit rate に近づくが、starvation の可能性を future work とする。P/D-Serve は gateway retries と reject により idle Prefill を探し、success rate を少なくとも 99% に維持する。KV キャッシュ利用率を最大化する順序と、ユーザー単位の公平性・SLO 達成は同じ目的関数ではない。(Source: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) - **CPU/DRAM/SSD を KVCache 第一階層に昇格させると、スケジューラが「どこのキャッシュを使うか」を中心目的関数にできる**: Mooncake の Conductor は prefill インスタンス選択を「ローカルキャッシュ長と転送時間と推定 TTFT を加算して最小化」として定式化し、LRUCache が 50,000 ブロックで約 50% ヒット率を達成する実データ分布(平均入力 7,590 トークン、5 万件超のブロック人気度の極端な不均一性)を示す。LMCache の階層ストレージとの違いは、Mooncake が CPU DRAM を「プライマリキャッシュ層」として位置づける点で、GPU VRAM はバッファとして使い終われば退避される。(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **ホットブロック複製は精密な使用量予測なしにヒューリスティックで達成できる**: Mooncake は「代替インスタンスへの KVCache 転送コストが追加 Prefill 計算コストより小さいとき転送して保存する」というルールだけで、ホットブロックをリクエストルーティングの副作用として複製する。実験で 8P+8D クラスタの平均 TTFT を 92 s(ランダム)から 6.26 s(KVCache 中心)に削減した(図 8)。この「精密予測なし複製」は、急成長するユーザー数で将来需要が予測不能な MaaS プロバイダに特有の設計選択である。(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **本番ワークロードの KV キャッシュ再利用率は合成データセットの報告値より有意に低い**: Aliyun 本番トレース([[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])では理想ヒット率が to-C で 62%、to-B で 54% であり、ShareGPT 等の合成ワークロードで報告される 80% 超を大きく下回る。さらに to-B(API)ワークロードでは KV 再利用の 97% がシングルターンリクエストに起因し、マルチターンがキャッシュ再利用を支配するという従来仮定は to-B 環境では成立しない。Mooncake の実運用再利用率約 50% とも整合し、本番 KV キャッシュ設計には実トレースに基づく容量見積もりが不可欠である。(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **KV ブロック寿命は短命かつ予測可能であり、LFU は不適切で LRU も最適でない**: Aliyun Trace B の P99 KV ブロック寿命は 97 秒、指数分布にフィットする。このため過去の高頻度情報を用いる LFU はノイズを蓄積し不適切であり、LRU も再利用確率の空間的偏りを捉えられない。ワークロード対応エビクションポリシー（カテゴリ別指数分布 + 空間局所性）が LRU 比で最大 23.9% ヒット率改善、41.4% QTTFT 削減を達成した。(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]]) - **非プリフィックス位置の KV キャッシュ再利用は選択的再計算で品質を維持できる**: CacheBlend は RAG 等で複数チャンクが入力に含まれる場合、プリフィックス以外のチャンクの KV キャッシュがクロスアテンションを欠くため品質が劣化する問題を特定し、各レイヤーで KV 偏差（ΔKV）が高い 10〜20% のトークン（HKVD トークン）のみ選択的に再計算することでフルプリフィルと同等品質を維持した。KVShare はこれをさらに発展させ、アテンション重みと KV 偏差の積（Score = α · ‖ΔV‖₁）で優先トークンを選定する DHD アルゴリズムと、ローリングハッシュによる可変長チャンクマッチングで、CacheBlend の固定チャンクサイズの制約を克服した。(Source: [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]], [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]]) - **アテンション偏差はプリフィルだけでなくデコードフェーズでも蓄積する**: CacheBlend はプリフィル時の選択的再計算で問題を解くが、KVShare はデコードフェーズで再利用済み KV キャッシュのバイアスが蓄積・伝播するアテンション・ドリフト問題を初めて体系的に定式化した。ステップごとの動的選択再計算で解決し、4 データセット全てで CacheBlend/EPIC を上回る精度を達成した(SOTA 比精度 20.38% 向上)。(Source: [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]], [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]]) - **sub-O(n) メモリの KV キャッシュ手法はマルチターン復号で実質的に破綻する**: SCBench の共有コンテキストベンチマーク([[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])は、StreamingLLM・SnapKV・PyramidKV 等の KV キャッシュ破棄手法が単一リクエストでは動作しても、マルチターン（KV キャッシュ再利用）シナリオでは精度が急落することを示した。スパース符号化 + 密復号（O(n) メモリ・sub-O(n²) プリフィリング計算）が堅牢であり、動的スパース性（MInference）は静的パターンより一貫して優れる。これは KV キャッシュ管理が「保持/破棄」の 2 値判断だけでなく「どのフェーズでどの粒度を保つか」を設計する必要性を示す。(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]]) - **クラウドネイティブ制御プレーンが分散 KV キャッシュをクラスタ横断で統合管理する段階に入った**: [[AIBrix]] は推論エンジン（[[vLLM]]・[[SGLang]]）の上位に位置するオーケストレーション層として、ノード/エンジン横断の分散 KV キャッシュファブリックを提供する。scan-resistant eviction で長コンテキスト・高再利用ワークロードの性能を改善し、分散 KV キャッシュ最適化で 50% スループット向上・70% レイテンシ削減を報告。Mooncake が KVCache Pool を Conductor で中央制御するのに対し、AIBrix は [[Kubernetes]] CRD と prefix-cache-aware request router の組み合わせで、既存クラウドエコシステム上に KV キャッシュ管理を載せる。(Source: [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]]) ## 未解決の問い - GPU 内 page size、ネットワーク transfer chunk、ストレージ object size の最適な対応関係は、モデルサイズ、層数、TP/PP 構成、ISL/OSL、prefix hit ratio にどう依存するか。 - Cache-aware scheduling と公平性を両立する標準的な目的関数はあるか。longest-shared-prefix-first、SLO-aware routing、tenant isolation はどのように組み合わせるべきか。 - RAG やエージェントでは prefix が完全一致しない。semantic/fuzzy matching による KV キャッシュ再利用は、正確性を壊さずにどこまで可能か。 - KV キャッシュの圧縮・量子化・損失あり保存は、TTFT/ITL だけでなく出力品質・再現性・安全性にどう影響するか。 - PD 分離で Decode 側障害が起きたとき、KV キャッシュをどの粒度で複製・再構築すれば、Goodput と復旧時間のバランスが最適になるか。 - 100 km 圏内の KV キャッシュ共有では TTFT と電力効率の効果が維持されると示されたが、実 APN 上での輻輳、マルチテナント隔離、障害時ルーティング、キャッシュ整合性を含めた評価はどう設計すべきか。 - Mooncake の実運用では最大 KV キャッシュ再利用率が約 50%。Aliyun トレースでも理想ヒット率は to-C 62%、to-B 54%。これはワークロード特性の構造的上限か、それとも容量・エビクション・ルーティング設計で改善できるか。 - GQA モデルでは GPU HBM の 4 倍程度のキャッシュ容量で理想ヒット率に近づく（Aliyun Trace B）。MHA → GQA/MQA 移行が進むと SSD 階層ストレージは不要になるのか、それとも長コンテキスト化で相殺されるのか。 - CacheBlend の選択的再計算と KVShare の DHD を組み合わせた場合、プリフィルとデコードの両フェーズで最適な再計算比率は ISL/OSL プロファイルにどう依存するか。 - SCBench が示した「sub-O(n) 手法のマルチターン破綻」は、マルチテナント環境で KV キャッシュ再利用（CacheBlend/KVShare）と組み合わせるとどう変化するか。 - NIXL の Memory Section / Metadata Handler のような登録・メタデータ交換抽象は、マルチテナント環境で最小情報公開とキャッシュ共有効率をどう両立すべきか。 ## 関連 - ソース: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] / [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]] / [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] / [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] / [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] / [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]] / [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] - エンティティ: [[vLLM]] / [[SGLang]] / [[LMCache]] / [[P-D-Serve]] / [[NIXL]] / [[Mooncake]] / [[CacheBlend]] / [[KVShare]] / [[SCBench]] / [[AIBrix]] - 関連 MOC: [[LLM4SRE - MOC]] / [[AI Infra Telemetry - MOC]] ## 出典 - [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] - [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]] - [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] - [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] - [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] - [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]] - [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] - [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]]（本番ワークロードの KV キャッシュ特性評価、ワークロード対応エビクション） - [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]]（非プリフィックス KV キャッシュ再利用、選択的再計算、EuroSys 2025 Best Paper） - [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]]（マルチテナント KV キャッシュ再利用、DHD アルゴリズム、デコード時アテンション・ドリフト） - [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]]（KV キャッシュ中心ベンチマーク、sub-O(n) 手法のマルチターン破綻、動的スパース性優位） - [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]]（クラウドネイティブ分散 KV キャッシュファブリック、scan-resistant eviction） - [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]（LMCache と NIXL の統合、異種ネットワーク/ストレージ抽象、Memory Section、Metadata Handler、VAST Storage 例）