推理前缀缓存能省多少，取决于请求重复度

dev.to · AI#推理优化#前缀缓存

Editor brief · 编辑速览

SGLang 的 RadixAttention 与 vLLM 的自动前缀缓存都通过复用 KV 缓存，减少相同提示词前缀的预填充计算。收益主要来自长前缀重复的请求，缺乏共享前缀时，不能照搬宣传中的加速幅度。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

SGLang 和 vLLM 谁更快，先看请求开头有多少内容相同。原文的结论是：前缀缓存能省掉重复读取提示词的计算，但收益取决于请求之间的复用程度，不能把某个测试里的最高加速倍数当成普遍结果。

这对部署 AI 服务的程序员很实用。固定系统提示词、Agent 反复携带的工具列表、围绕同一文档的问答，都可能受益；提示词各不相同、回答又很长时，换引擎未必能解决延迟问题。

模型生成回答前，需要先处理输入提示词，这一步叫 prefill。它完成后，才会开始输出第一个 token。

如果新请求的开头与此前处理过的内容相同，引擎就可以复用对应的 KV cache，也就是模型处理这些 token 时留下的中间状态，从而跳过这部分重复计算。

关键在于「开头相同」。两个请求都包含同一段文档，不代表它们一定能复用缓存；如果文档前面的内容不同，就不能仅凭文档相同判断会命中前缀。

前缀缓存加速的是 prefill，不会直接加速后续长回答的生成。

因此，长系统提示词被大量请求复用时，收益可能明显；如果大部分时间花在生成回答上，即使首个 token 更早出现，总耗时的改善也可能有限。

SGLang 的 RadixAttention 把提示词和已生成回答的 KV cache 组织在基数树（radix tree）里。开头相同的序列共享树上的分支，也共享已存储的缓存。

树结构放在 CPU，张量留在 GPU。旧叶子节点按最近最少使用策略（LRU）淘汰，调度器也会考虑缓存情况，安排请求执行顺序，提高命中机会。原文引用 LMSYS 的说法：作者在没有缓存命中时，没有观察到明显额外开销。这里的「作者」指被引用研究的作者，并非本文作者重新做过验证。

vLLM 的 automatic prefix caching 则按 KV cache 块计算哈希。每个块的指纹结合前一个块的指纹、当前块里的 token，以及 adapter IDs 等附加信息，淘汰同样采用 LRU。

它只缓存完整块。如果共享前缀结束在某个块的中间，可复用范围只能到前一个完整块。

两者都在避免重复计算，差别在于缓存如何组织、匹配和调度。仅凭树结构或哈希块，无法直接推导出谁在实际业务中更快。

SGLang 论文报告过最高 6.4 倍吞吐提升。LMSYS 的文章则报告，相比 vLLM v0.2.5、Guidance 和 TGI，最高可达 5 倍；测试包括单张 A10G 上的 Llama-7B，以及八张 A10G 上的 Mixtral-8x7B。

这组数字有两个限制：基线来自 2023 年末到 2024 年初，而 vLLM 此后也加入了 automatic prefix caching；「最高」代表被测负载中的最佳情况。

较新的结果也没有形成统一结论：

一篇 2026 年 DEV Community 文章报告，共享前缀测试中，首 token 延迟中位数为 vLLM 380 ms、SGLang 85 ms。
Spheron 的文章报告，在 H100、50 个并发请求下，SGLang 为 1,920 tokens/s，vLLM 为 1,850 tokens/s，差距很小。
SwiftKV 论文提到，在 Llama-3.1-8B 上，SGLang 相对 vLLM 有 1.4 到 1.8 倍优势。

首 token 延迟衡量多久开始返回内容，吞吐量衡量单位时间能处理多少输出。指标不同，负载和硬件也不同，这些数字不能拼成一张统一排行榜。

原文最有价值的地方，是把选型问题拉回请求结构：系统提示词有多长、共享前缀有多少、输出有多长、并发有多高，比一句「某引擎快几倍」更有用。

但这些材料仍不足以证明 SGLang 普遍领先。论文数据有特定测试条件，较新的单作者博客结果也相互不一致；所给内容没有完整列出版本、负载和配置，不能替这些比较背书。

相比直接更换引擎，先确认现有 vLLM 是否开启缓存，是更容易验证的一步。原文给出的参数是 enable_prefix_caching=True，同时明确说功能页没有说明默认值，需要检查所用版本。

原文末尾还提到内存压力和混合模型的研究，但没有展开细节，因此无法据此判断缓存容量、淘汰行为会怎样影响你的服务。

从真实 AI 请求中抽样，检查固定系统提示词、工具列表或文档是否出现在相同开头，并记录输入与输出长度，判断前缀缓存是否值得优先测试。
比较引擎时使用相同硬件、相同流量样本和预期并发，在 vLLM 中确认 enable_prefix_caching=True，同时记录首 token 延迟和吞吐量。
如果 Node 服务使用流式返回，分别观察多久收到第一个 token、多久生成完整回答，避免把首包改善误当成整个生成过程都变快。
对提示词大多独立、回答很长的业务，先验证缓存收益，再决定是否承担引擎迁移成本。