なぜ KV cache が serving のボトルネックなのか
- B クラスの dense モデルをシーケンス長 128K で 256 並列に回すと、KV cache だけで 1TB 級の HBM を要求する。MoE（Mixtral-8x22B や DeepSeek-V3 系）では expert 選択でスパースに動くため演算は軽いが、KV cache はフル保持なので容量圧は dense と同等かそれ以上。2026 年の serving チームが一日の大半を費やす問題は「GPU compute を食わすためにどう KV を詰めるか」であり、HBM だけでは明らかに足りない。本稿は FP8 量子化、paging、CPU / NVMe オフロード、RadixAttention、マルチテナント分離を一本の設計論としてまとめる。
FP8 KV cache の品質トレードオフ
FP8 KV（典型的に E5M2 または E4M3）は HBM 使用量を FP16 比で半減させる。2025 年時点では出力品質の劣化が懸念されていたが、2026 年現在は多数の論文と社内ベンチで「適切な量子化方式を選べば品質ロスは 0.5% 以内」が通説になった。推奨は以下。
- E5M2 (5 exp, 2 mantissa): ダイナミックレンジ広め。長文脈、多言語ワークロードに強い。精度ロスは E4M3 比でわずかに大きいが、hallucination 的失敗は少ない。
- E4M3 (4 exp, 3 mantissa): mantissa が多く精度寄り。コード生成、数学推論に適する。外れ値を持つ activation は clip される。
- per-channel scale + per-token shift: Activation-aware の量子化として、外れ値を吸収する。SGLang 0.4 系と vLLM 0.7 系の両方で実装済み。
KGA の品質ベンチ（MT-Bench、HumanEval、JMMLU、社内の日本語 RAG ベンチ 4 本）では、Llama-3.3-70B を FP16 KV → FP8 E5M2 KV に落としても aggregate score の劣化は -0.3%、Qwen3-72B では -0.6% にとどまる。一方 HBM 使用量は半減し、同一 GPU で同時セッション数を 1.8 倍伸ばせる。本番投入するなら E5M2 を初期設定にし、コード／数学特化エンドポイントで E4M3 を検討する運用が最適。
MoE のメモリプロファイル
MoE モデルは routing のスパース性で誤解されやすいが、KV cache は全 token について fully materialize される。DeepSeek-V3 系（671B total、37B activated）では、expert パラメータが HBM の大半を占める一方、長文脈運用では KV が追い越して支配的になる。
MoE 特有の KV 設計ポイントは三つある。第一に、MLA（Multi-head Latent Attention）系のモデルは KV の圧縮表現を学習時から持っており、KV 容量が同等パラメータの dense モデルより 70% 以上小さい。DeepSeek-V3 や Qwen3-MoE 系ではこれが serving コストを劇的に下げている。第二に、GPU ごとの expert 配置（expert parallelism）と KV cache 配置（tensor parallelism）を混ぜると負荷の偏りで一部 GPU の KV が先に溢れる。EP と TP を正しく分離し、KV は全 GPU に均等に分散させる設計が必須。第三に、ルーティングの hot/cold パターンで活性化する expert には偏りがあり、特定 expert の KV が頻繁にアクセスされる前提で prefetch を設計する必要がある。
ページングと CPU / NVMe オフロード
PagedAttention は KV を 16 トークンのページ単位で管理し、物理 HBM を連続確保しなくていい。2026 年現在、この「ページ」を HBM、CPU メモリ、NVMe の三層に跨らせる構成が実用期に入った。
CPU オフロード。アイドル中のセッション（ユーザ待ち、長考中のエージェント step）の KV を CPU メモリに退避する。再開時の PCIe 転送コストは 40GB/s オーダーで、70B モデルの 128K シーケンス KV でも数百 ms で GPU に戻せる。vLLM の swap、SGLang の offload backend、LMCache のどれかを使う。
NVMe オフロード。さらに低頻度のセッション（数分～数時間アイドル）を NVMe に落とす。Gen5 NVMe で実効 12GB/s、128K KV で 2～3 秒の復帰コストになる。長時間アイドル後の復帰時は「NVMe から CPU、CPU から GPU」の二段復帰を非同期にパイプライン化する。
階層ポリシー。KGA の社内検証では、最近 30 秒のアクティブ KV を HBM、30 秒～10 分を CPU、10 分以上を NVMe に落とすヒューリスティックが万能。ただしマルチテナントでは tenant ごとに固有の TTL を持たせる必要がある。
LMCache と SGLang RadixAttention のベンチマーク
- 年 Q1 に KGA 社内で揃えたベンチマーク。ワークロードは RAG チャット（system prompt 1.5K、retrieved context 8K、user turn 平均 200 トークン、マルチターン平均 6 ターン）、モデルは Qwen3-72B FP8、ハード H200 SXM 8 枚。
- vLLM prefix caching のみ: aggregate throughput 2100 tok/s、TTFT p50 210ms、TTFT p99 720ms、prefill 再計算率 38%。
- SGLang RadixAttention: throughput 2650 tok/s、TTFT p50 140ms、TTFT p99 510ms、prefill 再計算率 17%。
- vLLM + LMCache (local CPU+NVMe): throughput 2450 tok/s、TTFT p50 160ms、TTFT p99 430ms、prefill 再計算率 11%。
- vLLM + LMCache (分散、共有 NVMe): throughput 2380 tok/s、TTFT p50 180ms、TTFT p99 480ms、prefill 再計算率 6%。分散時は node ローカル HBM 再利用に勝てないが、クラスタ全体で cache を共有する効果が p99 に効く。
結論として、単一ノードなら SGLang RadixAttention、マルチノード共有キャッシュが必要なら vLLM + LMCache が現状の二強。TensorRT-LLM も同等機能を持つが、構成の柔軟性では上記二者が優位。
マルチテナントでの分離と公平性
SaaS でマルチテナント serving をする場合、KV 層に四つの設計制約が付く。
漏洩リスク。同一 system prompt を共有する場合は問題ないが、tenant 固有のデータを含む KV を別 tenant のリクエストが参照する「cache timing side channel」の可能性がゼロではない。金融・医療・政府など高セキュリティ領域では、tenant 単位で GPU プロセスまたは GPU グループを分離し、物理的に KV を分ける運用が現実解。
公平性。naive な LRU だと大量リクエストを流す tenant が KV を独占し、他 tenant の TTFT が劣化する。KGA では「tenant ごとに KV quota を設定し、quota を超えた部分は LRU だが通常運用時は 1 tenant 50% まで」という hybrid policy を提案している。
SLA 別サービス品質。プレミアム tenant には HBM 常駐枠を保証し、ベーシック tenant は CPU/NVMe オフロード優先という階層化が一般化している。vLLM、SGLang いずれも pluggable scheduler を持ち、カスタム policy を実装できる。
可視性。prometheus エクスポータで tenant 別 KV hit rate、KV eviction rate、KV quota 使用率をダッシュボード化しておくと、課金とキャパシティプランが連動できる。KGA の標準スタックではこれを Grafana で可視化している。
設定例: vLLM + LMCache + FP8 KV
```python from vllm import LLM from lmcache.integration.vllm import LMCacheConnector
llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8_e5m2", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, kv_transfer_config={ "kv_connector": "LMCacheConnector", "kv_role": "kv_both", "kv_buffer_size": 5e9, }, ) ```
LMCache 側では CPU 階層に 256GB、NVMe 階層に 2TB を割り当て、tenant ごとに論理 namespace を切って quota を管理する。
まとめ
- 年の KV cache は「HBM に収まる量を愚直に持つ」時代ではない。FP8 KV で容量を半減させ、MLA 系モデルで構造的に絞り、PagedAttention でフラグメンテーションを排除し、LMCache か RadixAttention で prefix 共有を効かせ、CPU / NVMe 階層で長期 KV を保存し、マルチテナント分離と公平性ポリシーでサービス品質を守る。この六層が同時に動いてようやく、1 ノードあたり数千 tok/s の実効スループットと p99 TTFT 500ms の SLO が両立する。KV を制する者が 2026 年の LLM serving を制する。