缓存怎么对账
缓存读写常占总用量八成以上；把每轮的写入、读取与实际扣费摊开，才知道钱花在哪一轮。
可引用结论
缓存命中率 = 缓存读取 token ÷ 输入总 token，需连续跑 5 轮以上取平均（首轮必然不命中）。写缓存按写入价计费、通常高于普通输入约 1.25 倍；因此「写了读不回」比完全不缓存更贵——每轮既付写入价，又按原价重发内容。
引用请注明来源 https://zhongzhuancha.com/guides/cache-reconciliation（抓取日期 2026-10-28）。
三个公式，先把口径定死
所有对账都建立在这三行上
命中率 = 缓存读取 token ÷ 输入总 token
应扣 = 输入价 × 新建输入量 + 缓存写入价 × 写入量 + 缓存读取价 × 读取量 + 输出价 × 输出量
有效输入单价 = 该轮输入相关实扣 ÷ 输入总 token
注意第一行的分母是「输入总 token」，包含新建部分与命中部分。很多站方的面板只展示命中量不展示总量， 这时要用「命中量 + 新建量」自己加回来，否则算出的命中率会虚高。
逐轮记录长什么样
下表是本站对某站的实际观测结构，用于说明要对齐哪些字段
| 轮次 | 输入 token | 缓存写入 | 缓存读取 | 观察 |
|---|---|---|---|---|
| R1 | 46,348 | — | 13,312 | 首轮，前缀刚建立 |
| R2 | 46,481 | — | 46,208 | 命中率接近满 |
| R3 | 46,616 | — | 46,336 | 稳定命中 |
| R4 | 46,718 | — | 46,464 | 稳定命中 |
| R5 | 46,823 | — | 46,592 | 稳定命中 |
这组数据里 R1 的读取量明显低于后续几轮，正是「首轮建立、后续命中」的典型形态。 如果 R2 之后的读取量仍然上不去，说明缓存没吃上，需要查前缀是否被改写。
对账五步
从建 Key 到算出有效单价
- 01
建临时 Key 专测
单独建、单独删。混在正常用量里，账单流水会把两类请求搅在一起，无法归因。
- 02
固定前缀跑 5 轮以上
同一段系统提示、同一份文档，连续调用。少于 5 轮取不到稳定命中率。
- 03
抄四项 token 数
每轮记录输入总量、缓存写入、缓存读取、输出。缺项就标「未采集」，不要估。
- 04
算命中率与应扣
按上面三行公式逐轮算。差额出现在哪一项，问题就在哪一项。
- 05
比对面板流水
用面板的扣费记录逐条对齐。对不上时，先确认面板给的是单轮还是累计。
两种失败形态，代价差很多
不缓存 vs 缓存失效
完全不缓存
每轮按普通输入价重发全部上下文。成本高，但至少可预期，账单随用量线性增长。
写了读不回
每轮按写入价建缓存（约 1.25 倍），然后仍要按原价重发内容。两头付费，比不缓存更贵，而且面板通常不标注，很难自己发现。
区分这两种情况的方法很简单：看第二轮开始的缓存读取量。读回来了是第一种的正向形态； 一直读不回来，就是第二种。
常见问题
＋缓存命中率怎么算？
命中率 = 缓存读取 token ÷ 输入总 token。分母用输入总 token（含新建与命中），不是用总用量。单轮看没有意义，要连续跑 5 轮以上取平均，因为首轮必然不命中。
＋为什么写了缓存却没读回来，反而更贵？
写缓存按写入价计费，通常高于普通输入（约 1.25 倍）。如果写了却在下轮读不回来，等于每轮都花高价建一个用不上的缓存，然后还要按原价把内容重发一遍，两头付费。命中率低的站点比完全不缓存的站点更贵。
＋哪些任务最适合吃缓存？
三类：同一套系统提示反复调用、同一份长文档多轮追问、多轮对话里历史上下文持续增长。共同点是「稳定前缀占比高」。短问答、每次换文档、单次调用几乎吃不到缓存。
＋缓存对账要看哪几个数？
四个：每轮的输入 token、缓存写入 token、缓存读取 token、输出 token，再加一个实扣金额。五项齐全才能算出命中率和有效单价；缺任何一项，都只能看个大概。