自建 vs API 的盈亏平衡点怎么算：一个能填参数的账本模型

2026-08-07

这个问题我在会议室里见过太多次了。一边的人说「我们量都这么大了，自建早就该做」；另一边说「算上人力和运维，自建根本不划算」。两个人吵半小时，谁也没说服谁，最后老板拍板——拍的还是感觉。

有意思的是，两个人说的都对。他们只是在心里代入了完全不同的参数：主张自建的那位默认卡是跑满的，主张买 API 的那位默认要专门养一个运维。参数不一样，结论当然不一样，而且都自洽。

所以这篇不站队。这篇给你一个能填参数的账本模型：成本项怎么列全、盈亏平衡点怎么解出来、使用率怎么把一笔看起来很划算的账彻底翻掉。参数你自己填——填完了，结论就自己出来了，不用吵。

一、先把成本项列全，这一步比算术更容易出错

我见过的错账，九成不是算错，是漏项。而且漏的方向是系统性的：永远是自建那一侧漏。因为 API 的成本是一张账单，你想漏都漏不掉；自建的成本散落在采购、电费、人力工时、机会成本里，很多根本不进同一个预算科目。

API 侧

表面上只有一项：单价 × 用量。

但真正付钱的用量，比你业务逻辑里「需要的」用量要大，大在三个地方：

重试。超时、限流、偶发 5xx，退避重试一次就是一次完整计费。输入 token 通常还得重发一遍。
失败但已计费的调用。模型返回了，但格式不合规、字段缺失、被下游校验打回。这笔钱花了，价值是零。
被浪费的输出。你只需要一个 JSON 字段，模型却写了三段解释；你截断了、丢弃了，但 output token 一个不少地计了费。

这三项加起来是一个损耗系数。你不需要估，跑一个月就能从账单和日志里量出来——这是本文后面反复要用的原则：能测的别估。

自建侧

这一侧的项目多得多，而且有几项是隐性的：

成本项	性质	说明
卡的成本	固定 / 变动	买断则按折旧摊销；租用则按小时或按秒计费
电力	变动为主	与负载相关，但空载也有底噪功耗
机房托管或云主机	固定	机位、制冷、网络接入；云主机形态则并入实例价
存储与带宽	混合	模型权重、KV 缓存落盘、镜像分发、出网流量
运维人力	固定	最容易被整个漏掉的一项
故障期间的业务损失	隐性	卡挂了、驱动崩了、OOM 了，这段时间业务的损失
闲置时段的空转	隐性	卡在那儿，没请求，钱照付

后三项我加粗了，因为它们是争论的真正分水岭。

运维人力不是「顺手就干了」。驱动版本、CUDA 兼容、推理框架升级、显存碎片、批处理调优、监控告警、值班响应——这不是一个人的全职工作，但它绝对不是零。合理的做法是给一个 FTE 系数：0.2 个人、0.5 个人，按你团队的真实情况填，然后乘以人月成本。填 0 是不诚实的，那等于假设这些活儿不存在。

故障期间的业务损失取决于你的业务形态。如果推理是异步的批处理，挂两小时补跑就行，损失接近零；如果它挂在用户下单路径上，两小时的账单可能比你一年省下的还多。这一项没法给通用数字，但你必须给它一个数——哪怕是 0，也要是「我判断它是 0」而不是「我忘了它」。

闲置空转是下面第五节的主角，先按下不表。

关于这些成本项的分类细节和更完整的科目拆分，自建推理成本测算里有一份更细的清单，可以对照着补漏。

二、两种自建形态，账完全不是一回事

「自建」这两个字包着两种截然不同的成本结构，混在一起谈是吵不出结果的第二个原因。

形态 A：买断自有卡

前期一笔大投入，之后每月是折旧 + 电 + 机位 + 人力。特点是：

固定成本占绝对大头，变动成本很小。多跑一个 token 的边际成本几乎只有电费。
成本随使用率上升而摊薄。跑得越满，单位成本越低——这是自建唯一的、也是全部的优势来源。
关键变量是使用率，不是卡的价格。这句话值得单独记下来。卡再便宜，跑不满也是贵的。

形态 B：按需租用 GPU

没有前期投入，随开随停。但要分清两种计费口径：

按小时/包月租实例：实例开着就计费，空转一样付钱。这种形态本质上是把「买断」的固定成本换了个付法，使用率的账还是要照算。
按秒计费的任务式平台：只为实际推理的秒数付费，任务跑完就停。这种形态才真正把固定成本降到接近零。

第二种值得多说两句，因为它把「闲置」这个最大的坑填上了。

以 Replicate 官方定价页公布的 GPU 秒价为例（来源：https://replicate.com/pricing，核对于 2026-08-07；价格随时可能调整，以官方定价页为准）：

GPU	标识	官方秒价	本文按 ×3600 换算的小时价
Nvidia L40S	`gpu-l40s`	$0.000975/sec	$3.51/hour
Nvidia A100 (80GB)	`gpu-a100-large`	$0.001400/sec	$5.04/hour
Nvidia H100	`gpu-h100`	$0.001525/sec	$5.49/hour
2x Nvidia A100 (80GB)	`gpu-a100-large-2x`	$0.002800/sec	$10.08/hour

小时价一列是本文自己做的算术换算（秒价 × 3600），不是官方原文的表述方式。官方按秒标价这件事本身就是信息：它在告诉你计费粒度是秒级的，不用为空转买单。

这个换算带来一个很有用的参照：假如某个月你实际只跑了 100 小时的 L40S 推理，按秒计费是 3.51 × 100 = $351；而如果你租一台同规格实例包月开着（一个月按 720 小时算），就是 3.51 × 720 = $2,527.20。同样的卡、同样的活儿，差 7.2 倍——差的全是空转。

这不是说按秒计费一定更好。它有它的代价：Replicate 这类平台走的是自有的 predictions API，默认异步提交、轮询或 webhook 回结果，不是「改个 base_url 就能切」的 OpenAI 兼容形态，改造成本要单独算进去。它更适合跑图、跑批、长任务，而不是低延迟聊天补全。选型时接入范式是比价格更早要回答的问题——这部分展开可以看云 GPU 租用和GPU 选型。

三、盈亏平衡公式

现在把上面的东西写成一个能解的方程。

设：

V = 月 token 量（单位：百万 token）
P = API 侧有效单价（美元 / 百万 token），注意是「有效」——含重试与浪费的损耗之后的单价
F = 自建侧月固定成本（卡折旧或租金 + 电力底噪 + 机位 + 存储 + 运维人力 + 故障损失准备）
c = 自建侧变动成本（美元 / 百万 token，主要是负载相关的电力）

两侧月成本：

API 月成本    = P × V
自建月成本    = F + c × V

令两者相等，解出盈亏平衡的月 token 量：

F + c × V* = P × V*
F = (P - c) × V*
V* = F / (P - c)

就这一个式子。它简单到有点让人失望，但它把所有争论都收进了三个参数里：

F 越大，平衡点越高——你养的运维越贵、卡买得越猛，越需要巨大的量才回本。
P - c 是你每百万 token 的「节省额」，它决定了固定成本回收的速度。
如果 c ≥ P，方程无解——意味着你自建的边际成本已经超过 API 单价，不管量多大都不会回本。这种情况真实存在，通常出现在卡的效率很低或者电价很高的场景。遇到这个结果，直接停止讨论。

完整算例（所有参数均为假设值）

下面这组数字全部是为了演示算术而假设的，不是市场行情，也不是任何厂商的报价。你必须换成你自己的真实数字——尤其是卡价、电价、托管费这三项，本文一个数都不给，因为给了就是误导。

参数	假设值	说明
`P`（API 有效单价）	$2.00 / 百万 token	假设值，输入输出混合后的加权单价
`F`（自建月固定成本）	$6,000 / 月	假设值：卡的月度摊销 + 电力底噪 + 机位 + 存储 + 0.3 FTE 运维
`c`（自建变动成本）	$0.10 / 百万 token	假设值，负载相关电力

代入：

V* = 6000 / (2.00 - 0.10)
   = 6000 / 1.90
   = 3157.89 （百万 token / 月）

也就是约 31.58 亿 token / 月，摊到每天约 1.05 亿 token / 天（3157.89 ÷ 30 = 105.26 百万/天）。

验算：自建侧 6000 + 3157.89 × 0.10 = 6000 + 315.79 = $6,315.79；API 侧 3157.89 × 2.00 = $6,315.78。两边相等（尾数差来自四舍五入），公式没问题。

结论就摆在这儿了：

月用量低于 31.58 亿 token → 用 API。差得越远越不用犹豫，比如你一个月只跑 3 亿 token，API 花 $600，自建要花 $6,030，贵十倍。
月用量高于 31.58 亿 token → 自建值得进入下一轮评估。注意措辞是「进入下一轮」，不是「该自建了」——后面第五节的使用率还没过关。

把 API 侧的损耗算进去，平衡点会移动

上面 P = $2.00 用的是标价。假设你从日志里量出重试 + 无效返回 + 浪费输出合计带来 8% 的损耗（同样是假设值），那么有效单价是：

P_有效 = 2.00 × 1.08 = $2.16 / 百万 token
V*     = 6000 / (2.16 - 0.10) = 6000 / 2.06 = 2912.62 （百万 token / 月）

平衡点从 3157.89 降到 2912.62，也就是从 31.58 亿降到 29.13 亿，门槛降低了约 7.8%（(3157.89 − 2912.62) ÷ 3157.89 = 7.77%）。

这说明一件事：先把 API 侧的浪费治好，再来讨论自建。如果你 8% 的损耗是因为 prompt 写得烂导致格式老出错，那治 prompt 的投入产出比远高于买卡。用成本估算先把当前账单拆成「有效支出」和「浪费」两块，很多时候自建的讨论就自然结束了。

四、使用率是自建的命门

这一节是全文最该看的一节。

自建的单位成本 = 固定成本 ÷ 实际处理量。注意分母不是「卡的理论产能」，是实际跑出来的量。这两个数之间隔着一个使用率，而使用率几乎总是低于规划时的假设。

为什么规划时的使用率总是偏高

因为你是按峰值配的卡。业务有波峰波谷——白天忙晚上闲、工作日忙周末闲、月初忙月中闲。为了峰值不崩，卡必须按峰值配；配完之后，谷时那些卡就在那儿空转。

峰谷比 3:1 是很常见的形态。按峰值配卡，平均使用率天然就在 33% 上下——而你做预算时脑子里想的多半是 70%、80%。

用假设参数看看这个滑坡有多陡

继续用上面那组假设参数（F = $6,000/月，c = $0.10/百万 token），再假设这套硬件满负荷的月产能是 50 亿 token（5000 百万，同样是假设值）：

实际使用率	月处理量（百万 token）	单位固定成本	+ 变动	自建单位总成本	vs API $2.00
90%	4500	$1.33	$0.10	$1.43	省 29%
70%	3500	$1.71	$0.10	$1.81	省 10%
63%（临界）	3158	$1.90	$0.10	$2.00	打平
50%	2500	$2.40	$0.10	$2.50	贵 25%
30%	1500	$4.00	$0.10	$4.10	贵 105%
15%	750	$8.00	$0.10	$8.10	贵 305%

（单位固定成本 = 6000 ÷ 月处理量，如 6000 ÷ 4500 = 1.33，6000 ÷ 750 = 8.00。）

临界使用率算出来是 3157.89 ÷ 5000 = 63.2%——和第三节解出的平衡点是同一个数，只是换了个坐标看。

看这张表最该注意的是曲线的形状：使用率从 90% 掉到 70%，单位成本只涨了 0.38；从 30% 掉到 15%，涨了 4.00。成本对低使用率极其敏感。这意味着一件事——如果你对自己的使用率没把握，你面对的不是「可能少省一点」，而是「可能贵三倍」。风险是不对称的。

可执行的做法

第一步：先用 API 跑一段时间，拿到你自己的真实用量曲线。

注意是曲线，不是总量。总量只能告诉你月消耗多少 token，告诉不了你使用率。你需要的是分布：

按小时聚合的 token 吞吐，画出 24 小时的形状
峰值时段的 P95 吞吐（配卡按这个配，不是按平均）
峰谷比 = P95 吞吐 ÷ 平均吞吐
周内的形状（工作日/周末）和月内的形状（有没有月末结算高峰）

有了这条曲线，前面公式里的 V 和使用率就不是拍脑袋的了，是量出来的。这一步没做完，后面所有的算都是假的——这也是我把它放在文末清单第一条的原因。

第二步：考虑混合部署——基线负载自建，峰值溢出走 API。

这是绕开使用率陷阱最实用的一招：自建只按基线配（不是峰值），让自有卡尽量跑满；超出基线的部分溢出到 API，按量付费，用完即走。

用同一组假设参数看一个例子。假设总量 60 亿 token/月（6000 百万），基线稳定部分 45 亿，峰值溢出 15 亿：

方案	计算	月成本
全走 API	6000 × 2.00	$12,000
全自建（按峰值配两套，`F` 翻倍到 12,000）	12000 + 6000 × 0.10	$12,600
混合（一套自建承接 4500，使用率 90%；1500 溢出走 API）	6000 + 4500 × 0.10 + 1500 × 2.00 = 6000 + 450 + 3000	$9,450

混合方案比全 API 省 $2,550/月（省 21.3%），而按峰值配卡的「彻底自建」反而比全用 API 还贵 $600——因为两套硬件的整体使用率只有 60%，低于 63.2% 的临界线。

这个结果值得停下来想一秒：在同一组参数下，「自建」既可能是最优解也可能是最差解，差别不在自建本身，在你按什么配的卡。这也正好回答了开头那场争论——两个人各自代入的使用率不一样，所以一个算出省 21%，一个算出还贵 5%，两个人的算术都没错。

关于自建与 API 两条路线的整体权衡，自建与 API 的取舍那篇有更偏架构视角的讨论，和本文的成本视角可以互补着看。

五、有三种情况，不该用成本模型来论证

上面整套公式的前提是「决策依据是钱」。但有三种情况，自建的理由根本不是省钱——这时候硬拿成本模型去论证，只会得出一个错误的否定结论。

一、数据不能出域的合规要求。 医疗、金融、政务，或者客户合同里白纸黑字写了数据不得离开指定环境。这种情况下 API 不是「贵一点的选项」，是不是选项。成本模型的作用从「要不要自建」变成「自建的哪种形态成本最低」，问题换了。

二、需要模型定制或微调。 你需要在自己的数据上持续微调、需要控制模型版本不被上游悄悄换掉、需要修改推理逻辑或注入自定义层。这些能力有的 API 给不了，有的给得很受限。这时候自建买的是能力，省钱是副产品——甚至可能不省。

三、需要极低且稳定的延迟。 注意「稳定」比「低」更重要。公网调用的尾延迟受网络、上游排队、限流退避影响，P99 可能是 P50 的好几倍。如果你的业务对尾延迟有硬约束，把推理放在自己的网络里是一个架构决策，不是一个财务决策。

这三种情况的共同点是：约束在成本模型之外。硬要用平衡点去论证，你会得到「量不够，不该自建」的结论，然后违反合规、做不了定制、扛不住延迟。识别出自己属于这三类，就该换一套评估框架。

六、反过来，这几个信号说明现在别自建

同样重要的是反向清单。即使你的量已经过了平衡点，出现下面这几个信号，也该再等等。

用量还在剧烈波动。 如果你的月用量还在翻倍或者腰斩，任何按当前量配的硬件都会错——配大了空转，配小了不够用。硬件的调整周期以月计，业务的波动周期以周计，这个错配本身就是成本。等曲线平下来再说。

团队没有专职运维。 前面 F 里那个 FTE 系数，如果你填的是 0.3 个人，那这 0.3 个人得真实存在。「让后端同学顺手看着」在纸面上省了钱，实际是把成本转移成了这位同学的其他产出损失，加上一个没人真正负责的故障响应链路。半夜卡挂了谁起来处理，这个问题答不上来，就不该自建。

模型选型还没稳定。 这是最容易被低估的一条。你现在跑的模型，半年后大概率不是最优选择——参数规模、量化方案、上下文长度、显存占用的要求都可能变。但卡买了是要摊三年的。硬件的折旧周期远长于模型的迭代周期，这个错配在快速迭代期是致命的。相比之下，租用形态（尤其是按秒计费的任务式平台）保留了换模型、换卡型的灵活性，代价是单位成本高一些——这笔溢价买的是期权，在选型不稳定期是划算的。

还有一个隐含信号：如果你到现在都拿不出自己的用量曲线，说明观测还没建起来。观测都没有，自建之后的调优和容量规划靠什么做？先把观测补上。

决策清单

先拿到你自己的真实用量曲线——按小时聚合的吞吐分布、峰值 P95、峰谷比、周内与月内形状。没有这条曲线，后面每一步都是猜。
量出 API 侧的有效单价，把重试、失败调用、被浪费的输出算进损耗系数，得到真实的 P。顺手看看这部分浪费能不能先治掉。
把自建的 F 列全，尤其别漏运维人力（给一个诚实的 FTE 系数）、故障期间的业务损失、闲置空转。填 0 必须是判断的结果，不能是遗忘的结果。
解一遍 V* = F / (P - c)，拿你自己的数字。如果 c ≥ P，方程无解，讨论到此为止。
算临界使用率 = V ÷ 满负荷月产能*，再拿第 1 步的真实曲线去对：你的实际使用率能不能稳定地站在临界线之上？站不上就别自建。
算一遍混合部署方案：基线自建 + 峰值溢出走 API，和「全 API」「全自建」三方对比。很多场景下混合是唯一比全 API 省钱的方案。
对照合规、定制、延迟这三条例外，确认自己是不是根本不该用成本模型做这个决策。
检查三个刹车信号：用量还在剧烈波动、没有专职运维、模型选型未定。中了任何一条，先解决它，再回来重算。

最后提醒一句关于本文所有数字的性质：P、F、c、满负荷产能这些全部是为演示算术而设的假设值，请勿当作行情参考；GPU 采购价、电费单价、机房托管费本文一个数都没给，因为这些随地区、时点、采购量差异极大，任何未经你自己核实的数字代进公式都只会得到一个精确的错误答案。唯一引用的真实市价样本是 Replicate 官方定价页的四行 GPU 秒价，以官方定价页为准。

公式是通用的，答案是你自己的。