提示词缓存

在学习上下文工程时，我们知道可以给大模型喂很多资料，比如几十页的公司产品手册、好几十轮的历史对话，甚至上万行的代码库。

资料给得越足，AI 干活确实越靠谱。但现实很快就会给你浇一盆冷水：

• 慢：每次提问，AI 都要把这几万字重新读一遍。等你拿到第一句回答，可能几秒钟甚至十几秒就过去了。
• 贵：大模型的 API 是按 Token（字数）算钱的。你每次问它一个几十字的小问题，它却要按几万字的阅读量给你算账，这成本谁顶得住？

那么，有没有一种方法，能让 AI 把那些固定不变的资料 “背” 下来，下次再问的时候直接答呢？答案是肯定的，这就是我们要聊的硬核技术——提示词缓存。

什么是提示词缓存？

提示词缓存（Prompt Caching），简单来说就是：把多次请求中重复出现的那部分内容，暂时存放在大模型厂商的服务器内存里。等下一次请求遇到相同或高度一致的 “前缀” 时，平台直接复用已经处理好的内容，不用再从头计算一遍。

这里的 “前缀”，可以理解为提示词最前面那一大段固定的内容，比如：

• 长篇的系统提示词和业务规则。
• 固定的 Few-Shot（少样本）问答示例。
• 被反复查询的产品手册、合同或长文档。
• 工具的定义和调用说明。
• 长对话里已经稳定下来的历史消息。

当你第一次发送这些内容时，平台没见过，只能老老实实从头处理，这叫 “缓存未命中（Cache Miss）” 。

处理完之后，符合条件的内容就会被悄悄写进缓存。而在接下来的请求，如果用了同样的前缀，平台直接调取缓存，这叫 “缓存命中（Cache Hit）” 其中，命中的部分不仅处理速度极快，API 计费通常也会便宜不少。

示例：

第一次请求：固定内容 + 当前问题
    ↓
缓存未命中：完整处理，并写入缓存

后续请求：相同固定内容 + 新问题
    ↓
缓存命中：复用固定内容，只继续处理变化部分

简单来说，提示词缓存不是让 AI 少看资料，而是让它别对同一份资料反复从头 “预习”。

提示词缓存到底缓存了什么？

很多小伙伴第一次接触 “缓存”，容易产生一个误解：是不是把 AI 上次生成的答案给保存下来了，下次原样返回？

其实并不是。准确来说，提示词缓存复用的是重复的输入内容（前缀），而不是最终的输出答案。

即使你的长篇资料命中了缓存，大模型依然会根据当前的新问题，老老实实地去生成新回答。所以，哪怕是同一个问题问两次，答案依然可能会有细微的差别。

为了避免混淆，我们可以简单区分一下这几个常见概念：

• 提示词缓存：复用重复的输入前缀，主攻省钱和提速。
• 回答缓存：直接保存生成的最终答案，遇到一模一样的问题直接返回旧答案（通常由开发者自己在后端实现）。
• RAG（检索增强生成）：临时从知识库里搜资料，再拼给大模型看。
• 长期记忆：记住用户的偏好，让后续对话更懂你。

它们可以搭配着干活，但各司其职。提示词缓存不是数据库，一旦缓存过期或者你的提示词结构变了，资料还是得重新处理。

哪些场景适合用提示词缓存？

提示词缓存最适合 “前面一大段内容长期不变，后面只有一小部分不断变化” 的任务。

其中，常见能获得较高收益的场景包括：

• 长系统提示词：比如客服、代码审核助手，每次的规则和角色设定都一模一样。
• 海量示例：提示词里塞了几十个标准的输入输出示例。
• 单文档反复问答：围绕同一本几万字的电子书或财报，连续提问。
• 长对话与 Agent 智能体：每一轮对话都要带着相同的工具定义和前面的大段聊天记录。
• 批量处理任务：用同一套长规则，排队处理大量不同的短文本。

相反，下面这些场景通常收益不大：

• 提示词很短：满打满算才几百个字，没什么重复的价值。
• 一次性任务：刚把缓存建好，任务就结束了，再也不用了。
• 前缀频繁变化：提示词开头每次都大变样，根本攒不出稳定的公共前缀。
• 资料高频更新：旧缓存还没焐热就失效了。

缓存不是免费的魔法。只有同一份内容被重复利用的次数足够多，省下的钱和时间，才能抵消掉缓存写入和管理的开销。

核心原则：固定放前面，变化放后面

大多数提示词缓存都是围绕 “共同前缀” 来工作的。也就是说，请求最前面的内容越稳定，命中率就越高。

假设每个用户的请求结构都长这样：

# 当前用户
[每次都在变的用户 ID、时间戳和问题]

# 系统规则
[长达一万 Token 的固定业务规则和示例]

这种写法非常吃亏。因为最前面的用户信息每次都在变，导致后面那一大段固定规则也跟着无法复用。这就好比每次换个门牌号，快递员连后面的整条街都当成新路重新认一遍。

更合理的结构应该是：

# 固定系统规则
[长期不变的角色、约束和安全规则]

# 固定示例与参考资料
[Few-Shot 示例、工具说明、公共文档]

# 当前用户与任务
[每次变化的用户信息和问题]

小伙伴们记住一句话：公共内容尽量放前面，个性化内容尽量放后面。

另外，像时间戳、随机编号、追踪 ID 等每次变化的数据，我们应该避免随手塞在固定前缀的最开头，不然缓存命中率大概率是个零蛋。

提示词缓存为什么会失效？

提示词缓存不是 “创建一次，终身有效”。想要让它稳定干活，得避开这几个坑：

• 公共前缀变了：哪怕只在最前面多加了一个空格、换了一下段落顺序，系统也会认为这是一段全新的内容，导致缓存未命中。
• 缓存过期了：缓存通常有个存活时间（TTL，比如 5 分钟）。超过时间没请求，就得重新写入。
• 模型换了：缓存通常和特定的模型版本绑定。更换模型、模型版本或 API 平台后，原来的缓存通常不能继续复用。
• 资料更新了：公司的退款政策改了，旧缓存就应当立即作废。不要为了省那几分钱的 API 费用，让 AI 抱着过期的政策忽悠客户。

自动缓存与显式缓存

不同的大模型厂商，通常会提供两类缓存方式：自动缓存和显式缓存。

1. 自动缓存（Implicit Caching）

平台在后台自动判断你的请求有没有重复前缀。符合条件就自动缓存，开发者基本不用改代码，接入毫无压力。

这种缓存方式的缺点是，控制权不在你手里。

2. 显式缓存（Explicit Caching）

显式缓存，指的是开发者在代码里主动打上标记，明确告诉平台 “从提示词开头到这个位置，属于可以重复使用的公共前缀。”

控制虽然更细了，但管理工作也变多了。你需要自己去处理缓存版本、有效期、失效策略以及不同用户之间的数据隔离。

目前主流厂商的支持情况变化很快，比如 OpenAI API 和 Claude API 都对 Prompt Caching 有着各自的优化方案，大家在写代码前记得翻一翻最新的官方文档。

实战演示：给课程答疑助手做提示词缓存

假设我们要给绿叶网的在线课程开发一个 AI 答疑助手。每次学生提问时，系统都需要提供下面这些固定内容：

• 课程规则。
• 章节目录。
• 20 组问答示例。
• 退款政策。

这些固定内容加起来有 12000 Token，而学生每次真正的问题只有 300 Token 左右。

如果不考虑缓存，请求结构是：

12000 Token 固定资料 + 300 Token 问题 = 每次按 12300 Token 计费。
如果问 100 次，总计费就是 123 万 Token。

开启提示词缓存后：

第一次提问：12000 Token 缓存写入（通常按普通或略贵的费率）+ 300 Token 问题
后续 99 次：12000 Token 缓存读取（通常有极大的折扣）+ 300 Token 问题

长期跑下来，Token 的账单消耗会直线下降，而且首 Token 响应时间（Time to First Token，TTFT）也会有肉眼可见的提升。

怎样判断缓存到底有没有省钱？

我们不要一看到 “缓存” 两个字就觉得一定能省钱，账单是不会陪你演戏的。上线后，建议重点盯一下这几个指标：

• 缓存命中率：到底有多少请求真正蹭到了缓存？
• 写入成本 vs 读取收益：如果每次写入的缓存只被用了一两次就过期了，可能不仅没省钱，反而更亏。
• 响应延迟：首字呈现时间（TTFT）是不是真的变快了？

最稳妥的办法，是用一小部分真实流量先跑跑灰度测试，把开启缓存前后的账单和延迟拉出来对比一下，心里有底了再全面铺开。