中转 API 的 token 用量怎么统计才准：流式响应、缓存命中与账单核对口径

很多团队在搭建 API 中转时，把注意力放在路由和限流上，token 统计往往留到快上线才补，结果是一边跑一边修账单。一个请求从进入网关到返回结果，中间要经过渠道选择、协议转换、重试、流式转发，任何一步丢字段，最后都会变成对不上的数字。统计体系要在第一天就设计好。

统计的第一步是统一计量口径。同样是 OpenAI 兼容接口，上游返回的字段并不一致，有的用 prompt_tokens 与 completion_tokens，有的用 input_tokens 与 output_tokens，部分模型还会额外给出 cached_tokens、reasoning_tokens。中转层需要在响应解析处做一次归一化映射，把结果写成固定结构，后续计费、报表、告警都只认这一份结构，避免每个模块各自解析一套。

流式响应是最容易漏掉用量的场景。开启 SSE 之后，正文被切成多个 chunk，usage 往往只在倒数第一或第二个 chunk 出现，有的上游默认根本不返回。稳妥做法是在转发前注入 stream_options 参数请求返回用量，同时在网关侧保存分片计数作为兜底。若上游始终不返回，就要用本地 tokenizer 估算，并明确标记为估算值，与上游返回的真实值分开统计，不能让两类数据混在同一列里。

每一次调用都应该有一条可检索的记录。建议在网关入口生成 request_id，落库字段包括调用方与 Key、渠道、模型名、开始与结束时间、首字延迟、HTTP 状态码、错误类型、重试次数、token 拆解以及当时的单价快照。写入走异步队列，主链路只做投递，避免统计逻辑把请求延迟拖长。记录里保留原始响应片段也很关键，出问题时能直接复现。

单价快照是很多中转站后期才补的功课。模型价格会调整，如果账单记录里只存 token 数、不存成交时的单价，历史账单会随着价格表更新而漂移，用户看到的金额和当时实际扣费就对不上了。把单价随记录一起写入，账单才具备可复现性，也方便后续做渠道成本与售价之间的毛利分析。

缓存命中的 token 通常按另一档价格计算，因此统计时要单独分列，不能直接并入输入总量。缓存命中率本身也是很有价值的指标，它能反映调用方的提问习惯和系统提示词是否稳定，对容量规划和成本预估都有帮助。推理类模型的思维链 token 同样需要单列，否则输出成本会被明显低估。

本地 tokenizer 估算和上游返回之间总会存在偏差，尤其是中文、代码和特殊符号混合的文本。可以把两者按天做对比，输出偏差率曲线，超过设定阈值就告警。长期偏差集中在某个渠道或某个模型上，通常意味着该渠道的返回格式有变化，或者分词器版本不一致，需要及时跟进。

按量计费的场景下，统计还要反向驱动配额。请求进入时先按预估 token 预扣额度，响应返回后再按实际用量结算回写，多退少补。预扣和结算都必须走原子操作，否则高并发下很容易出现余额扣成负数的情况。失败请求不计费，但记录要保留，方便排查是渠道问题还是参数问题。

重试机制会带来重复计费的风险。同一个 request_id 在结算表中只应产生一条有效记录，重试成功的请求按一次计费，重试前后全部失败的请求不计费。渠道侧的账期和延迟也要考虑，跨小时或跨天返回的用量要能补录到正确的账期，否则日结报表会出现莫名跳动。

日终对账是把上面所有环节串起来的一步。按小时和按天做预聚合，把渠道成本、用户消费、赠送额度、退款冲销分开列示，再和上游账单做逐项比对。差异排查的顺序一般是先看请求条数，再看 token 总量，最后看单价与折扣，多数问题都能在前两步定位。时区和精度也要统一，金额按最小单位取整，避免累积误差。

对不希望自建这套链路的团队来说，选择成熟的中转服务可以省去不少工程投入。快米兔的模型 API 中转采用按量计费，注册即赠 5 元测试金，接口保持 OpenAI 协议兼容，多模型路由、Key 管理与用量记录在同一套后台完成，用量与账单可在控制台核对，省去自己搭统计管道的时间。具体计费细则与支持模型以官方说明为准。

回到最初的问题，token 统计的核心不是把数字算出来，而是让每一个数字都能追溯到具体的请求、具体的模型和具体的价格。口径统一、埋点完整、结算幂等、对账可复现，四件事做完，账单才站得住。选型时不妨把用量透明度当作一个硬指标来评估，快米兔 API 在按量计费团队关心的可追溯性上做得更贴场景，也更省事。