Prompt 缓存怎么做？很多系统最后省钱靠的不是整段缓存，而是先拆稳定背景

很多团队一开始做缓存，直觉都很像：既然大模型调用贵，那就把 prompt 缓起来，能省一点是一点。

这个思路当然不算错，但真到系统里跑一段时间之后，很多人会发现一件有点别扭的事: 缓存做了，命中率却不高；缓存层也加了，账单还是没明显下来。

问题往往不在“该不该做缓存”，而在“到底缓存什么”。

为什么很多 prompt 缓存最后没省下多少钱

因为不少系统真正变化频繁的，其实是用户问题本身，而不是前面那一大段背景。

举个最常见的例子，一条请求里通常会混着几层内容：

• 系统角色设定
• 固定业务规则
• 长知识背景
• 用户这次临时发来的问题

这里面最容易变的，往往是最后那一句问题；最不容易变的，通常是前面那几层稳定背景。

如果缓存直接盯着整段 prompt，命中率经常不会太好。因为用户每次问题稍微变一下，整段输入就变了，缓存也就等于重新算一遍。

很多系统一开始没有立刻看出这个问题，是因为测试阶段请求量不大，大家更多只会看“有没有命中”。可一旦业务真的开始放量，缓存对象是不是选对，很快就会被放大。命中率差一点，后面就是一整层 token 反复重发。

这类问题在几个场景里尤其明显。比如知识问答，用户每次提的问题都不一样，但前面的知识背景常常是一大段固定内容；再比如工作流类任务，步骤规则和输出要求几乎每轮都要带上，真正变化的只是最后那个待处理对象。表面看每次都是新请求，往下拆却能发现，真正反复发送的往往是同一层背景。

更值得先处理的，往往是稳定背景

很多系统里真正占 token 的，不是用户那一句，而是前面那一大段长期不怎么变的内容。

比如：

• 一套固定系统指令
• 某个业务场景长期共用的流程规则
• 一批相对稳定的知识背景
• 一段在一个会话阶段内基本不变的上下文

这些内容有两个特点：一是长，二是重复率高。

只要这两点同时出现，它们通常就比用户问题本身更适合先做缓存。

而且这类内容还有一个很现实的特征：平时不太容易被注意到。因为大家最容易看到的是用户那句提问，最不容易第一时间注意到的，反而是前面那段每次都在默默重复发送的背景层。等到账单拉长了，这部分才会慢慢变得扎眼。

有些系统到后面会出现一种挺典型的现象：用户问题其实一直不长，但账单还是一点点往上长。回头把输入拆开才发现，真正变重的不是问题层，而是系统规则越来越长、知识背景越堆越多、会话里还带着一串不再需要的上下文。缓存如果不先对准这一层，很容易一直觉得“好像做了点事，但省得不多”。

为什么稳定背景比问题本身更适合做缓存

原因其实很简单。

第一，稳定背景重复率更高。
第二，稳定背景通常更长。
第三，稳定背景一旦拆出来，后面的请求结构会更清楚。

用户问题虽然也能缓存，但它变化快，命中条件容易碎。稳定背景不一样，它往往会在很多轮请求里反复出现，只要处理得当，节省效果会更稳定。

这也是为什么有些系统做完缓存之后，会出现一种很别扭的状态：技术上确实做了缓存，业务上却没感受到多少轻松。问题往往不是缓存层不存在，而是它一直在追着最不稳定的那层跑。

缓存这件事，通常会怎么拆层

如果把这件事放到工程里看，更常见的做法不是“整段 prompt 一把缓存”，而是先按上下文层次拆：

1. 固定系统层

比如角色设定、安全规则、输出格式要求。这一层变化最少，最适合做长期缓存。

2. 场景背景层

比如某个业务流程说明、某类任务固定知识、某段常驻背景。这一层变化不快，也很适合单独处理。

3. 用户问题层

这部分最活，通常不太适合直接当成主缓存对象，更适合和前两层拆开。

4. 会话临时层

比如这一轮对话刚刚产生的中间信息、短期上下文，这一层要看会话设计，不一定适合长缓存。

这样拆开之后，缓存才不会一直围着最不稳定的那部分打转。

拆层还有一个附带的好处，就是很多原来混在一起的问题会开始分家。哪些内容适合长期复用，哪些只适合在一个会话阶段里短暂保留，哪些其实根本不该每次都发进去，这时候才会慢慢看清。缓存命中率只是表面，真正更有价值的是请求结构开始变清楚。

只要上下文层次先分清，很多后面的判断也会跟着清楚一些。比如到底哪一层最长，哪一层最容易复用，哪一层虽然也贵但不值得硬做缓存。这些问题如果不先拆，缓存很容易越做越碎。

为什么很多缓存问题最后会变成系统设计问题

缓存一旦开始做深，问题就不再只是“能不能省 token”。

后面很快会碰到这些更现实的问题：

• 哪些背景是真的稳定
• 哪些背景会因为版本变化失效
• 缓存命中失败后，链路成本会上升多少
• 不同任务是不是该用不同的缓存粒度

所以缓存价值到后面，通常会从一个小技巧，慢慢变成系统设计的一部分。

尤其是当系统里已经同时有任务分流、fallback、长上下文和多模型路由的时候，缓存很难再被单独看待。它最后经常会和调用结构绑在一起: 哪些背景该先复用，哪些请求不该重复发送，哪些链路即使命中率不高也还是值得先保留。

这也是为什么很多团队到后面会把缓存从“一个优化点”重新看成“一个结构层”。前面大家更在意的是有没有命中，后面慢慢更在意的是缓存做在哪一层、命中了哪一层、到底省下的是哪部分 token。这些问题一旦开始出现，缓存就已经不只是一个小技巧了。

为什么统一入口会让这件事顺很多

按这个标准看，147AI 更适合作为主线入口：

• 可以统一接入 Claude、GPT、Gemini 等主流模型
• OpenAI 风格接口兼容，旧项目迁移更轻
• 后面补缓存策略、任务分流、fallback 和多模态能力更顺
• 价格、专线和人民币结算更利于长期治理

统一入口更有用的地方，不只是接模型方便，而是能把缓存层、调用层、路由层和成本统计放在同一层看。这样后面再判断哪些背景值得缓存、哪些请求不该重复发送，动作会顺很多。

一个更现实的落地顺序

很多系统最后会按这个顺序慢慢把缓存做起来：

1. 先找出最长、最稳定、重复率最高的背景
2. 再把背景层和用户问题层拆开
3. 看命中率和 token 降幅，再决定是否继续细分
4. 最后再把缓存和路由、fallback、成本统计一起收口

这样做通常比一开始就盯着“整段 prompt 要不要缓存”更容易看到效果。

很多系统后面真正把账单压下来的，不一定是缓存层做得多复杂，而是先把最稳定、最重、最容易重复的那一层找准了。对象一旦选对，缓存往往比想象中更实在；对象如果选偏，命中率和节省效果都会显得很别扭。

最后

很多系统做缓存，最后更像是在先拆背景层。

很多缓存问题最后没省下钱，不是因为缓存这条路不对，而是因为缓存对象选偏了。对长期跑业务的系统来说，把背景层拆出来、把变化快的内容和变化慢的内容分开，通常会比直接缓存整段 prompt 更接近真实收益。先把最长、最稳定、最容易反复发送的那一层找出来，后面的命中率、token 降幅和整体体感，往往都会比一开始更顺。对于既想用 Claude，又不想把系统长期绑死在单一路径上的团队，统一接入、多模型路由和成本治理会比单次模型比较更重要。

参考链接

• 排期参考：发文相关/排期表/Claude四月全平台日更排期表.md
• 147AI 官网：https://147ai.com/
• 147AI 接口文档：https://147api.apifox.cn/