前言

很多团队做大模型应用时，第一反应通常都是这些：

• 模型够不够强？
• 上下文够不够长？
• RAG 准不准确？
• Agent 会不会调用工具？
• 推理链路稳不稳定？

这些当然都重要。
但当系统真正开始上线、开始有真实流量、开始出现并发和成本压力时，一个原本不那么显眼的问题会迅速冒出来：

为什么很多请求明明内容差不多，却每次都要从头再算一遍？

比如你做一个企业知识库问答系统，几十万次请求里，很多部分其实都高度重复：

• 系统提示词是固定的
• 角色说明是固定的
• 工具定义是固定的
• 大段业务规则是固定的
• 同一个会话前半段历史也经常重复
• 一些通用上下文模板几乎每次都一样

如果这些内容每次都完整送进模型、完整重新计算，问题就会很快出现：

• 成本越来越高
• 首 token 延迟越来越长
• 吞吐越来越差
• 越是复杂 Agent，越容易被这类重复开销拖慢

这时候你会发现：

大模型系统很多性能问题，不只是“模型推理太贵”，而是“系统在反复为同样的 prompt 付费”。

而 Prompt Cache，就是解决这个问题的一种关键工程手段。

很多人第一次听到这个词，会把它理解成：

“不就是缓存一下 prompt 吗？”

但真正从系统角度看，它远不只是“缓存一段字符串”这么简单。

如果说 Prompt 决定的是模型这次看到了什么，
那么 Prompt Cache 决定的，就是：

这些已经看过、而且经常重复的上下文，能不能别每次都重新付出同样的代价。

---

一、什么是 Prompt Cache？

1. 最直白的理解：把“重复输入”变成“可复用前缀”

如果用一句话解释 Prompt Cache，可以这样理解：

当多个请求共享相同或高度相似的 prompt 前缀时，把这部分重复计算复用起来，而不是每次都重新处理。

这里最关键的词不是“缓存”，而是：

重复前缀

因为在大模型请求里，真正经常重复的，通常不是整条请求，而是前面很长的一段“公共上下文”。

例如一次企业问答请求，输入可能长这样：

1. 系统提示词
2. 安全约束
3. 工具定义
4. 业务规则说明
5. 会话历史
6. 用户当前问题

其中：

• 第 1～4 部分可能长期固定
• 第 5 部分可能在一个会话内大部分重复
• 只有第 6 部分是新内容

如果每次都把前 1～5 部分重新完整走一遍模型前向过程，成本会非常高。
而 Prompt Cache 的核心思想，就是：

把这些稳定部分尽量复用，让模型只为“新增加的变化部分”付出更多计算。

---

2. 它不是“缓存答案”，而是“缓存输入处理结果”

很多人第一次接触 Prompt Cache，容易把它和普通接口缓存混在一起。

但两者本质不同。

普通缓存更像：

• 同样请求进来
• 直接返回之前的最终结果

例如：

• 同样的商品详情请求
• 同样的搜索关键词
• 同样的配置读取

这类缓存的目标是：连计算都不做，直接复用最终输出。

---

Prompt Cache 则更像：

• 最终答案未必一样
• 但前面的输入上下文有很大一部分是重复的
• 所以复用“前半段输入处理成本”

也就是说，它不一定直接返回完整答案，
而是帮助你减少：

• prompt 预处理开销
• 前缀 token 编码开销
• 模型对固定上下文的重复计算
• 同一套系统上下文被无数次重读的成本

所以更准确地说：

Prompt Cache 不是结果缓存，而是前缀复用。

---

3. Prompt Cache 最像什么？最像“公共材料预装”

可以打一个更容易理解的比喻。

假设你每天都要开很多场会，每场会之前都要发这些固定资料：

• 公司背景
• 项目介绍
• 团队结构
• 会议规则
• 术语说明

如果每次开会都从零开始重新讲一遍，效率当然很低。

更合理的方式是：

把这些公共材料提前准备好，后面每场会只补充这次会议的新议题。

Prompt Cache 做的事情就很像这个：

• 公共上下文提前复用
• 当前请求只追加新内容
• 系统不再为重复部分一遍遍付费

所以从工程视角看，Prompt Cache 的价值并不只是“快一点”，而是：

把大模型请求里大量重复的基础成本，从按次重复支付，变成按前缀复用。

---

二、为什么 Prompt Cache 会越来越重要？

1. 因为真实的大模型应用，重复内容远比想象中多

很多人做 Demo 时，对 Prompt Cache 没什么感觉。
因为 Demo 通常很简单：

• 一段 prompt
• 一个问题
• 一次回答

这种场景下，重复前缀不明显，缓存价值也不突出。

但真实系统不一样。

一个真实线上大模型系统里，重复部分往往比你想象得多得多：

• 固定 system prompt
• 固定安全策略
• 固定角色定义
• 固定输出格式要求
• 固定工具 schema
• 固定业务知识块
• 长会话里前半段历史
• 多个用户共享的一致模板

也就是说：

你的请求看起来很多样，但真正变化的，往往只是末尾那一小段。

这时如果没有 Prompt Cache，系统就会不断为同样的前缀反复买单。

---

2. 因为上下文越长，重复成本越高

Prompt Cache 的价值在短 prompt 场景里也许不明显，
但一旦进入长上下文系统，它的意义会迅速变大。

比如：

• RAG 拼了很多检索结果
• Agent 带了很多工具描述
• 系统提示词很复杂
• 会话历史很长
• 输出格式要求很严格
• 安全策略和边界说明很多

这时候，你的每次请求可能都包含大量“必带材料”。

问题在于：

这些材料虽然必要，但并不等于每次都值得重新计算一遍。

上下文越长，重复成本越高；
重复成本越高，Prompt Cache 的收益就越明显。

---

3. 因为很多 AI 应用的性能瓶颈，并不只在“模型慢”，而在“重复输入太多”

很多团队优化性能时，第一反应往往是：

• 换更快的模型
• 缩短上下文
• 减少检索文档
• 减少工具数量
• 降低输出长度

这些手段当然都有效。
但很多时候，真正隐藏的浪费是：

大量请求都在重复处理同一批固定输入。

也就是说，系统慢不一定只是因为“模型本身慢”，
还可能因为：

• 固定前缀太长
• 每次都从零开始
• 会话历史不断重复计算
• 工具描述每轮都完整重放
• 系统模板无法复用

从这个角度看，Prompt Cache 其实是在解决一个很典型的系统问题：

如何减少不必要的重复计算。

---

三、Prompt Cache 和普通缓存，到底有什么不一样？

1. 普通缓存追求“命中后直接返回”，Prompt Cache 追求“命中后少算一段”

这是最核心的区别。

普通缓存的思路是：

• 输入一样
• 输出也一样
• 直接返回结果

Prompt Cache 的思路是：

• 输入不完全一样
• 输出当然也不一样
• 但前面一大段上下文一样
• 所以可以只重新计算后面变化的部分

所以两者关注点根本不同：

• 普通缓存关注“结果复用”
• Prompt Cache 关注“前缀复用”

---

2. 它更适合处理“共享骨架 + 局部变化”的请求

Prompt Cache 特别适合的请求结构通常是这样的：

一套长期固定的输入骨架 + 一小段会变的尾部内容

比如：

• 固定 system prompt + 不同用户问题
• 固定工具定义 + 不同任务步骤
• 固定业务规则 + 不同查询参数
• 固定会话历史前半段 + 当前最新一轮消息

这类场景下，请求不是完全一样，
所以普通结果缓存不一定有用；
但前缀重复度极高，所以 Prompt Cache 的价值很大。

---

3. 它和 Response Cache、Semantic Cache 也不是一回事

这个边界也很值得讲清楚。

Response Cache

缓存的是最终输出。
适合同样输入得到同样结果的场景。

---

Semantic Cache

缓存的是“语义相近问题”的已有答案。
适合 FAQ、知识问答、重复问题较多的场景。

---

Prompt Cache

缓存的是请求前缀或输入处理开销。
它不关心问题语义是不是近似，
而更关心：

前面这一大段 prompt，是不是已经出现过。

所以三者的作用点不一样：

• Response Cache：省整个回答过程
• Semantic Cache：省相似问题的再次生成
• Prompt Cache：省固定上下文的重复处理

很多成熟系统里，这三种缓存甚至会同时存在。

---

四、Prompt Cache 最适合用在哪些场景？

1. 长 system prompt 场景

这是最常见的一类。

比如你的系统里有很长的基础提示词，里面包含：

• 角色说明
• 输出规范
• 安全边界
• 产品知识
• 操作约束
• 风格规则

如果这部分每次都重新送给模型，它本身就已经是很大的固定成本。

所以：

系统提示词越长，Prompt Cache 越值得做。

---

2. 工具很多的 Agent 场景

Agent 系统经常有一个特点：

• 要把很多工具定义暴露给模型
• 每个工具还有参数 schema
• 有时还要附带使用规则和调用说明

结果就是，光“工具说明”这一段就可能占据大量上下文。

而这些内容通常又非常稳定。
如果每次调用都完整重算，成本和延迟都会明显变高。

所以在 Agent 系统里，Prompt Cache 的价值通常比普通聊天场景更大。

---

3. 多轮会话场景

多轮会话里，前面的会话历史经常反复出现。

特别是长对话中，前半段消息在很多轮里几乎完全不变，
只有最后一两轮是新增内容。

这时候，如果整段历史每轮都重新计算，浪费会很大。
Prompt Cache 可以帮助系统复用前面的公共历史，减少重复开销。

---

4. 模板驱动型业务场景

比如这些应用：

• 法务审查
• 合同总结
• 结构化信息抽取
• 代码审查
• 标准化报告生成
• 客服流程问答

这类系统通常都有一个固定模板骨架，只是局部内容不同。
因此非常适合通过 Prompt Cache 来优化成本和时延。

---

五、那 Prompt Cache 到底缓存的是什么？

1. 不是简单缓存字符串，而是缓存“可复用上下文”

很多人容易把 Prompt Cache 理解成：

把 prompt 文本存下来，下次再拿出来用。

但真正工程上更关键的是：

缓存的不是字面文本本身，而是这段文本在模型调用链路中的可复用价值。

具体来说，Prompt Cache 关注的往往是：

• 哪段前缀稳定
• 哪段上下文会频繁复用
• 哪段内容变化最少
• 哪段内容最贵
• 哪段内容可以独立成缓存边界

所以真正重要的不是“有没有存下来”，
而是：

有没有把高重复、高成本、低变化的那部分切出来。

---

2. 一个成熟的 Prompt Cache，通常至少要识别三层内容

（1）全局固定前缀

例如：

• system prompt
• 安全策略
• 工具定义
• 输出格式协议
• 统一业务规则

这类内容通常跨用户、跨请求都很稳定，
最适合做全局缓存。

---

（2）会话级稳定前缀

例如：

• 某个会话前半段历史
• 某个任务中间已经确认的上下文
• 某个 agent 当前阶段的固定工作记忆

这类内容不会全局共享，但会在局部任务周期内反复使用。

---

（3）请求级动态尾部

例如：

• 当前用户新问题
• 最新一步工具返回
• 新增检索结果
• 当前轮的最新状态变化

这部分变化最大，通常不适合作为稳定缓存主体。
它更适合被追加，而不是被强行缓存。

---

3. 所以 Prompt Cache 的核心，其实是“切分能力”

很多团队做不好 Prompt Cache，并不是不会写缓存逻辑，
而是没有把 prompt 切对。

因为真正难的不是：

“怎么存”

而是：

“哪一段值得存”

如果切分错了，就会出现两类问题：

• 缓存命中率很低
• 缓存了一堆没价值的内容

所以 Prompt Cache 的本质问题，不只是缓存问题，
更是：

Prompt 结构设计问题

---

六、为什么很多团队做了 Prompt Cache，效果却不明显？

1. 因为缓存边界切错了

这是最常见的问题。

比如你把整个请求都当作一个缓存单元，
那只要用户问题有一点变化，缓存就失效了。

又比如你把动态检索结果也塞进固定前缀，
那命中率也会迅速下降。

所以如果缓存切得太粗，
会导致：

• 命中率低
• 复用价值差
• 管理成本高

真正有效的 Prompt Cache，往往依赖精细的前缀切分。

---

2. 因为变化内容混进了固定层

很多系统表面上看 system prompt 很固定，
但实际里面混进了这些东西：

• 时间戳
• request id
• 动态用户属性
• 不稳定排序结果
• 临时注释
• 可变 metadata

这些内容一旦混进去，原本应该稳定的前缀就被污染了。

于是你会发现：

• 理论上很适合缓存
• 实际上却总命不中

这不是缓存机制的问题，
而是 prompt 设计没有把“稳定层”和“变化层”分开。

---

3. 因为只想着省钱，没有把它当系统优化手段

很多人看 Prompt Cache，第一反应只是：

能不能便宜一点？

省钱当然重要。
但如果只把它看成“账单优化工具”，就容易低估它真正的价值。

Prompt Cache 同时影响的，其实还有：

• 首 token 延迟
• 系统吞吐
• 并发承载能力
• Agent 多步执行速度
• 长会话体验稳定性

换句话说，它不仅是成本优化，
还是：

性能优化 + 架构优化

---

七、从工程角度看，Prompt Cache 应该怎么设计？

1. 先设计 prompt 结构，再设计缓存策略

很多团队是反过来的：
先想到“我要做缓存”，然后再看哪里能塞。

更合理的顺序通常是：

1. 先把 prompt 分层
2. 再识别稳定前缀
3. 再决定缓存边界
4. 最后再落缓存策略

也就是说：

Prompt Cache 的前提，不是缓存系统，而是结构化 prompt。

---

2. 固定层、会话层、动态层要明确分开

一个成熟系统通常会把 prompt 至少拆成这三部分：

固定层

长期不变，尽量全局复用。

会话层

在单个任务或会话内比较稳定，适合局部缓存。

动态层

实时变化，只负责追加，不强求缓存命中。

这种分层做得越清晰，Prompt Cache 越容易真正发挥作用。

---

3. 要把命中率、节省 token、延迟收益一起看

评估 Prompt Cache，不能只盯着一个指标。

更应该一起看：

• 缓存命中率
• 节省了多少输入 token 成本
• 首 token 时间下降多少
• 系统吞吐提升多少
• 多轮会话里平均收益如何
• Agent 长链路中累计节省了多少

否则很容易出现一种错觉：

好像做了缓存，但业务上感知不明显。

很多时候不是没收益，
而是你只看了账单，没有看整条链路。

---

八、为什么说 Prompt Cache 会逐渐变成大模型应用的基础设施？

1. 因为上下文会越来越长，公共前缀也会越来越重

未来的大模型应用只会越来越复杂：

• 更长的 system prompt
• 更复杂的安全规则
• 更多工具定义
• 更长的对话历史
• 更多业务说明
• 更重的 RAG 上下文

这意味着，请求里“公共材料”的比例会越来越高。

而公共材料越重，Prompt Cache 的基础设施属性就越明显。

---

2. 因为 AI 系统的竞争，最终会落到工程效率上

到了后面，很多团队的模型差距会缩小，
大家都能接到不错的底座模型。

真正拉开差距的，往往不只是：

• 你会不会写 prompt
• 你会不会接工具
• 你会不会做 RAG

而是：

• 你系统的成本控制怎么样
• 你首 token 延迟怎么样
• 你多步执行效率怎么样
• 你在相同预算下能承载多少流量

这时候，Prompt Cache 就不再只是一个“小优化”，
而会逐渐变成系统层能力。

---

3. 因为它本质上是在解决“重复工作”问题

任何成熟的软件系统，只要存在大量重复工作，最后都会走向缓存、复用、预计算或分层优化。

大模型系统当然也不例外。

而 Prompt Cache 解决的，正是其中最典型的一类重复：

同样的上下文，不该每次都从头再处理一遍。

所以从更本质的角度看，Prompt Cache 并不只是大模型里的一个技巧，
而是大模型系统走向工程化之后，一个很自然的基础设施方向。

---

总结

很多人一开始理解 Prompt Cache，会把它看成一个“节省 token 费用的小技巧”。

但如果从真实系统的角度看，它的重要性远不止如此。

因为大模型请求里，真正重复的往往不是完整请求，
而是：

• 长 system prompt
• 工具定义
• 安全规则
• 会话历史前缀
• 模板化业务上下文

如果这些内容每次都重新计算，系统就会不断为同样的输入重复付费。

所以，Prompt Cache 真正解决的并不是“存一段 prompt”这么简单，
而是：

• 如何识别稳定前缀
• 如何减少重复计算
• 如何降低长上下文系统的固定成本
• 如何让多轮会话和 Agent 链路更高效
• 如何把大模型应用做成一个更像系统的系统

也正因为如此，Prompt Cache 的价值，绝不只是“省钱”。

它更接近于：

让大模型应用从一次次重复计算，走向前缀复用与工程优化。

如果说 prompt 决定的是模型这次看到了什么，
那么 Prompt Cache 决定的，就是：

这些已经看过很多次的东西，能不能别再一遍遍重算。

而这，正在越来越接近大模型应用的隐形基础设施。

---

一句话结论

Prompt Cache 不是在缓存答案，而是在复用大模型请求里那些高成本、低变化、反复出现的公共前缀。