把 1.3 倍系数当成心算模型：从厂商挂牌价推到你实际扣的 USDC

为什么需要一个统一的口径

各家厂商的定价页面写法不一样：有的按每百万 token 报价，有的按每千 token 报价，有的把输入和输出分开列，有的还有缓存命中价、批处理价。你如果直接拿这些原始数字横向比，很容易被单位差异带偏。

聚合站这边只有一条规则：按对应后端的官方价乘 1.3 扣费，以 USDC 结算。所以真正需要做的，是把每个后端的官方挂牌价都换算到同一个口径——一次具体请求扣多少 USDC——再比较。

先把官方价折算成“每 token 单价”

不管官网写的是每百万还是每千 token，第一步都是统一到“每 1 token 的价格”，并保留足够多的小数位。心算时可以用这个形式记：

• 官方每百万 token 价 ÷ 1,000,000 = 每 token 官方单价
• 如果你更习惯每千 token 报价，则再 ÷ 1,000

输入价和输出价要分别处理，不要合成一个数字，因为一次请求里两者的 token 数量通常差很多。

乘上 1.3：得到你的每 token 扣费单价

官方每 token 单价 × 1.3，就是聚合站对你这一路 token 的扣费单价。这一步可以在纸面上一次做完，之后同一后端的所有估算都复用这两个数：

• 输入每 token 扣费单价 = 官方输入价 × 1.3
• 输出每 token 扣费单价 = 官方输出价 × 1.3

1.3 是固定系数，不随模型、用量、时间段变化，所以它非常适合做心算：你只要把官方价乘以 1.3，剩下就是纯加法。

从单价到一次请求的 USDC 金额

有了单价，一次请求的扣费就是：

扣费 ≈ 输入 token 数 × 输入扣费单价
     + 输出 token 数 × 输出扣费单价

实际使用时有两个习惯会让心算更准：

• 用你自己的典型请求去估，而不是用平均值。代码补全、长文摘要、多轮对话的输入输出比例差别很大。
• 把“每千次请求”或“每百万 token 混合用量”作为比较单位。单次金额太小，容易被四舍五入掩盖差异。

用这个模型横向比较六个后端

把六个后端都换算成“每百万输入 token 的扣费”和“每百万输出 token 的扣费”两组数字，再排在一起看：

• 同一后端内，输入和输出谁更贵、差几倍；
• 不同后端之间，在你自己实际的输入输出比例下，谁更省钱；
• 哪些后端在高输出占比的场景下优势更明显。

这样比较的好处是，所有数字都已经是“你要付的 USDC”，不需要在脑子里反复切换单位，也不会把官方价和扣费价混着比。

别忘了贡献侧的 1.1 / 1.2

如果你同时是 key 贡献者，同一套算法也能反向用：贡献返还是按官方价 × 1.1（优质 × 1.2）以 USDC 结算。也就是说，同一个后端、同样一段 token，在“用”和“供”两侧的系数分别是 1.3 和 1.1/1.2，可以直接用同一个 token 数乘出来对比。

常见误区

• 把 1.3 当成“涨价 30% 后再叠加其他费用”。它就是一个乘数，没有隐藏加项。
• 用官网的“每百万 token”数字直接和别人的“每千 token”数字比。先统一单位。
• 忽略输入输出比例，只比单个价格。真实账单由两者共同决定。
• 把不同后端的 token 计数方式默认为一致。分词方式不同，同样一段文本的 token 数会有差异，横向比较时心里要有这个误差带。

一个可复用的小结

把流程压缩成三步，随时可以在纸上复现：

1. 官方价统一到每 token（输入、输出分开）；
2. 各自 ×1.3，得到扣费单价；
3. 乘以你的典型 token 用量，得到每次请求或每批请求的 USDC 金额。

做完这三步，六个后端就站在同一个起跑线上了。