提示缓存怎么省下70%成本：架构、陷阱与选型

被忽视的降本大头

谈 AI 降本，大家先想到换小模型、砍上下文、做路由。但有一个手段往往被忽略——提示缓存（Prompt Caching）：把重复出现的前缀部分缓存起来，后续请求直接复用，不重复计费、不重复计算。

在客服、代码助手、Agent 这类”系统提示很长、用户输入很短”的场景里，提示缓存能省掉 50%–90% 的输入 token 成本。而你几乎什么都没改。

原理：前缀是复用的关键

主流大模型的推理都基于 Transformer。同一段前缀（prefix）在不同请求里重复时，其对应的 KV（Key-Value）计算结果是一样的。缓存这部分的中间状态，后续请求就能跳过重复计算。

关键约束：只有完全一致的前缀才能命中缓存。 顺序错了、中间插了一个变量、少了一个空格，缓存就失效。

这决定了缓存友好的提示结构：

[固定系统提示] [固定工具定义] [固定知识] ─┐
                                          ├─ 可缓存前缀
[动态用户输入] ─────────────────────────┘

把稳定内容放前面，动态内容放最后。 这是全部诀窍里最重要的一条。

常见的缓存杀手

很多人以为自己开了缓存，其实命中率接近零。检查这些：

1. 时间戳/请求 ID 放在开头：每个请求都不同，缓存全废
2. 检索到的知识顺序不稳定：RAG 结果排序每次不同，前缀就变了
3. 系统提示里嵌了随机示例：Few-shot 示例每次随机选，前缀不稳定
4. 多余空白和格式抖动：JSON 序列化顺序不一致
5. 多租户混用：不同租户前缀不同，本该分片管理

把”可变”的部分一律后置，把”稳定”的部分固定下来，命中率自然上去。

与 RAG 的组合：注意顺序

RAG 场景的经典矛盾：检索内容每次都变，但系统提示和工具定义是稳定的。

正确结构：

[系统提示 + 工具定义]        ← 稳定，缓存
[静态知识库摘要]             ← 尽量稳定
[动态检索结果]               ← 变化，放后面
[用户问题]                   ← 变化，最后

把动态检索结果放在稳定前缀之后，就能保住前面那段的缓存。如果检索内容插到系统提示中间，缓存直接归零。

与模型路由的组合

路由（简单请求走小模型）和缓存不是竞争关系，是叠加的：

• 缓存先减少单次请求的成本
• 路由再选择更便宜的模型处理

两者组合，降本效果是乘法的。一个常见坑是：为了路由方便，给每个模型都重排了提示格式，结果破坏了各自缓存的稳定性。路由时也要保持各模型前缀结构一致。

缓存的两类：输入与输出之别

• 输入缓存：省的是前缀 token 的重复计算，最主流
• 输出缓存：某些场景对相同输入直接返回缓存答案（对确定性问答极有效，但对创意任务不适用）

对高频 FAQ、固定计算类请求，输出缓存的效果甚至好于输入缓存——直接零成本返回。但要设 TTL 和失效策略，避免返回过期答案。

量化的收益

假设一个客服 Agent：

• 系统提示 + 工具定义：4000 token（固定）
• 检索知识：2000 token（每次变）
• 用户问题：200 token（每次变）

不做缓存，每次输入约 6200 token。做了缓存后，每次只需为变化的 2200 token 付费（假设缓存命中的 4000 token 按 10% 计费）。

输入成本大致降到原来的 45% 左右。 请求量越大，收益越明显。

选型检查清单

• 我的应用是”长前缀 + 短输入”模式吗？（是才值得做）
• 提示结构是否符合”稳定在前、动态在后”？
• 有没有把时间戳、随机 ID 放进前缀？
• RAG 检索结果是否后置？
• 缓存命中率有监控吗？
• 缓存 TTL 与内容更新频率匹配吗？
• 多租户是否分片管理缓存？

结语

提示缓存是投入产出比最高的降本手段之一：几乎不用改业务逻辑，只需要把提示结构理顺，就能拿到显著的省钱效果。先把”变的东西放后面”这一条做到，你就已经超过了大多数团队。别把时间和钱浪费在重复计算上。