先把用量估对，再谈选型

大部分人做 API 预算是反的：先挑一个模型，再看它多少钱。正确顺序是先把用量估出来， 因为用量结构决定了哪个模型最优——同样是每月一千万 token， 输入九百万输出一百万，和输入一百万输出九百万，最省钱的选择很可能不是同一家。

估用量的公式很朴素：单次请求 token 数 × 日请求数 × 30。 难点全在「单次请求 token 数」上，而这里最常见的错误是只算用户输入。 实际发出去的一次请求通常包括：固定的 system prompt、工具/函数定义、few-shot 示例、 检索出来的文档片段、之前几轮的对话历史，最后才是用户这一句。 真实项目里，用户输入常常只占总输入的一小部分。

四个把账单算炸的坑

多轮对话的输入是累加的。第十轮请求会把前九轮的问答一起发过去， 所以一次十轮的会话，输入 token 不是十份单轮，而是接近十的平方级增长。 做长会话产品时，要么截断历史，要么做摘要压缩，否则成本曲线会翘得很难看。

重试和超时是隐性成本。限流触发重试、生成中断重来，这些都照常计费。 并发估高一点、退避策略做好，比事后看账单省心。

max_tokens 设太大，输出就真的会那么长。输出单价通常是输入的几倍， 让模型「想说多久说多久」是最贵的默认配置。给一个贴合场景的上限，比什么都省。

把整份文档塞进上下文。长上下文不但按 token 计费，还常常跳到更贵的分档。 能用检索取出相关的三段，就别把三十页全塞进去，具体权衡看 上下文长度计算器。

降本的顺序：先结构，后单价

很多团队一说降本就去换更便宜的模型，其实这是最后一步。前面还有三步性价比更高： 第一步是砍掉不必要的输入（压缩 system prompt、裁剪历史、用检索替代全文）， 第二步是把重复前缀交给提示缓存（命中价通常只有标准输入价的零头）， 第三步是把简单任务分流给轻量档模型，只让难的走旗舰。 做完这三步再去比单价，往往发现已经不用换模型了。

如果你想先看看各家单价的横向情况，可以直接翻 价格对比表；想按厂商了解计费口径和免费额度， 国产大模型 API 价格对比那篇按家拆得更细。