缓存命中 计费 对比怎么设置

很多人开了提示缓存之后，账单没降反升，或者降了但说不清是哪一部分降的。问题通常不在缓存本身，而在对比口径没设对：命中价、写入价、普通输入价混在一张表里，看的是两个不同的东西。这篇给一套可落地的设置方法，从日志字段、分组口径到核对顺序，帮你把开启缓存前后这一段花费单独抽出来看。

很多人开了提示缓存之后，账单没降反升，或者降了但说不清是哪一部分降的。问题通常不在缓存本身，而在对比口径没设对：命中价、写入价、普通输入价混在一张表里，看的是两个不同的东西。这篇给一套可落地的设置方法，从日志字段、分组口径到核对顺序，帮你把开启缓存前后这一段花费单独抽出来看。

核心思路很简单：把「缓存省没省」当成一次可复现的对照实验来做，而不是凭账单截图猜。选一个固定任务，跑一遍不开缓存，再跑一遍开缓存，字段完全对齐，把三笔钱分列，差值一眼就能读。下面按这个顺序展开。

先定两条基线：不开缓存和开缓存

对比的第一个坑是基线不干净。不开缓存那组如果凭记忆估，或者干脆用「上个月账单除以请求数」，得到的均价里混了完全不同的任务，比出来的是任务差异，不是缓存的效果。要么临时关掉开关跑一轮同样的任务，要么从改前的历史日志里切出同类请求做基线。

• 两组必须同任务、同输入长度档位、同输出长度量级，否则比的不是缓存而是任务本身
• 缓存读取价、缓存写入价、普通输入价是三笔不同的钱，对比表里要分列，别合成一个『输入成本』
• 同一轮对比里只允许缓存开关这一个变量变化，其他参数锁死
• 命中率低到接近零的场景，做这个对比没有意义，省下的钱还不够你花时间核对的

日志里至少要留下哪几列

没有字段就没法分组，后面所有对比都做不了。建议在调用层统一打一条结构化日志，把下面这些列固定下来。字段名可以自己定，但含义不能合并，尤其是输入侧那三笔钱必须拆开。

是否开启缓存

一个布尔或枚举，用来把两次跑的数据分开

任务/会话标识

同一个任务在多轮之间靠它串起来，也用来剔除混进来的其他请求

输入拆分

普通输入、缓存写入、缓存读取分别记，别只记一个总量

命中率

用缓存读取量除以可缓存部分的总量，落成一列，不要事后心算

模型名、输入输出的 token 量、请求时间戳这几列也要有，它们是后面做分档和趋势图的基础。想知道同类任务在公开口径下的用量大概是什么分布，可以去 /usage 看当时的数字，用来判断自己这组数是不是离谱。单价和档位会变，别把任何单价写死在日志分析脚本里，跑对比时现查。

设置步骤：从开关到一个可反复跑的对比

1. 选任务并固定前缀挑一个会反复调用的真实任务，把提示词里不变的部分整理成固定前缀，只让变量部分变化，确认这段前缀长度稳定。
2. 跑基线组关掉缓存开关，跑若干轮，记录上面所有字段。轮数太少会被单次波动带偏，至少跑到输出长度量级稳定。
3. 跑缓存组只打开缓存开关，任务、参数、轮数保持一致。注意第一轮通常是写入，后面几轮才是读取，别把首轮当成常态。
4. 做对照表横轴放任务轮次，纵轴分别放普通输入、缓存写入、缓存读取、输出四行成本，最后一行放合计，两组并排放。
5. 单变量复跑只改一个东西，比如把固定前缀加长或缩短，看成本曲线怎么动，确认省下来的钱确实来自命中，而不是碰巧任务变简单了。

差值怎么看：三种常见结果对应什么动作

还有一种结果是对比表看起来降了，但你的主观感受是没降。这时别急着下结论，先确认两组的任务是不是真的一样，再确认计价口径有没有换档。数字有疑问一律以计价页为准，去 /official-api 和 /tools/model-cost-calculator 按当时的数字重新核一遍。

缓存省不省钱，取决于写入有没有被读回来，单看单价对比说明不了任何问题。