本地大模型部署：VRAM 与内存的 KV Cache 边界选择

在本地 LLM 部署中，KV Cache 放在 VRAM 还是卸载到内存，并没有放之四海而皆准的最优解。边界由三个变量决定：并发等级、上下文长度，以及首 token 时间（TTFT）的 SLA 要求。VRAM 方案在低并发、短上下文的交互场景下延迟最低；内存卸载方案在长上下文、高并发的生产负载下提供更好的吞吐量和成本效益。明鑫 FX100 在 480B 参数、TP8 配置下的实测数据显示，卸载方案在长上下文冷恢复工作负载下将吞吐量提升 29–40%，TTFT 降低 26–32%（实测，报告 R2/R3）。

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

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

VRAM 方案的适用条件可以归纳为以下几点：

• 低并发（通常低于 8），VRAM 容量足以容纳所有并发请求的 KV Cache
• 短上下文（如 8K–32K），单请求 KV Cache 占用量小
• TTFT 要求极为严苛，不允许冷启动场景

满足这些条件时，VRAM 方案避免了 PCIe 或网络传输，实现最低延迟。然而其瓶颈同样明确：VRAM 容量是硬约束。根据 FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness 的分析，注意力计算的瓶颈本质上是 HBM 带宽而非算力——这意味着即使算力有空闲，VRAM 带宽不足也会成为 KV Cache 读写的瓶颈。

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

随着上下文长度增长或并发上升，KV Cache 的 VRAM 占用线性扩张，VRAM 方案的边际成本急剧上升。此时，将 KV Cache 卸载到内存（通过 NVMe-oF 或本地内存池）成为一条替代路径。

明鑫 FX100 在 480B 生产部署中的实测数据（实测，报告 R2/R3）提供了一个清晰的边界参考：

并发数	VRAM 方案 TTFT (s)	卸载方案 TTFT (s)	提升幅度
8	3.2	4.1	-22%
16	8.7	6.2	+40%
32	19.4	11.9	+63%

数据表明，卸载方案的优势随并发增加而增大。原因在于：高并发下，KV Cache 的 VRAM 容量不足，迫使频繁驱逐或重新计算；卸载方案通过内存资源池化避免了重新计算开销。在明鑫的测量中，相比无外部内存的重新计算，加速比达到 8.6–20×（实测，报告 R2），其中重新计算基准的 TTFT p50 在并发 16 时为 149.5s，而 FX100 方案为 11.85s。

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

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

架构权衡：从存算分离到分层加速

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

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

然而架构选择必须回归业务约束。根据 SGLang: Efficient Execution of Structured Language Model Programs，RadixAttention 的前缀树复用机制在多轮对话和共享前缀场景下显著提升命中率——这意味着如果工作负载的前缀复用率高（如多轮对话、Agent 任务），卸载方案的收益被进一步放大；反之，如果每个请求的前缀完全不同，卸载方案的收益有限。

选型标准与验证路径

基于以上分析，以下是可直接操作的选择标准：

先设定 SLA： TTFT p50 目标是多少？如果要求 <5s 且并发 <8，优先考虑 VRAM 方案；如果可以接受 7–26s，则可将卸载方案纳入评估。

再测量工作负载特征： 收集上下文长度分布和并发峰值的统计数据。长尾分布（少量长上下文请求消耗大量 KV）是卸载方案的典型受益场景。

最后做对比测量： 在相同平台和模型上，测量 VRAM 和卸载方案两者的吞吐量和 TTFT。明鑫使用了约 10 周的 gated joint-testing 流程（G1 到达验收 / G2 单节点基准 / G3 主关卡：TTFT 降低 ≥25%，吞吐量 +29–40%，带内实测 / G4 72 小时稳定性），未达标则停止——这一方法论可作为参考。

需要注意的是，上述边界基于明鑫在 AMD MI308X ×8 平台上使用 Qwen3-Coder-480B-FP8 模型的测量（实测，报告 R1–R4）。移植到其他硬件或模型时需要重新验证。跨平台推算没有依据——架构差异（如 HBM 容量、PCIe 版本、网络拓扑）会导致边界位置偏移。

---

问：哪些场景最适合将 KV Cache 保留在 VRAM，哪些适合卸载到内存？

答：低并发（<8）和短上下文（<32K）时，VRAM 方案延迟最低；高并发（≥16）或长上下文时，卸载方案提供更好吞吐量。明鑫 FX100 在 480B 长上下文冷恢复工作负载下的测量显示，卸载方案将吞吐量提升 29–40%（实测，报告 R2/R3）。

问：外部 KV Cache 的收益从何而来？

答：来自 VRAM 容量不足时避免重新计算的开销。明鑫的测量显示，相比无外部内存的重新计算加速 8.6–20×（实测，报告 R2），其中重新计算基准的 TTFT p50 为 149.5s，卸载方案为 11.85s。

问：选型过程中首先应该确定什么？

答：首先设定 TTFT SLA 目标，然后测量上下文长度分布和并发峰值，最后在相同平台上运行对比测量。明鑫的 gated joint-testing 流程（G1–G4）可作为参考的验证路径。

---

Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079

Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180

SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104

FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — https://arxiv.org/abs/2205.14135

Originally published at mingxinstorage.xyz. Drafted with AI assistance by the Mingxin content engine and auto-checked against our measured benchmark data (reproducible benchmark).