提示缓存和 KV 缓存差在哪？两种「缓存」

用大模型对话时，同一个长提问发两遍，第二遍明显出得更快、更便宜，这背后往往是两种缓存之一在起作用。先把结论给你：KV 缓存省的是模型内部的重复计算，提示缓存省的是服务侧的重复读取，一个藏在推理引擎里，一个架在请求入口处。两种缓存都在为对话提速，但省钱的路径和受益人不一样。

先看各自的分工

判断自己该关心哪一个，可以问一句：我复用的是「算过的中间结果」，还是「发过的原文」？前者是 KV 缓存的地盘，后者是提示缓存的地盘。 Kimi 这类长对话产品重度依赖前者，而企业批量调用接口的场景更常碰到后者的计费优惠。

KV 缓存：推理引擎的记事本

大模型生成每个字之前，都要先「读」一遍前文，把前文换算成一组中间数据，这组数据就是 KV 值。没有缓存时，每生成一个字都要把整段前文重算一遍，长对话越到后面越慢。KV 缓存相当于把读过的内容记在笔记本上，下次直接翻笔记，省掉重复计算。

类比到这里要收回一半：笔记本可能被清掉。内存不够、会话切换、服务重启，都会让这份笔记作废，所以它只保证「短期内快」，不承诺一直在。

提示缓存：请求入口的速记册

提示缓存发生在更靠外的位置。很多应用的开头几段是固定的，比如系统设定、知识库摘要、常用指令，这部分每次请求都原样发出，既占传输量又占处理时间。服务方把这段固定前缀存下来，后续请求只发变化的部分，开头直接复用，前缀命中后，后面的推理也能搭上 KV 层的便车。DeepSeek 的接口文档里对前缀命中给出了明确的折扣说明，属于这类机制的典型代表。

两者的命名容易误导人：提示缓存听起来只缓存「提示词」，实际上凡是重复出现的前缀内容都在射程之内，文档、示例、固定指令都算；KV 缓存的名字倒是直白，存的就是键值对形式的中间数据。记住「外层省读取、内层省计算」这个分工，名字之争就不重要了。

把两种缓存想成外层与内层的接力：请求一到，先过外层的速记册，再进内层的记事本，两站都命中，速度与消耗双双受益；只命中一站，也能吃到一半的好处。

对照表：位置与受益人

• 位置：KV 缓存在推理引擎内部；提示缓存在请求处理层。
• 复用对象：前者是算好的中间数据；后者是发过的固定前缀。
• 受益方式：前者让单个会话越聊越顺；后者让重复请求直接打折。
• 失效原因：前者怕内存淘汰和会话切换；后者怕前缀哪怕改一个字。

四项差别连同典型场景排开：

怎么用才不吃亏

把不变的设定放在提问开头，把容易变的内容放在结尾，是同时吃到两种缓存红利的通用做法。多轮对话尽量在一个会话里连续进行，减少中断；调用接口的应用则固定系统提示，避免为省几个字频繁微调开头。想了解上下文长度怎样影响账单，可以看API 计费和订阅计费的上下文差在哪；想理解长对话里的接续机制，中断续答和重新提问有什么区别补了另一块拼图。至于两种缓存对部署架构的要求，多实例和多租户有什么区别里也有关联讨论。

速查表

• 响应忽快忽慢：先想 KV 缓存有没有被清。
• 账单有折扣行：大概率是前缀命中了提示缓存。
• 想让缓存稳稳命中：开头固定、结尾多变、会话别乱切。

聊聊提示缓存与KV缓存的常见疑问

• 两种缓存能同时生效吗？：能，前缀命中后内部记事本也能接着用，效果叠加。
• 换了会话缓存还在吗？：提示缓存看前缀是否一致，KV 缓存则通常跟随会话，各自规则不同。
• 自己部署能用上吗？：主流推理框架都内置这两类机制，细节以官方技术报告为准。