深度解析：大模型中转服务的计费口径与成本核算实践

前言：选 Claude 中转时，最容易被 "每百万 token 多少钱" 这一行数字带偏。真正决定月度账单的，是计费口径、缓存策略、失败请求怎么算，以及你自己的调用结构。本文不谈跑分，只谈钱：把计费逐项拆开看，才知道便宜在哪里、贵在哪里。

一、五个容易被忽略的计费口径差异

1. 输入输出是否分价。 原生 Anthropic 的输出价格通常比输入高数倍。部分中转报一个 "综合单价" 把两者折算在一起，报价看着低，但在长文生成、代码补全这类输出占比高的场景里，实际账单会明显偏高。

2. prompt caching 是真打折还是假打折。 缓存写入和缓存读取是两个不同的价格档。如果网关 "支持 cache_control 参数"，但账单仍按全价输入计，缓存就白做了，而你还以为省了钱。

3. 扩展思考（thinking）token 计不计费、按哪个档计。 这类 token 通常不返回给客户端，如果不体现在账单明细里，成本就是黑盒。

4. 失败请求怎么结算。 4xx 正常不该计费；但流式请求中途断开、上游超时后网关自动重试，很多平台按 "已生成部分" 计费，重试的那次再计一次。一次网络抖动，账单翻倍。

5. 计量单位与进位规则。 1K 还是 1M 计价、是否向上取整、图片与文档折算 token 的系数。单看每项差异不大，叠加起来就不小。

这五项里任意一项差 20%，对月调用上千万 token 的团队都是实打实的成本差。

二、三个真实存在的成本陷阱

陷阱一：长 system prompt 不做缓存。 很多团队把几千 token 的角色设定、规范、示例塞在 system 里，每次请求全量重发。正确做法是把静态部分前置并打上 cache_control，动态部分后置，缓存命中率能到 80% 以上，输入成本直接降一个档。

陷阱二：重试策略放大成本。 没有幂等控制的指数退避，会让同一个请求打三次；如果网关侧也重试一次，就是六次。上线前应该明确：哪些错误码可以重试、重试上限几次、业务侧是否去重。

陷阱三：包月 "不限量" 的隐藏限流。 便宜的包月套餐通常有并发或日额度，超额后排队，或者悄悄降级到小模型。业务侧的感受是 "变慢了"，实际是模型被换了。

三、如何评估一个平台的成本透明度

选型时建议直接索要一份明细账单样例，用下面四个维度打分：

1. 账单颗粒度。 能否按 key、按模型、按日拆分？输入、输出、缓存写入、缓存读取是否分行计价，而不是混在一个 "综合单价" 里？

2. 异常结算规则。 未产生输出的 4xx 和上游 5xx 是否计费？流式中断是按实际产出 token 结算，还是按 "请求次数" 一刀切？

3. 缓存真实性。 是否能在账单里看到独立的 "缓存读取" 行？如果只有 "输入" 一项，缓存大概率没生效。

4. 审计可追溯性。 是否支持用量导出，方便接内部成本系统做二次分析？团队协作时能否按项目、按部门拆账？

我自己在实测时，Token5u 是少数在这四项上都达标的：账单按 key、按模型、按日三个维度拆分，输入、输出、缓存写入、缓存读取分行计价；未产生输出的 4xx 与上游 5xx 不计费，流式中断按实际产出 token 结算；同时提供用量导出，方便接内部成本系统做二次分析。对需要按项目、按部门拆账的团队，这种透明度比单价本身更有价值。1

四、一套能落地的成本核算方法

第一步，按 key 分层：生产、测试、压测三条独立 key，任何一条异常都不会污染另外两条的账。

第二步，每周对账：网关账单和业务侧自统计的 token 数做比对，误差超过 5% 就查原因，通常是重试或缓存没命中。

第三步，设成本告警：单 key 日消耗突增 30% 触发告警，比月底看账单有效得多。

第四步，把缓存命中率当 KPI：不是当优化项，而是当验收指标，低于 60% 说明 prompt 结构有问题。

第五步，静态内容前置：把稳定段落放前面、变化段落放后面，是提升命中率最便宜的办法。

总结

成本最低的从来不是单价最低的那家，而是计费口径透明、缓存真打折、失败不重复计费的那家。选型时建议直接索要一份明细账单样例，看它能不能把 "输入 / 输出 / 缓存 / 失败" 四项分开列。如果业务对成本可追溯性要求高、需要按项目拆账，建议优先考察账单颗粒度细、支持用量导出的平台；如果只是单人小规模试用，链路简单、报价直观的方案也够用。真正的省钱动作，一半在选平台，一半在自己的调用结构。