开源模型 vs 闭源模型：2026 年到底什么时候该自建

关于开源模型和闭源模型，网上有两种极端说法：一种说闭源 API 永远更贵、早晚被替代；一种说开源部署的隐性成本是 API 的十倍。两种都对，也都只在特定条件下对。

真正的答案取决于四个变量：年调用量、数据敏感度、定制深度、延迟容忍度。下面给数字和边界。

盈亏平衡点：调用量在哪一档

以 2026 年中期价格为基准，一个中等质量模型（相当于去年旗舰水平）的对比：

• 闭源 API：输入约 2 元/百万 token，输出约 8 元/百万 token，按阶梯折扣。
• 自建开源：一台 8×H 系列卡服务器，整机月成本约 3-5 万元（含折旧、电费、机房、运维人力），吞吐在特定调度下约每秒 3000-5000 输出 token。

按每天 8 小时满载跑业务算，月输出约 4000-6000 百万 token。摊下来自建的等效单价落在 6-12 元/百万输出 token——和闭源 API 同一量级，甚至更贵。

结论很反直觉：单纯为了省钱自建，在中等调用量下几乎不成立。 只有当利用率能稳定跑过 40%、或者你有大量可以合并批处理的离线任务时，自建才有成本优势。闲置的 GPU 是最贵的 GPU。

真正让人选择自建的是另外三个变量。

场景一：数据不能出厂

医疗、金融、政务、以及任何涉及个人信息和商业机密的场景，数据出境或过第三方 API 是硬约束。这时候自建不是因为便宜，而是因为唯一可行。

但要注意执行细节：私有云部署不等于合规。日志、prompt 缓存、监控上报这些链路都会把数据带出去，上生产前要逐条确认。合规场景里最常被忽略的是可观测性工具默认开启的请求采样。

场景二：需要微调与格式强约束

当你需要一个非常特定的输出结构（比如某个行业的编码规则、固定的多级 JSON schema），大模型靠提示词能到 85% 合规，剩下 15% 靠后处理兜底。微调一个小模型可能直接到 98%。

这里的成本算法不同：微调后的小模型 token 成本可能是旗舰 API 的 1/20，而且延迟更低。此时自建的价值不在硬件摊薄，而在用更小的模型做更专的事。一个 8B 微调模型在单一任务上打败通用大模型，是这两年的常态。

判断标准：任务是否窄、样本是否够（至少 500-2000 条高质量样本）、输出是否有明确可验证的格式。

场景三：延迟与吞吐的稳定性

API 的高峰限流是生产事故的常见来源。如果你的业务对 P99 延迟有硬要求（实时语音、游戏、交易辅助），自建的确定性更强。但自建同样会排队——取决于你的调度和批处理策略。开源推理框架在连续批处理上已经相当成熟，合理配置下单卡并发能到几十路。

场景四：长期迭代的锁定风险

这个理由常被跳过，但对产品团队很现实：API 的模型版本会被下线、定价会变、行为会漂移。如果你的产品依赖某个特定的输出风格，迁移成本迟早要付。自建把控制权拿回来的同时，也把维护责任拿回来了——每次框架升级、CUDA 变更都要自己扛。

一个五分钟能做完的决策流程

按顺序回答四个问题，第一个”是”就停：

1. 数据是否不允许出厂？ → 是：自建（并做合规链路审计）。
2. 是否有可量化、样本足够的窄任务，且对成本极敏感？ → 是：微调小模型，托管或自建皆可，优先选托管。
3. 是否有硬性延迟 / 可用性 SLA，且 API 无法承诺？ → 是：自建或混合（主流量本地、溢出到 API）。
4. 以上都不是？ → 用闭源 API。把资源投在提示词、检索、评测上，回报率远高于搬硬件。

一个被验证有效的架构是混合路由：80% 的常规请求走便宜的小模型或 API，20% 的复杂请求升级到旗舰；敏感数据的分支单独走本地。这套结构在团队规模变化时最不容易翻车。

最后一句实话：绝大多数团队没到需要自建的那一步。先跑起来、先有真实调用量，再谈基础设施，顺序反了就会用大量时间维护一套闲置的机房。