# 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キャッシュ量子化]] - [[LLMサービング管理]] - [[Prefill-Decode分離]] - [[エージェント型コーディング]] - [[パイプライン並列化]] - [[動的バッチングと継続的バッチング]] ## 横断的知見 - **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 キャッシュの退避先は CPU/SSD 階層だけでなく、同一ノード内のピア GPU HBM も低レイテンシ階層として扱える**: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving|DynamoServe]] は、FlexGen の CPU/NVMe オフロードや Aqua の単一ピア GPU オフロードと異なり、複数ピア GPU に KV キャッシュを分散配置できる。短コンテキストでは重みのみピア GPU へ、長コンテキストでは KV キャッシュも段階的にスピルする。これは LMCache の「GPU 外階層」と Mooncake の「CPU DRAM プライマリキャッシュ」の間に、NVLink 接続ピア GPU という第 3 の退避階層が存在することを示す。(Source: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant 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]]) - **エージェント型コーディングは「ターン境界」「モデル切替」「コンテキスト圧縮」という 3 つの構造イベントを持ち、それぞれが異なる劣化幅で本番トレース上に定量化できる**: これまでの横断的知見はマルチテナント環境での再利用率・退避粒度・障害耐性を主に扱ってきたが、[[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] は GitHub Copilot コーディングエージェントの 1,350 万本番セッションで、単一セッション内部の時系列に沿ったキャッシュ劣化イベントを 3 段階で定量化した: (1) ターン内の同一モデル呼び出しでは 87%→91% と安定、(2) 同一モデルのターン境界では 81%→55%(-26 ポイント)、(3) モデル切替を伴うターン境界では 75%→8%(-67 ポイント、ほぼ完全な無効化)。コンテキスト圧縮はさらに独立した第 3 のイベントとして、発火時に中央値でキャッシュヒット率を 66.1% 失う(34.3% のイベントは 90% 以上を喪失)。既存知見(Aliyun Trace B の KV ブロック P99 寿命 97 秒・指数分布)が「時間経過による摩耗」を扱うのに対し、本論文は「どの構造的イベントがどれだけ壊すか」という原因別の劣化を切り分けた点で補完的である。(Source: [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] §5.2-5.4, §6, [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]]) - **ターン間アイドル時間の分布は、Aliyun トレースが示す短命 KV ブロック寿命と同じ「時間ベースエビクションの崖」構造を、エージェント型ワークロードの粒度で裏付ける**: Aliyun Trace B は KV ブロック P99 寿命が 97 秒の指数分布であることを示したが、GitHub Copilot の特性化はこれをターン境界という意味的単位で再現する: アイドルギャップが 2 分未満なら安定して高ヒット率(中央値 95% 超)を保つが、2〜10 分で急落(中央値約 70%)し、10 分を超えるとほぼ完全崩壊(中央値 0〜5%)する。ターン内アイドル(KV キャッシュ中央値 1.2 秒)とターン間アイドル(KV キャッシュ中央値 172 秒=2.9 分)の 2 桁の差は、「時間ベースのエビクションタイムアウトが引き起こす崖」というサービング側のポリシー的性質を、ワークロード側の意味的境界(ターン)と対応づけて説明する初めての本番証拠である。(Source: [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] §5.3, §9.1, [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]]) - **ユーザーアーキタイプ間の 50 倍のトークン消費格差は、均一な KV キャッシュエビクションポリシーの機会費用を定量化する**: Mooncake・Aliyun トレースはキャッシュミスのコストを再プリフィルトークン数として扱うが、絶対量の分布は示さない。本論文はユーザーを 5 アーキタイプ(Readers・Coders・Terminal users・Deep-loop users・Chat-only users)に分類し、Deep-loop ユーザーのキャッシュミス 1 回あたりの再プリフィルコスト(中央値 110 万トークン)が Chat-only ユーザー(中央値 2.3 万トークン)の約 50 倍に達することを示した。これは、均一なエビクションタイムアウトが Deep-loop ユーザーに不均衡に高いレイテンシ税を課す一方、Chat-only/Reader セッションは積極的なエビクションでもほぼ無害であることを意味し、アーキタイプ対応の階層化 SLO(保持優先度・エビクション積極性・容量計画の 3 軸)という設計原則を、既存の SLO 駆動オフロード判断(SuperInfer の VLT)とは異なる「ユーザー行動セグメント」という粒度から補強する。(Source: [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] §8, [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) - **KV キャッシュのハードウェア階層コストは、DRAM と NAND フラッシュの間に約 200 倍の価格差があり、わずかなヒット率改善が演算需要を半減させるほど非線形に効く**: これまでの横断的知見は再利用率・退避粒度・障害耐性というソフトウェア設計の観点を主に扱ってきたが、OCTS 2026 の業界横断報告(沐曦/MetaX)は 1TB DDR5(約 2.8 万ドル)対 1TB NAND フラッシュ(約 140 ドル)という約 200 倍のコスト差を示し、ヒット率 95%→97.5%(ミス率 5%→2.5%)という一見小さな改善が、1M トークンあたりの prefill 必要トークン数を 5 万から 2.5 万へ半減させると分析する。Aliyun 本番トレースが示す理想ヒット率(to-B 54%)の構造的低さと突き合わせると、ヒット率改善への投資対効果はハードウェア階層のコスト構造(DRAM/NAND 価格比)によって非線形に増幅されることが示唆される。またサムスン電子は、Agentic AI の永続セッション・ツール出力・推論トレースの蓄積により 1 ユーザーあたり約 10GB・1,000 ユーザーでシステムレベル 10TB に達すると試算し、Active/Archive の用途別 2 階層(TLC/QLC SSD)を提案しており、これは Mooncake・LMCache が扱う CPU DRAM 階層のさらに外側(SSD 階層)の設計選択として位置づけられる。(Source: [[@2026__SpeakerDeck__AIインフラの最新技術動向 2026 — 中国OCPコミュニティから読み解く6つの技術トレンド]], [[@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]]) - **PD Disaggregation下でのKV Cache転送量は、モデル規模・入力長・同時接続数の組み合わせで数百MBから数百GBまで4桁変動する**: [[@2025__SpeakerDeck__AIインフラを考える]] は `KV Cache Size = 2 × n_layers × (n_heads × head_dim) × seq_len × precision_bytes × batch` という MHA構造の計算式で、7B MHAモデル・4Kトークンで約2.0GB、Llama3 8Bで入力1K/8Kトークンならそれぞれ0.13GB/1.0GB、Llama3 405Bで入力8K×同時接続100リクエストなら420GBに達する試算を段階的に示した。さらに100/400/800 Gbpsの転送速度でのKV Cache転送時間を具体値(405B・8Kで100Gbps=33.6秒、800Gbps=4.2秒)として提示し、「このKV Cache転送にかかる時間がユーザー体験を悪化させるが、ユーザーの入力傾向次第でシステムにかかる負荷が変わるのがインフラ設計上難しいポイント」と結論づけた。既存知見(さくらのナレッジ、Llama-3.1-405B・8k入力で約4GB/リクエスト)と整合しつつ、単一値ではなくモデル規模×入力長×同時接続数の3軸でのスケーリング表を提供する点で補完的である。(Source: [[@2025__SpeakerDeck__AIインフラを考える]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) - **KV Cache転送先ネットワークの選択(Scale Up vs Scale Out)は、転送時間そのものを左右する設計変数である**: 同資料は、KV Cacheの転送先としてScale Up(PCIe Gen5/Gen6・NVLink 4.0/5.0、最大900GB/s)とScale Out(400G/800G NIC・DPU、最大100GB/s)の2つの経路があり、どちらを使うかでボトルネックが変わることを示した。「サーバのレイアウトやインフラ構成によって選択できる経路が変わる→どこがボトルネックになるか知っておく」という指摘は、[[Prefill-Decode分離]]の設計判断が単なる資源分離の是非だけでなく、KV Cache転送層に実際に使えるネットワーク帯域の物理的上限に強く制約されることを具体的な帯域数値とともに裏付ける。(Source: [[@2025__SpeakerDeck__AIインフラを考える]]) - **プレフィックスキャッシュのデータ構造(trie/radix tree)とその運用パラメータ(マージ率計測・LRUエビクション)は、既存の横断的知見が扱う配置・退避・転送の議論を実装レベルで裏付ける**: これまでの横断的知見は主に KV キャッシュの配置・退避・転送戦略というシステムレベルの設計を扱ってきたが、[[@2025__OReilly__AI Systems Performance Engineering - Chapter 16 Profiling, Debugging, and Tuning Inference at Scale]] は vLLM のトークン列 trie と SGLang RadixAttention の圧縮 radix tree という、既存知見の背後にある具体的なデータ構造とその運用手順(`vllm:gpu_prefix_cache_queries`/`vllm:gpu_prefix_cache_hits` によるヒット率計測、プレフィックスマージが機能しない場合はトークナイザ差異を疑う、というデバッグ手順)を提供する。これは既存の SOSP/NeurIPS 論文が示すアルゴリズムを、本番運用でどう観測・デバッグするかという実務的な補完情報である。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 16 Profiling, Debugging, and Tuning Inference at Scale]] §Prefix Caching, §Profiling, Debugging, and Tuning Inference Performance, [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]]) - **継続的バッチングとプレフィックスキャッシュは独立した最適化軸だが、GPU上で同時に運用される**: Chapter 16 は継続的バッチング(トークン生成イテレーションごとのシーケンス入れ替え)とプレフィックスキャッシュ(共有プレフィックスのKV再利用)を別々の技法として説明するが、vLLM・SGLangはこれらを同一エンジン内で組み合わせて運用する。KVキャッシュ管理の「どの粒度でスケジュールするか」という既存の未解決の問い(BatchLLMのprefix-sharing group単位スケジューリング)と、継続的バッチングの「トークン単位でスケジュールする」という粒度は、同じスケジューラ内でどう調停されるかが明確に述べられていない。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 16 Profiling, Debugging, and Tuning Inference at Scale]] §Continuous Batching, §Prefix Caching) → [[動的バッチングと継続的バッチング]] - **分離型KVキャッシュプールは「クラスタ全体のGPUメモリを仮想メモリ化する」という単一の設計原理で、Mooncakeの3プール分離とLMCacheの階層退避を統合的に説明できる**: これまでの横断的知見はMooncakeのConductor(局所キャッシュ長・転送時間・推定TTFTの加算最小化)とLMCacheの階層ストレージを別々の実装として扱ってきたが、『AI Systems Performance Engineering』第18章はこれらを「GPU device memoryをアクティブページ、CPU DRAM/NVMeをオーバーフローのバッキングストアとする多層メモリ階層」というOSの仮想メモリに相似した単一の設計原理として整理する。250,000トークンのコンテキストがFP16で約328GB、FP8+選択的レイヤーキャッシングで約100〜150GBに達するという具体的な計算は、Mooncakeの「精密予測なし複製」やLMCacheの階層退避が対処する容量問題の桁数を裏付ける。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **KV転送のページ収集(collation)最適化は、LMCache+NIXLの実測とAI Systems Performance Engineeringの実装ガイドで独立に同じ数値(20ms→8ms)が確認された**: PyTorch Conference 2025のLMCache+NIXL資料が示すKV転送の性能特性を、第18章はさらに具体的な運用パラメータ(128トークン以上のページに収集、専用CUDAストリームでのオーバーラップ、`UCX_RNDV_THRESH=16384`によるrendezvous/eagerしきい値調整)として補完する。両ソースが同一の7,500トークンKVで約20ms→約8msという数値を報告することは、この最適化が実装依存のノイズではなく物理的なRDMAプロトコルオーバーヘッド(WQE数削減)に由来する再現性のある効果であることを示す。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]], [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]) - **Decode専用カーネル(FlashMLA/ThunderMLA/FlexDecoding)によるカーネル融合は、KVキャッシュ管理の最適化軸を「データの配置・転送」から「データへのアクセスパターンそのもの」へ拡張する**: これまでの横断的知見はKVキャッシュを「どこに置き、どう転送し、どう圧縮するか」というデータ管理問題として扱ってきたが、第18章のPOD-Attention(SM-aware CTAスケジューリングでprefillとdecodeを同一SMに動的割当、アテンション性能最大29%改善)やFlexDecodingのPagedAttentionブロックマスク変換は、KVデータ自体を動かさずカーネル起動とメモリアクセスパターンを最適化することで同種の効果を得る。これは、KVキャッシュ管理が「データ移動の最適化」と「データアクセスの最適化」という2つの独立した(しかし組み合わせ可能な)最適化レイヤーを持つことを示す。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]]) - **KV プリフェッチは「複数リクエスト間の再利用」から「単一リクエスト内の TTFT 短縮のための投機的先読み」へ、既存知見が扱う粒度と異なる次元を追加する**: これまでの横断的知見(vLLM/SGLang/LMCache/Mooncake)は主に複数リクエスト間の KV キャッシュ再利用・退避・転送を扱うが、第19章の SpeCache と Hugging Face `OffloadedCache` は、単一リクエストの prefill から decode への移行時に、次のレイヤーの KV を CPU から GPU へ非同期プリフェッチする「1 レイヤー先読み」の仕組みである。これは既存知見が示す「GPU 内 page とネットワーク/ストレージ転送 chunk の二重粒度」(LMCache・P/D-Serve・SuperInfer)にさらに「レイヤー単位の投機的先読み」という第四の粒度を加える。オフロードによるスループット低下は約 5〜10% に留まり、CPU 常駐 KV でも TTFT への影響が最小化されると報告される。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **KV キャッシュ量子化のビット幅切り替えは、Kitty のような静的最適構成の探索から、メモリ圧に応じた実行時ポリシー切り替えへと発展する余地がある**: [[KVキャッシュ量子化]] の Kitty はチャネル単位の精度配分を事前に最適化する静的手法だが、第19章のリアルタイム KV キャッシュ圧縮は、GPU メモリ使用率の閾値(例: 80% で 8-bit へ、極度の圧迫で 4-bit へ)に応じて FP16→INT8→INT4 へ実行時に切り替え、直近トークンのみ高精度に保つスライディングウィンドウ方式を採る。フラッピングを避けるヒステリシス(クールダウン)の導入や、チャンク単位での安全な切り替えタイミング(イテレーション境界)という実装上の制約は、Kitty のような静的手法には現れない、動的ポリシー特有の設計課題である。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]], [[@2026__MLSys2026__Kitty - Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost]]) - **サーバーレス環境ではKVキャッシュの生存管理主体が「サービング内部のエビクションポリシー」から「デプロイスキーム側のスケールダウン判断」へ一段外側に移る**: これまでの横断的知見(Mooncake・LMCache・AIBrix等)はいずれも常駐推論エンジン内部でのKVキャッシュのエビクション・退避・再利用を扱ってきた。[[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]] はこれと異なる文脈として、エージェントのSLM(Small Language Model)インスタンス自体がサーバーレス環境でスケールダウン(アンロード)される場合に、将来の推論呼び出しのためKVキャッシュをどう永続化するかという問題を提起する。同論文はCORTEX(Pagonas ほか 2025、未 ingest)が推論リクエストをステージ単位で専用インスタンスへルーティングしてキャッシュヒット率を高める点、HELIUM(Wadlom ほか 2026、未 ingest)がエージェントプロンプトの静的部分をコンパイル時に事前計算しグローバルにキャッシュ・プリロードする点を挙げ、「KVキャッシュは数ギガバイトまで成長しうるため、ディスク保存と再計算のトレードオフは依然として微妙な問題として残る」と位置づける。これは、KVキャッシュ管理の設計対象が「常時起動インスタンスの中での容量管理」に加えて「インスタンスのライフサイクル(存在するかしないか)をまたぐ永続化」という新しい軸を持ちうることを示唆する。(Source: [[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]] §4.4) - **KVキャッシュ再利用の軸が「同一モデル内のリクエスト間」から「異なるサイズのモデル間」へ拡張する**: これまでの横断的知見(vLLM・SGLang・LMCache・Mooncake等)はすべて単一モデルのKVキャッシュを前提とし、リクエスト間・レイヤー間・GPU間でどう配置・転送・共有するかを扱ってきた。[[@2026__arXiv__Cross-Model KV Cache Transfer in LLM Families - A Closed-Form Linear Mapping for Prefill Reuse]] はこれと直交する軸として、同一ファミリの異なるサイズのモデル(例: Qwen3 14B→32B)間でKVキャッシュそのものを写像し、受信側の再プリフィルを省略する。KVヘッド数・ヘッド次元が一致する「matched-KV」ペアという前提付きだが、勾配学習なしのper-headリッジ回帰という閉形式解で6ペア中4ペアが標準精度の73〜98%を保持し、再プリフィルより2.7〜25倍高速という結果は、KVキャッシュ管理が「同一モデル内での配置最適化」に加えて「モデル切替時の再利用可能性」という新しい設計対象を持ちうることを示す。既存のPrefix caching(SGLang RadixAttention等)がプレフィックスの完全一致を前提とするのに対し、本手法はモデルが異なっても入力トークン列が同一であれば適用でき、コスト品質カスケーディングやルーティングでのモデル切替コストを直接削減する点で、モデル切替時のKVキャッシュ劣化を実測した [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] の知見(モデル切替で-67%ポイント)とも接続しうる。(Source: [[@2026__arXiv__Cross-Model KV Cache Transfer in LLM Families - A Closed-Form Linear Mapping for Prefill Reuse]]) - **「転送品質を決めるのは誤差の大きさではなく誤差の着地位置」という知見は、KVキャッシュ量子化・圧縮の評価指標にも転用しうる**: cross-model KV転送研究は、校正R²(平均的な再構成誤差)がペア間の転送品質を予測せず、attention出力コサイン類似度(誤差がattentionが実際に読む部分空間にどれだけ集中しているか)の方が下流精度と強く相関する(r=+0.57 vs r=−0.20)ことを示した。これは、[[KVキャッシュ量子化]] のKittyが採用するチャネル単位精度配分の評価や、LMCache・Mooncakeの選択的再計算・エビクション判断においても、単純な再構成誤差(MSE・R²)ではなくattention感度で重み付けした誤差指標の方が、下流タスク精度をより正確に予測しうる可能性を示唆する。既存のKVキャッシュ最適化の多くはMSEベースの再構成誤差やヒット率で評価されており、attention-aware な評価指標への転換は横断的な検証課題として残る。(Source: [[@2026__arXiv__Cross-Model KV Cache Transfer in LLM Families - A Closed-Form Linear Mapping for Prefill Reuse]] §4.5) - **master-executor アーキテクチャの下で、KVキャッシュの「照合」と「取り込み」を別APIに分離し取り込みだけを非同期化する設計は、Mooncake・LMCacheの階層退避とは異なる粒度でNPU待ちを削減する**: [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]](Huawei Cloud)の Relational Tensor Cache(RTC)は、`MatchByPrefixToken`/`MatchByID` による同期的な照合と、`Populate` による非同期的な NPU への取り込みを明確に分離する。sched-enqueue スレッドは `match` でキャッシュ有無とコストモデルによる再利用可否を判断した後、有益と判断した場合のみ `populate` を非同期に呼び出し、RTC が DistFlow 経由で階層ストレージまたは他 TE から KV を読み込む間もスケジューラは次のリクエスト処理を続ける。Mooncake・LMCache が「どこに何を配置するか」という階層設計を中心課題とするのに対し、RTC は同じ階層設計の上に「照合(同期)と取り込み(非同期)を分離してNPUを待たせない」という実行モデル側の最適化を重ねる点で補完的である。(Source: [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]] §4.2, §4.3) - **KVキャッシュ管理層は、prefix-token ベースのインデックス(RadixAttention由来)と ID ベースの明示的インデックスを同一データ構造上で共存させることで、暗黙のプレフィックス再利用と明示的なコンテキストキャッシュ API の両方に応えられる**: DeepServe の RTC は SGLang 由来の radix-tree インデックスと ID ベースインデックスを組み合わせたハイブリッドインデックス層を持ち、FlowServe の暗黙キャッシュ(prefix-token ベース)と DeepServe の明示的コンテキストキャッシュエンドポイント(ID ベース)の双方に単一の RTC が応える。これは、[[ContextPilot]] が「完全一致 vs 近似一致」というマッチング精度の軸で KV キャッシュ再利用を拡張したのとは異なる軸——「暗黙のプレフィックス共有 API と明示的なキャッシュ管理 API をどう同一インデックス上で統合するか」という API 設計の軸——を示す。(Source: [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]] §4.3) - **Kubernetes ネイティブなキャッシュ認識ルーティングは、プレフィックスキャッシュヒット率をレプリカ選択のシグナルとして Gateway API レベルへ引き上げる**: これまでの横断的知見が扱う RadixAttention(SGLang)・LMCache・Mooncake は、いずれも単一の推論エンジン内またはエンジン間の KV キャッシュ配置・転送を扱ってきた。Red Hat + Illinois Institute of Technology の産業論文が報告する Kubernetes Gateway API Inference Extension(GAIE)は、これと異なる層でキャッシュ認識を実装する。KV キャッシュテレメトリをレプリカ選択(InferencePool の Endpoint Picker)の入力として Kubernetes のロードバランシング層(Gateway/Service）に統合し、「Precise Prefix-Cache Aware Scheduling(well-lit path)」という戦略でプレフィックス一致レプリカへ優先的にルーティングする。実験(Qwen3-8B、8 レプリカ、GPU あたり KV キャッシュ容量 143,360 トークン、合計プロンプト量がキャッシュ容量を上回る負荷)では、ランダムルーティング比で平均 TTFT を約 6.25 倍改善、99 パーセンタイル TTFT を最大 90% 改善した。これは、プレフィックスキャッシュ管理の最適化対象が「単一エンジン内のデータ構造」(trie/radix tree)や「エンジン間の転送」(Mooncake・LMCache)に加えて、「Kubernetes のサービスディスカバリ・ロードバランシング層」という新しい統合ポイントを持ちうることを示す。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - **NIXL を共通のストレージバックエンド抽象として、フレームワーク非依存の階層管理ロジックを別コンポーネントに切り出す設計が独立に確立されつつある**: これまでの横断的知見は、Mooncake の Conductor・LMCache の階層退避のように、階層キャッシュ管理ロジックが特定の推論エンジンに強く結合した実装として扱われることが多かった。[[NVIDIA Dynamo]] の [[KVBM (KV Block Manager)]] は、LLM 推論ランタイム層(コネクタで vLLM・TensorRT-LLM を接続)・KVBM ロジック層(ブロック生存周期・エビクションポリシー)・[[NIXL]] 層(実データ転送)という3層に明確に分離し、「複数の推論エンジンから共有される独立したメモリ管理コンポーネント」という設計を取る。ただし SGLang は KVBM に対応せず、自身の HiCache が NIXL を直接呼ぶ経路を選んでおり、フレームワーク非依存の共通レイヤーを挟む設計とエンジン内蔵の階層キャッシュ実装のどちらを取るかは、システムごとに異なる選択が続いている。(Source: [[@2026__NVIDIADynamoDocs__KVBM (KV Block Manager) 概要]]) - **「LLM×DATA」サーベイの KV シュリンキング3手法(CacheGen・MiniCache・HCache)は、既存知見が扱う「配置・転送」の粒度問題とは独立した「何を圧縮対象にするか」という第3の軸を、それぞれ異なる層で示す**: 本ページのこれまでの横断的知見は、GPU 内 page(vLLM/vTensor のブロック単位)とネットワーク/ストレージ転送 chunk(LMCache の 256 token 単位)という「配置・転送の粒度」を主題としてきたが、サーベイが紹介する3手法は圧縮の**対象そのもの**を変える: CacheGen はカスタムテンソルエンコーダで KV を効率的なビットストリームへエンコードし帯域使用量を削減する「層内冗長性」の圧縮、MiniCache は隣接層間の KV キャッシュ状態の類似性(大きさ・方向成分への分解、SLERP によるマージ)を利用する「層間冗長性」の圧縮、HCache は KV そのものでなく KV の半分のサイズしかない隠れ状態(hidden states)のみを保存し必要時に再計算する「保存対象の格下げ」である。これは、既存知見が確立した vLLM/vTensor の論理・物理ブロック分離という枠組みの**内側**で、ブロックの中身をどう軽量化するかという独立した設計軸が存在することを示す。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.6) - **RAGCache・CachedAttention の KV 配置戦略は、Mooncake の Conductor・LMCache の階層退避と同一の「アクセス頻度に基づく高速/低速ストレージ間の階層化」原理を、RAG 特化のコスト関数で独立に再確認する**: RAGCache は prefix-aware PGDSF(アクセス頻度・サイズ・再計算コストに基づく)置換ポリシーで頻繁アクセスデータを GPU メモリへ、低頻度データをホストメモリへ配置する。CachedAttention は推論ジョブスケジューラの観測に基づき、保留中ジョブの KV キャッシュを実行前にディスクからホストメモリへプリフェッチし不要な KV キャッシュを退避する。いずれも「どこに置けばヒット率・レイテンシが最適か」という Mooncake・LMCache と同型の問いに RAG 文脈で答えており、KV キャッシュの階層配置という設計原理が推論サービング全般(Mooncake・LMCache)と RAG 特化システム(RAGCache・CachedAttention)の双方で独立に収斂していることを示す。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.6, [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **ChunkAttention の prefix tree・PSM の列/行並べ替えは、SGLang RadixAttention が確立した「prefix tree でリクエスト間 KV 共有を最大化する」という設計を、インデックス構造・データレイアウトという異なる角度から補強する独立実装である**: ChunkAttention は KV キャッシュを prefix-aware KV cache(PAKV)として prefix tree に組織化し共通プレフィックスのキーバリューテンソルを共有する、SGLang の radix tree と同型の設計。PSM(Prefix Sharing Maximization)はデータの列・行を動的に並べ替えて(列は値の頻度・サイズでソート、行は共有プレフィックスを持つリクエストでグルーピング)prefix 共有を最大化する、レイアウト最適化という異なる角度からの寄与である。SGLang(NeurIPS 論文)と ChunkAttention/PSM(本サーベイが紹介する引用研究)が独立に「prefix tree/木構造による共有最大化」という同じ設計原理へ到達していることは、この原理が特定実装に依存しない一般解であることを裏付ける。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.6, [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]]) - **KV キャッシュメモリ管理の粒度は「事前確保長の予測」→「ブロック単位ページング」→「トークン単位管理」→「レイアウト最適化」という系譜で細分化してきた**: 『A Survey on Efficient Inference for Large Language Models』は、S3 が生成長の上限予測により事前確保空間の浪費を削減し、vLLM の PagedAttention がブロック単位の非連続ページングで断片化を解決し、LightLLM がさらにトークン単位まで粒度を細かくして不規則な境界の浪費を削減し、FlashInfer が多様なデータレイアウト + アクセス方式で paged storage と attention 演算子の不規則メモリアクセスを調停する、という 4 段階の発展を通時的に整理する。本ページの既存知見(LMCache の 20-63KB ページ vs 256 token チャンクという「二重粒度」)は GPU 内外の転送粒度を扱うのに対し、本サーベイの系譜は GPU 内部でのブロック粒度そのものが時系列でどう細分化されてきたかを補完する。(Source: [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 6.1 System-level Optimization - Serving System]] §6.2.1, [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]) - **paged KV キャッシュストレージと attention 演算子の効率化は、サーベイの時点(2024年)で既に「サービングシステムの発展における最前線の課題」と位置づけられていた**: PagedAttention は非連続なブロック管理で断片化を解決する一方、attention 演算子側では仮想アドレス空間と物理アドレス空間のマッピングを考慮した連続メモリアクセスへの調整が必要になるというトレードオフを生む。本ページが後に蓄積した SuperInfer の block-first レイアウト問題(GPU-CPU 密結合 Superchip でも「セグメントが小さすぎる」問題が再燃する)は、この 2024 年時点で予見されていた課題が、ハードウェア世代が進んでも解消されていないことを裏付ける。(Source: [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 6.1 System-level Optimization - Serving System]] §6.2.1, [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) - **LightLLM のトークン単位細粒度化は、Zhou サーベイが定量化していない「他の最適化と重なったときの負のトレードオフ」を、Miao サーベイが定性的に補完する**: 本ページ既出の未解決の問い(LightLLM のメタデータ管理コストが『A Survey on Efficient Inference for Large Language Models』で定量比較されていない件)に対し、[[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 3.2 Taxonomy - System Optimization]] は同じ LightLLM のトークン単位管理を「フラグメンテーションしたメモリ管理機構のオーバーヘッドは新たな課題をもたらし、他の最適化(バッチサイズ拡大)と併用すると纯増分のスループット改善が乏しくなりレイテンシを実質的に増大させうる」と定性的に指摘する。両サーベイを突き合わせると、細粒度化それ自体は単調に有利ではなく「単独では有利、他の最適化と重ねると打ち消し合いうる」という条件付き効果である可能性が高いが、いずれのサーベイも定量評価は示していない。(Source: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 3.2 Taxonomy - System Optimization]], [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 6.1 System-level Optimization - Serving System]] §6.2.1) - [再帰深度モデルにおけるステップ間キャッシュ共有] [[@2025__arXiv__Scaling up Test-Time Compute with Latent Reasoning - A Recurrent Depth Approach]] は、再帰深度アーキテクチャにおいて全ての反復ステップの KV キャッシュが同一の K, V 射影行列から生成されるため互いに「一致」する性質を利用し、固定予算 k のキャッシュを i mod k で使い回すゼロショット KV キャッシュ共有を提案した(MTBench 性能への影響は軽微)。これはリクエスト間・レイヤー間のキャッシュ共有とは異なり、単一トークン内の反復(recurrence)ステップ間でのキャッシュ共有である点が新しい(Source: [[@2025__arXiv__Scaling up Test-Time Compute with Latent Reasoning - A Recurrent Depth Approach]])。 ## 未解決の問い - LightLLM のトークン単位 KV キャッシュ管理は vLLM のブロック単位より細粒度だが、この細粒度化がメタデータ管理コスト(トークンごとのポインタ管理オーバーヘッド)とどうトレードオフになるかは、『A Survey on Efficient Inference for Large Language Models』では定量比較されていない。本ページが蓄積した「GPU 内 page とネットワーク/ストレージ転送 chunk の二重粒度」という知見に、この GPU 内部でのブロック粒度対トークン粒度というさらに細かい粒度選択の軸を統合するには、どのような評価指標が必要か。他の最適化(バッチサイズ拡大)と併用した場合に負のトレードオフが顕在化するという Miao サーベイの定性的指摘を、どう定量化すればよいか。(Source: [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 6.1 System-level Optimization - Serving System]] §6.2.1, [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 3.2 Taxonomy - System Optimization]]) - KV シュリンキング3手法(CacheGen のビットストリームエンコーディング・MiniCache の層間マージ・HCache の隠れ状態格下げ)は理論上直交する軸を最適化するため組み合わせ可能に見えるが、同一システムでの統合実装・精度劣化の複合効果は「LLM×DATA」サーベイでは検証されていない。[[KVキャッシュ量子化]] の Kitty(ビット幅削減)を含めた4手法の組み合わせ空間はどこまで有効か。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.6) - Kubernetes Gateway API Inference Extension(GAIE)の Precise Prefix-Cache Aware Scheduling は、SGLang の longest-shared-prefix-first や Mooncake の Conductor が既に確立したキャッシュ認識ルーティングのアルゴリズムと本質的に同等か、それとも Kubernetes ネイティブな実装(Gateway レベルでのモデル対応ルーティング)固有の制約(EPP とバックエンド間のテレメトリ伝達遅延等)で異なる特性を持つか。GAIE 自体の導入オーバーヘッド(同時実行度 6〜20 で TTFT +3〜11ms)は、既存のプレフィックスキャッシュ実装のインエンジンルーティングと比べてどの程度追加コストか。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - DynamoServe が示すピア GPU への KV キャッシュ分散退避は、LMCache の階層ストレージや Mooncake の CPU DRAM キャッシュとどの条件で共存・置換されるか。NVLink 帯域がボトルネックになるコンテキスト長・並行度の閾値は。(Source: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving]]) - サーバーレスエージェントデプロイでSLMインスタンスがスケールダウンされる際のKVキャッシュ永続化(ディスク保存 vs 再計算)は、Mooncake・LMCacheが確立した階層退避の設計をそのまま転用できるか、それともコールドスタート再開時特有の制約(復元レイテンシがコールドスタート遅延に直接加算される)により別の設計が必要か。(Source: [[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]]) - SpeCache のようなレイヤー単位の投機的プリフェッチは、Mooncake の Conductor や LMCache の階層退避が扱う「リクエスト間再利用」の判断と、同一の KV キャッシュ管理ループでどう協調させるべきか。投機的先読みが外れた場合(実際のトークンが予測と異なった場合)のコストは、リクエスト間再利用の機会損失とどうトレードオフされるか。 - リアルタイム KV キャッシュ圧縮ポリシー切り替え(FP16→INT8→INT4)のヒステリシス閾値は、[[KVキャッシュ量子化]] の Kitty が示すチャネル単位の精度配分の知見と組み合わせられるか。「どのチャネルを」「いつ」低ビット化するかを同時に最適化する統合設計は可能か。 - POD-AttentionのSM-aware CTAスケジューリング(prefillとdecodeを同一SMに動的割当)と、Prefill-Decode分離の物理的ワーカー分離は、同一システム内でどう共存すべきか。POD-Attentionは同一GPU内でのフェーズ融合、分離アーキテクチャは別GPU・別ノードへの分割であり、両者は排他的な選択肢か、それとも階層的に組み合わせられるか(例: ノード間は分離、ノード内SM単位ではPOD-Attention的な融合)。 - 分離型KVキャッシュプールが提供する「GPUメモリの仮想化」は、GH200のUnified Memory(SuperInfer の横断的知見が示すbandwidth cliff問題)とどう異なるか。ソフトウェア明示制御のページング(第18章のDisaggregated KV Cache Pool)とハードウェア透過的マイグレーション(GH200)は、同じ多層メモリ階層問題への異なる解であり、どちらがLLMサービングのような短命・高頻度アクセスパターンに適するかの定量比較は示されていない。 - **KV キャッシュ階層のハードウェアコスト非線形性(DRAM/NAND 約 200 倍)は、既存のソフトウェア的キャッシュ配置最適化(Mooncake の Conductor、SuperInfer の VLT)の目的関数にどう組み込むべきか**: 現状の配置ポリシーは主にヒット率・TTFT・SLO 進捗を最適化するが、ハードウェア階層ごとの単価差を明示的にコスト関数へ組み込んだ場合、最適配置はどう変化するか。OCTS 2026 の分析は業界横断の概算にとどまり、具体的な配置アルゴリズムへの統合は示されていない。 - **エージェント型コーディングのターン境界シグナルは、既存のプリフィックスキャッシュ管理システム(SGLang の RadixAttention・LMCache 等)にどう統合すべきか**: [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] のターン境界検知(軽量 LightGBM 予測器、86〜90% のアイドル時間捕捉)はコンテナ/KV キャッシュ回収の signal として提案されるが、SGLang の longest-shared-prefix-first や Mooncake の Conductor のような既存スケジューラの優先度計算にこの signal を組み込む具体的な設計は示されていない。ターン境界予測とキャッシュ retention priority を同一の意思決定に統合する余地はあるか。 - **モデル切替(-67% ポイント)とコンテキスト圧縮(-66.1%)がほぼ同じ劣化幅を示すことは偶然か、共通のメカニズムに由来するか**: 両者ともプロンプトプレフィックスを実質的に作り直すイベントである点で類似するが、モデル切替は外部要因(レート制限・エラー)、圧縮はコンテキスト管理の内部判断という発火条件が異なる。プレフィックス保持型圧縮(著者らが提案する incremental compaction)が実現した場合、劣化幅はモデル切替と同水準まで下がるか、それとも構造的に異なる下限があるか。(Source: [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] §5.4, §6, Takeaway 9-10) - 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 帯域とスケジューリング設計の関係はどう変化するか。 - **cross-model KVキャッシュ転送は、mismatched-KV(KVヘッド数・ヘッド次元が異なる)ペアでも成立するか**: 現状の閉形式per-headリッジマッパーはKVヘッド数・ヘッド次元が一致する「matched-KV」ペアでのみ検証されており、著者ら自身がmismatched-KVへの適用可能性を将来課題として明示している。異なるアーキテクチャファミリ間(Qwen3→Llama 3.1等)への転送も未検証であり、Prefix caching・階層退避のような既存のKVキャッシュ再利用機構が「同一モデル」を暗黙の前提としてきたことの限界がどこまで緩和できるかは開かれている。(Source: [[@2026__arXiv__Cross-Model KV Cache Transfer in LLM Families - A Closed-Form Linear Mapping for Prefill Reuse]]) - **cross-model KVキャッシュ転送の成否を事前(フィット前)に予測する信号は何か**: attention出力コサイン類似度は転送品質と強く相関するが、これはマッパーをフィットした後にしか計算できない事後診断であり、著者ら自身がデプロイ前スクリーニングのための予測的信号を将来課題として挙げている。同一ファミルの他ペアでの実績、アーキテクチャの深さ比・パラメータ比、あるいはHellaSwagのような代表ワークロードでの下流精度が候補として挙げられているが、いずれも系統的な検証はされていない。(Source: [[@2026__arXiv__Cross-Model KV Cache Transfer in LLM Families - A Closed-Form Linear Mapping for Prefill Reuse]] §5 Future work) - **cross-model KVキャッシュ転送と、既存のプリフィックスキャッシュ・階層退避(SGLang RadixAttention・LMCache・Mooncake)は同一サービングスタック内でどう協調すべきか**: cross-model転送は「モデルを跨ぐ再利用」、既存機構は「同一モデル内でのリクエスト間再利用」という直交する軸を最適化するが、両者が同時に有効な状況(モデルルーティングとプレフィックス共有が両方発生するマルチテナント環境)でのキャッシュ配置・優先度の統合設計は示されていない。マッパー自体もCPU/ディスク常駐が想定されており、既存の階層ストレージ設計(LMCache・Mooncakeの階層退避)とマッパー重みの配置がホストメモリ容量を奪い合う可能性もある。 - DeepServe の RTC は「照合は同期・取り込みは非同期」というAPI分離でNPU待ちを削減するが、この分離がMooncake・LMCacheの階層退避ポリシー(いつ何をどこへ退避するか)とどう組み合わさるかは論文中で明示されていない。RTCのコストモデル(populateが有益かどうかの判断基準)の具体的な定式化も公開されておらず、Mooncakeのようなヒット率ベースの配置ポリシーとどちらが優れるかは比較されていない。 - **KVBM の SGLang 非対応(❌)は、SGLang が独自に持つ HiCache + NIXL 直接連携という代替経路とどこまで機能的に等価か**: [[NVIDIA Dynamo]] の [[KVBM (KV Block Manager)]] は vLLM・TensorRT-LLM には対応するが SGLang は Feature Support Matrix で明示的に非対応とされ、ドキュメントは代わりに SGLang 自身の階層キャッシュ HiCache を NIXL と直接連携させるページへ誘導する。両者はいずれも最下層に NIXL を置く点で共通するが、KVBM が「ランタイム非依存の共通ロジック層(ブロック生存周期・エビクションポリシー)を挟む」設計であるのに対し、HiCache は「SGLang エンジン内蔵の階層キャッシュが NIXL を直接呼ぶ」設計であり、フレームワーク横断のポータビリティとエンジン特化の最適化のどちらを優先するかという設計思想の分岐に見える。具体的な機能差分(エビクションポリシーの共有可否、複数エンジン間でのブロック共有可否)は SGLang HiCache ページ・KVBM Design ページとも未取り込みのため検証できていない。(Source: [[@2026__NVIDIADynamoDocs__KVBM (KV Block Manager) 概要]]) - **KVBM と LMCache・FlexKV・HiCache の機能差分は何か**: NVIDIA Dynamo 公式ドキュメントは KV Cache Offloading の比較ページで KVBM を [[LMCache]]・FlexKV・HiCache と並べて比較すると案内するが、本 ingest では比較ページ自体を取り込んでいない。LMCache が vLLM の KV connector 経由で GPU 外階層キャッシュを提供する設計(本ページ上部の横断的知見参照)と、KVBM が NIXL を最下層に持つ3層設計との間に、対応ストレージバックエンドの範囲・エビクションポリシーの実装・マルチエンジン共有可否などでどのような具体的差分があるかは未検証。 ## 関連 - ソース: [[@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]] / [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]] / [[@2026__SpeakerDeck__AIインフラの最新技術動向 2026 — 中国OCPコミュニティから読み解く6つの技術トレンド]] / [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] / [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]] / [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] / [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 6.1 System-level Optimization - Serving System]] / [[@2025__arXiv__Scaling up Test-Time Compute with Latent Reasoning - A Recurrent Depth Approach]] - エンティティ: [[vLLM]] / [[SGLang]] / [[LMCache]] / [[P-D-Serve]] / [[NIXL]] / [[NVIDIA Dynamo]] / [[Mooncake]] / [[CacheBlend]] / [[KVShare]] / [[SCBench]] / [[AIBrix]] / [[ContextPilot]] / [[MLCommons Chakra]] / [[NVIDIA Rubin GPU]] / [[NVIDIA GH200]] / [[Qwen3]] / [[Llama3]] / [[Mistral 3]] / [[Gateway API Inference Extension]] / [[llm-d]] / [[Huawei Cloud]] - 概念: [[耐障害LLMサービング]] / [[パイプライン並列化]] / [[KVキャッシュ量子化]] / [[エージェント型コーディング]] - 教科書: [[wiki/surveys/KVキャッシュ管理の教科書]] — 本ページの横断的知見を 13 部 35 章に体系化(矛盾 4 件と数値引用の注意 12 件を付録に集約) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]] — Decode専用カーネル(FlashMLA/ThunderMLA/FlexDecoding)、分離型KVキャッシュプールのメモリ階層設計、ページ収集によるRDMA転送最適化 - 関連 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__ATC__DeepServe - Serverless Large Language Model Serving at Scale]]（Huawei Cloud、USENIX ATC '25。Relational Tensor Cache による同期照合/非同期取り込みの分離、radix-tree+ID ベースのハイブリッドインデックス、1年以上の本番 Ascend NPU クラスタ運用実績） - [[@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) - [[@2026__arXiv__Agentic Coding in the Wild - Characterizing GitHub Copilot at Production Scale]](GitHub Copilot コーディングエージェントの本番規模ワークロード特性化。ターン境界・モデル切替・コンテキスト圧縮という3つの構造イベントによる KV キャッシュ劣化を定量化(-26%/-67%/-66.1%)、ユーザーアーキタイプ間50倍のキャッシュミスコスト格差を実証) - [[@2026__SpeakerDeck__AIインフラの最新技術動向 2026 — 中国OCPコミュニティから読み解く6つの技術トレンド]](OCTS 2026 業界横断報告。DRAM/NAND 約200倍のコスト差とヒット率改善の非線形な経済効果、Active/Archive 用途別2階層 SSD 設計、CXL メモリプール化(Beluga)による TTFT 89.6% 削減の実証事例) - [[@2025__SpeakerDeck__AIインフラを考える]](KV Cacheサイズ計算式とLlama3 8B/405Bの段階的試算・100/400/800GbpsでのKV Cache転送時間・Scale Up/Scale Out経路選択によるボトルネックの違い) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 16 Profiling, Debugging, and Tuning Inference at Scale]](vLLMのトークン列trie・SGLang RadixAttentionの圧縮radix treeによるプレフィックスキャッシュ実装、prefix-merge率の計測手法、LMCacheのGPU/CPUキャッシュ比率調整) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]](FlashMLA/ThunderMLA/FlexDecodingによるDecode専用カーネル融合、分離型KVキャッシュプールのメモリ階層計算(250,000トークンで約328GB)、POD-AttentionのSM-aware CTAスケジューリング、NIXL/RDMAによるゼロコピーKV転送とページ収集(20ms→8ms)) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]](SpeCacheとHugging Face OffloadedCacheによるレイヤー単位の投機的KVプリフェッチ、GPUメモリ使用率閾値に応じたFP16→INT8→INT4のリアルタイムKVキャッシュ量子化切り替え) - [[@2026__arXiv__Cross-Model KV Cache Transfer in LLM Families - A Closed-Form Linear Mapping for Prefill Reuse]](同一LLMファミリ内の異なるサイズのモデル間でのKVキャッシュ転送。matched-KVペアに対するper-headリッジ回帰による閉形式・勾配学習不要のマッパー、6ペア中4ペアが標準精度73〜98%保持・再プリフィル比2.7〜25倍高速。attention出力コサイン類似度が校正R²よりcross-pair転送品質を予測する、NVIDIA) - [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]](§2.4.6 KV Cache: キャッシュ空間管理(vLLM/vTensorのブロック分離)・KV配置(RAGCache/CachedAttentionの階層化)・KVシュリンキング(CacheGen/MiniCache/HCacheの3系統圧縮)・KVインデキシング(ChunkAttention/PSMのprefix tree・並べ替え)) - [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 6.1 System-level Optimization - Serving System]](§6.2.1 Memory Management: S3の生成長予測・vLLM PagedAttentionのブロック単位ページング・LightLLMのトークン単位管理・FlashInferのレイアウト最適化という粒度細分化の系譜)