自建推理服务和直接调 API，成本曲线在哪交叉

每次有人问我"自己搭推理服务还是调现成的 API"，我都要先把问题反过来问一遍：

你一天有多少次请求？

不是"我们业务量挺大的"，而是一个能算出来的数字。因为这两种方案的成本曲线形状完全不同，交叉点出现在一个具体的位置上，猜不出答案。

两条曲线的形状

调 API 是线性的。 付多少取决于用多少，输入输出 token 分别计价。没有固定开销，也没有闲置成本。你不用的时候不花钱，这是它最大的优势。

自建是阶梯形的。 一台实例开着就在花钱，不管你用不用。所以自建的月成本可以拆成两块：

月成本 = 固定成本（实例 + 磁盘 + 流量） + 变动成本（几乎为 0）

变动成本接近于零是关键：多来一倍请求，机器不变，成本几乎不变。这意味着自建的成本曲线是"越用越划算"。

而 API 的成本曲线是恒定斜率的直线。两条线必然交叉。

交叉点在哪

粗略的算法是这样的：

自建月成本 ≈ 实例月价 + 存储 + 出站流量 + 运维工时折算

自建每百万 token 成本 = 自建月成本 ÷ 月 token 量
API 每百万 token 成本 = 单价（输入/输出分开算）

交叉月 token 量 = 自建月成本 ÷ (API 单价 - 自建的每百万 token 边际成本)

举个我实际算过的例子（数字是量级示意，用来演示算法）：

• 自建：一张 40GB 显存的卡，包月加磁盘约某个量级
• API：一个中等模型的输入输出混合单价

代入之后交叉点落在每月几千万 token 这个区间。也就是说，如果你的月用量在交叉点以下，API 便宜；以上，自建便宜。

但这个算法有个致命漏洞——它假设自建那台机器的利用率是 100%。

利用率才是真正的分水岭

假设你的业务每天只有 3 小时有流量，其余时间机器空转。那自建的实际每百万 token 成本是上面算出来的 8 倍（24 小时 ÷ 3 小时）。

所以正确的算法是：

有效运行小时数 = 每天有流量的小时数 × 30
每百万 token 成本 = 月成本 ÷ (有效运行小时数 ÷ 单小时吞吐量)

这就把"利用率"这个变量显式地放进来了。

我把这个表做出来之后，团队的决策就快了很多：

别只算机器钱

算完钱，还有一堆东西要加进"隐性成本"，不然自建永远显得划算：

运维工时。 我第一次自建时以为"跑起来就不管了"，实际上第一周就花了十几个小时在排环境依赖冲突、CUDA 版本不匹配、显存碎片。真要把这件事算进去，自建在中小用量区间会直接翻盘。

出站流量。 这个最容易被漏掉。自建的推理服务在前面挂个网关，模型响应、embedding 结果都要走公网出去。出站流量在多数云厂商是单独计费的，量大之后是一笔实打实的钱。API 方案里这块是打包在单价里的，自建方案里它是裸露的。

数据合规。 如果你的数据不能出内网，那 API 方案直接出局，不用算钱。这条往往是最先起作用的。

模型升级的滞后。 商业 API 的模型一更新你就用上了。自建的版本是你自己 pin 死的，升级要重新验证效果，工程量不小。

故障责任。 API 挂了是别人负责，自建挂了是凌晨三点你爬起来。

我自己算错过的账

有一年我给一个文档处理项目算过一笔账，得出的结论是"自建一年能省下十几万"。数字算得很漂亮。

结果项目上线后，那个所谓的"稳定服务"实际每天只在跑两个小时，机器 22 小时空转。半年之后复盘，我重新算了一遍——如果当时按有效利用率算，这笔账是反的。

更糟的是，为了"不浪费这台机器"，我们又往上面加了两个不相干的推理任务，导致它变成了一台谁都说不清在干什么的机器。最后还是退回了 API 方案。

这件事让我形成一个习惯：在算账之前，先去看一眼监控图，确认这台机器到底会被用满。 很多看起来很美的方案，输在利用率上。

有几个中间选项

不是只有"全自建"和"全 API"两个选项：

混合路由。 简单请求走自建，复杂的走 API。这适合自建模型能力不足、但又不想完全放弃成本优势的情况。代价是两套代码要维护。

小模型自建 + 大模型 API。 大部分请求其实用不上最强模型。我做过一次统计，八成的请求用小模型就能答对，剩下两成升级到大模型。这条路的性价比最高，因为它把两边的优势都用上了——自建承接基数，API 承接难例。

按需开关的自建。 平时不常驻，有需要才开机。这个方案在"用量波动大"的情况下最优，但每次开机要几分钟，模型加载的冷启动时间是实打实的体验损失。

我的判断顺序

不按金额排，按可行性排：

1. 数据能不能出内网？ 不能的话，只剩自建，不用往下算。
2. 月用量在千万级以下吗？ 是的话直接调 API，别折腾。
3. 能不能用包年包月把固定成本摊薄？ 能的话自建的性价比会明显提升。
4. 有没有"流量大但负载不均"的特征？ 有的话考虑混合方案，而不是纯自建。

最后照例说一句：单价、包月价、流量费这些数字各厂商调整得频繁，而且不同地区、不同规格差别很大，写在文章里过几个月就会误导。真正可复用的是上面这套算法，把你自己机器上的真实吞吐和真实单价代进去，结论会比任何别人的数字都准。