从官方价到你的账单：一次完整的成本换算演练

为什么「倍率」不够用

倍率只解决了一个问题：单价打几折。但账单是这么来的：

账单 = Σ（各模型的 token 用量 × 该模型单价 × 倍率）+ 各种附加项

倍率只是其中一环。要算准成本，得先把整条链路补齐。

一个具体的例子

假设你的应用每月调用情况：

假设官方定价（仅为示例，实际以各家官网为准）：

第一步：算官方价

Claude: 8 × $3  + 1 × $15  = $39
GPT-4o: 2 × $2.5 + 0.5 × $10 = $10
官方总价 = $49

第二步：套倍率

假设中转站倍率 0.5：

49 × 0.5 = $24.5

到这里看起来省钱了一半。但还没完。

被忽略的三个计费项

一、prompt caching（影响最大）

如果你的应用会重复发送相同的上下文（RAG 系统、长文档问答、代码补全），官方会对命中缓存的部分按约 1/10 计价。

关键问题：中转站是否透传了缓存字段？

• 支持 → 你的输入费用可能降到原来的 1/5 甚至更低
• 不支持 → 每次都是全价，账单可能比预期高数倍

在上面的例子里，如果 800 万输入 token 中有 600 万是可缓存的：

支持缓存：600万 × $3 × 0.1 + 200万 × $3 = $1.8 + $6 = $7.8
不支持：  800万 × $3 = $24

仅这一项，差出 16 美元 —— 占官方总价的三分之一

这就是为什么「低倍率」不一定便宜。一个 0.3 倍率但不支持缓存的站，实际可能比 0.8 倍率支持缓存的站更贵。

二、推理模型的思考 token

如果你用推理模型（o 系列、DeepSeek R1 等），模型的思考过程也计入输出 token，而且往往远多于最终答案。

一个 200 字的回答，背后可能消耗 3000 个思考 token。按输出价计算，账单会明显高于「按对话轮次」的直觉估算。

三、失败重试

请求失败通常不计费，但部分成功的情况（比如流式输出中断）可能已经计费。

如果你的应用有自动重试，要注意重试策略 —— 无脑重试会在上游不稳的时段放大账单。

完整算式

把上面都放进去：

月账单 = Σ 模型 {
    输入 token 中不可缓存部分 × 输入价
  + 输入 token 中可缓存部分   × 输入价 × 0.1   （仅当站点支持）
  + 输出 token × 输出价
  + 思考 token × 输出价                        （推理模型）
} × 倍率 × (1 + 重试系数)

一个实用的做法：先跑一周再说

上面的算式看着清楚，但你的实际 token 结构得跑起来才知道。所以最靠谱的流程是：

1. 接入后跑一周真实流量
2. 导出用量记录，统计实际 token 结构
3. 套上面的算式复核，看与账单是否吻合
4. 根据实测结构去选站，而不是根据宣传的倍率

只有第 4 步做到，才算真的在按成本选型。

一个常被忽略的省钱方向

省 token 比省钱费率更有效。

比如把重复的 system prompt 精简 30%，对账单的影响往往大于换一家倍率低 10% 的站。原因是前者是乘法（作用在所有请求上），后者只是系数上的小让步。

值得先做的三件事：

• 精简 system prompt 与上下文
• 用缓存友好的方式组织请求（固定内容放前部）
• 按任务难度分层用模型（简单任务用便宜模型）

相关阅读

• prompt caching 在中转站上到底生效吗
• 推理模型的账单为什么比预期高
• 预付费、订阅制、按量计费：三种模式的成本分界线