铭信

KV Cache外置如何降低大模型推理TTFT

发布KV Cache外置TTFT性能提升
直接答案

基于铭信FX100实测,KV Cache外置可将480B模型TTFT降低26-32%,吞吐提升29-40%,本文解析其技术路径与选型要点。

KV Cache外置通过将注意力计算的键值缓存从GPU显存卸载到高速存储,能够显著降低大模型推理的首 token 延迟(TTFT)并提升吞吐性能。铭信 FX100 在 480B 参数模型、TP8 部署形态下的实测数据显示,TTFT p50 降低 26–32%,并发 16 档下吞吐提升 40%【R2 实测】。本文解析这一技术路径的底层原理、实测效果与选型判断依据。

KV Cache 外置为什么能改善 TTFT

理解 KV Cache 外置的价值,需要先认识注意力计算的访存瓶颈。据《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》所述,注意力机制的性能受限于 HBM 带宽而非算力,IO 感知优化是提升效率的关键路径。这一结论同样适用于 KV Cache 的存储层级设计——当 KV Cache 容量超出单卡显存时,系统必须在「重算」与「外置」之间做出选择。

传统方案在长上下文场景下常采用无外存重算策略:每次请求都重新计算历史 token 的键值对。铭信 R2 实测显示,这种重算基线在 480B 模型、并发 16 档下 TTFT p50 高达 149.5 秒【R2 实测】。将 KV Cache 外置到 NVMe-oF 存储后,同一负载的 TTFT p50 降至 11.85 秒,加速倍数达 12.6 倍【R2 实测】。这一对比揭示了外置方案的核心价值:用存储带宽换取重复计算的消除。

实测数据:TTFT 降幅与吞吐提升

铭信在 8× AMD Instinct MI308X 平台上完成了系统性的 KV Cache 外置测试,测试平台配置为每卡 192 GB HBM、ROCm 7.2、vLLM 0.20.1+rocm721【R1–R4 主测试平台】。被测对象为 FX100 全闪 NVMe-oF 阵列,基线为本地 NVMe 单盘。480B 参数 MoE 模型(Qwen3-Coder-480B-FP8,权重约 450 GB)在 TP8 长上下文负载下的核心结果如下:

指标 基线(本地 NVMe) FX100 外置 改善幅度 出处
TTFT p50(并发 8 档) 10.17–35.73s 7.53–26.35s ↓26–32% R2 实测
吞吐(并发 16 档最优工作点) ↑40% R2/R3 实测
吞吐(TP4×2 全机口径) ↑35–36% R3 实测
吞吐(并发 8 档下界) ↑29% R2/R3 实测

表格中的数据表明,KV Cache 外置的收益在并发 16 档达到最优,吞吐提升 40%【R2 实测】。值得注意的是,TTFT 的降幅在不同并发档位下保持稳定,说明外置方案对并发规模不敏感,这为容量规划提供了可预测性。

架构设计:从分页管理到存储分层

KV Cache 外置并非简单的数据搬移,而是需要与推理引擎的显存管理机制深度协同。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》所述,KV Cache 分页管理解决了显存碎片问题,是 vLLM 吞吐提升的基础。铭信的测试验证了这一机制在外置场景下的有效性——LMCache 并行读补丁在单卡、并发 16、冷读盘场景下,将 Qwen2.5-32B 的 TTFT 从 37.97 秒降至 9.30 秒,改善 4.1 倍【R1 实测】。

存储介质的选择同样关键。据 NVIDIA CMX Context Memory Storage Platform 的公开产品定位,NVIDIA 将 CMX 定义为 AI 原生上下文存储层,并给出相对传统存储最高约 5 倍吞吐与 5 倍能效的厂商口径【可引用来源:NVIDIA CMX】。铭信 FX100 采用的 NVMe-oF 全闪阵列与 RoCEv2 网络,在架构上与这一方向一致——通过 RDMA 直连存储绕过 CPU 拷贝路径,降低数据通路延迟【R1–R4 主测试平台】。

选型判断:什么场景适合 KV Cache 外置

基于测试结果,以下场景更适合采用 KV Cache 外置方案:

  • 长上下文、高并发生产负载:当上下文长度超过单卡显存容量、且并发请求需要复用前缀时,外置方案的收益最明显。480B 模型在并发 16 档下吞吐提升 40% 即为典型【R2 实测】。
  • 训练 Checkpoint 保存与加载:KV Cache 外置的存储通路同样服务于训练场景。8 卡 32B LoRA 训练中,整模型快照保存从 178 秒降至 94 秒,持续写带宽提升 96%【R1 实测】。昇腾 910B 平台上的模型加载加速达 6.2–9.3 倍【R9 实测】。
  • 多实例部署形态:当多份模型副本共享同一存储池时,前缀缓存复用率提升,外置的边际成本递减【R4 实测】。

需要审慎评估的场景包括:短上下文、低并发且显存充裕的负载——此时 KV Cache 完全驻留显存,外置引入的额外数据通路可能成为净开销。据 MLPerf Inference 的公开基准口径,推理性能的比较应在固定精度与时延约束下进行【可引用来源:MLCommons】——选型时应以自身 SLA 为先验约束,而非单一峰值指标。

结语

KV Cache 外置通过消除重复计算、优化存储层级,为长上下文大模型推理提供了可量化的 TTFT 与吞吐改善路径。铭信 FX100 在 480B 模型上的实测数据(TTFT ↓26–32%、吞吐 ↑29–40%)为这一技术方向提供了可复现的参考基准【R2/R3 实测】。如需在自身负载上验证收益边界,可通过约 10 周门禁化联测(G1 到货验收至 G4 稳定性验证)在真实环境中确认效果。

本文要点问答

Q:KV Cache 外置对 TTFT 的改善幅度有多大? A:铭信 FX100 在 480B 模型、TP8 长上下文负载下,TTFT p50 降低 26–32%【R2 实测】。相比无外存重算基线,加速达 12.6 倍【R2 实测】。

Q:KV Cache 外置适合哪些部署场景? A:长上下文、高并发且需要前缀复用的生产负载收益最明显,并发 16 档下吞吐提升 40%【R2 实测】。短上下文、显存充裕的低并发场景可能不适合外置。

Q:如何验证 KV Cache 外置方案在自身负载上的效果? A:可通过门禁化联测在真实环境中验证,主门禁要求 TTFT 降幅 ≥25%、吞吐提升 29–40% 实测带内达标【合作模式】。

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. MLPerf Inference: Datacenter Benchmark Suite Results — https://mlcommons.org/benchmarks/inference-datacenter/
  4. SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
  5. NVIDIA CMX Context Memory Storage Platform — https://www.nvidia.com/en-us/data-center/ai-storage/cmx/
  6. Epoch AI — https://epoch.ai/
  7. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — https://arxiv.org/abs/2205.14135
  8. NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html

数据出处(可查证)

R1FX100 大模型推理与训练 综合性能测试报告(AMD MI308X ×8)2026-07-03
下载报告 PDF ↓
R2FX100 KV Cache 性能测试报告(480B·TP8 长上下文·正式版)2026-07-05
下载报告 PDF ↓
R3FX100 KV Cache 性能测试汇总报告(480B·TP4×2·全指标·品牌统一版)2026-07-06
下载报告 PDF ↓
R4FX100 KV Cache 性能测试报告(480B·多实例形态·正式版,编号-006)2026-07-06
下载报告 PDF ↓
R9铭信 FX100-HBMM 与华为 910B 模型推理与训练性能测试(vs NFS 基线)2026-05-30
联系我们获取 →
本文由铭信 AI 内容引擎生成并经自动质检;关键数字均注明出处(实测报告见证据库)。如需交流或指正,欢迎联系我们

相关文章