API 中转站按量计费怎么核算：模型倍率、缓存折扣与失败请求的对账口径

企业采购大模型 API 中转服务时，预算表上通常只写一行：每百万 token 多少钱。但真正决定月底账单的，往往不是这个单价，而是背后的费率核算方式。在 API 中转场景里，所谓支付费率指的是用户按量消耗折算成人民币的计费口径，它由模型倍率、输入输出差价、缓存折扣、失败请求处理等多个变量共同决定。把这些口径问清楚，比砍下几个点的单价更有意义。

任何一家商用 API 中转站的费率，基本都拆成三块：模型基准价、输入输出倍率、调用分组。基准价通常对标模型官方公布的美元报价，再按固定汇率折算；输入与输出分开计价，输出一般高于输入，因为解码阶段的算力开销更重。同一个模型放在不同分组里，倍率可能不同，这也是同样一句提问、账单却不一样的根本原因。

中转站的成本来自上游通道，售价则要覆盖通道费、带宽与运维、失败重试带来的额外消耗，以及合理毛利。因此核算费率时不能只看官方价乘一个系数，还要看这个系数里是否已经包含了重试与退款成本。倍率压得越低，通常意味着重试空间越小或可用通道越集中，稳定性风险也相应上升，这部分隐性成本必须计入总账。

上下文缓存命中、批量推理这类能力会把实际消耗压下来。有的中转站把节省直接体现在 token 计费上，有的只在部分模型上支持。核算时应该分别测算命中缓存与未命中两种情形，否则按满价估的预算会偏高，按折扣价估的预算又会偏低，两种情况都会让最终支出偏离预期。

流式响应下，调用可能在中途断开，但已经生成的 token 已经产生成本，这部分算不算用户账，各家口径不同。较为合理的处理方式是按已返回的 token 计费，未产生任何输出的失败请求不计费或自动退回额度。用户在正式放量前，最好用真实日志验证一轮，而不是只看资费页上的说明。

费率核算的最终落点是账单能不能对上。需要关注的维度包括每次请求的请求 ID、模型名、输入输出 token 数、单价倍率、扣费金额与余额变动。粒度过粗的账单只能看到一个总数，一旦出现争议就无法定位到具体调用。对开发者而言，明细日志的价值往往高于总价本身。

快米兔在模型 API 中转上采用按量计费，注册赠送 5 元测试金，团队可以先用真实业务流量跑一轮，再根据明细反推自己场景下的费率结构。接口兼容 OpenAI 协议，原有代码改动量较小，切换后新旧账单口径也容易横向比较。对于同时接多家模型的团队来说，这种先实测、再核算的路径比只对着报价单估算更稳妥。

举个例子，假设某模型官方标价为每百万输出 token 10 美元、输入 2.5 美元，中转站给出固定的人民币倍率。若某月输入 2000 万 token、输出 500 万 token，可以先按倍率算出理论金额，再与账户实际扣费比对，差额就是重试、缓存折扣或分组差异造成的。连续记录两三个月，就能得出自己业务下真实的综合单价，也可以据此判断是否需要调整模型路由策略。

分组也不只是价格标签，它同时对应限流策略。高倍率分组通常对应更高并发与更稳通道，低倍率分组则可能共享通道、在高峰期限速。核算时要把限流导致的业务等待折算成成本，否则表面上便宜的费率反而更贵。令牌桶参数、并发上限这些指标，建议和费率放在一张表里评估。

还有一点容易被忽略：Key 的分账能力会直接影响核算效率。如果每个项目、每个业务线都能分配独立子 Key 并单独查看消耗，财务口径就能和研发口径对齐，不必再靠人工拆分。反过来，如果所有调用共用一个 Key，费率再透明，月底也只能得到一笔糊涂账。

综合来看，核算商用 API 中转站的费率，至少要问清五件事：输入输出是否分别计价、倍率是否公示、缓存与失败请求如何处理、账单明细能细到什么程度、Key 能否按项目分账。任何一项含糊，都会在放量之后变成对不上的账，而补救成本远高于前期多问几句。

对多数团队来说，费率的绝对值并不是最重要的，可预期、可核对、可解释才是。快米兔以按量计费、测试金先行、明细可查的方式，把核算这件事前置到了试用阶段，对需要严格控制推理预算的团队来说更省事一些。最终选型仍建议用自己的业务流量实测一轮，具体资费与规则以官方说明为准。