中转站账单对不上？按这五步逐笔核对

"余额掉得比预期快"是最常见的中转站投诉，但其中真正属于"站点算错"的比例并不高。多数情况是计费口径和你的预期不一致：赠送额度不算进单价、缓存没打折、重试被重复计费、实际走的是更贵的模型。下面五步能把"感觉贵"变成"具体差在哪"。

第一步：导出，不要靠感觉

先导出这一期的用量记录，按模型和日期分组。不要看总余额，余额是结果，不是证据。

需要的字段：

• 请求时间
• 请求的模型 ID
• 返回的模型 ID
• prompt_tokens / completion_tokens
• 站点扣费金额
• 请求 ID（如果有）

缺少"返回的模型 ID"或"请求 ID"的记录，后面几步做不了，先找站点要。

第二步：算理论成本

对每一行：(prompt_tokens / 1e6) × 官方输入价 + (completion_tokens / 1e6) × 官方输出价。

官方价要用站点自己声明的基准，不是你的记忆。如果站点写"按 OpenAI 官网价 × 0.3"，那就用官网价 × 0.3 作为基准。

把理论成本和实际扣费放在同一张表里，算偏差率。先看分布，不要看平均值：如果 90% 的请求偏差在 2% 以内，10% 的请求偏差 300%，那问题在那一小撮，不是整体定价。

第三步：分类这四类偏差

1. 充值赠送

充 100 送 20，等于实际单价打了 8.3 折。如果你的理论成本用的是"官方价 × 标注倍率"，而扣费用的是"余额（含赠送）"，两边必然差一截。这类偏差是均匀的，通常正好等于赠送比例。

处理方式：把赠送额度单独记账，或者统一按"实付 / 到账"折算成有效单价。

2. 缓存折扣

OpenAI、Anthropic 都对缓存命中的输入 token 有折扣（通常是标准价的 10%–50%）。如果站点按全价扣，你的预期会偏低；反过来，如果站点按缓存价扣而你的模型没算，预期会偏高。

看请求的 usage 里有没有 cached_tokens 或 cache_read_input_tokens 字段。有的话，这部分要单独按缓存价算。

3. 模型映射

你请求 gpt-4o-mini，站点路由到了 gpt-4o，扣费按后者。这类偏差的特征是同一模型 ID 的偏差率不稳定，取决于当时的路由。

验证方法：看响应里的 model 字段。不一致就是映射。映射不一定是恶意的（有些站点用同名不同版本），但你必须知道。

4. 重试重复计费

客户端超时后重试，第一次请求其实已经在服务端完成并计费。如果你的重试没有幂等键，两次都收费。这类偏差的特征是同一时间点有两条几乎相同的记录。

处理方式：客户端加重试上限，服务端支持的话加 Idempotency-Key。流式请求要判断"流是否已经开始"再决定重试。

第四步：单请求复核

从偏差最大的十条里挑一条，拿它的请求 ID 找站点要完整的计费明细：输入多少 token、输出多少 token、单价多少、有没有折扣、最终扣多少。

这一步的目的不是吵架，是确认你对计费公式的理解和站点一致。多数争议在这一步就解决了——因为你会发现某个字段的含义和你以为的不一样。

第五步：什么时候该升级

只有三种情况值得开ticket：

1. 同一个请求被扣两次，且有两条记录。
2. 返回的模型和请求的模型不一致，且站点没有事先说明会映射。
3. 按官方价折算偏差超过 50%，且站点无法解释计价公式。

开单时给：请求 ID、时间戳、请求的模型、返回的模型、usage 原文、扣费金额。不要给 Key。

一个核对模板

把这张表填满一页，你就能判断这家站是"定价贵"还是"计费不透明"。前者是选择问题，后者是诚信问题。

顺带一句

本站的成本计算器可以按官方价算单次调用成本；检测台的第二项检查会把 usage × 官方价和站点回传的 cost 做对比，偏差超过 15% 记 WATCH，超过 50% 记 FAIL。这两个工具都不能替你和站点对账，但能让你在开单之前知道自己大概在争什么。