LLM 应用对不上账？大概率是漏记了这三种「失败但计费」的请求

凡是接了大模型 API 的团队，月底对账大概率经历过这种事：内部统计的调用量、token 数，和上游账单对不齐。差个百分之几都算正常的，差的多的能到两成。

大多数人第一反应是怀疑自己统计代码写错了。其实更常见的原因是：有一类请求，业务上算"失败"，计费上却是真实发生的。漏记它们，账永远对不齐。

第一种：流式半途断掉

客户端等不及超时了、网络抖了、用户直接关了页面——流式响应中途断开。业务侧记的是"失败"，但上游已经吐出去的那些 token 是真实消耗的。流式场景下这类请求占比不低，尤其前端交互重的应用。

处理方式：不要在收到断开时就停止读取上游，把连接排空（或等到空 chunk 超时），拿到响应尾部携带的 usage 数据再落账。

第二种：5xx 前已吐了一半

上游 500、网关 504，错误发生在响应中途。之前已经生成的那部分 token，上游照样计费。这类请求如果不单独标记，统计侧会把它们归零。

第三种：缓存命中的计费歧义

大部分平台的 prompt cache 命中部分按折扣计价（常见 1 折到 4 折），但上游返回的 usage 字段里，有的把缓存命中算进 prompt_tokens，有的单列 cached_tokens。如果网关自己拿 tokenizer 重新数一遍再乘单价，和账单的差异能差出 5%~10%——因为 tokenizer 和上游的计数本来就有细微差别。

对账的铁律只有一条：计量认上游返回的 usage 字段，计价按账单口径拆分。自己数出来的数只能用于业务分析，不能用于对账。

一个架构建议

这三类问题都指向同一个结论：接大模型 API 的项目，值得在业务和上游之间放一层轻量网关，专职做三件事——透传 usage、标记异常请求的计费状态、按账单口径归一化。转发本身不复杂，复杂的是这些「财务视角」的细节，集中在网关里处理，比散在各业务线里各自为政强得多。

工具备注：我们自己的推理服务也是这个思路做的计费层。顺带做了一个翻译小工具「随心翻译」，同样按量计费，用多少算多少。