缓存命中率怎么计算

很多人接了大模型 API，听说开缓存能省钱，但真到月底对账还是一头雾水：命中率到底怎么算、按请求算还是按 token 算、算出来多少算正常、为什么我这边开了缓存却没便宜多少。这篇不讲缓存原理，只解决三件事：命中率的公式该用哪个口径、影响它的因素有哪些、以及怎么按顺序把命中率拉上去。

很多人接了大模型 API，听说开缓存能省钱，真到月底对账还是一头雾水：命中率到底怎么算、按请求还是按 token、算出来多少算正常、为什么开了缓存账单没降多少。这篇不讲缓存原理，只解决三件事：公式用哪个口径、影响它的因素有哪些、按什么顺序把命中率拉上去。

先说一句结论：命中率不是一个数，是一组数。你换个口径、换个分母，结论可能完全反过来。所以别急着优化，先把手上的口径定死，再谈趋势。

先定口径：命中率到底拿什么当分子分母

最常用的写法是「缓存读 token ÷（缓存读 + 缓存写 + 普通输入 token）」。输出 token 通常不放进分母，因为它走的是另一条计价线。但具体哪几项参与分母，要看你所用平台的账单字段定义，别照搬别人文章里的公式。

• token 口径和请求口径差别可能很大：一次请求里只要有一小段没命中，整条请求不算命中，但 token 口径会把命中的部分算进去。
• 对账用 token 口径，看接口行为用请求口径，别混着比。
• 分母口径要固定：今天按全部输入算、明天只按系统提示算，趋势图就没有意义。
• 命中率本身不是钱，要乘上各自单价才有意义；单价会变，去 /official-api 和 /tools/token-price-calculator 核对当时的数字再算。

影响命中率的四类变量：哪些能改，哪些改不了

多数缓存只认「完全一致的前缀」。这句话决定了后面所有事情：前缀一变，前面写过的缓存就白写。理解了这点，再看下面四类变量，你就知道哪些是能动手的。

前缀稳定性

system 提示里塞了时间戳、随机 ID、用户昵称，等于每次重新写缓存，命中率长期贴地

长度与间隔

前缀太短往往达不到最小可缓存长度，间隔太久缓存已过期，这两项受平台规则限制

并发形态

同一段前缀被多个请求同时打进来，早到的写缓存、晚到的读缓存；但每次拼不同文件内容就永远不一致

请求组织方式

把不变的部分放前面、变动的部分放后面，最有效也最容易做错

要注意不适用的情况：短提示、低频调用、一次性任务，硬凑缓存反而增加复杂度，可能写缓存比读缓存还多，得不偿失。

排查顺序：先量出来，再决定改哪一处

1. 第一步 量基线从用量记录里导出最近一段时间的输入、缓存写、缓存读三类 token，算出当期命中率。用量日志该记哪些字段，照 /usage 的思路对齐。
2. 第二步 做单变量对照固定模型和提示词，只改「前缀是否含变动内容」这一项，跑两组数据对比命中率变化。一次只动一个变量，否则归因不了。
3. 第三步 按性价比排序动作通常优先级是先清理前缀里的随机内容，再考虑拆成短提示加检索，最后才是调缓存有效期这类受平台限制的开关。

什么情况下不用管命中率：调用量很小，或者每次内容都完全不同，比如逐条处理互不相关的用户文本。这时候优化命中率的投入产出比很低，不如去看模型档位和输出长度。

把命中率换算成省下的钱，并守住不亏的边界

换算思路：命中部分的 token 数乘以普通输入与缓存读之间的单价差，再减去缓存写多付的部分。缓存写一般比普通输入贵，所以「写得少、读得多」才划算。单价随时会变，具体数字去 /official-api 和 /tools/token-price-calculator 核对当期值再算。

• 业务上判断要不要上缓存，看同一段前缀会被复用多少次：复用够多才回本。
• 只被用一次的提示，缓存写反而更贵，这种情况不开更划算。
• 把命中率当成持续指标挂到月度复盘，而不是一次性开关。
• 价格和规则会变，当期数字以站内页面为准，可以去 /price-watch 看变动记录。
• 对账不符时，先分清是命中率算错、口径没对齐，还是计价项本身不同，不要一上来就怀疑平台。

命中率不是开关，是一条要长期盯的曲线；先固定口径，再动提示词结构，最后才是调参数。