# 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]]) - **KVCache 容量の具体的な見積もり式は、なぜ削減技術群が必要とされるかを直感的に示す**: LLM高速化の勉強会資料は `2 × batch_size × num_layers × sequence_length × head_dim × num_heads` という KVCache サイズの計算式を示し、batch=16・layers=96・seq=32768・head_dim=128・heads=8・float16 という条件で 192 GiB に達する例を挙げる。この単純な計算例は、PagedAttention のブロック管理、GQA/MLA のようなアーキテクチャ的圧縮、Speculative Decoding のドラフト設計制約など、KV キャッシュ管理の横断的知見が扱う多様な削減技術に共通する定量的な出発点を与える。(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]]) - **「KV 値レベルで近似一致させる」のではなく「コンテキスト(検索文書・メモリ)レベルで並べ替え・重複排除する」ことで、完全一致キャッシングの再利用率の低さと近似 KV マッチングの精度劣化を同時に回避できる**: [[ContextPilot]] は、RadixCache/LMCache のような完全一致方式が MultihopRAG + Qwen3-32B でヒット率わずか4.6%にとどまる一方、[[CacheBlend]] のような近似 KV マッチングは9〜11%の精度劣化を招くという二律背反を報告し、両者の間に「コンテキストブロックを prefix cache に整列させてから投入する」という第三の設計点を導入した。整列由来の精度低下は0.1〜3.3%と小さく、優先順位を伝える簡潔な注釈(annotation)でほぼ回復・上回ることさえある。これは、KV キャッシュ管理の最適化対象が「KV テンソルそのもの」から「KV テンソルの元になるコンテキストの提示順序」へ一段上流にシフトできることを示す。(Source: [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]]) - **現代 LLM の入力順序耐性の向上が、コンテキスト整列というシステム最適化を成立させる前提になっている**: ContextPilot は DEmO 順序感度研究(2024)を GPT-5.1 で再現し、SST2・SNLI・SUBJ・CR で近似ゼロの順序ギャップを確認した(GPT-3.5 時代は大きなギャップがあった)。これは、モデル世代交代がもたらす副次的性質(順序頑健性)を、システム設計者がキャッシュ最適化のために積極的に利用した例であり、KV キャッシュ管理の設計余地がモデル自体の進化にも依存することを示す。(Source: [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]]) - **標準化された実行トレースが、KV キャッシュのオフロードコストをベンダー非依存に定量化する手段を提供する**: [[MLCommons Chakra]] は GPU-CPU 間の KV キャッシュオフロードを Chakra ノードとして捕捉し、Llama3-8B でオフロード有効時に Memcpy DtoH が 387 回・0.895ms(ベースライン)から 5,958 回・216.484ms へ急増することを実測した。これまでの横断的知見の多くが「どう再利用・転送を高速化するか」という最適化アルゴリズムを扱うのに対し、Chakra はアルゴリズムを提案せず、既存システムのオフロード挙動を任意のフレームワーク・ハードウェアで比較可能な標準形式として可視化するという、補完的な計測インフラの役割を担う。(Source: [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]]) - **ホストメモリへの KVCache 退避は「再利用のためのキャッシュ層」だけでなく「障害復旧のためのバックアップ層」としても機能する**: Mooncake・LMCache はホスト DRAM/SSD を prefix 再利用のための階層キャッシュとして扱うのに対し、[[@2025__arXiv__FailSafe - High-performance Resilient Serving]] は同じ「GPU HBM より大容量で GPU 障害でも無傷なホストメモリ」という物理的性質を、GPU 障害発生時の KVCache 復旧に転用する(Proactive KVCache Backup)。稼働中に非同期でホストメモリへバックアップし続け、障害時は失われた分だけを再読み込みすることで、再計算比 41.5 倍の高速復旧を達成する。「ホストメモリへの退避」という同一の物理設計判断が、通常運用時は再利用ヒット率向上、異常時は復旧レイテンシ削減という異なる目的で二重に活用されている。(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]], [[@2025__arXiv__FailSafe - High-performance Resilient Serving]]) - **KVCache の GPU 間配置は、再利用ヒット率だけでなく耐障害性の観点からも設計対象になる**: これまでの横断的知見は KVCache の配置・退避をヒット率・TTFT・帯域の最適化として扱ってきたが、FailSafe の Cyclic KVCache Placement は同じ「どの GPU にどの KVCache を置くか」という問題を、GPU 障害後のメモリ不均衡緩和という別の目的関数で解く。テンソル並列の各層でヘッド-GPU 対応を周期的にローテーションすることで、素朴な配置比で約50%の KVCache メモリ利用改善を達成する。KV キャッシュ配置問題は「どこにあれば速く引けるか」に加えて「どこにあれば障害後も均等か」という第二の軸を持つ。(Source: [[@2025__arXiv__FailSafe - High-performance Resilient Serving]]) - **バッチ全体が事前に既知であるオフライン推論では、LRU の「暗黙的再利用」から DP による「明示的・大域的な prefix 拡大」へ設計原理が転換する**: SGLang の RadixAttention や vLLM の prefix-caching はいずれもリクエスト到着順に依存する LRU ベースの暗黙的キャッシュ管理であり、大規模バッチの中で「今後どのプレフィックスが再利用されるか」をグローバルに把握できない。[[BatchLLM]] はオフライン/大規模バッチ推論では入力プロンプト全体が処理前に既知であるという前提を利用し、compact prefix tree 上の動的計画法(Algorithm 1)で 1st-level prefix を事前に最大化してから明示的にグループ単位で再利用する。あるワークロードでは vLLM の暗黙的 LRU が理論上の最適節約率 58.1% に対し実測 35.8% しか達成できないのに対し、共有プレフィックス長 16000・share-degree 16 の条件では BatchLLM の token 再利用率が 92.6%(vLLM/SGLang は 6.3%/5.2%)に達する。これは KV キャッシュ管理の設計原理が「オンラインでは履歴からの推測」「オフラインでは事前の大域最適化」という 2 つの異なるレジームに分岐することを示す。(Source: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]]) - **KV キャッシュ再利用の効率は、スケジューリング粒度(リクエスト単位 vs グループ単位)にも依存する**: 既存システムはリクエスト粒度でスケジューリングするため、同じプレフィックスを共有するリクエストが時間的に分散し、共有 KV コンテキストのライフタイムが不必要に延びて他の再利用可能な KV が早期退避される。BatchLLM は prefix-sharing group(同じプレフィックスを共有するリクエスト集合)をスケジューリングの基本単位にすることで、共有 KV のライフタイムを圧縮し退避を防ぐ。KV キャッシュ管理の横断的知見はこれまで「どこに置くか・どう転送するか・どう圧縮するか」を扱ってきたが、BatchLLM は「どの粒度でリクエストをまとめてスケジュールするか」という第 5 の軸を提示する。(Source: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]]) - **KV キャッシュ転送は、再利用・退避・障害復旧に加えて「パイプライン並列化の負荷均衡」という第 4 の目的でも発生する**: これまでの横断的知見が扱う KV キャッシュ移動(SGLang/LMCache の再利用、Mooncake/LMCache の階層退避、FailSafe の障害復旧)はいずれも「同じ層を別の場所へ複製・移動する」操作だが、[[パイプライン並列化]] の DynaPipe における KV キャッシュ移行は、層のステージ割当自体が実行時に変わることに伴う「担当が変わった層の KV キャッシュを新しい担当ステージへ引き渡す」操作であり、性質が異なる。DynaPipe はソースステージが移行対象層の計算完了後に非同期送信し、ターゲットステージは新規割当層に到達するまで受信を待たずに他の層の計算を継続することで、計算と通信を重ねてこの移行コストを隠蔽する。KV キャッシュ移動の目的は「同じ配置構造の中でどこにキャッシュを置くか」から「配置構造(層のステージ割当)自体が動く」場合の移行という新しい軸に広がる。(Source: [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]], [[@2025__arXiv__FailSafe - High-performance Resilient Serving]]) - **KV キャッシュ容量制約への対応は「保持データ量を減らす(再利用/退避/エビクション)」と「保持データそのものを軽くする(量子化)」の 2 系統に分かれ、両者は直交して組み合わせ可能である**: これまでの横断的知見(Mooncake・LMCache・AIBrix 等)は KV キャッシュを FP16 のまま前提とし、どこに配置・退避・複製するかを最適化する。[[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost|Kitty]]([[KVキャッシュ量子化]])はこれと直交する軸として、KV キャッシュのビット幅そのものを 2-bit まで削減する。Kitty は Key チャネルのうち少数(12.5〜25%)だけを高精度(INT4)に保つことで、KIVI 等の均一 2-bit 量子化が抱える精度劣化(Qwen3-8B の MATH-Algebra で -40.97)をほぼゼロまで回復しつつ、有効ビット幅を長文脈で約 2.44 bit(6.6 倍圧縮)まで下げる。量子化によって同じ物理メモリで保持できる有効コンテキスト量が増えれば、Mooncake の Conductor や LMCache の階層退避が扱う「どのキャッシュを残すか」の判断対象そのものが小さくなるため、両軸の組み合わせ効果は未検証の設計空間として残る。(Source: [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **これまでソフトウェア層(ページング・階層ストレージ・エビクション)が担ってきた KV キャッシュ容量制約への対応に、ハードウェア側の容量増強という第 2 の軸が加わる**: Mooncake・LMCache・AIBrix 等はいずれも GPU HBM 容量を所与として、CPU/SSD への階層退避・エビクションポリシー・分散ファブリックでキャッシュ容量不足に対処してきた。[[NVIDIA Rubin GPU]] は GPU あたり最大 288GB の HBM4(帯域 22 TB/s)を提供し、記事はこれを明示的に「KV キャッシュオフロード不要な高並行性」の実現手段と位置づける。ソフトウェア側の横断的知見(GQA 移行で HBM の約 4 倍のキャッシュ容量が理想ヒット率に近づく、Aliyun Trace B)と突き合わせると、HBM4 の容量増加は既存のオフロード最適化群(LMCache の階層ストレージ、Mooncake の Conductor)が対処してきた問題の一部を、そもそも発生させない方向に押し返す可能性がある。ただし容量増加はコンテキスト長・並行性の要求も同時に押し上げるため、オフロード不要化がどこまで実現するかは長コンテキスト化の速度と HBM 容量拡大の速度の競争に依存する。(Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]], [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]]) - **GPU-CPU「密結合」ハードウェアでも、ページ粒度がボトルネックになる問題は解消されない**: LMCache・P/D-Serve はネットワーク/ストレージ転送に対して PagedAttention の GPU 内ページ粒度(20-63KB)が小さすぎることを問題としたが、SuperInfer は GPU-CPU 間を NVLink-C2C(900GB/s、PCIe の 14-28 倍)で直結した GH200 上でも、同じ「セグメントが小さすぎる」問題(Qwen2.5-32B で 64KB セグメント)により C2C 帯域を 5% 未満しか活用できないことを実測で示した。つまり帯域を桁違いに増やしても、KV キャッシュのメモリレイアウト(layer-first vs block-first)とカーネル起動粒度を co-design しない限り、ハードウェアの潜在能力は解放されない。「GPU 内 page とネットワーク/ストレージ転送 chunk の二重粒度」という既存知見に、「GPU-CPU 密結合インターコネクトも同じ粒度問題の対象になる」という第三の粒度階層が加わる。(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]], [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) - **KV キャッシュのオフロード判断は「容量」だけでなく「SLO 進捗」も入力にすべき、という設計原則が独立に複数系統で収斂しつつある**: SuperInfer の RotaSched は Virtual Lag Time(VLT)によりリクエストの TTFT/TBT 進捗の遅れを定量化し、GPU メモリに余裕があっても SLO 違反リスクが高いリクエストを能動的にプリエンプト・スワップする。これは、他の KV キャッシュ管理システム(Mooncake・LMCache 等)が主に「再利用率」や「容量」を最適化目標とするのとは異なる軸であり、[[LLMサービング管理]] が蓄積してきた SLO 駆動リクエストルーティングの知見と、KV キャッシュのオフロード配置判断が同じ「SLO 進捗」シグナルで統合されうることを示唆する。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) - **ハードウェア管理の透過的機構(GH200 Unified Memory)は、ソフトウェア明示制御のオフロードを代替できない**: GH200 は page-fault 非依存のハードウェアアクセスカウンタ駆動ページマイグレーションを持つが、SuperInfer の検証では CPU DRAM への初期アクセスが C2C 経由でも DRAM 自体の帯域(384GB/s、GPU HBM の 4TB/s の約1/10)に制限される「bandwidth cliff」により、LLM サービングのような短命・高頻度アクセスパターンでは migration が発火する前にリクエストが完了してしまい、著しい TBT 悪化を招く。これは「ハードウェアが自動でやってくれる」設計が KV キャッシュ管理には原理的に不向きであり、明示的なブロックテーブル管理(PagedAttention 系譜)が今後も必要であり続けることを裏付ける。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) - **スパース注意はメモリ削減ではなく容量ボトルネックの再配置であり、既存のホストメモリ階層退避の設計思想がそのまま適用できる**: これまでの横断的知見(Mooncake・LMCache・AIBrix 等)は密な(dense)注意を前提に、KV キャッシュ全体をどこに配置・退避・複製するかを最適化してきた。[[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory|HiSparse]]([[スパース注意]])は、top-k スパース注意が計算量を削減しても「フルコンテキストの KV キャッシュを高速アクセスのため GPU HBM に保持し続ける必要がある」という制約は残ることを指摘し、不活性エントリのホストメモリ退避 + GPU HBM 上の hot device buffer という、既存のホストメモリ階層退避と同じ設計パターンをスパース注意に適用して並行数256でベースライン比3倍超のスループットを達成した。これは、スパース注意の導入が KV キャッシュ管理の必要性を減らすのではなく、「どのエントリが active か」を追加で判定する層(top-k キャッシュミス処理)を既存の階層メモリ設計に上乗せする形で残ることを示す。(Source: [[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory]]) ## 未解決の問い - KV キャッシュ量子化(Kitty 等、[[KVキャッシュ量子化]])とキャッシュ配置・退避・エビクション最適化(Mooncake・LMCache・AIBrix)を同一システムで組み合わせた場合、量子化による有効容量増加は本番トレースが示す再利用率の構造的上限(Aliyun to-B 54%)自体を引き上げるか、それとも別の軸の改善に留まるか。 - Rubin の HBM4 容量拡大(288GB)は、本番トレースが示す KV キャッシュ再利用率の低さ(Aliyun to-B 54%)やホットブロックの短寿命性(P99 97 秒)をどの程度緩和するか。容量増加だけでは解決しない構造的なワークロード特性(シングルターン支配)は残るか。 - 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 キャッシュ再利用は、正確性を壊さずにどこまで可能か。→ [[ContextPilot]] は「KV 値の近似一致」ではなく「コンテキストの整列・重複排除+注釈」というコンテキストレベルの折衷案で、精度劣化 0.1〜3.3%(整列由来)まで抑えつつ最大3倍のプリフィル高速化を達成したと報告する。ただし、コンテキスト重複率が低い(整列で得られる共有プレフィックスが乏しい)ワークロードでの限界や、α(距離関数の重み)の感度は十分に検証されていない。 - CacheBlend 自身の論文([[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]])は精度損失を F1/Rouge-L で0.01〜0.03程度と報告するが、[[ContextPilot]] は同種の近似 KV マッチングで9〜11%の劣化を観測したと報告する。評価条件(選択的再計算比率、チャンクサイズ、比較対象設定)の違いを両論文から突き合わせて、どちらの条件がより実運用に近いかを検証する必要がある。 - 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 のような登録・メタデータ交換抽象は、マルチテナント環境で最小情報公開とキャッシュ共有効率をどう両立すべきか。 - FailSafe のプロアクティブホストバックアップは単一 GPU/ノード構成での復旧を対象とする。Mooncake・LMCache のようなクラスタ横断 KVCache 管理層と統合した場合、「通常時の再利用のための配置」と「障害復旧のためのバックアップ配置」という2つの目的関数はどう調停すべきか(同じホストメモリ容量を奪い合う可能性)。 - DynaPipe の非同期 KV キャッシュ移行(パイプラインステージ間)と、既存の再利用/退避/障害復旧のための KV キャッシュ移動は、同一システムで競合しうるか。層再配分が発火するタイミングと、prefix キャッシュのエビクション・階層退避のタイミングが重なった場合、どちらを優先すべきか。 - BatchLLM の DP による 1st-level prefix 拡大(オフライン・バッチ全体既知が前提)は、リクエストが継続的に到着するオンラインストリーミング環境でどこまで適用できるか。バッチ境界を区切って準リアルタイムに DP を再実行するハイブリッド方式は、SGLang の RadixAttention や LMCache の階層退避と比べてどの程度の追加レイテンシで成立するか。 - BatchLLM は prefix-sharing group 単位のスケジューリングでリクエスト個別のレイテンシを犠牲にすると著者自身が認めている。Cache-aware scheduling の公平性問題(SGLang の longest-shared-prefix-first の starvation 懸念)と、BatchLLM のグループ優先度(R_group)は同じトレードオフ構造を共有するか、それとも質的に異なる制約か。 - SuperInfer の VLT(Virtual Lag Time)による SLO 駆動オフロード判断を、Mooncake・LMCache のような再利用率最適化の KV キャッシュ配置ポリシーと同一システムで組み合わせた場合、「SLO 違反リスクの高いリクエストを優先的に GPU に留める」ことと「将来の再利用可能性が高いブロックを優先的に GPU に留める」ことは競合しうるか。両者を単一の優先度スコアへ統合する設計は可能か。 - SuperInfer の block-first レイアウト(全レイヤーを 1 ブロック内で連続配置)は、PagedAttention の GPU 内ページ粒度最適化の系譜と両立するか。特に、LMCache や NIXL が前提とする GPU 外転送 chunk(256 token 程度)の設計と、block-first レイアウトが生む転送単位(4MB クラス)は整合するか、それとも Superchip 固有の別レイヤーとして扱うべきか。 - GH200 の bandwidth cliff(DRAM 384GB/s の半二重制約)は、Grace CPU の DRAM 容量を KV キャッシュオフロード先として使う他の Superchip 世代(AMD MI300A、将来の NVIDIA Vera Rubin 世代)でも同様の構造を持つか。世代が進むにつれ CPU 側 DRAM 帯域とスケジューリング設計の関係はどう変化するか。 ## 関連 - ソース: [[@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__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]] / [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]] / [[@2025__arXiv__FailSafe - High-performance Resilient Serving]] / [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]] / [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]] / [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]] - エンティティ: [[vLLM]] / [[SGLang]] / [[LMCache]] / [[P-D-Serve]] / [[NIXL]] / [[Mooncake]] / [[CacheBlend]] / [[KVShare]] / [[SCBench]] / [[AIBrix]] / [[ContextPilot]] / [[MLCommons Chakra]] / [[NVIDIA Rubin GPU]] / [[NVIDIA GH200]] - 概念: [[耐障害LLMサービング]] / [[パイプライン並列化]] / [[KVキャッシュ量子化]] - 教科書: [[wiki/questions/KVキャッシュ管理の教科書]] — 本ページの横断的知見を 13 部 35 章に体系化(矛盾 4 件と数値引用の注意 12 件を付録に集約) - 関連 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 例） - [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]]（コンテキストレベルの整列・重複排除・注釈による KV キャッシュ再利用、完全一致 vs 近似 KV マッチングの二律背反を回避、MLSys 2026 Oral） - [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]]（標準実行トレースによる KV キャッシュオフロード・PD 分離間 KV 転送のベンダー非依存な計測、MLSys 2026 Oral） - [[@2025__arXiv__FailSafe - High-performance Resilient Serving]]（Cyclic KVCache Placement による障害耐性配置・Proactive KVCache Backup によるホストメモリ復旧、再計算比 41.5 倍高速化） - [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]]（Rubin GPU の HBM4 最大 288GB・22 TB/s によるオフロード不要な高並行性の実現) - [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]](パイプラインステージ間の非同期 KV キャッシュ移行、計算・通信オーバーラップによる無停止レイヤー再配分) - [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]](チャネル単位混合精度 2-bit KV キャッシュ量子化、page-centric レイアウト、MLSys 2026) - [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]](GPU-CPU 密結合 Superchip 向け SLO 認識 KV キャッシュローテーション、RotaSched + DuplexKV、TTFT SLO 達成率最大 74.7% 改善、MLSys 2026) - [[@2026__LMSYS Blog__HiSparse - Turbocharging Sparse Attention with Hierarchical Memory]]([[スパース注意]]の容量ボトルネックをホストメモリ階層退避 + hot device buffer で緩和、並行数256でベースライン比3倍超・長文脈で最大5倍のスループット改善、LMSYS Blog 2026-04-10)