LLM 推理 · Prefix Cache

大模型服务 Prefix Cache 详解：
同一个前缀，只算一次

Q: 前缀缓存和 KV Cache 是一回事吗？

不是。KV Cache 解决单个请求内跨步的重复计算（让第 n 个 token 只做增量计算，避免 O(n²) 重算）；前缀缓存解决多个请求之间相同前缀的重复计算，是 KV Cache 之上的复用层。两者的关系可以记成：KV Cache 是引擎内部的事，Prefix Cache 是跨请求的事。

Q: 前缀缓存会改变模型输出吗？

不会。它复用的是「相同输入前缀必然相同」的中间结果（KV 张量），对输出结果无任何影响，是纯优化。这也是它与语义缓存的最大区别——前缀缓存按 token 序列精确匹配，语义缓存按语义近似匹配。

Q: vLLM 为什么缓存按 16 token 一个 block？

vLLM 的 KV 以固定 block 管理（配合 PagedAttention 分页显存），哈希寻址以 block 为单位，每个 block 的哈希由父块哈希等链式信息决定。好处是寻址简单、显存好管理、命中可挂载物理块；代价是前缀不足一个 block 时无法命中——前缀过短的请求等于没有缓存。

Q: SGLang 的 RadixAttention 和 vLLM 的 APC 哪个好？

没有绝对好坏：SGLang 用基数树组织前缀，匹配精确到 token 级，多轮对话、分支采样（self-consistency）、Agent 链式调用等前缀高度重叠的场景收益大，且默认开启零配置；vLLM 的 APC 与 PagedAttention 显存体系天然融合、生态成熟，一行参数开启。两者都支持 LRU 淘汰，实践差距主要在前缀组织的质量。

Q: 服务商的 Prompt Cache 和我自己部署的 Prefix Cache 冲突吗？

不冲突，也不重复收费。服务商缓存发生在服务端推理引擎（如火山方舟显式/隐式缓存），你的应用代码无需感知；自部署时你拥有引擎缓存的完全控制权。两者都遵循同一规律：前缀越稳定，命中越多、越省钱。

Q: 隐式缓存为什么不保证命中？

隐式缓存由系统自动管理：缓存容量有限会按策略淘汰、分布式路由可能把请求分到不同实例、多租户共享会互相挤占。需要确定性收益时，用显式缓存手动声明复用片段，或选择独享接入点保证请求落在同一组缓存实例上——缓存红利与接入点强相关。

Q: 命中率上不去，先改哪里？

先查「前缀稳定性」：动态变量是否误放开头（时间戳/用户 ID/随机数）、System Prompt 是否频繁改版、RAG 检索结果排序是否稳定。命中率低于 40% 时，换哪家服务商都救不了——先把前缀修稳，再谈折扣；合格线目标是 60% 以上，高并发模板化场景可达 90%+。

KV Cache 之上的跨请求复用层：命中时跳过 Prefill，TTFT 骤降、吞吐飙升、账单打骨折

大模型推理里有一条「几乎免费的午餐」：如果两个请求的输入前缀相同，前缀部分的 KV 计算就完全可以复用，一次都不用重算。

这就是 Prefix Cache（前缀缓存）。它的收益立竿见影：

首 token 延迟（TTFT）大幅下降：复用前缀后直接跳过 Prefill 阶段，响应从「读完整个 prompt 再开始」变成「接着上次算到的地方继续」
吞吐量飙升：有实测案例吞吐提升 8 倍、整体性能最高提升 7 倍（RAG、多轮对话等长共享前缀场景）
账单立省：主流服务商对缓存命中的 token 打骨折——Anthropic 缓存读 90% off、OpenAI 50% off、Google Gemini 75% off，火山方舟豆包系列命中价约为输入价的 10%，向量云命中价 0.04 元/百万 tokens 起

更难得的是：vLLM、SGLang 两大自部署引擎都把它做成了「默认或一行参数」的能力，服务商侧也不需要改代码——前提是你得按缓存友好的方式组织 Prompt。这篇文章一次讲透原理、实现、计费与最佳实践。

原理

一、Prefix Cache 是什么：KV Cache 之上的跨请求优化

1. 先定位：它和 KV Cache 是什么关系

一句话：KV Cache 解决「单个请求内」的重复计算，Prefix Cache 解决「多个请求之间」的重复计算。

KV Cache：自回归生成时，每生成一个 token 都要重新计算所有历史 token 的注意力。KV Cache 把每层每头的 K/V 张量缓存下来，让第 n 个 token 只做增量计算——没有它，推理复杂度是 O(n²)
Prefix Cache：KV Cache 之上再加一层。两个请求如果输入前缀完全相同（同一个 System Prompt、同一段历史对话、同一批检索文档），前缀部分算出来的 KV 张量必然一模一样——为什么不让第二个请求直接「继承」第一个请求算好的结果？

这就是前缀缓存的第一性原理：相同的 token 序列 → 相同的 KV → 算一次，人人共享。

2. 命中和不命中时分别发生什么

请求到来
  ↓
在缓存索引中查找「最长公共前缀」（Longest Common Prefix）
  ↓
命中：直接加载已缓存前缀的 KV 张量，只计算后缀部分
      → Prefill 只算新增 token → 首 token 延迟（TTFT）大降
  ↓
未命中：正常 Prefill 全量计算，并把可复用的前缀写入缓存
      → 后续请求可以复用

注意：缓存与输出的内容无关，只与输入的 token 序列有关——所以它「不挑模型、不影响输出质量」，纯赚。

3. 能拿到什么收益

维度	收益
首 token 延迟（TTFT）	命中后跳过前缀 Prefill，长前缀场景从秒级降到百毫秒级
吞吐	RAG/多轮对话等场景实测吞吐提升最高 8 倍、整体性能最高 7 倍
计算/能耗	相同前缀只算一次，Prefill 计算量按重复度成比例下降
成本	服务商侧缓存命中 token 打折计费，最高 90% off

引擎实现

二、两大自部署引擎的实现：哈希块寻址 vs 基数树

自部署场景绕不开 vLLM 和 SGLang。两者都支持前缀缓存，但底层路线完全不同——这也是「选型」时最常被问的问题。

1. vLLM：Automatic Prefix Caching（哈希块寻址）

引入版本：v0.4.0 起，自动识别公共前缀，无需手动指定
数据结构：把 KV Cache 切成固定大小的 block（默认 16 token），为每个 block 计算哈希值，用哈希表做内容寻址。block 的哈希由父块哈希等链式信息共同决定，保证同内容必然同哈希
与 PagedAttention 深度耦合：KV 按分页管理，缓存命中时直接「挂载」已缓存的物理块，显存复用效率高
启动方式：一行参数 --enable-prefix-caching 开启
代价：缓存占的是显存（KV Cache 那块），请求一多，旧缓存按 LRU 淘汰——所以它适合「同一个长前缀被高频复用」的场景

2. SGLang：RadixAttention（基数树索引）

默认开启：RadixAttention 是 SGLang 后端的核心优化，零配置，开箱即用
数据结构：用基数树（Radix Tree）把所有请求的前缀组织成可检索、可分裂合并的树形结构；新请求到来时在树中查找最长匹配前缀，命中后直接复用已缓存的 KV 张量
命中流程四步：Traverse（树中查找最长匹配前缀）→ Reuse（复用已缓存 KV）→ 计算剩余部分 → 把新计算的前缀挂回树中
淘汰策略：默认 LRU（最近最少使用），也可通过 radix_eviction_policy 切换为 LFU、SLRU 等
对比小结：SGLang 用树形索引做「精确前缀匹配」，vLLM 用哈希块寻址做「内容匹配」，两者都能实现跨请求复用，工程取舍不同

3. 两者对比速查

维度	vLLM APC	SGLang RadixAttention
数据结构	固定 block + 哈希表（内容寻址）	基数树（树形前缀索引）
匹配粒度	block（16 token）	精确 token 级前缀
开启方式	`--enable-prefix-caching` 参数	默认开启
淘汰策略	LRU	LRU（可换 LFU/SLRU）
优势	与 PagedAttention 显存管理天然融合	前缀匹配更精确，多轮对话/分支采样场景收益大

产品化

三、产品化：服务商的 Prompt Cache / 上下文缓存

前缀缓存不止存在于自部署引擎，服务商把它封装成了 API 特性，用户直接用、按命中折扣付费：

服务商	机制	缓存读折扣	备注
Anthropic	显式 `cache_control` 断点	90% off（缓存写有 1.25x 溢价）	命中 1.4 次即回本
OpenAI	自动缓存，无需配置	50% off	无感、省心但不可控
Google Gemini	上下文缓存，最小 1 小时 TTL	75% off	长上下文场景收益大
火山方舟	显式缓存 / 隐式缓存	豆包系列命中价约输入价 10%	另有缓存存储按小时计费
向量云	独享接入点 + 显式/隐式缓存	命中价 0.04 元/百万 tokens 起	接入点级缓存隔离，命中率更高

火山方舟的两种缓存模式

隐式缓存：系统基于请求输入的公共前缀自动创建缓存；后续请求输入开头与已有缓存存在相同前缀时自动复用。不保证命中——缓存容量有限、旧缓存可能被淘汰，分布式路由也会影响命中概率
显式缓存：开发者主动声明需要缓存的内容，命中更可控，适合对确定性有要求的业务
计费口径：命中 token 按 cached_token 计费（远低于 prompt_token 单价）；未命中部分仍按原价；缓存存储按小时计费

为什么「独享接入点」能锁住缓存红利

隐式缓存的命中率受共享链路干扰：请求被路由到不同实例、缓存池被其他租户挤占，都会导致命中率跳水。独享接入点保证你的请求始终落在同一组缓存实例上——前缀稳定、命中稳定，缓存红利才真正落袋。

适用场景

四、哪些场景适合、哪些不适合

✅ 适合（高共享前缀）

RAG 问答：固定指令模板 + 检索文档 + 动态问题，检索到的文档被反复复用
多轮对话：历史对话作为前缀不断累积，天然共享
固定 System Prompt 的应用：客服、角色扮演、行业助手，系统提示几万 token 恒定不变
批量推理：相同 Prompt 多次采样（如自一致性 CoT、A/B 测试）

❌ 不适合

每个请求前缀完全不同：如随机生成的唯一 prompt，无前缀可复用
前缀过短：vLLM 按 16 token 的 block 缓存，前缀连一个 block 都凑不满，永远 miss

命中率最佳实践

五、命中率最佳实践：让缓存「一打一个准」

1. 固定部分放前面，动态部分放后面

缓存的是「输入的开头」。前缀越靠前、越稳定，命中率越高：

❌ 反例：动态变量放在开头
You are a helpful assistant. Current time: 2026-10-09 14:05:23 ...

✅ 正例：固定内容前置，动态内容后置
You are a helpful assistant. [长系统提示] ...
用户信息 / 时间戳 / 随机数都放到 Prompt 末尾

2. 避坑清单（这四件事会让缓存每秒失效）

时间戳写进前缀：当前时间放开头，缓存每秒失效一次
用户 ID / 随机数前置：每个用户一个前缀，等于没有缓存
前缀频繁改版：系统提示动不动加个词，整条链上所有缓存全部失效
输入顺序不稳定：RAG 检索结果排序每次变化，同样内容也算不同前缀

3. 命中率目标

合格线 ≥ 60%，高并发模板化场景可达 90%+
命中率低时，优先排查：前缀是否频繁变动、动态内容是否误放开头

省钱数学

六、省钱数学：缓存命中到底省多少

以 Anthropic 官方口径为例：缓存读 90% off、缓存写 1.25x 溢价——同一前缀被读 1.4 次即可回本，之后的每一次命中都是净赚。换算到自家业务：

假设 System Prompt 固定 2000 token，每天被调用 10 万次
未命中：每天为这段前缀支付 2000 × 100000 次的输入费
启用缓存（90% off 档）：只有首次 + 每次命中的 10% 费用
→ 该前缀的输入成本约降一个数量级

自部署引擎（vLLM/SGLang）没有 token 单价，但显存和算力是钱：缓存命中让同量显存服务更多并发、让首字更快，等于用「缓存空间」换「算力与时间」。

落地八条

七、落地八条

自部署优先选 SGLang（默认开启）或 vLLM 加 --enable-prefix-caching，两行配置先拿到收益
API 调用优先选有缓存折扣的服务商，并把 System Prompt 固定下来
System Prompt 前向稳定：越靠前越稳定，命中率越高
动态内容一律后置：时间戳、用户信息、随机数放 Prompt 末尾
RAG 检索结果排序固定：同一文档集合尽量稳定排序，别让「内容相同、顺序不同」破坏前缀
监控缓存命中率：目标 ≥60%，低于阈值先查前缀稳定性
缓存有淘汰、有容量：长前缀高频复用的场景收益最大，低频场景别指望
生产环境注意缓存隔离：需要确定性命中率时，选独享接入点而非共享链路

FAQ 速答

FAQ

Q1：前缀缓存和 KV Cache 是一回事吗？
不是。KV Cache 解决单个请求内跨步的重复计算；前缀缓存解决多个请求之间相同前缀的重复计算，是 KV Cache 之上的复用层。

Q2：前缀缓存会改变模型输出吗？
不会。它复用的是「相同输入前缀必然相同」的中间结果，对输出结果无任何影响，纯优化。

Q3：vLLM 为什么缓存按 16 token 一个 block？
vLLM 的 KV 以固定 block 管理（配合 PagedAttention），哈希寻址以 block 为单位。好处是寻址简单、显存好管理，代价是前缀不足一个 block 时无法命中。

Q4：SGLang 的 RadixAttention 和 vLLM 的 APC 哪个好？
没有绝对好坏：SGLang 树形索引前缀匹配更精确，多轮对话、分支采样（self-consistency）场景收益大；vLLM 与 PagedAttention 显存体系天然融合、生态成熟。都支持 LRU 淘汰，实践差距主要在前缀组织的质量。

Q5：服务商的 Prompt Cache 和我自己部署的 Prefix Cache 冲突吗？
不冲突。服务商缓存发生在服务端推理引擎，你的应用代码无需感知；自部署时你同时拥有引擎缓存的控制权。两者都遵循「前缀越稳定越赚钱」的同一规律。

Q6：隐式缓存为什么不保证命中？
隐式缓存由系统自动管理：容量有限会淘汰、分布式路由可能把请求分到不同实例、多租户共享会互相挤占。需要确定性收益时用显式缓存或独享接入点。

Q7：命中率上不去，先改哪里？
先查「前缀稳定性」：动态变量是否在开头、System Prompt 是否频繁改版、RAG 排序是否稳定。命中率 <40% 时，换哪家服务商都救不了——先把前缀修稳，再谈折扣。

一句话总结：前缀缓存是「KV Cache 之上的复用层」：自部署有 vLLM/SGLang 两行配置，API 有服务商按折扣计费，收益由「前缀的稳定性」决定——相同的 token 序列，算一次，人人共享。

关于向量云

向量云（南京）科技有限公司

面向大模型应用落地的技术服务型企业，依托字节跳动火山方舟能力，为合作方提供低折扣模型 Token、可独立部署的运营支撑平台及全链路运营支持。

火山方舟官方授权官方 API Key 独享接入点缓存隔离降本低折扣 Token 即用即扣 · 不设账期

常见问题（FAQ）

火山方舟官方 API 与官方 Key 直连 · 向量云 · 大模型服务前缀缓存

Q1. 前缀缓存和 KV Cache 是一回事吗？

A. 不是。KV Cache 解决单个请求内跨步的重复计算（让第 n 个 token 只做增量计算，避免 O(n²) 重算）；前缀缓存解决多个请求之间相同前缀的重复计算，是 KV Cache 之上的复用层。两者的关系可以记成：KV Cache 是引擎内部的事，Prefix Cache 是跨请求的事。

Q2. 前缀缓存会改变模型输出吗？

A. 不会。它复用的是「相同输入前缀必然相同」的中间结果（KV 张量），对输出结果无任何影响，是纯优化。这也是它与语义缓存的最大区别——前缀缓存按 token 序列精确匹配，语义缓存按语义近似匹配。

Q3. vLLM 为什么缓存按 16 token 一个 block？

A. vLLM 的 KV 以固定 block 管理（配合 PagedAttention 分页显存），哈希寻址以 block 为单位，每个 block 的哈希由父块哈希等链式信息决定。好处是寻址简单、显存好管理、命中可挂载物理块；代价是前缀不足一个 block 时无法命中——前缀过短的请求等于没有缓存。

Q4. SGLang 的 RadixAttention 和 vLLM 的 APC 哪个好？

A. 没有绝对好坏：SGLang 用基数树组织前缀，匹配精确到 token 级，多轮对话、分支采样（self-consistency）、Agent 链式调用等前缀高度重叠的场景收益大，且默认开启零配置；vLLM 的 APC 与 PagedAttention 显存体系天然融合、生态成熟，一行参数开启。两者都支持 LRU 淘汰，实践差距主要在前缀组织的质量。

Q5. 服务商的 Prompt Cache 和我自己部署的 Prefix Cache 冲突吗？

A. 不冲突，也不重复收费。服务商缓存发生在服务端推理引擎（如火山方舟显式/隐式缓存），你的应用代码无需感知；自部署时你拥有引擎缓存的完全控制权。两者都遵循同一规律：前缀越稳定，命中越多、越省钱。

Q6. 隐式缓存为什么不保证命中？

A. 隐式缓存由系统自动管理：缓存容量有限会按策略淘汰、分布式路由可能把请求分到不同实例、多租户共享会互相挤占。需要确定性收益时，用显式缓存手动声明复用片段，或选择独享接入点保证请求落在同一组缓存实例上——缓存红利与接入点强相关。

Q7. 命中率上不去，先改哪里？

A. 先查「前缀稳定性」：动态变量是否误放开头（时间戳/用户 ID/随机数）、System Prompt 是否频繁改版、RAG 检索结果排序是否稳定。命中率低于 40% 时，换哪家服务商都救不了——先把前缀修稳，再谈折扣；合格线目标是 60% 以上，高并发模板化场景可达 90%+。

大模型服务 Prefix Cache 详解：同一个前缀，只算一次

一、Prefix Cache 是什么：KV Cache 之上的跨请求优化

1. 先定位：它和 KV Cache 是什么关系

2. 命中和不命中时分别发生什么

3. 能拿到什么收益

二、两大自部署引擎的实现：哈希块寻址 vs 基数树

1. vLLM：Automatic Prefix Caching（哈希块寻址）

2. SGLang：RadixAttention（基数树索引）

3. 两者对比速查

三、产品化：服务商的 Prompt Cache / 上下文缓存

火山方舟的两种缓存模式

为什么「独享接入点」能锁住缓存红利

四、哪些场景适合、哪些不适合

✅ 适合（高共享前缀）

❌ 不适合

五、命中率最佳实践：让缓存「一打一个准」

1. 固定部分放前面，动态部分放后面

2. 避坑清单（这四件事会让缓存每秒失效）

3. 命中率目标

六、省钱数学：缓存命中到底省多少

七、落地八条

FAQ

常见问题（FAQ）

Q1. 前缀缓存和 KV Cache 是一回事吗？

Q2. 前缀缓存会改变模型输出吗？

Q3. vLLM 为什么缓存按 16 token 一个 block？

Q4. SGLang 的 RadixAttention 和 vLLM 的 APC 哪个好？

Q5. 服务商的 Prompt Cache 和我自己部署的 Prefix Cache 冲突吗？

Q6. 隐式缓存为什么不保证命中？

Q7. 命中率上不去，先改哪里？

大模型服务 Prefix Cache 详解：
同一个前缀，只算一次