为何 KV cache 是推理服务的瓶颈
以序列长度 128K、256 路并发运行 70B 量级的 dense 模型时，仅 KV cache 就需要 TB 级的 HBM。MoE 模型（Mixtral-8x22B 或 DeepSeek-V3 系列）由于 expert 选择的稀疏性，计算量较轻，但 KV cache 需完整保留，因此容量压力与 dense 模型相当甚至更高。2026 年推理团队每天大部分时间都耗在「如何在有限 GPU compute 的前提下尽量装入更多 KV」这一问题上，仅靠 HBM 显然远远不够。本文将 FP8 量化、paging、CPU/NVMe offload、RadixAttention 与多租户隔离整合为一条设计思路加以阐述。
FP8 KV cache 的质量权衡
FP8 KV（通常为 E5M2 或 E4M3）可将 HBM 使用量相比 FP16 减少一半。2025 年时，输出质量的下降曾令人担忧，但到 2026 年，大量论文与内部基准已形成共识：「选择合适的量化方案，质量损失可控制在 0.5% 以内」。推荐方案如下。
- E5M2（5 指数，2 尾数）：动态范围较宽。适合长文本、多语言工作负载。相比 E4M3 精度损失略大，但幻觉类失败较少。
- E4M3（4 指数，3 尾数）：尾数更多，偏向精度。适合代码生成、数学推理。含异常值的 activation 会被截断。
- per-channel scale + per-token shift：作为 Activation-aware 量化方式，可吸收异常值。已在 SGLang 0.4 系列和 vLLM 0.7 系列中均实现。
在 KGA 的质量基准测试（MT-Bench、HumanEval、JMMLU，以及内部 4 套日语 RAG 基准）中，将 Llama-3.3-70B 从 FP16 KV 降至 FP8 E5M2 KV 后，综合评分劣化仅 -0.3%；Qwen3-72B 为 -0.6%。而 HBM 使用量减半，同一 GPU 上的并发会话数可提升至 1.8 倍。投产时，建议初始设置使用 E5M2，代码/数学专用端点再考虑 E4M3。
MoE 的内存画像
MoE 模型因路由的稀疏性容易产生误解，但 KV cache 对所有 token 都是完整物化的。DeepSeek-V3 系列（671B 总参数，37B 激活参数）中，expert 参数占用了大部分 HBM，而在长文本运行时，KV 会超越参数占用成为主导。
MoE 特有的 KV 设计要点有三。第一，采用 MLA（Multi-head Latent Attention）的模型在训练时即具备 KV 的压缩表示，KV 容量比同等参数量的 dense 模型小 70% 以上。DeepSeek-V3 和 Qwen3-MoE 系列借此大幅降低了推理成本。第二，GPU 间的 expert 布局（expert parallelism）与 KV cache 布局（tensor parallelism）混用会导致负载不均，某些 GPU 的 KV 率先溢出。必须正确分离 EP 与 TP，并将 KV 均匀分散至所有 GPU。第三，路由存在冷热 pattern，被频繁激活的 expert 有所偏倚，设计 prefetch 时需以特定 expert 的 KV 被频繁访问为前提。
Paging 与 CPU/NVMe Offload
PagedAttention 以 16 个 token 为一页管理 KV，无需连续分配物理 HBM。截至 2026 年，将这些「页面」跨 HBM、CPU 内存和 NVMe 三层部署的方案已进入实用阶段。
CPU offload：将空闲会话（等待用户输入、Agent 深度思考中）的 KV 转移至 CPU 内存。恢复时的 PCIe 传输速度在 40GB/s 量级，即使是 70B 模型 128K 序列的 KV，也能在数百毫秒内返回 GPU。可使用 vLLM 的 swap、SGLang 的 offload backend 或 LMCache 中的任一方案。
NVMe offload：将频率更低的会话（空闲数分钟至数小时）转移至 NVMe。Gen5 NVMe 实测约 12GB/s，128K KV 的恢复耗时为 2～3 秒。长时间空闲后的恢复采用「NVMe → CPU，CPU → GPU」的两阶段异步 pipeline。
分层策略：KGA 客户案例中，「最近 30 秒的活跃 KV 在 HBM，30 秒～10 分钟在 CPU，10 分钟以上在 NVMe」的启发式策略具有普遍适用性。但在多租户场景下，需为每个租户设置独立的 TTL。
LMCache 与 SGLang RadixAttention 的基准测试
以下是 KGA 内部在 2026 年 Q1 整理的基准测试。工作负载为 RAG 对话（system prompt 1.5K，检索上下文 8K，用户轮均约 200 token，多轮平均 6 轮），模型为 Qwen3-72B FP8，硬件为 H200 SXM 8 张。
- 仅 vLLM prefix caching：吞吐量 2100 tok/s，TTFT p50 210ms，TTFT p99 720ms，prefill 重计算率 38%。
- SGLang RadixAttention：吞吐量 2650 tok/s，TTFT p50 140ms，TTFT p99 510ms，prefill 重计算率 17%。
- vLLM + LMCache（本地 CPU+NVMe）：吞吐量 2450 tok/s，TTFT p50 160ms，TTFT p99 430ms，prefill 重计算率 11%。
- vLLM + LMCache（分布式，共享 NVMe）：吞吐量 2380 tok/s，TTFT p50 180ms，TTFT p99 480ms，prefill 重计算率 6%。分布式场景下无法超越节点本地 HBM 复用，但跨集群共享缓存的效果体现在 p99 上。
结论：单节点优先选择 SGLang RadixAttention，需要多节点共享缓存时选择 vLLM + LMCache，是目前的两强格局。TensorRT-LLM 也具备同等功能，但在配置灵活性上两者占优。
多租户场景下的隔离与公平性
SaaS 场景下进行多租户推理服务时，KV 层存在四项设计约束。
泄漏风险：共享 system prompt 时不成问题，但含有特定租户数据的 KV 被另一租户请求引用的「缓存时序侧信道」风险并非为零。在金融、医疗、政府等高安全级别领域，按租户隔离 GPU 进程或 GPU 组、物理上分离 KV，是现实的解决方案。
公平性：朴素的 LRU 会导致请求量大的租户独占 KV，其他租户的 TTFT 因此恶化。KGA 建议采用「为每个租户设置 KV 配额，超出配额部分走 LRU，正常运行时单个租户不超过 50%」的混合策略。
分级服务质量：高级租户保障 HBM 常驻配额，基础租户优先走 CPU/NVMe offload 的分层运营正在普及。vLLM 和 SGLang 均内置可插拔调度器，支持自定义策略实现。
可见性：通过 Prometheus exporter 将各租户的 KV hit rate、KV eviction rate、KV 配额使用率仪表板化，即可将计费与容量规划联动。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，并为每个租户划分逻辑命名空间以管理配额。
总结
- 年的 KV cache 已不再是「在 HBM 能装多少就装多少」的时代。以 FP8 KV 将容量减半，以 MLA 系模型从结构层面压缩，以 PagedAttention 消除碎片化，以 LMCache 或 RadixAttention 发挥 prefix 共享效果，以 CPU/NVMe 分层存储长期 KV，以多租户隔离和公平性策略保障服务质量——这六个层次同时运转，才能实现单节点数千 tok/s 的实效吞吐量与 p99 TTFT 500ms 的 SLO。掌控 KV，即掌控 2026 年的 LLM 推理服务。