API 中转站 token 消耗统计怎么做：预估冻结、usage 回填与流式补数的实现路径

在大模型 API 中转站里，token 消耗统计不只是一张报表，它同时驱动三件事：按量计费、额度扣减和限流判断。统计口径一旦有偏差，用户看到的是账单与预期对不上，运营看到的是毛利被悄悄吃掉。所以成熟的实现通常不会只信一个数据源，而是把请求前预估、上游返回用量、事后校正三层串起来，任何一层缺失都要有兜底方案。

计数来源可以拆成三类。请求到达网关时，用本地分词器对 messages 做一次预估算，得到输入侧的大致 token 数，用于预扣额度和限流判断；上游响应回来后，读取本次调用的 usage 字段作为权威值回填；如果是流式响应且上游没有回传用量，则只能依靠流式分片的累计来估算输出侧。三类数据各有误差区间，关键是清楚误差从哪来、什么时候需要纠正。

本地预估最大的误差来自分词器不一致。同一个中文句子，不同厂商的词表切分结果可能差几个百分点到十几个百分点，代码、URL、长数字串这类低冗余文本的偏差更明显。上下文越长，误差被放大的倍数越高。因此预估只适合作为预授权额度使用，真正入账必须等上游 usage 回填，否则长期累积会出现系统性多扣或少扣，用户对账单的信任很难挽回。

OpenAI 兼容协议里，usage 一般包含 prompt_tokens、completion_tokens、total_tokens 三个字段，部分实现还会给出缓存命中的 token 明细，用于区分缓存价与标准价。中转层要做的是把原始 usage 原样落库，而不是只存一个换算后的金额。因为模型倍率、缓存折扣这些价格参数会调整，保留原始 token 数才能在不重算历史的前提下重新定价，也方便应对不同上游字段结构的变化。

流式场景是统计最容易失真的地方。标准的事件流里，多数上游只在最后一个数据块带上 usage，还需要在请求参数里显式开启用量回传；有些上游干脆不返回，只能按分片内容累加。这时要注意心跳包、空 delta、结束标记都不应计入输出 token。较稳妥的做法是转发过程中实时累加可见文本，流结束后再与上游 usage 比对，差异超过阈值就写一条异常日志，便于后续归因。

多模型路由会把字段差异进一步放大。不同厂商对输入、输出、缓存读取的命名各不相同，有的把思考类 token 单独列出，有的把工具调用参数算进输出。适配层需要统一成内部结构：模型标识、输入 token、输出 token、缓存 token、来源标记。模型倍率与 token 数分列存储，避免以后调价时要动历史明细，也方便按路由目标分别统计成本。

失败与重试请求的口径必须先定死。上游参数错误通常不消耗 token，服务端错误或超时则可能已经算过一次生成；如果网关自动重试，同一次逻辑调用会在日志里出现多行，必须用请求指纹把它们串成一条业务记录，只对最终成功的一次计费。缓存命中、降级到备用模型的请求也要单独打标，否则对账时无法解释差额究竟来自哪里。

落库结构建议分两层：明细层每个请求一行，保存请求标识、Key、用户、模型、输入输出 token、耗时、状态与上游返回摘要；汇总层按小时和天，按 Key、用户、模型三个维度预聚合。查询账单读汇总，排查问题读明细。写入走异步队列，转发链路只负责投递事件，不要让数据库抖动拖慢响应时间，这一点在高峰期尤其明显。

额度扣减常用的做法是先冻结、后结算。请求进入时按预估值冻结一部分额度，响应回来后用上游 usage 结算，把差额释放。这样既能防止并发超支，也不会因为预估偏高而长期占用用户余额。对注册赠送的测试额度，最好与充值额度分开记账，既方便区分消耗来源，也便于风控判断异常调用，比如短时间内的超高频请求。

快米兔 API 在按量计费场景下的处理思路比较清晰：接入侧提供 OpenAI 兼容协议，注册赠送 5 元测试金，用户可以直接跑通链路再决定用量。其统计链路把上游 usage 归一化后回填，流式响应做补数校验，并支持按 Key、按模型查看消耗明细，对于需要给多个业务线分账的团队，这种 Key 维度的聚合比只看总额更有参考价值。具体计费细则以官方说明为准。

日终对账至少要归因四类差异：流式估算与真实用量的偏差、失败请求的退补、缓存折扣未及时生效，以及倍率调整带来的口径变化。把差异按来源分类记录，比单纯看一个总差额有用得多。预留一个可重算的中间层，一旦发现某天上游返回的 usage 结构发生变化，可以重放明细修正汇总，而不是手工调整一个总数。

token 计数用整数存储，避免浮点累加误差；时间戳统一到 UTC 再按业务时区聚合；日志保留周期要覆盖最长账期；导出接口加上分页与限流。这些细节看起来琐碎，但用户对中转站的信任，往往就是从账单能不能对上开始建立的。统计链路做扎实，按量计费才真正站得住，多模型路由和限流策略也才有可靠的数据底座。