LLM API 成本怎么估算？一篇讲清 Token、价格表和预算方法

很多团队第一次做大模型项目，最容易低估的不是开发难度，而是 API 成本。问题通常不在于不会看价格表，而在于：只盯输入单价、不算输出 token、不算历史消息叠加、不算重试、不算工具调用，最后项目一上线，成本就和预估差一大截。本文不讲空泛概念，直接从 怎么算、算哪些、怎么控 三件事入手，把 LLM API 成本估算这件事讲清楚，并给你一套能直接拿去做预算的公式。

一、先说结论：成本不是“单价 × 次数”这么简单

很多人会这样估算：

• 每次调用 0.001 元
• 一天 1 万次
• 那一天就 10 元

这几乎一定偏差很大。因为真实成本至少还受这几类变量影响：

所以更准确的理解应该是：

LLM API 成本 = 请求量 ×（平均输入 token 成本 + 平均输出 token 成本）+ 异常与冗余成本。

二、先把最基本的 3 个概念讲清楚

1. Token 不是“字数”也不是“字符数”

Token 可以粗略理解为模型计费的最小文本单位，但它和中文字符数、英文单词数都不是 1:1 对应。

大致可以这样理解：

• 中文：通常 1 个汉字不一定等于 1 token
• 英文：通常 1 个单词也不一定等于 1 token
• JSON、代码、Markdown、表格：token 消耗通常比你直觉更高

所以你做预算时，不要拍脑袋按“500 字 = 500 token”去算。

2. 输入和输出通常是分开计费的

大多数模型价格表会分成：

• Input tokens
• Output tokens

而且很多时候，输出比输入贵很多。这点在代码生成、长答案、Agent 总结场景尤其明显。

3. 不是每次请求都只有一轮

如果你做的是：

• 多轮对话
• 工作流
• Agent
• 工具调用
• RAG

那一次用户问题，背后可能对应 2~5 次模型请求，成本会放大得很快。

三、预算时最该先算的，不是价格表，而是请求结构

先不要急着比谁便宜。先把自己项目里的请求拆开。

你至少要回答 5 个问题

1. 用户平均一天发多少请求？
2. 每次请求平均输入多少 token？
3. 每次请求平均输出多少 token？
4. 是单轮还是多轮？
5. 有没有工具调用、重试、RAG 附加上下文？

一个更接近真实的预算模板

这时候你就会发现：

• 真正要算的不是“1 万次”
• 而是“1 万次 × 每次真实 token 消耗 × 调用链路放大系数”

四、最实用的成本估算公式

场景 1：普通单轮问答

公式：

总成本 = 请求数 × [(平均输入 token / 1,000,000 × 输入单价) + (平均输出 token / 1,000,000 × 输出单价)]

场景 2：多轮对话

公式：

总成本 = 对话轮数总和 × 每轮平均 token 成本

注意：多轮对话不是线性增长，因为历史消息会让后面轮次越来越贵。

场景 3：Agent / Function Calling / 工作流

公式可以再加一个放大系数：

总成本 = 用户请求数 × 单次主请求成本 × 调用链路系数 × 重试系数

其中：

• 调用链路系数：例如 1.5 ~ 3
• 重试系数：例如 1.03 ~ 1.15

五、一个可以直接套的示例

假设你做一个客服问答系统：

• 日请求数：20,000
• 平均输入：1,500 token
• 平均输出：500 token
• 模型价格：
  • 输入 ¥2 / 1M token
  • 输出 ¥8 / 1M token

基础成本

输入成本：

20,000 × 1,500 / 1,000,000 × 2 = ¥60

输出成本：

20,000 × 500 / 1,000,000 × 8 = ¥80

合计：

¥140 / 天

如果再考虑 10% 重试与冗余

140 × 1.1 = ¥154 / 天

月成本

154 × 30 = ¥4,620 / 月

这才是一个更接近真实值的预算结果。

六、最容易低估成本的 6 个地方

1. 只看输入单价，不看输出单价

很多模型看起来输入很便宜，但如果输出贵，你做长回答、代码生成、报告总结时，成本会迅速放大。

2. 忽略历史消息累积

一个 10 轮对话，不是把首轮成本乘 10 就完了。因为第 10 轮通常会把前 9 轮历史一起带上。

3. Prompt 写得太长

很多团队会把：

• 超长 system prompt
• 一整页规则
• 大段 few-shot 示例
• 大块文档原文

全部塞进每次请求里，结果输入 token 被白白拉高。

4. RAG 返回内容太多

不是检索越多越好。你把 20 段文档全扔进去，通常不是效果提升 20 倍，而是成本翻倍、延迟上升、噪音变大。

5. 工具调用没做裁剪

Agent 场景里，如果：

• 工具描述太长
• 工具结果回传太长
• 一个请求调用多个工具

成本会很快超过普通问答场景。

6. 模型选型过度

很多任务根本不需要最贵模型。

例如：

• 分类
• 提取字段
• 改写短文本
• 路由判断

这些任务通常可以先用更低成本模型处理，再把复杂任务交给高质量模型。

七、如何真正把成本压下来

方法 1：按任务分层用模型

这是最有效的方法之一。

不要所有请求都默认上旗舰模型。

方法 2：缩短上下文

可以做的事包括：

• 截断无效历史消息
• 摘要化旧上下文
• RAG 只取最相关内容
• system prompt 去冗余

方法 3：限制输出长度

很多场景下，你并不需要模型每次都回一大段。

可控方式包括：

• 明确要求“给 3 条以内结论”
• 限制最大输出 token
• 分步骤输出，而不是一次性长文

方法 4：降低无意义重试

429、timeout、503 这些异常如果处理不好，成本会隐形上升。

正确做法：

• 有上限的重试次数
• 指数退避
• 区分可重试错误与不可重试错误

方法 5：做多模型 A/B 测试

这也是 APIBox 这类聚合入口更适合开发者的原因之一：

• 用同一套 OpenAI 兼容 SDK
• 只改 base_url 和 model
• 快速对比不同模型的效果 / 延迟 / 成本

这样更容易找到“够用但不浪费”的组合。

八、什么时候该做正式预算，什么时候不用算太细

应该认真做预算的情况

• 准备正式上线
• 请求量会比较大
• 要做团队采购或内部立项
• 涉及多轮对话、Agent、RAG
• 成本直接影响毛利或报价

暂时不用算太细的情况

• 还在最早期 DEMO 阶段
• 日请求量很低
• 只是验证单一功能

但即使是 DEMO，也建议至少做一个粗预算，防止后面路线选错。

九、给开发者一套最实用的预算表结构

如果你要做内部汇报或立项，建议表里至少有这几列：

这样你后面做：

• 降本
• 替换模型
• 分流策略
• 调整输出长度

都会容易很多。

十、总结

LLM API 成本最容易踩坑的地方，不是看不懂价格表，而是：

• 低估输出 token
• 忽略多轮上下文
• 忽略 Agent / 工具调用放大
• 没把重试和失败请求算进去
• 没做任务分层选型

如果你正在做成本方案，建议顺手一起看 3 篇相关内容：

• 2026 免费大模型 API 额度汇总：开发者怎么低成本验证项目
• GPT-5 API 国内怎么用？最低价接入方案（人民币直充）
• DeepSeek API 为什么容易 429 / 503 / timeout？一篇讲清排查思路

这样你就不只是知道“怎么算”，还会知道“怎么选”和“怎么避坑”。

如果你只记住一句话，那就是：

预算先看“单次真实 token 结构”，再看模型单价；先做任务分层，再谈统一上高模。

对于要长期跑的项目，最稳的方式通常不是一开始就押单一模型，而是通过 APIBox 这种统一入口，把多模型测试、成本对比和后续切换能力一起保留住。这样你做预算时，不只是“算今天多少钱”，而是给后面的优化留余地。