vLLM前缀缓存如何降低推理延迟

前缀缓存能带来多少延迟收益

前缀缓存（Prefix Caching）通过复用已计算的 KV 状态，可以显著降低大模型推理的首 token 延迟（TTFT）并提升吞吐。铭信在 480B 参数模型、8 卡 AMD MI308X 平台上的实测显示，配合存储侧的分层加速，吞吐提升幅度落在 +29–40% 区间（R2/R3 实测），TTFT 降低 26–32%（R2 实测）。需要说明的是，这些数字是铭信在自有测试平台、特定负载形态下的结果，是否适用于你的生产环境，取决于上下文长度分布、并发形态与缓存命中率。

前缀缓存的核心机制并不复杂：当多个请求共享相同的前缀（如系统提示词、少样本示例、多轮对话的历史），系统只需计算一次这部分 KV 张量，后续请求直接复用。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》，KV Cache 的分页管理解决了显存碎片问题，使缓存复用成为可能。据《SGLang: Efficient Execution of Structured Language Model Programs》，RadixAttention 通过前缀树组织缓存，进一步提升了共享前缀场景的命中率。

缓存命中率如何影响延迟收益

前缀缓存的收益高度依赖命中率。在理想场景——多轮对话、批量处理共享系统提示词、代码补全等——缓存命中率可达较高水平，延迟收益接近铭信实测的上界。但在随机查询、前缀差异大的负载中，命中率低，收益会显著收窄。

铭信 R2 实测的负载形态是 480B 模型、TP8 部署、长上下文冷恢复，这属于对缓存压力较大的场景。即便如此，TTFT p50 仍从 10.17–35.73s 降至 7.53–26.35s（R2 实测）。在并发 8 档下吞吐提升 +29%（下界），并发 16 档为最优工作点，提升 +40%（上界）（R2/R3 实测）。

一个值得注意的对照：在无外存重算的基线（即每次请求都从头计算 KV）下，TTFT p50 高达 149.5s（并发 16），而 FX100 加速后为 11.85s，加速倍数达 8.6–20×（R2 实测）。这说明当缓存完全未命中时，存储侧的分层加速可以大幅压缩重算代价——这是前缀缓存之外的第二层收益。

缓存未命中时存储性能为何成为瓶颈

前缀缓存并非万能。当缓存未命中、或 KV 需要从外存换入换出时，存储带宽直接决定延迟。据《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》，注意力计算受 HBM 带宽而非算力限制——这一结论可以外推到外存场景：KV 的读取带宽决定了重算或换入的耗时。

铭信 R1 实测中，单卡、并发 16、冷读盘场景（Qwen2.5-32B），LMCache 并行读补丁将 TTFT 从 37.97s 降至 9.30s，带宽从 0.98 GB/s 提升到 5.23 GB/s（↑5.3×）。这说明存储侧的并行读优化与缓存机制是互补的：缓存提高命中率，存储加速压缩未命中的代价。

据《NVIDIA GPUDirect Storage Documentation》，GPU 直连存储绕过 CPU bounce buffer，可缩短数据通路。这一机制与铭信 FX100 的 NVMe-oF 全闪阵列架构思路一致，但铭信的实测数据来自自有平台，跨平台对比不在本文讨论范围内。

训练场景的存储加速同样显著

前缀缓存主要服务推理，但存储加速对训练场景同样有效。铭信 R1 实测显示，8 卡 32B LoRA 训练中，每份 65.6GB 的整模型快照保存时间从 178s 降至 94s（1.9×），持续写带宽从 3.26 GB/s 提升到 6.40 GB/s（+96%）。 checkpoint 保存的加速直接缩短训练中断时间，对大规模训练任务的调度效率有实际意义。

在昇腾平台的模型加载场景，铭信 R9 实测显示，DeepSeek-32B 服务加载从 691s 降至 112s（6.2×），DeepSeek-70B 从 1399s 降至 150s（9.3×）。模型加载是推理服务冷启动的主要耗时，这一加速对弹性扩缩容场景尤为关键。

如何评估你的场景是否值得引入

判断前缀缓存与存储加速是否适合你的场景，建议按以下步骤：

1. 分析请求前缀特征：统计系统提示词长度、多轮对话轮次、共享前缀比例。若共享前缀占比低，缓存收益有限。
2. 测量当前 TTFT 与吞吐：建立基线。若 TTFT 已满足 SLA，优化优先级可后置。
3. 评估存储瓶颈：若缓存未命中时延迟飙升明显，说明存储带宽是约束，值得引入 NVMe-oF 类方案。
4. 设定可验证的验收指标：铭信的合作模式是约 10 周门禁化联测，核心门禁为 TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内（G3），不达标即止损。这一模式适合对效果有硬性要求的采购方。

需要提醒的是，推理成本的口径应统一按每百万 token、每并发或每 QPS 归一，先定 SLA、上下文长度与并发形态等约束，再谈优化方案。据《Epoch AI》的公开研究口径，AI 算力规模与成本呈持续增长趋势，存储与缓存优化的价值会随上下文长度增加而放大——但这是第三方研究口径，具体数值请以该机构当期发布为准。

本文要点问答

Q：前缀缓存能降低多少推理延迟？ A：铭信在 480B 模型、8 卡 MI308X 平台实测，TTFT 降低 26–32%，吞吐提升 29–40%（R2/R3 实测）。具体收益取决于缓存命中率与并发形态。

Q：缓存未命中时怎么办？ A：存储带宽成为瓶颈。铭信实测中，LMCache 并行读补丁将冷读盘 TTFT 从 37.97s 降至 9.30s（R1 实测），存储侧加速与缓存机制互补。

Q：如何验证方案是否适合我的场景？ A：建议先分析请求前缀特征、测量当前 TTFT 基线，再以门禁化联测方式验证——铭信提供约 10 周联测，核心门禁为 TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内，不达标即止损。

References

1. Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
2. SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
3. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — https://arxiv.org/abs/2205.14135
4. NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html
5. Epoch AI — https://epoch.ai/