如何估算你的大模型 API 月度成本

几乎每一张让人意外的账单都来自同一个地方：用平均请求大小去估算，而真正推高开销的流量恰恰不平均。下面这套方法能避开它，大约一小时的埋点，而且随规模增长依然准确。

它是成本总指南里「度量」的那一半。拿到这些数字之后，后面的优化决策会容易得多。

公式

单条路由的月度成本 = 每次调用输入 token × 月调用次数 × 输入单价 + 每次调用输出 token × 月调用次数 × 输出单价。如果用了提示缓存，就把输入项拆成命中缓存与未命中两部分，分别按各自费率计。

模型就这么多。难点从来不是公式，而是给这些变量取到诚实的值。

要记录的四个数

1. 每次调用的输入 token，按路由分。不是按应用分——各路由之间能差一个数量级，混在一起平均会毁掉整个估算。
2. 每次调用的输出 token，按路由分。记 API 返回的真实用量数字，不要记你自己对模型写了多少的估计。
3. 命中缓存的输入 token（如果用了缓存）。这是一条单独计价的独立项。
4. 每条路由的月调用次数，取整周样本再外推。只取工作日会高估消费级产品，低估内部工具。

一个算例

假设一个客服助手每月处理 10 万次调用，每次发送约 500 token 的提示与检索上下文，返回约 50 token。也就是每月 5000 万输入 token、500 万输出 token。用目录里四款模型分别定价：

各档位之间的跨度，正是选对档位比谈价更重要的原因；而两列价格之间的跨度，是奥莱价在完全不改代码的前提下对同一负载做的事。

让估算偏低的四件事

• 重试与失败。重试的调用要计费，已经生成了 token 的超时也要计费。把失败率算进调用次数。
• Agent 循环。一次用户操作可能是五次模型调用。要数模型调用，不是数用户操作。
• 后台任务。夜间批处理常常远超交互流量，却几乎从不出现在任何人对用量的心理模型里。
• 月内增长。如果你每月增长 15%，请按月末而不是月初来估算。

跳过电子表格

拿到分路由的 token 用量之后，API 成本计算器会在整个目录上替你做这套算术，包含缓存输入的拆分，并把官方价与奥莱价并排给出。这是把四个日志数字变成一个决策最快的路径。

然后再把选定的模型和替代项核一遍：两家厂商如何定价，以及一次直接的双模型对照。