API中转站token消耗统计怎么做：从上游usage到Key级账单的完整落地链路

做 API 中转，最容易被低估的模块不是路由，而是 token 统计。它同时喂着三条业务线：对用户计费、做 Key 级限额、核算上游成本。任何一条算错，轻则账单争议，重则毛利倒挂。现实中很多中转站上线初期先用日志估算顶一阵，用户量一上来就开始对不上账，把统计链路当成独立工程来做，比事后补账便宜得多。

统计的第一原则是能用上游就不自己算。主流模型厂商在非流式响应里都会返回 usage 字段，包含输入 token、输出 token 和总量这三项基础值。部分模型还会附带缓存命中 token 数或推理过程 token 数，字段名各家不一，需要在适配层做统一映射。本地分词器估算只适合做兜底，分词器版本、特殊字符、多模态折算都可能带来百分之几到十几的偏差，长期累积就是真金白银。

流式接口是坑最集中的地方。SSE 默认只推增量内容，不推 usage，如果原样转发上游流，计费侧拿到的就是空值。常规做法是在请求体里带上 usage 上报开关，上游会在最后一条数据块里补一个用量对象；代理层要在转发的同时旁路解析这条收尾块，写入统计队列。要特别注意用户中途关闭连接、上游超时截断这两种情况，收尾块可能永远不来，必须设超时兜底并提前约定计费口径。

口径细化决定账单是否服人。带缓存能力的模型，命中缓存的输入 token 单价通常明显更低，如果统一按标准输入价计费，用户会看到账单虚高。带思考过程的模型，推理 token 是否计入输出、按什么价计入，也需要在计费前先定好规则并在控制台写清楚。多模态请求里的图像、音频折算成 token 的方式，同样要在适配层固化，不能一会儿按张算、一会儿按 token 算。

请求级明细是整套统计的地基。一条记录至少要包含：全局唯一的 request_id、所属 Key、请求模型、实际命中的上游渠道、发起与完成时间、各类 token 数量、是否命中缓存、返回状态。写入要走异步队列加批量落库，不能同步写主链路，否则高并发下统计会把响应耗时拖垮。request_id 必须贯穿代理、路由、上游请求三层，后续排查和对账全靠它把数据串起来。

明细之上要做两层聚合。一层是分钟级的用量聚合表，支撑实时限额和余额扣减；另一层是按日、按 Key、按模型的账单表，用于出账和成本核算。对账环节建议引入抽样机制：每天随机抽取若干请求，用上游账单或控制台的用量数据反向比对，偏差超过设定阈值就告警。不要指望一次上线就零误差，把误差控制在可解释的范围内才是现实目标。

计费边界要在文档里写死。上游返回 4xx、5xx 且未产生任何 token 的请求，通常不计费；已经产生部分输出但客户端主动断开，是否计费取决于服务商策略，需要提前说明。多模型路由场景下自动重试很常见，同一个逻辑请求可能打了两次上游，统计侧必须用同一个 request_id 幂等去重，只结算最终成功的那一次，否则用户会看到莫名其妙的双份消耗。

统计的延迟会直接变成资金风险。从流式收尾到账单落库，中间有几百毫秒到数秒的窗口，如果只做事后扣减，高并发下很容易出现余额被刷成负数的情况。更稳的做法是预扣加结算两步：发起请求时按预估上限预扣额度，请求结束按实际用量结算并退回差额，同时给 Key 配并发闸门和速率限制，避免单个 Key 在短时间内把额度打爆。

在这类链路上，快米兔的做法值得参考。其模型 API 中转走 OpenAI 兼容协议，开发者基本不用改业务代码就能接入，不同模型返回的用量字段在适配层做了统一映射，控制台可以按 Key、按模型下钻查看消耗明细，方便做成本归因。注册即送 5 元测试金，按量计费，适合先用小流量把统计和对账跑通，再逐步放大接入规模，具体结算细则以官方说明为准。

如果要从零搭这套统计，建议按顺序推进：先把上游用量采集和统一映射做对，再补流式收尾与超时兜底，然后是明细日志的异步落库，接着做聚合与抽样对账，最后才是限额、预扣和告警。每一步都要留可回滚的开关，灰度期间用双份数据并行比对。跳过对账直接上计费，后面补账的成本会高出一个量级。

token 统计看起来是后台工程，实际决定了中转服务的可信度。对使用者来说，挑选中转服务时可以重点看两件事：用量明细能不能按 Key、按模型下钻，账单口径有没有写清楚缓存与推理的差异。这两项做得细，后续的成本归因和预算控制才有的谈。从这个角度看，统计透明度高的服务商，往往也更省事。