大模型 API 计价详解：怎么估算每月账单

大模型 API 计价在价目表上看起来很简单，每款模型两个数字，可一旦有了真实流量，账单就不好预估了。花多少取决于发进去多少 token、生成多少 token、输入里有多少是重复的，以及模型在回答前做了多少看不见的推理。这篇逐项讲清楚，用我们 2026 年 10 月 16 日实测的数据说明这些数字从哪来，最后算一遍月度账单，你可以换上自己的数字照着算。

大模型 API 计价的基本规则

几乎所有文本模型都按每百万 token 计价，输入和输出分开定价。输入是你发过去的全部内容：系统提示、之前的对话、工具定义、检索到的文档，以及这一次的新消息。输出是模型生成的全部内容。

关于 token，有三点比精确定义更重要：

• token 不等于词。 每家厂商用自己的分词器，同一段文字在不同模型上算出的 token 数不一样。代码、非英文文本和长数字，通常比普通英文占用更多 token。
• 请求比你写的消息大。 在 Kimi K3 上，三个词的消息「Reply with OK」被算作 88 个输入 token。模板和格式也要计数。以每次响应里的 usage 字段为准，不要按自己输入的文字估算。
• 输出通常比输入贵好几倍。 在 BoostRail 模型目录里，Claude Sonnet 5 的输出价是输入价的五倍，DeepSeek V4.1 Flash 是四倍。生成文字多的场景，对这一点感受最明显。

账单上的四类 token

价目表上只有两个数字，但现在的大模型账单最多会有四行。

推理 token 很容易被忽略。 我们让 Kimi K3「Reply with OK」，看得到的回答只有两个字母，响应里报告的输出却是 98 个 token，因为模型在回答前做了推理。把预算设成 16 个 token 时，同一个请求一个字也没返回。推理模型需要在 max_tokens 里留出余量，而这部分按输出计费。

缓存写入各家定价不同。 比如 Anthropic 官方 API，根据它的提示词缓存文档，写入缓存的价格高于输入价，读取缓存是输入价的十分之一。在 BoostRail，缓存写入不另外加价：第一次按正常输入价计费，之后的缓存读取按每款模型公布的缓存读取价计费，前提是这款模型的线路支持缓存。

为什么 agent 比聊天贵

聊天的一轮是发一条消息、收一个回答。agent 的一轮要把整个工作上下文重新发一遍：指令、工具定义、读过的文件、命令输出和之前的每一步。在 Claude Code 2.1.295 里，只回一个词的请求也发了 20,751 个输入 token。一次长时间的会话，每个任务会把这样的前缀重复几十次。

由此有两个结果：

1. 输入占大头。 编程 agent 的输入 token 通常是输出的许多倍，所以输入价和缓存读取价决定了账单的大部分。
2. 缓存占比决定剩下的部分。 如果每个请求的大部分是命中缓存的重复前缀，实际的输入单价会接近缓存读取价。如果前缀每一轮都在变，就什么也缓存不了，每个 token 都按完整输入价计费。

成本计算器按这个思路给了三档用量，并解释了为什么缓存占比比标价更影响账单。编程场景的具体做法，见 Claude Code 接入其他模型。

实算一遍：估算月度账单

取计算器的中间档，大致是一位开发者每天都用编程 agent：每月输入 3000 万 token、输出 600 万 token，其中 70% 的输入命中缓存。这样输入就拆成 2100 万缓存 token 和 900 万未缓存 token。

BoostRail 目录 2026 年 10 月 16 日的价格，单位是美元每百万 token：

公式对每款模型都一样：未缓存输入 × 输入价，加上缓存输入 × 缓存读取价，再加上输出 × 输出价，各自除以一百万。

同样一个月的工作量，用 DeepSeek V4.1 Flash 大约 $5.33，用 Claude Sonnet 5 大约 $78.09。如果不用缓存，Sonnet 这个月会是 $114.00，因为 3000 万输入 token 全部按完整输入价计费。模型之间差得多，用不用好缓存也差得多。

有两点提醒，让估算更可靠。token 数才是难估的部分：先从 usage 字段量一周的真实用量，再相信月度数字。另外，便宜的模型如果要多跑几轮才能完成任务，每个任务的成本可能比单价看起来高，所以要比较每完成一个任务花多少，而不只是每个 token 多少钱。

账单上可能出现的其他费用

• 图片和视频。 大多数文本模型把图片输入折算成 token。视频生成通常按输出的秒数计价，按分辨率区分，见视频模型页。
• 上下文上限。 BoostRail 上有些模型标明了输入上限，上限内统一按一个价格计费。超过上限的输入，在计费之前就返回 context_length_exceeded 错误。
• 中断的流式请求。 流式请求在完成前被关闭，按模型服务报告的用量计费，其中可能包括推理 token。具体规则见价格页常见问题。
• 失败的请求。 在 BoostRail，一款模型的所有线路都失败时，这个请求不收费。你自己发起的重试是新的请求，成功了就会计费。
• 充值手续费。 银行卡充值收 5.5% 手续费，最低 $0.80；USDT 充值收 1%，最低 $0.10。按量付费没有月度订阅费。

怎么把账单降下来

• 保持提示词前缀稳定。 固定的指令和工具定义放在前面，会变的内容放在后面，让重复的请求共享一个可缓存的前缀。
• 按任务分配模型。 规划和难的推理交给强模型，批量摘要、分类和简单修改交给便宜的模型。DeepSeek V4 Pro 与 Flash 怎么选那篇讲了一种分法。
• 选择推理强度。 不少推理模型可以调低推理强度（Chat Completions 里的 reasoning_effort）。在我们测试的一个编程提示词上，设为 low 后，GLM-5.3 的输出从 29,570 个 token 降到 3,348 个。
• 有意识地设 max_tokens。 留够推理模型完成回答的余量，但不要大到失控的回答花掉很多钱。
• 给每个 Key 设花费上限。 BoostRail 的 Key 可以设每日或每月花费上限，超出后请求返回 key_spend_limit_exceeded，账单不会继续涨。见错误与故障切换。

常见问题

不同模型的 token 是一样的吗？

不一样。每家厂商有自己的分词器，同一段文字在不同模型上的 token 数不同。比较模型时，看同一个请求各自报告的 usage，不要只看价目表。

为什么输出比输入贵？

模型生成 token 是一个接一个产出的，比读取输入花的计算时间多，厂商也按这个定价。目录里大多数模型的输出价都是输入价的好几倍。

推理 token 怎么计费？

按输出计费。即使只显示最终答案，模型的思考也计入响应的输出 token。所以推理模型一个很短的回答，计费的输出 token 可能远多于看到的长度。

跑编程 agent 怎样花得少？

用对缓存友好的写法，日常步骤用低价模型，只在能改变结果的地方用强模型。然后量一周每完成一个任务的成本；只看目录单价看不出这个数。

在哪里看每个请求花了多少？

在 BoostRail 控制台。它记录每个请求的用量和实际使用的价格，也就是从余额里扣掉的数字。