缓存未命中和缓存命中的区别

很多人第一次看用量明细会愣一下：同一段提示词反复发，费用却有时高有时低，于是一口咬定是平台乱扣。其实多数情况是缓存命中与否在起作用。这篇不重复讲缓存怎么生效，只教你从账单和日志里把两种状态分出来，怎么核对、怎么判断差价合不合理、什么情况下这套方法不适用。

很多人第一次翻用量明细会愣一下：同一段提示词反复发出去，费用有时高有时低，第一反应是平台乱扣。实际多数情况是缓存命中与否在起作用，输入侧被记到了不同的计价档位。这篇不讲缓存怎么生效，只讲怎么从账单和日志里把这两种状态分出来，怎么核对，怎么判断差价合不合理，以及什么情况下这套方法根本用不上。

先建立一个前提：缓存省的是输入侧的钱，不省输出侧。你看到的价差如果出现在输出那一栏，那跟缓存没关系，得往别处找原因。下面按「差在哪一笔 → 怎么在明细里找 → 自己动手核对 → 差价对不上怎么排查 → 日志该记什么 → 什么时候方法失效」的顺序走一遍，每一步都给可执行动作。

两种状态在账单上到底差在哪一笔

缓存未命中的那部分输入，按普通输入价计；命中的那部分走更低的档位。注意是「输入侧」，不是「输出侧」。输出的 token 一般不参与缓存定价，所以如果你把总价差全部归因到缓存上，很容易把输出变长、重试次数变多这些因素一起算进去，最后得出一个夸大的结论。

缓存未命中

这段输入没被平台的缓存规则接住，按普通输入价走到账单里

缓存命中

这段输入被接住了，命中部分按更低档位计，同样记在输入侧

缓存写入

第一次把这段内容放进缓存时可能单独记一笔，金额通常介于两者之间，别和未命中混为一谈

有效期

缓存不是永久有效，过了窗口再发同样的内容，会重新按未命中走

• 同一段提示词第二次发出去是否算命中，取决于平台的匹配规则和有效期，不是「发过一次就一定命中」；
• 前缀一旦有细微变化，比如时间戳、随机 ID、动态拼接的用户信息，命中率会直接掉下来；
• 所以判断差价之前，先确认这几次调用的提示词前缀是不是真的完全一致；
• 别拿两个不同模型、不同入口的结果直接对比缓存差价，那是在比两种计价体系。

从用量明细里找出这两类记录

多数平台会把输入拆成几列，常见的写法是缓存写入、缓存读取、普通输入、输出。你要做的第一件事不是算钱，而是确认这四列是不是都在。只要平台给了这几列，后面的核对就有据可依；如果只给一个输入总量，就得换方法。

1. 先确认字段在用量记录里找有没有分开的缓存字段，找不到就别硬算，换控制变量法。
2. 再做加总把一次调用的四列 token 数分别乘以各自单价，加起来看能不能对上账单总额。
3. 定位差额对不上时，逐列替换成相邻一次调用，看换哪一列会让总额匹配，差额就出在那列。
4. 回看时间线如果平台只给一个输入总量，就按调用时间排序，连续同前缀的请求里第一条多半是未命中。

一套可复用的自查顺序

光看账单容易被各种汇总口径绕晕，更稳的做法是自己造一组可控的调用，亲手把两种状态复现出来。下面这套顺序按「制造差异 → 手算比对 → 换样本验证 → 写成结论」四步走，跑一遍以后就不用再猜。

1. 制造阶梯固定一段提示词，连发三次，记录三次的输入计价档位，看是否出现阶梯变化。
2. 手算比对把这三次的金额按字段手算一遍，与账单行逐条比对，差在哪个字段一目了然。
3. 换新样本换一段全新的长提示词再发一次，确认未命中价确实按普通输入收，排除是偶发波动。
4. 写成备注把结论写进团队的成本备注，下次有人问直接引用，不用重新验一遍。

这套顺序的价值在于：它不依赖任何一家的字段命名，也不依赖你记住具体数字。所有单价、档位差异，到站内页面核对当时的数字即可，你只需要在核对时确认「差的是输入侧还是输出侧」这一个问题。

为什么你算出来的差价和别人说的不一样

经常出现这种情况：同事说缓存省很多，你按自己的账单算出来几乎没什么差。这通常不是谁算错了，而是两边比的根本不是同一件事。下面几种因素会直接改变你看到的差价，判断前先确认自己在哪一层。

• 不同平台的缓存档位、有效期、最小可缓存长度都不一样，跨平台横向比会得出错误结论；
• 中转渠道可能在官方口径上再叠一层自己的计价规则，看到的价格差要先确认是哪一层；
• 批处理、长上下文、不同模型的缓存策略各自独立，混在一条汇总里看必然对不上；
• 同一天里如果改了提示词模板，前半段命中和后半段未命中的记录会混在一起，看不出规律。

为了让这件事以后不用再猜，日志该记什么

对账痛苦，多半不是账单的问题，是日志没记全。把下面几个字段落到你的调用日志里，以后再遇到「这次为什么贵」的问题，几分钟就能回答，而不是翻好几天的记录靠回忆。

另外注意日志保留周期要覆盖你的账单结算周期，不然到对账那天只能靠回忆。这一条很多团队是在第一次对不上账之后才补上的。

哪些情况下这套判断方法会失效

前面这套方法有前提，遇到下面几种情况要换思路，硬套只会浪费时间还得出错误结论。

• 平台不提供缓存状态的明细字段，只能看总价，这时用控制变量法做前后对比，而不是按字段拆；
• 提示词每次都被动态拼接，前缀不稳定，命中率天然接近零，讨论缓存差价意义不大；
• 按次或按订阅计费的入口根本不走 token 计价，缓存与否不影响账单，这时要查的是别的东西；
• 你把多次调用合并成一次汇总看，缺少单次记录，任何差价都定位不到具体原因。

缓存命中与否是输入侧的事；先确认差在输入还是输出，再谈省不省。