充了钱、跑了几次请求，账单一出来发现和心里估的对不上——多半是倍率在中间起了作用。这篇不给你具体数字，而是把倍率的来源、算法结构、和对账单的对应关系讲清楚，让你能自己拿用量记录反推出每一笔扣费，也知道什么情况下倍率算出来的结果不能直接拿来比价。
充了钱、跑了几次请求，账单一出来发现和心里估的对不上——多半是倍率在中间起了作用。这篇不给你具体数字，而是把倍率的来源、算法结构和对账单的对应关系讲清楚，让你能自己拿用量记录反推出每一笔扣费，也知道什么情况下倍率算出来的结果不能直接拿来比价。
先记住一句话：倍率不是价格本身，它只是一个换算系数。同一个模型，不同站可以用不同的倍率、不同的计费口径，最后落到你钱包上的数字才是一致的比较对象。所以真正要练的能力不是背倍率，而是能拿一次调用把它倒推出来。
倍率到底是什么，它乘在哪一层
倍率本质是一个换算系数：把官方标价换算成中转站自己的扣费单位。它最常见的位置是乘在「token 数 × 官方单价」之后，也就是先算理论价，再乘一个系数得到实际扣费；但也有站把它套在充值换算环节，你充值那一刻就已经被折算过一次。看账单前先确认你看的是哪一层，否则容易把两种换算叠加算两遍。
- 模型倍率
- 按模型区分，贵模型倍率高、便宜模型倍率低，乘在单价上
- 渠道倍率
- 按上游线路区分，同模型走不同渠道价格不同，乘在模型之上
- 充值倍率
- 只作用在充值与额度的换算环节，和单次调用用量无关
- 同一家站可能同时存在模型倍率、渠道倍率、充值倍率，先确认账单里展示的是哪一套
- 判断方法：拿一次已知 token 数的调用，用扣费金额倒推，看差额倍数是否稳定，稳定才说明是单一倍率在起作用
- 如果两次同类调用的倒推倍数差距很大，说明是按模型或按渠道分别定价，不是统一倍率
- 不适用的情况：账单里已经混了赠送额度、阶梯折扣或缓存价，倒推出的倍数会飘，这时候不能直接当成倍率
用一次调用把倍率反推出来
反推倍率不需要工具，只需要一次干净、可复现的调用。关键在于把输入和输出分开记，很多客户端默认只显示总 token，那样你没法对应官方价格表里的输入/输出两列单价，倒推出来的数是错的。
- 留一次调用的用量在客户端或日志里记下这次调用的输入 token 和输出 token 数，别只看总次数；最好选一个长输入短输出的请求，方便区分两列单价
- 核对当期官方单价到 /price-watch 或官方 API 价格页核对对应模型的当期输入、输出单价，别背数字，单价会随官方调整变化
- 算理论价理论价 = 输入 token × 输入单价 + 输出 token × 输出单价，这一步只用官方数字，不掺中转站口径
- 做除法实际扣费 ÷ 理论价，得到的倍数就是这次调用对应的综合倍率，记下来
- 换模型复算换一个模型再走一遍上面四步，两次结果接近才说明是统一倍率；差得多说明是按模型分别定价
- 手算嫌麻烦，可以用站内 /tools 目录里的 Token 单价换算和模型成本计算器，输入 token 和单价直接出结果
- 倒推时尽量用整数 token 的请求，避免分次计费或四舍五入干扰
- 把几次倒推结果记成一张小表，比记单次数值更能看出规律
倍率怎么体现在对账单的每一行
最容易误判的地方是预扣和结算。很多中转站在调用时先按预扣扣一次，结算时再按实际用量补差或退差，于是同一笔请求在账单里出现两条记录，数字不一样。这不代表倍率算错，只代表你看到的是两个阶段。
| 账单里的量 | 作用 | 核账时看什么 |
|---|---|---|
| token 数 | 计费基数 | 和客户端日志对不对得上 |
| 官方单价 | 理论价来源 | 是否与当期官方价一致 |
| 倍率 | 换算系数 | 同一模型多次调用是否稳定 |
| 最终扣费 | 真正支出 | 与理论价 × 倍率的偏差是否可解释 |
这四个量缺任何一个都核不清账。只要 token 数对不上，后面单价和倍率全白算。所以核账顺序必须是先对 token 数、再对单价、最后才看倍率；顺序反了，很容易把数据问题误判成倍率问题，去和客服争论一个根本不存在的高倍率。
- 缓存命中的部分往往不参与同一套倍率，混在一起看会把倍率算高
- 预扣与结算的差额不算异常，先确认是不是同一笔请求的两个阶段
- 补差记录如果出现在调用之后很久，可能是批量结算，不必当成重复扣费
- 核对不出来的行，先截图保留用量和账单，再去看站内核对工具或找客服
什么时候倍率不能拿来横向比价
倍率适合做粗筛，不适合当结论。两家站倍率数字接近，但计费口径不同——一个按输出为主、一个把缓存单独计价——实际花费可能差很远。倍率只反映换算关系，不反映额度有效期、赠送部分是否参与计费、结算延迟这些条款，而这些条款在长期使用中的影响往往比倍率本身更大。
- 口径不同不比较：缓存、赠送、阶梯折扣的处理方式不同的两家站，倍率没有可比性
- 看任务不看单价：拿你真实会跑的任务各跑一遍，比总花费和成功率，比盯倍率有用
- 粗筛可以，签量不行：小规模试水看倍率够用，一旦要做预算或签量，必须落到具体任务的用量记录上重新算
- 异常另算：遇到限速、重试、失败请求时，倍率解释不了为什么同一活扣了两次钱，这类问题要单独走排查流程
倍率是用来核对单笔账的，不是用来替代横向比价的。
如果只是想知道自己有没有被多扣，倒推几次就够；如果要在几家站之间做选择，把倍率、口径、条款三条放一起看，再拿真实任务跑一遍，结论才站得住。
下一步拿你最近一次调用的用量记录，按上面五步倒推一次倍率；再去价格追踪页核对当时的官方单价数字，两次结果放在一起，你就知道自己这份账单是怎么算出来的了。→常见问题
倍率是越低越划算吗？
不一定。倍率只是换算系数，真正决定花多少的是它乘在什么单价上、有没有把缓存和输出分开算、赠送额度能不能抵扣。两家倍率一个高一个低，但低的那家如果输出单价口径更贵，实际账单可能反而更高。比之前先对齐口径，再比数字。
为什么我自己算的倍率和账单显示的对不上？
最常见的三个原因：一是 token 数统计口径不同（客户端统计和平台统计会差）；二是把预扣金额当成了最终结算；三是账单里混了缓存命中或赠送额度的部分。建议先拿一次干净的、没有缓存命中的调用单独核算，对上了再扩大到整月账单。
倍率会变吗，多久看一次合适？
会变，通常跟着官方单价调整或渠道成本波动走，不是长期固定的。判断频率上，做预算的团队建议每次大批量任务前核一次，个人用户可以在账单明显偏离预期时再查。站内价格变动追踪和官方 API 价格页可以核对当期数值。
