直接调 API 和自建开源模型推理，这笔账怎么算？

调 API 的好处是零运维、按量付费、模型能力跟着厂商升级；自建的好处是数据不出域、可以跑自己微调的权重、量大之后单位成本更低。

选择上主要看三件事：一是数据合规，如果数据不能出域就只能自建；二是调用量，量小的时候 API 划算，量大到一定程度自建的固定成本能摊薄；三是模型需求，如果要用自己微调的模型，API 侧通常没有对应支持。

具体的打平点要看业务，可以拿一个月的真实调用量估算：算出这些 token 走 API 要多少钱，再算自建需要几张卡、卡的月成本是多少，两边一比就有结论。

为什么只有 60 分：三条判据都对，但全部停在定性层面。"算出需要几张卡"这一步恰恰是最难的，也是面试官真正想听的——它取决于你的输入输出长度分布、并发模式和延迟约束，而不是简单的 token 总量除以吞吐。而且完全没提利用率和人力成本。

我把这笔账拆成四个维度，前两个决定"能不能选"，后两个决定"值不值得选"。

先看两个硬约束。 第一是数据主权与合规：数据能不能出域、行业有没有强监管、要不要物理隔离。这一条一旦成立，账就不用算了，只能自建。第二是模型控制：要不要跑自己微调的权重、要不要 LoRA 多租户、要不要改采样逻辑。这两条不成立的话，默认答案就是调 API。

然后是利用率，这是自建的生命线。 一张卡包月的钱是固定的，跑 20% 和跑 80% 花一样多；而 API 是按 token 计费，天然只为用掉的部分付钱——这是 API 最被低估的优势。所以真正的问题不是"我一个月用多少 token"，而是"我的流量能不能把卡持续喂到 60% 以上"。有明显波峰波谷的业务，自建就是在为波谷付钱。

核算方式上，我坚持用 goodput 而不是 throughput。 压测跑出来的峰值吞吐里，有一部分请求的延迟已经超出用户能接受的范围了。如果 throughput 是 10 rps 但只有 3 rps 落在 SLO 内，你的有效成本就是账面成本的 3.3 倍。我们的做法是压测时同时对 TTFT 和 ITL 设阈值，只统计达标的那部分，再用它折算每百万 token 的自建成本。

第四个维度是团队，也是最容易被漏掉的。 自建的隐性成本不是卡钱，是得有人看得懂 preemption 日志、知道 max_num_batched_tokens 该往哪边调、能判断长上下文请求把并发打下去了。我们踩过一次坑：上下文从 8K 涨到 128K 之后 QPS 塌了十几倍，团队第一反应加卡、第二反应换小模型，两次都错——真因是 KV Cache 把显存吃光了，能并发的请求数从 50 多掉到 3 条。这两次试错的人力成本，够买很久的 API。

最后一条容易被忽略的是：自建要打平的不是 API 的标价，是 API 打完折之后的价。 批处理四家现在一律五折，prompt 缓存命中是输入价的 0.1 倍。把能异步的负载扔进批处理、把长 system prompt 做成缓存友好的结构之后，API 侧的实际支出可能只有标价的三四成——很多"算下来自建更便宜"的结论，是拿自建的最优情况对比 API 的最差情况得出来的。

我们最后的选择是混合：主链路调 API，把评测、语料标注、离线摘要这类能异步的扔批处理；只有一个数据不能出域的私有化客户单独部署了一套自建集群，并且明确接受它的单位成本更高。