缓存命中 计费 推荐怎么设置

很多人第一次看到缓存相关的账单项时会懵：明明请求没变多，费用却拆成了几行，命中率高低也说不清。这篇不重复讲概念，只解决一件事——缓存命中到底按什么口径计费，以及你该把参数怎么设、设完怎么验证。适合已经在调 API、想把这块成本压下来的开发者。

很多人第一次看到缓存相关的账单项时会懵：明明请求数没变，费用却被拆成好几行，命中率高低也说不清到底省没省。这篇不重复讲缓存是什么，只解决一件事——缓存命中按什么口径计费，参数该往哪设，设完又该怎么验证。适合已经在调 API、想把这块成本压下来的开发者。

先说结论方向：缓存省钱的前提是「同一个前缀被反复复用」，而不是「开了缓存就一定便宜」。搞不清这个前提，配置越复杂越容易踩坑。下面按计价口径、配置决策、验证循环、不该开的场景四块来讲。

先搞清：缓存命中是怎么被计价的

缓存不是免费加速。写入和读取通常各算一项，写入的单价和读取的单价不一定相同，具体倍数各家不一样，去 /official-api 里逐家核对当时的数字。所以判断划不划算，要同时看写入成本摊薄后有没有被读取次数覆盖掉。

命中只是把原本按普通输入价算的那部分，换成按缓存价算，并不是整单打折。整单里没命中的部分照旧按普通输入计费，输出也照旧。别看到「有命中」就以为整张账单都在打折。

配置时真正要做的四个决定

• 决定缓存什么：稳定不变的部分（系统提示、长文档、工具定义、少样本示例）放最前面，会变的部分（用户输入、时间戳、随机 ID、用户昵称）放后面，顺序错了命中率直接归零
• 决定什么时候开：短提示、一次性任务、内容每次都变的场景，写入成本可能盖过节省，这种就别开
• 决定缓存粒度：同一个前缀跨多次调用复用最划算，前缀哪怕差一个字符就是另一份缓存，等于重新写
• 决定失效与刷新：内容更新了就换一个新前缀，别在原前缀里改字，否则等于每次都在重新写入

这四条里最容易做错的是顺序。很多人把系统提示写在中间，或者在开头拼了时间戳，结果请求量再大也命中不了。判断标准很简单：拿两次真实请求的原文对比，从第一个字符开始数，看最长公共前缀有多长，这段才是有可能被复用的部分。

1. 拉一份真实请求样本从日志里取十到二十条同业务的请求，别用构造的假数据。
2. 算最长公共前缀从第一个字符逐位比对，找出所有请求都一致的那一段，这段就是候选缓存区。
3. 重排内容顺序把候选缓存区提到最前，把变量部分（用户输入、时间戳）统一挪到后面。
4. 确认存活时间对照所用接口的缓存存活规则，看你的请求间隔是否落在存活窗口内，短于最短存活时间可能根本不计入。

设完怎么验证有没有省到

配置改完不能凭感觉说「应该省了」，要有一轮固定动作。核心是把用量日志按计费项拆开，对比开缓存前后的占比变化，而不是只盯总金额。总金额受调用量波动影响大，占比才说明问题。

固定跑一批相同前缀的任务，记录四个字段：缓存读取量、缓存写入量、普通输入量、输出量。缺字段就没法复盘，字段口径可以参考站内用量日志相关的做法自己对齐。

小批量试跑达标后再全量切换。全量切换后如果账单结构突变却找不到原因，回退起来会很痛苦。验证这一环多花半天，比事后翻账省事。

这些情况下缓存不值得配

• 提示词很短、单价本来就低，节省的绝对值可能还不够你花时间调试
• 内容一次性、天然不复用，或者每次前缀都带时间戳、随机 ID、用户昵称，命中率会长期趴在地上
• 对时效要求极高、缓存可能返回旧内容造成业务风险的场景，宁可不用
• 前缀很长但每个用户各不相同，写入成本摊不开，等于每次都重新写一遍

判断值不值得配，别凭感觉。用真实调用量去 /tools/model-cost-calculator 估一遍再决定，把最坏情况（命中率为零、全是写入）也算进去，能接受再上。

缓存省的是「重复」的钱，不是「请求」的钱。没有重复，就没有节省。