面板一个数、脚本一个数：跨视图核对 token 计数差异

同一个 API key，同一段时间范围，聚合站的用量页显示消耗了 X 个 token，你本地脚本按官方 tokenizer 算出来是 Y。两个数对不上，先别急着怀疑计费。跨视图核对的第一步，是把“差异”从“错误”里拆出来。

为什么两个视图会天然不同

常见的差异来源有这几类：

• tokenizer 版本不一致：你用 tiktoken 或某个开源 tokenizer 库，聚合站侧可能调用模型官方返回的 usage。同一个模型在不同版本 tokenizer 下切分结果会有出入，尤其对中文、代码、emoji、重复空格敏感。
• 计入范围不同：你本地可能只算了 prompt 的 messages 内容，而实际请求还包含 system、工具定义、函数 schema、stop 序列、图片占位符等。这些都会计入 input。
• 流式响应（stream）：流式模式下，很多客户端拿不到最终 usage，只能靠自己估算输出。本地估的和服务端结算的往往不是一个数。
• 重试与失败请求：本地脚本可能只记录成功那次，但网关可能记录了多次尝试，或把 4xx/5xx 前后的消耗分别记账。
• 缓存与重复请求：如果客户端做了 prompt 缓存或自己去重，本地账本会少记，而服务端按实际收到的请求计。
• 多模态与特殊 token：图片、音频、文件会按各自规则折算，本地按纯文本估算会偏差很大。
• 时间窗口与归属时区：面板按 UTC 或按你账号时区聚合，本地脚本按本地时间，跨天、跨小时的对账会切错边界。
• 舍入与展示：面板常常展示的是聚合后的整数或千分位，本地是逐条精确值，累加后自然有零头差。

理解这些之后，你会发现“面板一个数、脚本一个数”是正常现象，关键是把差异压到一个可解释的区间，而不是强求完全相等。

每周对账清单

建议固定一个时间（比如周一上午），用 10–20 分钟跑一遍下面这套流程。不要等到月底账单出来才动手。

1. 锁定对账窗口：选一个明确的起止时间，最好落在同一个 UTC 日内，避免跨天归属问题。记录面板使用的时区。
2. 导出面板数据：从聚合站用量页导出（或截图记录）这段时间的 request 数、input tokens、output tokens、总 token、模型维度分布。
3. 导出本地日志：从你的客户端或代理日志里，按同一时间窗口过滤，取出每条请求的模型、消息长度、是否流式、是否重试、usage 字段。
4. 按模型分别对：先把总量差异拆到每个模型。不同模型的 tokenizer 和计价规则不同，混在一起对会放大噪音。
5. 逐项对比字段：request 数是否一致 → input 是否一致 → output 是否一致。哪一层先出现偏差，问题就在那一层。
6. 标记异常条目：任何单条差异超过你设定阈值的请求，单独拎出来看原始请求体。特别注意含图片、长 system、工具调用、流式截断的请求。
7. 记录而非争论：把差异写成“窗口 / 模型 / 面板值 / 本地值 / 可能原因”，形成可追溯的表格。

差异出现后，先排查这几件事

• 确认客户端是否记录了服务端返回的 usage：如果 API 响应里带 usage，优先以它为准。只有拿不到 usage 时才用本地 tokenizer 估算。
• 确认统计口径：面板的“总 token”是否等于 input + output，是否包含缓存命中、是否包含失败请求。不同聚合站的口径不同，先读文档或问客服确认。
• 确认模型映射：聚合站可能把请求路由到该模型的某个具体版本。你的本地 tokenizer 对应的是另一个版本，切分结果自然不同。
• 确认流式收尾：流式请求结束标记是否完整收到，有没有因超时被客户端主动断开，导致服务端计了输出而本地没记全。
• 确认重试策略：SDK 或网关的自动重试会产生额外请求。本地只记一次，面板可能记多次。

把对账变成例行动作

差异本身不可怕，可怕的是它一直躺在那里，直到某天被当成“计费错误”翻出来。固定节奏的对账，能带来两个好处：一是及早发现客户端 bug（比如消息重复拼接、流式处理截断），二是把合理的口径差异沉淀成文档，下次对账时直接对照，不必重新推理。

如果你的差异主要集中在某几个特定模型或某类请求上，那通常指向 tokenizer 或请求结构问题；如果差异均匀分布在所有请求上，更可能是口径或时间窗口问题。按这个方向走，大多数“面板一个数、脚本一个数”的情况都能在几分钟内解释清楚。