相同的问题问了一百遍，账单就翻了一百倍——缓存没做对，预算治理全是白忙

先说三个失败现场

失败现场一：把希望寄托在“供应商缓存”上。

某工具团队上线了一个文档摘要服务，每次用户打开同一篇文档就重新调用一次大模型。负责人听说部分供应商有自动 prompt 缓存，就默认“平台会帮我省”，结果月底账单纹丝不动。原因很简单：供应商的自动缓存通常只对完全一致的前缀生效，而他们的代码里每次都会在 prompt 头部拼一个时间戳和随机会话 ID——前缀永远不同，缓存永远命中不了。指望别人替你省钱，先得保证你的请求真的“长得一样”。

失败现场二：在应用层自己造缓存，但缓存键设计错了。

另一个团队倒是自己写了缓存层，但缓存键直接用了完整的原始 prompt 字符串加上用户 ID。两个用户问同一个问题，缓存失效；同一段系统指令后面跟了不同的换行符，缓存失效；用户问“这个怎么用”和“这个怎么用？”——语义相同，缓存照样失效。更糟的是，他们把对话上下文整个塞进缓存键，而上下文里包含了上一轮的模型回复，导致多轮对话几乎永远无法命中。缓存写了，命中率不到 4%，白白多了一层维护成本。

失败现场三：缓存做了，但没人能证明它省了钱。

第三个团队技术上做对了，缓存命中率稳定在 60% 以上。但季度预算会上，财务问“到底省了多少”，他们拿不出来：缓存在应用层，计费在供应商侧，两边的日志对不上号，用量归因全靠估算。预算治理的最后一公里断了。

这三个现场指向同一个结论：缓存省钱不是“开个开关”，而是一套从请求构造到用量归因的完整策略。

正确路径的三个层次

第一层：让请求“可缓存化”——在写代码时就开始省钱

缓存命中率的上限，在你拼接 prompt 时就已经决定了。要点有三个：

1. 稳定的前缀：系统指令、few-shot 示例、RAG 的固定模板放在 prompt 开头且保持字节级一致，不要嵌入时间戳、随机 ID、请求序号这类每次变化的内容。
2. 合理的缓存键设计：不要用原始字符串全量做键。做归一化（去空白差异、统一大小写策略），再对“系统指令 + 核心问题”做哈希；多轮对话只对“无状态部分”建缓存，而不是把历史全卷进去。
3. 区分可缓存与不可缓存请求：摘要、分类、固定知识问答是缓存金矿；带个性化上下文的对话则应该走另一条路径，别污染缓存键空间。

第二层：网关层的缓存与路由治理——把钱花在刀刃上

应用层缓存管“要不要发请求”，网关层管“发了请求走哪条路”。这也是很多团队从“失控”走向“可控”的转折点。

以 ThisToken.AI 的网关为例，你可以在网关层面统一配置缓存策略和路由规则：

• 模型白名单：先别急着让每个工程师自己挑模型。在网关上配置白名单，明确哪些场景允许调用哪些档位的模型。摘要、打标签这类任务锁死在低成本档；只有复杂推理才放行旗舰模型。缓存未命中时，请求也不会“顺手”落到最贵的模型上。
• 托管渠道与降级路由：当某个渠道延迟异常或额度紧张时，网关可以把请求路由到备用托管渠道，而不是让请求失败重试——重试风暴是账单爆掉的常见隐形杀手。
• 网关侧缓存兜底：即使某个应用忘了做缓存，网关层还可以基于归一化后的请求特征做二次拦截，给整个团队的预算上一道保险。

路由治理的价值在于：省钱规则不再散落在每个服务的代码里，而是集中、可视、可审计。

第三层：用量归因——让省下的钱能被证明

预算治理的闭环是归因。做不到这三件事，缓存做得再好也只是“感觉省了”：

1. 按团队/项目/功能打标：在网关层为每个请求注入归因标签，账单按维度拆分，而不是一锅粥。
2. 缓存命中与计费对账：记录每次请求是缓存命中还是真实调用，月底能直接算出“节省额”，复盘会上才有共同语言。
3. 阈值告警与预算熔断：为每个归因维度设预算上限，异常增长（比如缓存键设计被某次改动破坏、命中率骤降）自动告警甚至熔断，而不是等月底账单惊喜。

一张预算治理清单

结语

“相同 prompt 不重复计费”这句话，一半靠缓存技术，另一半靠治理：谁有权调用什么模型、省下的钱怎么被证明、异常由谁来发现。应用层把请求做规整，网关层把路由和缓存兜底做扎实，归因层把账算清楚——三件事都到位，预算才真正可控。

如果你的团队正准备把 AI 调用纳入统一管理，可以先在 ThisToken.AI 注册一个网关账号，把白名单、路由和用量归因跑起来：https://api.thistoken.ai/register

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。