缓存命中率才是真账本 - 一次数据驱动的AI成本复盘教训

先说我们踩的坑

去年第三季度，我们团队每月的AI API开销涨了三倍多。老板让我复盘，我做的第一件事是错的：我打开了账单页面，看到总额，然后开始“猜”。

猜的内容大概是：可能是新来的实习生调用量大？可能是某次活动脚本跑飞了？可能是模型单价涨了？于是我发了个通知：“大家注意节约使用AI接口。”效果如何？下个月开销继续涨。

这是第一种常见失败做法：看总额做治理。总额只告诉你“疼”，不告诉你“哪里在流血”。

第二種失败做法更隐蔽：无差别降级。我们当时拍板把所有调用从大模型切到便宜的小模型，结果代码解释类任务的质量暴跌，同事偷偷把Key接到了自己个人账号上，成本没省多少，数据反而流出了公司边界。

第三种：一刀切断缓存。有人提建议说缓存返回的结果可能过期，风险大，干脆全关。这等于把已经到手的折扣扔掉——很多供应商对命中缓存的部分收费极低甚至免费，缓存不是可有可无的优化，而是账单结构里最大的一块“折扣区”。

复盘到最后我才明白：不做用量归因、不看缓存命中率，任何成本优化都是玄学。

正确路径：先有数据，再谈策略

我们后来把整个治理流程重做了一遍，核心是三个动作：归因、路由、白名单。下面展开讲。

方法一：用量归因——给每一分钱找到主人

真正的转机是把所有调用收口到统一网关之后。之前二十几个Key散落在各个脚本、服务和个人手里，账单是一锅粥。接入 ThisToken.AI 的网关后，每个调用都带上了标签：哪个项目、哪个团队、哪个功能模块、用的哪个模型、是否命中缓存。

有了这层数据，第一次看报表时我愣住了：

• 一个内部周报生成脚本贡献了近三成开销，因为它每次都重新总结全部原始数据，从不复用；
• 缓存命中率整体只有11%,而同行做法得当的话，同类工作负载能到40%以上；
• 有一个“测试环境”在周末也在跑量，是某个忘了关的调试循环。

这三个发现，每一个都对应一个具体的止血动作，而不是“发通知让大家节约”。归因的本质是把成本从“大家的责任”变成“具体问题的清单”。

方法二：缓存友好路由——让重复劳动别付两次钱

提高缓存命中率的关键，是理解什么调用“值得被缓存”以及“如何提高命中概率”：

1. 稳定提示词前缀。很多供应商的缓存按前缀匹配，系统提示词、few-shot示例、长文档上下文放在最前面且保持字面稳定，命中概率会显著上升。我们曾把动态时间戳放在提示词开头，一个字符的差别，整个缓存全废。
2. 按场景决定是否缓存。代码库解读、文档问答、内部知识库检索这类高频且结果稳定的场景，缓存价值极高；实时性要求强的场景(如行情分析)则不要硬套。
3. 在网关层统一配置。ThisToken.AI 的托管渠道能力让我们可以在网关层面为不同项目配置缓存策略，而不需要每个脚本自己实现一遍。策略改动一次生效，全团队受益。

调整一个月后，我们的整体缓存命中率从11%爬到38%,这部分开销的降幅直接体现在账单上——不是靠降级模型，而是靠不重复付费。

方法三：模型白名单与条件路由——贵的模型留给值得的问题

归因数据揭示的另一个真相是：大量低价值调用(格式转换、简单分类、日志摘要)在用旗舰模型，而真正需要深度推理的任务反而因为怕贵被限制了。

我们的做法是建立角色白名单 + 条件路由：

这套东西在 ThisToken.AI 上配置起来很直接：网关侧定义渠道和模型白名单，按项目Key绑定规则，超出预算自动熔断或降级，而不是靠月度账单出来后追责。

一份可以抄走的预算治理清单

写在最后

那次复盘之后我有个总结：成本优化的天花板，取决于你能不能回答“每一分钱是谁、在什么场景、以什么命中率花掉的”。 回答不了，就只能降级模型、发通知、砍预算，全是伤及无辜的手段；回答得了，优化动作就是精准的、可验证的。

如果你的团队还在用散装Key、靠账单总额做决策，不妨先把网关和归因这一层搭起来。ThisToken.AI 的网关、模型白名单、托管渠道与路由治理能力，正好覆盖了上面清单里的前半部分，注册即可上手：https://api.thistoken.ai/register

---

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