KV Cache 与 Prompt Caching 看起来像两个名词其实都在解决同一件事已经算过的内容不要再算一遍。区别只是前者主要发生在一次生成内部后者把复用范围扩大到了不同请求之间。一句话先记住KV Cache 让逐 token 生成跑得动Prompt Caching 让重复长前缀的 API 请求更快、更省。一、为什么大模型生成一句话会产生大量重复计算大模型生成文本不是一次性把整段答案写出来而是每次预测一个 token。生成第 2 个 token 时模型已经看过 Prompt 和第 1 个 token生成第 100 个 token 时它需要参考前面的全部内容。最朴素的做法是每一步都把整个序列重新送进模型。问题在于旧 token 对应的 Key 和 Value 已经算过而且模型参数和旧输入没有变化再算一次不会得到新信息。二、KV Cache 到底缓存了什么在自注意力里每个 token 会产生 Query、Key、Value。可以把它们理解成Query 是当前 token 提出的问题Key 是历史 token 的索引Value 是历史 token 携带的信息。当前 token 需要用自己的 Query 去查询前面所有 token 的 Key 和 Value。历史 token 的 K 和 V 一旦计算完成在后续生成步骤里不会改变。因此推理框架把它们保存在显存中。下一步只需要计算新 token 的 Q、K、V再把新 K/V 追加到缓存末尾。KV Cache 不缓存最终答案也不缓存注意力输出它缓存的是模型每一层、每个历史 token 的 K/V 张量。三、Prefill 和 Decode看懂延迟从哪里来Prefill 阶段处理整段输入负责建立最初的 KV Cache。Prompt 越长首 token 往往越慢。Decode 阶段逐个生成 token虽然每一步只计算一个新 token但需要不断读取越来越长的 KV Cache所以常常受显存带宽和缓存管理影响。TTFTTime to First Token从请求发出到看到第一个 token 的时间长 Prompt 和缓存未命中会明显影响它。TPOTTime per Output Token后续每个 token 的平均耗时通常更受模型大小、并发和 KV Cache 读取效率影响。四、KV Cache 用速度换显存KV Cache 的占用会随上下文长度和并发数近似线性增长。这里最容易被忽略的是“KV 头数”传统多头注意力为每个注意力头保存一套 K/V而 GQA、MQA 会让多个 Query 头共享较少的 KV 头能显著缩小缓存。因此长上下文部署中经常会看到 PagedAttention、KV Cache 量化、CPU/NVMe 卸载、分层缓存、GQA/MQA 等方案。它们不是改变模型会不会回答而是在有限显存里容纳更长上下文和更多并发。五、Prompt Caching把复用从“同一次生成”扩展到“不同请求”企业应用里很多请求都有很长的公共前缀固定 System Prompt、安全规则、工具定义、Few-shot 示例、知识库文档。真正变化的可能只是最后一句用户问题。若每个请求都从头做 Prefill会反复消耗计算。Prompt Caching 的做法是保留相同前缀对应的缓存结果。新请求到达时系统先检查前缀是否已经存在命中就从缓存位置继续只处理新增 token未命中才重新计算并写入缓存。六、三个概念不要混在一起在自建推理服务中常见叫法是 Prefix Caching 或 Automatic Prefix Caching在商业 API 中产品通常叫 Prompt Caching。它们可能都复用 KV 结果但缓存是否自动开启、能保留多久、怎样计费、前缀最小长度和数据隔离规则取决于具体平台。七、缓存命中的核心固定内容放前面动态内容放后面缓存按 token 前缀匹配而不是按“语义差不多”匹配。哪怕两段文字表达同样意思只要 token 序列发生变化就可能在变化处停止命中。将 System Prompt、工具定义、稳定示例和固定文档放在前面。把时间、用户问题、检索结果中的动态部分尽量放在后面。固定 JSON 序列化方式、字段顺序、空格和工具列表顺序。不要在公共前缀开头插入时间戳、请求 ID、随机数或用户专属信息。内容更新时采用版本化前缀避免旧缓存与新规则混用。八、哪些业务最值得做 Prompt CachingPrompt Caching 并不是所有请求都能获益。它最适合“公共前缀长、重复请求多、动态尾部短”的业务。一次性短问答、每次 Prompt 都完全不同通常命中率不高。九、工程落地时应该监控什么缓存命中率请求中有多少前缀 token 被复用。缓存写入与读取 token判断是否真的复用了足够长的内容。TTFT 的 P50/P95不要只看平均值。单位请求输入成本写入缓存可能有额外成本读取通常更便宜但规则因平台而异。显存利用率与淘汰率自建服务里缓存过多也会挤占新请求空间。数据隔离不同租户、权限和敏感文档不能因为缓存键设计错误而发生交叉复用。十、一个简单的 Prompt 组织示例下面的重点不是某个厂商 API而是内容顺序稳定且可共享的部分尽量靠前变化内容靠后。SYSTEM_RULES你是企业知识库助手。回答必须引用已提供资料不确定时明确说明。 TOOLSload_stable_tool_definitions()# 固定顺序KNOWLEDGEload_versioned_document(v3)# 相同版本保持不变prompt[SYSTEM_RULES, TOOLS, KNOWLEDGE, user_question,# 动态内容放最后]十一、常见误区误区一Prompt Caching 会缓存完整回答。实际上通常复用的是输入前缀的计算结果回答仍会重新生成。误区二语义相同就能命中。缓存更依赖 token 前缀一致性。误区三开启缓存一定更省。若公共前缀很短、命中率低或缓存频繁过期收益可能有限。误区四缓存越久越好。长期缓存会占资源也会带来规则更新、隐私与版本一致性问题。误区五KV Cache 只影响速度。它同时决定显存容量、最大上下文和可承载并发。十二、总结KV Cache 解决的是自回归生成内部的重复计算历史 token 的 K/V 只算一次后续步骤持续复用。Prompt Caching 则把相同思路扩展到多个请求公共前缀只做一次 Prefill后续请求从命中的位置继续。真正的工程价值不在“有没有打开缓存”而在于前缀设计是否稳定、命中率是否足够高以及延迟、成本、显存和数据隔离是否被持续观测。