模型下线的通知一来，麻烦往往不在换模型，而在回头看：上个月的账单里哪些钱是已经下架的旧模型花掉的？口径怎么和当时预估的对齐？这篇给做复盘和审计的人一条可执行的追溯路径——先分清哪些记录还可能存在、再去哪里找、最后怎么把口径写清楚，让数字能解释得通。
模型下线的通知一来，麻烦往往不在换模型，而在回头看：上个结算周期里哪些钱是已经下架的旧模型花掉的？当初的预估和最终账单能不能对上？做复盘和审计的人要的不是一句「差不多」，而是一条能把总额倒推回单次调用的路径。下面按「先分清哪些记录还在、再去哪找、最后怎么把口径写清楚」的顺序走一遍，目标是让数字能解释得通，而不是让它变好看。
先明确一个前提：追溯是和平台记录赛跑。下架越久，平台侧能查到的按模型维度的明细越少，你自己留的请求日志就越关键。所以这篇不教你「怎么算得更准」，而是教你「在记录还在的时候，怎么把能还原的部分还原、把不能还原的部分老实标注出来」。
先搞清楚：模型下线后，哪些记录还会在、哪些会没
不同平台对下架模型的处理差别很大，但规律基本一致：越靠上游的汇总越稳，越靠下游的明细越容易消失。账单一般还能看到金额条目，但按模型拆分的维度可能被合并、改名，或者干脆只保留总额。用量明细的保留期由平台决定，部分平台下架后就不再展示对应模型的按模型维度明细。这意味着你现在能查到的，和三个月后能查到的，很可能不是同一批数据。
| 记录类型 | 下线后大概率状态 | 追溯时怎么用 |
|---|---|---|
| 账单汇总条目 | 通常保留，模型名可能被合并或改名 | 作为总额校验的锚点，不当明细用 |
| 按模型用量明细 | 可能只留一段时间，或不再展示 | 能导出就先导出原始文件 |
| 自留请求日志 | 取决于你自己，通常在 | 作为时间轴基准，逐条还原 |
| 计价规则说明 | 当时页面可能已更新 | 以当时口径为准，别用现价倒推 |
- 账单侧：确认金额是按当时计价还是当下计价，单价口径要单独标记
- 用量侧：按模型维度的明细优先导出，导出后不要再手工改格式
- 日志侧：请求时间、模型标识、token 数、请求 ID 这四项至少要齐
- 缺口侧：哪些区间只有总额没有明细，提前列成清单，别等到审计才想起来
三条线对齐：平台账单、平台用量页、你自己的日志
对齐的方法是：以你自己的请求日志当时间轴，把每一次调用标上时间、模型标识和 token 数；再用平台账单的总额去校验这条时间轴；最后用平台用量页做交叉检查。差异必须能落到某一类调用上，落到「其它」这种模糊科目上就等于没对上。这三条线谁也不是绝对权威，平台记录可能因下线而缺失，自留日志可能因采集中断而有洞，所以要互相补位而不是互相替代。
旁证可以看，但别拿旁证当结论。到站内 真实用量榜 和 价格变动追踪 看同类模型在相近时间段的公开口径，能帮你判断当时的价格区间是否合理；到 官方 API 价格 与 AI 模型库 确认下线模型在位期间的计价项有哪些、有没有缓存或分时计价。这些页面上的数字随市场变动，写审计说明时要注明「以查阅当时页面为准」。
- 基准时间轴
- 以自留日志的调用时间为准，平台账单只用来校验总额
- 旁证
- 站内公开页面可参考口径区间，不能替代你自己的原始记录
- 交叉检查
- 三条线两两比对，差异定位到具体调用类型才算闭环
把旧调用的单价还原出来：按当时口径，不按现在
最难也最容易出错的一步是单价还原。模型下线后，你现在看到的可能是替代模型的价，或者是已经调过几次的价，两者都不能直接套到旧账上。正确做法是按调用发生的时间段分段：先把原始调用按时间切片，每片对应当时生效的计价规则，再分别乘以各片的 token 数。中间调过价就用分段算，别用一个均价覆盖整段，否则总额对上了、单条明细却解释不通。
- 先分清计价项：输入、输出、缓存写、缓存读是否分别计价，各自单价不同
- 再看有没有倍率或分组折扣：是否按渠道、时段、批量调价
- 缓存命中部分单独算，下线后缓存项常被漏算或错算到输出里
- 用 站内 Token 单价换算 工具走一遍交叉验证，别只信手算
- 把单价来源写进说明：来自当时账单条目、当时官方页，还是自留截图
如果你手头没有当时的单价记录，只能靠替代模型或公开页面推断，那就在口径说明里明确标注这是「推断值」，并写清推断依据和误差范围。审计口径讲究可复现，一个标注了假设的推断，比一个看起来精确但说不清来源的数字更可信。
追溯步骤：从总额倒推到单次调用
- 锁定区间与标识确定受影响的起止时间和旧模型标识，把这段时间内所有相关调用圈出来，避免把替代模型的调用混进来
- 拉出汇总条目从平台账单取该区间的金额条目，记录口径是当时计价还是当下计价，能导出原始条目就导出
- 乘回当时单价用日志里的 token 数乘对应时段的单价，得到还原金额，分段计算后加总与账单总额比对
- 归因差额对不上的部分优先怀疑三类原因：重试产生的重复调用、缓存计价项、渠道或分组倍率
| 差额表现 | 常见原因 | 先查什么 |
|---|---|---|
| 还原值偏低 | 漏算缓存写或缓存读 | 日志里是否有缓存相关字段 |
| 还原值偏高 | 重试调用被重复计入 | 同一请求 ID 是否出现多次 |
| 整体比例偏差 | 倍率或分组折扣没算 | 当时是否有渠道或套餐折扣 |
| 单条对不上 | 时段切分错误 | 单价生效时间点是否卡准 |
差额对不上时，先怀疑口径而不是怀疑被多扣。多数所谓「账单异常」最后都落在计价项没对齐或者时间切片切错了。把结论写成一页对照表：区间、模型标识、token 数、单价来源、差额说明，这页表就是复盘和审计的基础材料。
审计口径怎么写：留证、说明、不承诺
审计看的是可复现，不是数字好看。口径说明里至少要写清四件事：数据来源是平台账单还是自留日志、单价出处、还原方法、以及做了哪些假设。截图要带时间和账号标识，导出的原始文件保留原格式，不要只留二次加工过的表格，否则别人无法从头复算。如果某些区间只能给推断值，就把它和实测值分开列。
- 来源标注：每一条数字后面跟一句「来自哪里」，别让读者猜
- 假设单列：推断、估算、缺失区间单独成段，不混进实测结论
- 证据留存：原始导出文件、带时间与账号的截图、口径说明三件套齐备
- 复核路径：写清别人照什么步骤能复算出同样结果
- 边界声明：明确标注「按当时计价还原，事后不保证平台仍可复核」
如果你的团队还在选长期用的中转或直连方案，复盘口径这件事最好在选型阶段就一起看，免得下次换模型又从头追。到 站内中转站目录 看各家在记录留存和用量导出上的差异，会省掉不少事后补账的功夫。
下一步把这篇的对照表模板先用起来，再去站内价格变动追踪核对当时的计价口径，两件事合起来做，追溯才算闭环。→常见问题
模型下线后，平台的用量明细还能查到吗？
不一定。各家保留策略不同，有的只剩汇总金额，按模型拆分的明细可能不再展示。稳妥做法是以自己侧的请求日志为准，平台数据只用来校验总额，具体保留情况去 真实用量榜（/usage） 相关页面和平台后台确认。
旧调用只能用现在的单价估算，这样可以吗？
不建议。现在单价和当时可能已经不同，还会漏掉缓存、倍率这些计价项，算出来的口径没法解释原始账单。至少要按调用发生的时间段分段还原，单价出处写清是当时公告还是历史截图，让审计能顺着查回去。
追溯结果和账单总额差一截，先查哪里？
先查计价项而不是先怀疑被多扣：缓存写读是否计入、有没有重试产生的重复调用、分组倍率当时是多少。这三类能解释大部分差额。把差额按类型列出来，比笼统说「对不上」更有用。
