一百万 token 的成本：两种方式都算给您看。

简要版本

几乎所有你读到的这两者对比，最终都会归结成一个孤零零的数字—“自建便宜十倍”“API 便宜，直到你规模巨大为止”—而这两种说法犯的是同一个错误：给一台并非按 token 计费的机器算出一个每 token 成本。一台租用的 GPU 只有一个价格，且它不会变动：这个月您生成十亿个 token，还是一个都没生成，账单都完全一样。所以真正诚实的问题不是“这里每个 token 多少钱”，而是“需要生成多少 token，固定价格才能反超计量计费”。

这个数字是一次除法运算，下文将用我们自己的价格和吞吐量模型来计算—正是配置器所使用的同一套模型。此后的内容，都是关于决定您能否达到这个用量的两个因素：批处理，以及您让服务器闲置的时长。

运算

四行公式。第三行值得写在白板上；第四行是人们常常跳过的一行，而跳过它，正是一个可靠的估算变成错误估算的原因。

# 1. What the API charges. Linear in what you use, zero when you stop.
api_cost_per_month = output_tokens_per_month / 1e6 × api_price_per_million

# 2. What the machine charges. A constant. Tokens are free once you own the hours.
machine_cost_per_month = monthly_price

# 3. Set them equal. This is the break-even VOLUME, in output tokens per month.
break_even_tokens = monthly_price / api_price_per_million × 1e6

# 4. And the only question that matters: can the machine produce that many?
#    730 hours is the month we bill, so 2,628,000 seconds of it.
sustained_tokens_per_second = break_even_tokens / 2,628,000

第 4 行是持续速率，而非峰值。一台服务器如果每天有一小时达到每秒 600 个 token，其余二十三小时闲置，其持续速率就是 25，账单可不管您说的是哪一个。

单流的成本

先从最差情形说起，因为这是唯一无需任何假设就能给出的数字：一次一个请求，不做批处理，其余时间服务器闲置。以下每个节点都以 4-bit (AWQ, GPTQ) 运行 Llama 3.3 70B，吞吐量是我们自己给出的保守估算—它受限于显存带宽，而非在状态最好的那天测出来的数字。

请把这个数字当作上限，而不是报价。它是这样算出的：让服务器一次只回答一个问题，其余时间整月闲置—这是拥有一块 GPU 效率最低的用法。任何真正的推理服务栈都会做得更好，接下来两节要说的正是好多少。

各档次的盈亏平衡点

取上表中最便宜的一行—2 × NVIDIA RTX 5090，每月 $692—问它需要处理多少工作量，才能在 API 市场的各档次中胜出。

最后一列就是本文的核心。凡是写着「已经更便宜」的地方，$692 服务器上一条未经批处理的单流就能胜过 API，无需多想。凡是显示倍数的地方，服务器仍有胜出的机会—但前提是您真正把它喂饱，这正是下一节的内容。

批处理才是关键

生成一个 token 需要从显存中读取一次活跃权重。为一百个不同请求生成一百个 token，同样只需要读取一次—同一份权重服务于该批次中的每一个请求。这就是为什么采用连续批处理的推理服务栈，在相同硬件上能产出比单流多出许多倍的每秒 token 数，也是为什么那张表格最后一列所示的倍数真实可达。

实际含义是：把盈亏平衡表中的倍数当作吞吐量目标，而不是用户数。「单流的十倍」这个目标，并不意味着「十个用户」；它意味着服务器平均要达到未批处理速率的十倍，这通常需要远超十个、又远少于一百个的并发请求。在您确定具体数字之前，先在服务器上实测—这只是一次基准测试，却能一锤定音。

您仍需付费的闲置时间

以上都假设负载在整个月内均匀分布。而实际情况从来不是这样。按月租用的机器，在周日凌晨四点也照样计费，那个时段您没有生成的 token 不会顺延到之后。把您实际提供服务的那部分时间，除以您实际付费的时间：

第三行是大多数内部工具所在的区间，它会悄悄把您的盈亏平衡点拉高四倍以上。这正是自行托管估算出错的最常见原因—不是 token 单价，不是硬件，而是把「一个工作周」当成了「一整周」的假设。

为什么您的提示词几乎不花钱

有一种不对称性明显有利于自建服务器，而任何按 token 单价的比较都体现不出来。API 会对输入 token 收费—通常是每 token 输出价格的四分之一到三分之一。而在您自己的 GPU 上，输入 token 是在预填充（prefill）阶段处理的，该阶段并行处理整个提示词，受限于算力而非显存带宽。预填充阶段每秒处理的 token 数比生成阶段高出一个数量级。

这套算法没有算进去的东西

四件从不会出现在“每 token 成本”表格里的事，但它们决定这个问题的份量，不亚于数字本身。

您站在哪一边

按顺序阅读，遇到第一条符合您情况的就停下。

1. 您需要顶尖闭源模型的质量。那么本文并不适用：没有人会把那些权重租给您。请使用 API，等到某个开放模型在您的具体任务上追平差距时再重新考虑。
2. 您的流量不大，或者您现在还不清楚。请使用 API。这是摸清您真实流量情况最便宜的方式，而计量计费本身就是一件很好用的测量工具。
3. 您的流量波动大，且能容忍排队。请使用 API，或者拆分处理：用自己的机器承担稳定的基础负载，用托管接口应对峰值。没有什么强制要求只能选一种方式。
4. 您正针对一个开放权重模型，持续承载真实的批量流量。这正是硬件胜出的场景，而且胜出很多—固定价格不再变动，而计量表还在持续走动。在相信这一点之前，先核对上表中您自己的数字。
5. 提示词敏感、模型不能变动，或者账单必须提前可知。这种情况下，算式只是走个形式。租下能容纳您模型的机器，不必告诉任何人您是谁，为它付款即可。

无论您在哪一行停下，要核对的都是盈亏平衡表中对应您的模型和您的用量的那个数字。配置器会针对我们出租的每个节点，报告您的模型能否放进单张卡、是否需要拆分，以及吞吐量估算是多少—这正是这套算法所需的全部输入。如果您还在犹豫按月租用还是按小时计费，那是另一个盈亏平衡问题，同样已经算好。