AI API 倍率计费全解析:model_ratio 与 completion_ratio 到底怎么算

AI API 倍率计费怎么算?

调用 Claude、GPT、Gemini 等国际模型时,同一网关下不同模型的账单常常差异很大,这背后正是 AI API 倍率计费 在起作用。倍率计费用「官方基准价 × model_ratio × 用户分组折扣」这一公式,把不同模型的调用成本精确映射到实际扣费,理解它才能提前预估每次调用的花费。

model_ratio 是什么:官方基准价之上的倍率修正

为什么不同模型不能用同一个单价

model_ratio 是倍率计费体系里最基础的乘数,作用是把各家模型厂商公开的官方基准价,按照网关自身的成本结构与定价策略重新修正一遍,得到网关侧的实际计费单价。不同模型的官方基准价本身就差异巨大:参数规模更大、推理算力消耗更高的旗舰模型,基准价通常是轻量模型的数倍甚至数十倍。如果网关对所有模型使用同一套加价逻辑,便宜模型会被计费过重,昂贵模型又可能倒贴成本。model_ratio 的存在,让每个模型都能按照自己真实的成本水平定价,而不是被平均主义的固定单价拉平。举例(示例倍率,实际以最新定价页为准):假设某模型官方基准价为每千 tokens 0.01 美元,model_ratio 示例值为 2,用户分组折扣为 0.9,那么实际单价即为 0.01 × 2 × 0.9 = 0.018 美元/千 tokens。下表列出几类模型的倍率示例,具体数值以最新定价页为准:

completion_ratio 计算:为什么输出 token 比输入贵

输入与输出分开计价的原因

如果说 model_ratio 解决的是不同模型之间怎么定价,那么 completion_ratio 解决的是同一个模型内部、输入和输出怎么分开计价。多数模型的推理成本并不对称:输入(prompt)部分可以并行处理,输出(completion)部分要逐 token 自回归生成,计算开销明显更高。因此网关通常把输入 tokens 按基准单价 × model_ratio 计费,输出 tokens 再额外乘上一个 completion_ratio 系数,得到更高的输出单价,计算方式可以写成:输出单价 = 输入单价 × completion_ratio。举例(示例倍率,实际以最新定价页为准):若某模型输入单价经 model_ratio 折算后为 0.02 美元/千 tokens,completion_ratio 示例值为 1.5,那么该模型输出 tokens 的单价即为 0.02 × 1.5 = 0.03 美元/千 tokens。一次调用的总花费,需要把输入、输出两段 tokens 分别乘各自单价后再相加,不能按平均单价一概而论。

从 model_ratio 到实际调用花费:一步步估算

计算实际调用成本的 5 个步骤

把前面两个系数串起来,任何一次 API 调用的实际花费都可以按固定步骤算出来,不需要死记硬背每个模型的最终价格。具体可以拆成以下几步:

1. 查到目标模型的官方基准价(通常按每千 tokens 计)。
2. 乘以该模型的 model_ratio,得到网关侧的基础单价。
3. 区分输入、输出 tokens:输入按基础单价计费,输出再乘 completion_ratio 得到输出单价。
4. 叠加用户分组折扣,不同套餐或等级对应不同折扣系数。
5. 按本次调用实际消耗的输入、输出 tokens 数量分别乘对应单价后相加,得到最终花费。

这套步骤对任何模型都通用,唯一变化的只是 model_ratio、completion_ratio 和分组折扣这三个具体数值,查阅定价页对应参数代入即可完成估算。

cache_ratio:多轮对话与长上下文如何省钱

缓存命中为什么能降低计费

多轮对话和长上下文场景,比如带着一长串系统提示词、参考文档反复提问,有一个共同特点:前面几轮的上下文会被后续请求重复携带。如果每次都按完整上下文的 tokens 全额计费,成本会随对话轮数线性攀升。cache_ratio 就是针对这种重复上下文设计的折扣系数——当请求命中缓存的上下文部分,这部分 tokens 不再按原单价计费,而是按原单价 × cache_ratio 计费,cache_ratio 通常明显小于 1。举例(示例倍率,实际以最新定价页为准):若某次调用有 60% 的输入 tokens 命中缓存,cache_ratio 示例值为 0.2,这部分 tokens 的计费只有原来的两成,只有未命中缓存的剩余 40% 按原价计费。对话轮数越多、复用的上下文越长,cache_ratio 带来的节省就越明显,这是长上下文、多轮对话类应用值得重点关注的计费细节。

钱包余额与订阅套餐:两种额度模式怎么选

累积计费与固定额度的适用场景

倍率计费公式解决的是单价怎么算,但额度从哪里扣、扣完之后怎么办,还要看账户用的是哪一种额度来源。钱包余额是充值制:按实际消耗的 tokens 乘对应单价实时扣费,余额可以持续累积、不会过期,适合调用量不规律、或者希望额度长期留存的场景。订阅套餐(日卡/周卡)则是固定额度制:每天发放固定额度,当天用不完不会累积到第二天,套餐到期后也不再发放新额度,更适合调用节奏稳定、希望成本可预测的场景。两种模式并不互斥,不少团队会用订阅套餐覆盖日常稳定用量,超出部分再由钱包余额按倍率补足。

总结:算清倍率,再选额度模式

倍率计费核心公式是「基准价 × model_ratio × 分组折扣」,配合 completion_ratio 区分输入输出、cache_ratio 优化多轮对话成本,就能精算每次调用的真实花费。登录 PioModel 控制台查看各模型实时倍率,选择合适的钱包或套餐额度,开始稳定调用 Claude、GPT、Gemini 等模型。