LinkyMonitor / Token 虚标

Token 虚标与倍率对账：账单对不上，怎么自己查

用官方接口，账单是 OpenAI 或 Anthropic 算的。用中转站，账单是站长写的代码算的—— 包括你在响应里看到的那个 usage 字段。这是整件事的起点。

最后更新 2026-08-15 · 阅读约 6 分钟

问题的根源：你看到的用量，也是它给你的

很多人默认 usage 里的数字是客观事实，其实它只是响应体里的一个字段。 请求经过中转站时，这个字段完全可以在返回给你之前被改写。 你没有第二个数据源可以对照——除非你自己去造一个。

这不意味着每家中转站都在改。但它意味着：「我看了账单，没问题」这句话本身不构成证据， 因为账单和被审计对象是同一方出的。

四种常见手法

1. 倍率虚标

最直接的一种：实际消耗 100 token，账面上乘一个系数记成 150。 用户侧完全看不出来，因为你唯一的参照物就是那个被乘过的数字。 社区里常用「倍率」来描述这个系数，也常拿它当判断站点性质的粗略指标—— 但要注意，低倍率既可能是补贴，也可能意味着背后跑的根本不是官方链路。

2. 缓存套利

prompt 缓存的机制是：重复的前缀命中缓存后，上游只收很少的钱。 如果中转站命中了缓存、按缓存价结算给上游，却按完整 token 数向你收费， 中间的差价就进了它的口袋。这一类特别隐蔽，因为你的请求确实发了那么多 token， 账面看上去完全合理。

3. 输出缩水

按官方费率收钱，但实际给你的输出比官方短。同样一笔钱，你拿到的内容更少、 任务完成度更低，需要重试的次数更多——实际单价远高于标价。

4. 上下文重复计费

多轮对话里，历史消息每轮都会重新发送。计费逻辑如果处理不当（或故意不当）， 同一段上下文可以被反复全额计费。对话越长，差距越大。

怎么自己对账

核心思路只有一句：拿官方接口当尺子。

1. 准备一段固定的 prompt。内容、长度、参数全部写死，不要用变化的真实业务请求。
2. 官方接口跑一次，记下 usage。这是你的基准值。
3. 同一段 prompt 在中转站跑一次，记下 usage。模型、max_tokens、temperature 等参数保持完全一致。
4. 比对输入 token 数。输入是确定的，这个数字理论上应当一致或极接近。差异明显就是信号。
5. 再比对账户扣费。看扣掉的额度和 usage 是否自洽——有时 usage 是真的，倍率加在结算那一步。
6. 关掉缓存和 thinking 再跑一遍。排除这两项带来的计费差异，让比对更干净。

输出 token 天然有随机性，单次不可比，需要多跑几次看分布。输入 token 则应当稳定， 是最灵敏的那个指标。

对账一次的局限

你今天对完账，数字都对得上。然后呢？

• 倍率是后台配置，随时可改。甚至可以按用户分组配置——新用户干净、老用户加码。
• 可以只对一部分请求下手。按比例抽取，你的对账样本大概率落在正常那一批里。
• 你不会每天都对账。手工对账做一次要十几分钟，没人会天天做，而配置改一次只要几秒。

所以对账真正的价值不在「今天对不对」，而在「这一个月的曲线有没有跳过」。 单点比对回答不了这个问题，只有连续记录可以。