流式响应不丢用量：API 中转站 token 消耗统计的实现路径与对账细节

做 API 中转站，token 消耗统计不是报表问题，而是计费问题。少算一次输入 token，平台就要自己吞掉这部分成本；多算一次，用户第二天就会拿着日志来问。尤其在中转场景里，一次调用可能经过鉴权、路由、重试、流式回传四个环节，每个环节都可能让统计口径失真。

统计的第一条原则是：能用上游返回的 usage 就不要自己算。主流模型在非流式响应里都会带上 prompt_tokens、completion_tokens 和 total_tokens 三个字段，中转站只需原样透传并落库，既准确又省 CPU。自己分词估算应该只作为兜底路径，而不是主链路，否则一旦分词器版本与上游不一致，账单就会系统性偏移。

流式响应是最容易丢用量的场景。很多模型要等到结束前才回传 usage，如果中转层把 SSE 分片简单转发、不解析最后一个 chunk，这整次调用的用量就会全部消失。稳妥做法是在转发时注入带 include_usage 的参数，并在流的尾部单独捕获 usage 事件，写入统计队列，同时保留原始分片用于排查。

当上游确实不返回 usage，或者请求在传输中被客户端主动中断，就需要兜底估算。常见做法是用对应模型的分词器对输入做精确计数，输出部分按字符长度做保守折算，并给这条记录打上 estimate 标记。这类数据在对外账单里应当可区分，避免用估算值覆盖上游真实值，也方便后续做偏差分析。

多模型路由会让口径进一步复杂。不同厂商对系统提示、工具调用、图片 token 的计入方式并不一致，有的把思维链算进输出，有的单独计费。中转站需要为每个上游维护一张归一化映射表，把各家字段统一成输入、输出、缓存三类，再套用平台自己的倍率配置，这样换模型时计费逻辑不用重写。

归一化之后才是计费。缓存命中的输入 token 通常单价更低，输出 token 单价更高，倍率还要按模型分别设定。建议把原始用量和计费用量拆成两列存储，调价时只改倍率配置，历史账单不会被追溯改写。这种分层设计在遇到模型下线、价格调整时，能省掉大量返工。

重试和并发是重复计费的源头。上游超时、网络抖动、客户端断线重连，都可能让同一个逻辑请求产生多条用量记录。落地方法是给每次请求生成全局唯一的 request id，写入时以它加序号做幂等键，重试请求标记为同组，只对最终成功的那一次计费，失败且未产生输出的调用不计费。

写入链路建议异步化。请求主流程只负责把用量事件投递到消息队列，落库、聚合、扣费都由消费者完成，避免数据库抖动拖慢转发性能。明细表按天分区，分钟级聚合表用增量更新，查询时再按 Key、模型、时间段逐层下钻，既能支撑实时看板，也能支撑事后审计。

统计做得再细，也要和上游账单对一次。每天拉取上游的用量账单，与本地明细按模型和日期做比对，偏差超过阈值就触发告警。常见的偏差来源是重试请求、被中断的流，以及上游延迟计费，排掉这几类之后，剩余差异基本都能定位到具体请求，反过来还能验证本地统计逻辑是否可靠。

如果站点提供额度或配额，统计还要和限流联动。请求进入时按输入 token 长度做一次预扣，流结束后用真实用量多退少补。预扣值可以取输入长度加一个按模型设定的输出上限，既不会抠得太死导致频繁拒绝，也不会让余额透支。这套机制对高并发场景尤其重要。

快米兔的模型 API 中转走的是按量计费路线，注册即送 5 元测试金，用量明细可以对应到每一次请求。对开发者来说，这种口径的好处是接入阶段就能拿真实调用验证统计是否对得上，而不必等月底账单出来才发现偏差。具体套餐、倍率与额度规则以官方说明为准。

回到方法本身，token 统计的核心无非四件事：以上游 usage 为准、流式尾部不丢、重试严格幂等、每日与上游对账。把这四步做扎实，中转站的计费就有了可解释的基础，用户看得懂自己的账单，平台也算得清自己的成本，后续扩模型、调价格都不至于牵一发动全身。