AI API Token 用量对不上账单？从请求日志到中转站账单的对账指南

很多团队只记录“今天调用了多少次”，月底却发现内部估算与 AI API 中转站账单差距很大。问题通常不在一道乘法题，而在统计口径：一次用户操作可能触发主请求、自动重试、工具调用和兜底模型；流式连接断开也不等于上游立即停止生成。想把账算清，必须建立请求级证据链，而不是依赖前端埋点或月底总额。

本文是跨模型、跨供应商的方法论，不引用易变的模型价格。实际单价应以调用时供应商公布并由你保存的价格快照为准。

先统一“一个请求”的定义

建议给每次用户操作生成 trace_id，给每次真实上游调用生成独立 request_id，每次尝试再增加 attempt。三者不能混用：

• trace_id：一次业务动作，例如“生成周报”
• request_id：网关向某个模型发起的一次逻辑调用
• attempt：超时或限流后发生的第几次传输尝试
• provider_request_id：上游或中转站返回的查询凭证

这样才能回答“同一按钮是否触发了两次调用”“失败重试有没有计费”“兜底模型花了多少钱”。不要把 Prompt 正文直接写入财务日志，记录哈希、模板版本和长度即可，避免泄露隐私。

每条用量日志至少保存什么

一条可对账记录建议包含：时间、租户、模型请求名、实际模型名、输入与输出用量、缓存用量、状态、是否重试、价格版本、币种和供应商请求号。模型别名尤其重要：客户端发出的 smart-default 可能被路由到不同实际模型，仅按别名套单价会产生系统性误差。

type UsageRow = {
  traceId: string;
  requestId: string;
  attempt: number;
  requestedModel: string;
  resolvedModel: string;
  inputUnits: number;
  outputUnits: number;
  cachedInputUnits: number;
  priceVersion: string;
  providerRequestId?: string;
  status: "ok" | "failed" | "cancelled";
};

原始响应中的 usage 字段应整体留档，再映射到内部统一结构。不同接口字段不一致时，不要默认为零；使用 unknown 并进入待核对队列。零是确定值，未知是证据缺失，两者在财务意义上完全不同。

用价格快照，而不是今天的价格回算历史

对账服务需要一张带生效区间的价格表。每次调用按照发生时间关联对应版本，同时保存中转站折扣、加价规则、币种与汇率快照。历史重算时仍使用当时版本，避免供应商调价后整月成本被改写。

计算逻辑可以保持简单，但口径必须显式：

function cost(row: UsageRow, p: {
  input: number; output: number; cachedInput: number; unit: number;
}) {
  return (
    row.inputUnits * p.input +
    row.outputUnits * p.output +
    row.cachedInputUnits * p.cachedInput
  ) / p.unit;
}

这里不要假定计费单位一定是 Token。图像、音频和视频接口可能采用完全不同的计量维度，应统一命名为 usage_units，并保留 unit_type。

最常见的五类差异

1. 重试被漏记

应用只保存最终成功响应，中间失败尝试却可能已被上游处理。解决办法是每次尝试都落日志，重试前写入原因，并禁止对非幂等长任务盲目重放。

2. 流式中断被当成零输出

浏览器关闭只说明下游断开。网关是否取消、供应商何时停止，需要结合后台完成事件和供应商请求号判断。流式过程定期记录已接收用量，最终再用权威账单修正。

3. 缓存字段重复相加

先确认缓存用量是输入用量的子集还是独立计量项，再编写适配器。不要把不同供应商的字段直接拼到同一公式里。

4. 模型别名发生漂移

中转站可能更新别名指向。对账应记录实际路由结果；拿不到时，至少保存当时的模型列表快照和响应头，便于追溯。

5. 时区与结算周期错位

内部日报与供应商账单若使用不同时区，月初月末会出现“少一天或多一天”的假差异。原始时间统一存 UTC，对账报表再按结算时区切分。

建立分层对账流程

每天先做请求数量与用量总和的一级核对；发现差异后按模型、租户、状态和小时逐层缩小范围；最后用 provider_request_id 做请求级抽查。建议设置绝对差额与相对差额双阈值，低流量模型避免被百分比误导，高流量模型避免小比例掩盖大金额。

对账结果不要直接覆盖原始记录。新增调整分录并写明原因，例如“供应商延迟回填”“缓存口径修正”或“重复请求退款”。这能让财务、研发和供应商支持看到同一条审计链。

上线前检查清单

• 是否区分业务动作、逻辑请求和传输尝试
• 是否记录请求模型与实际模型
• 未返回用量时是否标记未知而非零
• 是否保存价格、汇率和路由配置版本
• 是否能按供应商请求号检索
• 是否覆盖重试、取消、流式中断和异步任务
• 是否定期把内部汇总与供应商账单交叉验证

总结

AI API 对账的核心不是追求一次估算完全准确，而是让每一笔差异都能被定位、解释和修正。先建立请求级日志与价格快照，再做自动聚合和异常告警，往往比不断调整 Token 估算器更有效。

准备评估中转服务时，可以前往 openairouter.net 查看中转站对比与排行榜，重点比较账单明细、用量导出、请求追踪和模型透明度，再决定把生产流量交给谁。