大模型接口账单怎么估才靠谱

最初于 2026 年 10 月 16 日发布在 boostrail.com。

LLM API 的定价在价目表上看起来很简单，每个模型只有两个数字，但一旦接入真实流量，费用就很难预测了。账单取决于输入了多少 token、输出了多少 token、输入中有多少重复内容，以及模型在回答前进行了多少隐藏推理。本文会逐项解释这些费用，结合我们在 2026 年 10 月 16 日的实测说明数字从何而来，并演示如何估算月度账单，你也可以代入自己的数据计算。

LLM API 如何计费

几乎所有文本模型都按每百万 token 定价，输入和输出分别计费。输入包含你发送的一切：system prompt、截至当前的对话、工具定义、检索到的文档，以及新消息。输出则包含模型生成的一切内容。

关于 token，下面三点比它的精确定义更重要：

• token 不等于单词。 每家模型厂商都使用自己的 tokenizer，因此同一段文本在不同模型上可能对应不同的 token 数。代码、非英语文本和长数字通常比普通英文段落消耗更多 token。
• 请求的体积比你输入的消息更大。 在 Kimi K3 上，只有三个单词的消息“Reply with OK”被计为 88 个输入 token。模板和格式也会计入用量。应该读取每次响应中的 usage 字段，而不是根据自己输入的文字估算。
• 输出通常比输入贵数倍。 在 BoostRail 的模型目录中，Claude Sonnet 5 的输出价格是输入价格的五倍，DeepSeek V4.1 Flash 则是四倍。需要生成大量文本的工作负载，对这一点感受最明显。

账单上的四类 token

现代 LLM 账单最多会有四个计费项目，即使价目表上只显示两个数字。

推理 token 很容易被忽略。我们让 Kimi K3 执行“Reply with OK”时，可见答案只有两个字符，但响应报告了 98 个输出 token，因为模型在回答前进行了推理。将 token 预算设为 16 后，同样的请求完全没有返回文本。推理模型需要在 max_tokens 中留出足够空间，而这部分空间会按输出计费。

不同服务商对缓存写入的定价不同。例如，根据 Anthropic 的 prompt 缓存文档，其自有 API 的缓存写入价格高于输入价格，缓存读取价格则是输入价格的十分之一。在 BoostRail 上，缓存写入没有附加费：首次处理按正常输入价格计费；如果模型使用的路由支持缓存，后续缓存读取则按各模型公布的缓存读取价格计费。

为什么 Agent 比聊天更贵

一轮聊天是发送一条消息，得到一个回答。Agent 的一轮操作则会重新发送完整的工作上下文：指令、工具定义、读过的文件、命令输出，以及此前的每一步。在 Claude Code 2.1.295 中，即使只回复一个单词，仍然发送了 20,751 个输入 token。在较长的会话中，每个任务可能会重复发送这样的前缀数十次。

这会带来两个结果：

• 输入占据费用的大头。 对编程 Agent 来说，输入 token 通常是输出 token 的许多倍，因此输入价格和缓存读取价格决定了账单的大部分金额。
• 缓存命中占比决定其余差异。 如果每次请求的大部分内容都是能命中缓存的重复前缀，实际输入价格就会接近缓存读取价格。如果前缀每轮都变，就无法利用缓存，每个 token 都按完整输入价格计费。

费用计算器据此提供了三种用量配置，并解释了为什么缓存命中占比比价目表上的标价更重要。关于编程场景的具体讨论，可以参阅《在 Claude Code 中使用其他模型》。

实例：估算月度账单

以计算器中的中等用量配置为例，大致相当于一名开发者每天使用编程 Agent：每月 30M 输入 token、6M 输出 token，其中 70% 的输入由缓存提供。这样，输入就分成了 21M 缓存 token 和 9M 非缓存 token。

以下价格来自 2026 年 10 月 16 日的 BoostRail 模型目录，单位为美元／每 1M token：

所有模型都使用同一个公式：非缓存输入量 × 输入价格，加上缓存输入量 × 缓存读取价格，再加上输出量 × 输出价格，各项都除以一百万。

因此，同样一个月的工作量，使用 DeepSeek V4.1 Flash 大约花费 5.33 美元，使用 Claude Sonnet 5 大约花费 78.09 美元。如果没有缓存，Sonnet 的月度费用会达到 114.00 美元，因为全部 30M 输入 token 都会按完整输入价格计费。模型之间的费用差距很大，能否有效利用缓存，同样会带来很大差距。

要让估算可靠，需要注意两点。首先，token 数量最难估：在相信某个月度数字之前，先从 usage 字段收集一周的真实用量。其次，如果便宜的模型需要更多轮才能完成任务，那么每个任务的实际费用可能比标价暗示的更高。因此，要比较完成一个任务的费用，而不只是每个 token 的价格。

还可能出现哪些费用

• 图片和视频。 在大多数文本模型中，图片输入会折算为 token。视频生成通常按输出视频的秒数计费，并根据分辨率区分价格；具体可参阅视频模型页面。
• 上下文上限。 BoostRail 上的部分模型，对不超过规定上限的输入采用统一费率。输入超出上限时，会在产生任何费用之前返回 context_length_exceeded 错误。
• 中断的流式响应。 流式请求在完成前被关闭，仍会根据服务商报告的用量计费，其中可能包含推理 token。具体规则见定价常见问题。
• 失败的请求。 在 BoostRail 上，如果某个模型的所有路由都失败，该请求不会收费。你自行发起的重试属于新请求，成功后会计费。
• 充值手续费。 银行卡充值收取 5.5% 的手续费，最低 0.80 美元；USDT 充值收取 1%，最低 0.10 美元。按量付费没有月度订阅费。

如何降低账单

• 保持 prompt 前缀稳定。 把固定指令和工具定义放在前面，把变化的内容放在最后，让重复请求共享可缓存的前缀。
• 按任务选择模型路由。 将规划和高难度推理交给强模型，将批量摘要、分类和简单编辑交给便宜的模型。《DeepSeek V4 Pro 与 Flash 对比》一文介绍了这样一种分工方式。
• 选择推理强度。 许多推理模型支持较低的推理强度设置，在 Chat Completions 中对应 reasoning_effort。在我们测试的一条编程 prompt 上，设置为 low 后，GLM-5.3 的输出从 29,570 个 token 降到了 3,348 个。
• 有意识地设置 max_tokens。 既要足够让推理模型完成任务，也要避免上限过高，导致失控的回答产生高额费用。
• 为每个 key 设置支出上限。 BoostRail 的 key 可以设置每日或每月支出限额；超过限额的请求会返回 key_spend_limit_exceeded，避免账单继续增长。具体可参阅《错误与故障转移》。

常见问题

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

不一样。每家模型厂商都有自己的 tokenizer，因此同一段文本在不同模型上会产生不同的 token 数。比较模型时，应该查看它们处理同一个请求时报告的用量，而不能只看价目表。

为什么输出比输入贵？

生成一个 token 比读取一个 token 需要更多计算时间，因为输出是逐个 token 生成的，模型厂商也据此为输出定价。模型目录中的价格显示，大多数模型的输出价格都是输入价格的数倍。

推理 token 如何计费？

按输出计费。即使只展示最终答案，模型的思考过程也会计入响应的输出 token。因此，推理模型的一条简短回答，实际计费的输出 token 数可能远远超过其可见长度。

运行编程 Agent 最省钱的方法是什么？

采用便于利用缓存的配置，将常规步骤交给低价模型，只在强模型能改变结果时使用它。然后，用一周时间测量完成每个任务的费用；仅凭模型目录中的价格，无法知道这一点。

在哪里可以查看每次请求的费用？

在 BoostRail 控制台中查看。它会记录每次请求的用量和实际采用的价格，这就是最终从余额中扣除的金额。

如果需要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。