大模型 API 月成本怎么算？一套能拿去排预算的估算方法
月成本的骨架公式只有一条：单次请求 token 数 × 日请求数 × 30 × 单价。难的从来不是这个乘法，而是「单次请求 token 数」里那些你没算进去的东西，以及「日请求数」背后被忽略的重试和峰值。
这篇给一套能直接落到预算表里的算法。想边看边填，开 API 月成本估算器，它会按各模型单价把月成本排好序。
顺序错了会返工：先估用量，再选模型
常见做法是先挑一个顺眼的模型，再看它多少钱。这个顺序会让你返工，因为用量结构决定了哪个模型最优。
同样是每月一千万 token：输入九百万、输出一百万的场景，输入单价便宜的模型胜出；反过来输入一百万、输出九百万，输出单价便宜的才划算。两种场景的最优解经常不是同一家，先定模型再算账，等于把选型建在一个还没算出来的假设上。
所以正确顺序是：估用量 → 代进各家单价排序 → 在成本可接受的候选里做效果自测 → 定型。
第一步：把单次请求估准
单次请求的输入不是用户那句话，而是完整拼装后的请求体。逐项过一遍：
- system prompt（含格式约束、禁止事项）
- 工具 / 函数定义的 schema
- few-shot 示例
- 检索片段（RAG 场景通常是最大的一块）
- 对话历史
- 用户输入
把这一整坨粘进 token 计算器，得到的才是有意义的单次输入。
输出侧还没生成，没法粘，用两种方式兜底：一是按历史平均回答长度估（有日志就直接统计），二是按你设的 max_tokens 估一个天花板。建议两个都算——前者是期望值，后者是最坏情况，预算表里最好两栏都有。
第二步：把「日请求数」算实
这里有三个常被漏掉的乘数。
多轮会话的累加。 如果你的产品是多轮对话，第 N 轮要重发前 N−1 轮的内容。一次十轮的会话，总输入远不止十份单轮输入。实用做法是直接统计「单次完整会话」的总 token，再乘以日会话数，而不是按单轮乘轮次。
重试。 限流触发的重试、超时重来、输出格式不合规的重跑，全都照常计费。给一个百分之几到百分之十几的重试系数是合理的，具体看你的限流额度和退避策略。
峰值。 预算按日均算，容量按峰值算。如果你的流量集中在几个小时，日均能过但峰值会撞限流，撞了就退化成重试，重试又变成钱。这两件事要分开算。
第三步：代进单价，注意分档
拿到月输入和月输出后，代进月成本估算器。它会把各模型按月成本排序，第一名高亮。
有三件事表格里不会自动帮你处理，得手动想清楚：
分档计费。 不少厂商按上下文长度分档，超过阈值单价跳一档。如果你的场景经常是长上下文，按基础档算会低估。
缓存折扣。 提示缓存命中后，那部分输入按很低的折扣价计。如果你的请求前缀高度重复（固定 system prompt、固定工具定义），实际账单会明显低于表内估算——这是好事，但别在选型时忘了它，因为它可能改变排序。
Batch 折扣。 离线批处理通常打五折。能异步的活别走实时接口。
第四步：给结论加一个安全边界
估算做完，建议给出一个区间而不是单一数字：
- 下界：平均输出长度 + 缓存命中理想 + 无重试
- 上界：max_tokens 打满 + 无缓存 + 含重试系数
真实账单通常落在中间偏下。把区间给到决策方，比给一个精确到小数点的假数字更有说服力，也免得月底解释为什么超了。
三种典型场景的估法差异
同一套公式，落到不同场景上重点完全不同。下面三个是最常见的形态。
场景一：单轮问答（客服、搜索问答）。 输入由固定 system prompt 加检索片段加用户问题组成，输出通常几百 token。特点是输入远大于输出，属于输入敏感型。这类场景的最大杠杆是提示缓存——固定前缀占比高，命中后成本能明显下降。估算时务必把缓存命中率作为一个变量单独列出来，因为它可能改变模型排序。
场景二：多轮会话（助手、陪练）。 输入随轮次累加，是所有场景里最容易失控的。估算时不要用「单轮 token × 平均轮次」，而要按完整会话统计总 token。一个实用做法是从日志里取一批真实会话，直接统计每次会话的累计 token，取中位数和 P90。中位数用来估常态，P90 用来估重度用户带来的长尾成本。
场景三：长文档处理（摘要、抽取、审阅）。 输入极大、输出中等，且往往是批量的。这类场景优先考虑 Batch 接口（通常五折），其次考虑把「一次处理整份」拆成「分段处理再汇总」——分段之后每段都能落在更便宜的计费档里，虽然请求数变多，总成本常常反而下降。
一张预算表该有哪些列
把估算落到表格里，建议至少包含这些列，缺哪列后面就会在哪列上扯皮：
- 功能 / 接口名
- 状态（实验 / 灰度 / 生产）
- 单次输入 token（实测值，注明是否含缓存前缀）
- 单次输出 token（期望值与上限两栏）
- 日调用量（当前 / 满负荷）
- 模型与单价（注明核对日期）
- 缓存命中率假设
- 重试系数
- 月成本（基准 / 上界）
有了这张表，任何一行数字变了，总数会自动跟着变，也方便别人复核你的假设。最怕的是只交一个总数，没人知道它是怎么来的，出了偏差也无从查起。
数字太大怎么办：优化的先后顺序
一说降本很多团队就去换便宜模型，其实这是最后一步。前面还有三步性价比更高：
- 砍输入：压缩 system prompt、裁剪历史、用检索替代整份文档。这一步的收益立竿见影，且不影响效果。
- 开缓存：把固定前缀交给提示缓存，命中价通常只有标准输入价的零头。
- 分流：分类、抽取、格式化这类简单任务交给轻量档模型，只有难任务走旗舰。
做完这三步再回头看，往往已经不用换模型了。真要换，去价格对比表看单价，用模型横向对比把候选并排看，最后再拿真实任务盲评效果。
这个数字能当报价单吗
不能。它是量级判断，用来回答「这个功能烧不烧得起」。正式报价还要考虑厂商的阶梯优惠、并发保障、合规与数据处理条款，以及你和厂商谈定的具体条件。请以官方定价页和合同为准。
想按厂商了解计费口径，可以读国产大模型 API 价格对比；想把成本监控做进系统，API 成本监控那篇讲了埋点思路。