大模型本地部署KV Cache外置内存与显存的边界

结论先行

大模型本地部署中，KV Cache留在显存还是外置到内存，没有普适的最优解，边界由三个变量决定：并发档位、上下文长度、首 token 延迟（TTFT）的 SLA 要求。显存方案在低并发、短上下文的交互式场景中延迟最低；内存外置方案在长上下文、高并发的生产负载中吞吐与成本效率更优。铭信 FX100 在 480B 参数量、TP8 形态下的实测数据表明，外置方案在长上下文冷恢复负载中吞吐提升 29–40%，TTFT 降低 26–32%（R2/R3 实测）。

显存方案的适用边界：低并发与短上下文

KV Cache 留在显存的核心优势是访问路径最短。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》所述，KV Cache 分页管理的动机正是解决显存碎片化问题，让有限的显存容纳更多并发请求。这一机制在显存充足时效率最高。

显存方案的适用条件可以归纳为三个：

• 并发数低（通常 8 以下），显存容量足以容纳全部并发请求的 KV Cache；
• 上下文长度短（如 8K–32K），单请求的 KV Cache 占用小；
• 对 TTFT 有极严苛的要求，且无冷启动场景。

当上述条件满足时，显存方案无需经过 PCIe 或网络传输，延迟最低。但它的瓶颈同样明显：显存容量是硬约束。据《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》的分析，注意力计算的瓶颈本质是 HBM 带宽而非算力——这意味着即使算力闲置，显存带宽不足时 KV Cache 的读写仍会成为瓶颈。

内存外置方案的适用边界：长上下文与高并发

当上下文长度增长或并发数上升，KV Cache 的显存占用呈线性膨胀，显存方案的边际成本急剧上升。此时将 KV Cache 外置到内存（通过 NVMe-oF 或本地内存池）成为替代路径。

铭信 FX100 在 480B 生产部署形态下的实测数据（R2/R3 实测）提供了明确的边界参考：

出处：R2/R3 实测

数据表明，外置方案的收益随并发上升而增大。原因在于：高并发下显存的 KV Cache 容量不足，被迫频繁驱逐或重算；而外置方案通过池化内存资源，避免了重算开销。铭信实测中，对无外存重算的加速倍数达到 8.6–20×（R2 实测），重算基线 TTFT p50 为 149.5s（并发 16 档），而 FX100 方案为 11.85s。

需要强调的是，外置方案并非没有代价。它引入了额外的 I/O 路径，在低并发、短上下文的场景中，外置方案的延迟优势不明显，甚至可能因网络开销而劣于显存方案。因此，外置方案的适用条件是：

• 上下文长度 ≥32K，或并发数 ≥16；
• 存在冷恢复或缓存未命中场景（如多实例共享 KV 池）；
• 对 TTFT 的 SLA 要求允许 7–26s 的 p50 范围（R2 实测）。

架构取舍：从存算分离到分层加速

外置 KV Cache 的架构思路与存算分离一脉相承。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》所述，以 KV Cache 为中心的存算分离架构通过跨节点 KV 池化，将缓存从 GPU 显存中解放出来，实现资源按需分配。这一设计的前提是：KV Cache 的访问模式（顺序读、前缀复用）与训练时的随机访问不同，可以容忍更高的延迟。

铭信 FX100 的实测验证了这一架构在推理场景的可行性。在华为 Atlas 910B 平台上，模型推理加载加速达 6.2–9.3×（R9 实测），说明外置方案不仅适用于 KV Cache，还适用于模型权重的加载。训练侧同样受益：8 卡 32B LoRA 的 Checkpoint 保存加速 1.9×（R1 实测），持续写带宽从 3.26 GB/s 提升至 6.40 GB/s。

但架构选择必须回到业务约束。据《SGLang: Efficient Execution of Structured Language Model Programs》所述，RadixAttention 的前缀树复用机制在多轮对话与共享前缀场景中能显著提升命中率——这意味着如果业务负载中前缀复用率高（如多轮对话、Agent 任务），外置方案的收益会进一步放大；反之，若每次请求都是全新前缀，外置方案的收益则有限。

选型判据与验证路径

综合以上分析，给出可操作的选型判据：

1. 先定 SLA：TTFT 的 p50 目标是多少？如果要求 <5s，且并发 <8，显存方案优先；如果允许 7–26s，外置方案可纳入评估。
2. 再测负载形态：统计上下文的长度分布与并发峰值。长尾分布（少量长上下文请求占用大量 KV）是外置方案的典型受益场景。
3. 最后做对照实测：在同一平台、同一模型下，分别测显存与外置方案的吞吐与 TTFT。铭信采用约 10 周的门禁化联测流程（G1 到货验收 / G2 单机基线 / G3 主门禁：TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内 / G4 72h 稳定性），不达标即止损，这一方法论可供参考。

需要提醒的是，上述边界是基于铭信在 AMD MI308X ×8 平台、Qwen3-Coder-480B-FP8 模型上的实测（R1–R4 实测），迁移到其他硬件或模型时，应重新验证。跨平台外推没有依据，架构差异（如 HBM 容量、PCIe 版本、网络拓扑）会改变边界位置。

本文要点问答

Q：KV Cache 留在显存和外置到内存，各自适用什么场景？ A：低并发（<8）且短上下文（<32K）时显存方案延迟最低；高并发（≥16）或长上下文时外置方案吞吐更优。铭信 FX100 实测在 480B 长上下文冷恢复负载中，外置方案吞吐提升 29–40%（R2/R3 实测）。

Q：外置 KV Cache 的收益来自哪里？ A：来自避免显存容量不足时的重算开销。铭信实测对无外存重算的加速倍数为 8.6–20×（R2 实测），重算基线 TTFT p50 为 149.5s，而外置方案为 11.85s。

Q：选型时应该先确定什么？ A：先定 TTFT 的 SLA 目标，再统计上下文的长度分布与并发峰值，最后做同平台对照实测。铭信的门禁化联测流程（G1–G4）可作为验证路径参考。

References

1. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
2. Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
3. SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
4. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — https://arxiv.org/abs/2205.14135