对账不是看总额对不对，而是把“业务消耗、平台计费、项目归属”三盘账对齐。三者不一致时，通常不是平台算错，而是 Key 分组、重试或并发解析出了问题。
一、对账三张表
| 表 | 来源 | 关键列 |
|---|---|---|
| 业务消耗 | 应用日志 | trace_id, project, model, input, output, status |
| 平台计费 | 平台用量导出 | key_name, model, usage,month, unit_price, amount |
| 项目归属 | 内部配置 | project, cost_center, reviewer, budget |
二、固定流程
- 导出本月平台账单和用量明细。
- 按 key_name 聚合应用日志。
- 比较三张表的“请求数、input tokens、output tokens、金额”。
- 误差超过 1% 时逐小时拆分。
- 再拆到单 key、单接口、单模型。
三、常见差异来源
- 重试：应用日志记一个请求，但上游多次计费。
- 截断：输出被截断，但实际计费仍包含一些推理 token。
- 工具调用：中间结果没有记录，但模型已经消耗 tokens。
- 多模型路由：同一业务调用路由到了不同模型。
- 免费或低价模型被误标成高成本模型。
- 批量任务在月末跨日执行，分摊到不同账期。
四、建议核对顺序
- 先总额：毛误差是否小于 2%。
- 再模型：按模型对比金额。
- 再项目：检查哪个项目有异常增幅。
- 再 key：找出费用最高和最异常的 key。
- 最后抽 20笔 trace 逐行检查。
五、月底收尾检查
- 所有项目的预算是否超过 90%。
- 是否仍有没有任何项目归属的 key。
- 测试 key 是否已经进入 prod？
- 是否还在使用已停用的模型？
- 汇率或单价变化有没有影响下月预算？
六、例子
假设某项目本月账单是 $1,240，应用日志估算只有 $1,050。按以下顺序拆：
- 先看两边的模型分布：发现平台里 pro 模型占 40%，应用日志只有 10%。
- 再看 key：某个 ETL 项目把同一个 key 用于两个任务，一个意外路由到了 pro。
- 再看重试：该任务网络超时后重试 10 次，日志只记一次。
- 结论：不是平台算错，是路由和重试记录都不完整。
七、账期收尾清单
- 每笔金额都能对应到模型与项目。
- 所有 key 都有负责人和预算。
- 不再使用测试 key 于生产。
- 输出长度与输入长度都符合业务期望。
- 重试次数和费用已分别统计。
八、示例问题
业务端估计某月消耗 $1000，平台账单 $1420。识别方式：
- 差额 $420，约占 42%。
- 按模型拆账单，发现一个 pro 模型用了 $350。
- 按 key 拆，发现一个 ETL 项目用了这个 pro 模型。
- 按 trace 抽查，发现重试次数没有记录。
- 最后归类：ETL 路由错误 + 重试成本未统计。
九、预算复盘
每月固定做三件小事：
- 按项目重新分配下月预算。
- 关闭没有业务产出的项目。
- 更新模型单价，尤其是跨月切换模型时。
做法为本站整理；与团队预算制度配合使用。