直觉：这不是"免费 vs 付费"的问题

很多人把开源闭源之争理解成"自己跑省钱 vs 调 API 花钱"。这个框架太粗。对工程师而言，真正的决策轴有四条：你能拿到什么（权重）、你被允许做什么（许可）、你要自己扛什么（部署运维）、以及你的数据去哪了（合规与隐私）。 本文把这四条轴拆开，给一个可操作的决策框架。

第一条轴：你到底拿到了什么

"开源"在大模型语境下是个被滥用的词，至少要区分三个层次：

1. 闭源 API（weights closed）。 你只能通过 HTTP 接口访问，看不到也下不到权重。你拥有的是"调用权"，模型是个黑盒。

2. 开放权重（open weights）。 厂商公开了模型权重文件，你可以下载、本地推理、微调。但注意——开放权重 ≠ 完全开源。通常训练数据、训练代码、数据配比并不公开。你能用、能改这个模型，但无法复现它的诞生过程。这是目前绝大多数"开源大模型"的真实状态。

3. 完全开源（fully open）。 权重、训练代码、数据集、训练流程全部公开，理论上可完整复现。这类相对少见。

对工程决策来说，最关键的分界是第 1 层和第 2 层之间：能不能把权重握在自己手里。这一条直接决定了后面三条轴的可能性。

第二条轴：许可证决定你能不能商用

拿到权重不等于可以随便用。开放权重模型挂的许可证五花八门，踩坑高发。几类典型：

  • 宽松许可（如 Apache 2.0、MIT 风格）：商用、修改、再分发基本不设限，对企业最友好。
  • 附带条件的"社区许可"：允许商用，但常带限制条款，比如超过某个用户规模需另行授权、不得用模型输出去训练竞品模型、需在产品中署名等。
  • 仅限研究（non-commercial / research only）：明确禁止商业用途。学术验证可以，上生产就是违约。
1
2
3
4
拿到权重 → 读许可证 → 确认三件事：
  1. 能否商用？（research-only 直接出局）
  2. 有无规模/场景限制条款？
  3. 模型输出（生成内容）的权属与再训练限制？

第 3 点尤其容易被忽略：有些许可禁止用该模型的输出去训练或改进其他模型。如果你的产品链路涉及"用大模型生成数据再训小模型"（蒸馏），这条款可能直接卡死你的方案。许可证要在选型阶段就读，别等上线了才发现违约。

第三条轴：部署与运维，开放权重的隐藏成本

自托管开放权重模型，省下的是 API 调用费，扛起来的是一整套基础设施。

显存与硬件：前面"算账"系列说过，70B 级模型 fp16 推理就要上百 GB 显存，需要多卡或量化。这意味着 GPU 采购/租赁、机房或云实例的固定成本。

推理服务化：把一个权重文件变成稳定的线上服务，要解决一堆工程问题：

1
2
3
4
- 批处理(continuous batching)：把并发请求动态拼批，提吞吐
- KV Cache 管理：长对话、高并发下的显存调度
- 量化：int8/int4 压显存，权衡精度损失
- 负载均衡、扩缩容、灰度、监控、故障转移

这些正是成熟推理框架（vLLM、TGI 这类）在做的事。自己搭这套，等于把"一次 API 调用"背后厂商替你做的运维全接过来。

TCO 的临界点：自托管是高固定成本、低边际成本；闭源 API 是零固定成本、高边际成本。两条成本曲线有个交叉点：

\text{自托管} = C_{\text{固定}} + c_{\text{边际}} \cdot V, \quad \text{API} = p \cdot V

VV 是调用量。VV 小时 API 划算（不用养 GPU），VV 大到一定规模、且 GPU 利用率能拉满时，自托管的边际成本优势才体现出来。低频、波动大的负载用 API；高频、稳定、可填满 GPU 的负载，自托管才可能更省。 注意"GPU 利用率"是隐藏前提——闲置的 GPU 一样烧钱，规模不够时自托管反而更贵。

第四条轴：数据、隐私与可控性

这条轴常常是压倒性的，甚至盖过成本。

数据驻留：调闭源 API，请求数据要发到厂商服务器。对医疗、金融、政企或受数据出境法规约束的场景，这本身可能不被允许。自托管开放权重可以做到数据完全不出内网。

可控性与确定性：

  • 闭源 API 的模型会被厂商静默升级，同样的 prompt 今天和下个月的输出可能变化，对需要行为稳定的生产链路是风险。开放权重模型权重在你手上，版本完全可控。
  • 自托管可以深度定制：自定义量化方案、改采样逻辑、挂 LoRA 适配器、做特殊的 KV Cache 策略。API 只给你暴露出来的几个参数。

能力天花板与时效：另一面是，闭源前沿模型往往在能力上保持领先，且无需你承担任何训练/运维。开放权重在很多任务上已经够用甚至追平，但追前沿能力时仍可能有差距。

决策框架：四象限速查

把上面四条轴压缩成可操作的判断：

你的优先级 倾向选择
数据绝对不能出内网 / 强合规 开放权重自托管
需要行为版本可控、可深度定制 开放权重自托管
负载高频稳定、GPU 能填满 开放权重自托管（成本）
要快速上线、负载低或波动大 闭源 API
追前沿能力、不想养基础设施 闭源 API
涉及蒸馏/再训练 先读许可证，再决定

现实中很多团队的答案是混合：用闭源 API 快速验证产品、跑高难度任务，同时对高频、对隐私敏感或成本敏感的环节用自托管开放权重模型兜底。两者不是非此即彼。

踩坑

1. 把"开放权重"当"完全开源"。 训练数据和流程通常不公开，你无法完全审计或复现，安全/合规评估时要意识到这点。

2. 选型只看 benchmark 不看许可证。 一个分数漂亮但 research-only 的模型，对商业产品价值为零。

3. 低估自托管的运维复杂度。 "下载权重就能跑"和"提供稳定的生产级推理服务"之间隔着批处理、量化、监控、扩缩容一整座工程。

4. 用调用量算成本时忘了 GPU 利用率。 自托管的经济性高度依赖把昂贵的 GPU 喂满；利用率低时，自托管的单位成本可能远高于 API。

5. 忽视模型静默升级的影响。 依赖闭源 API 的链路，要为模型行为漂移做回归测试和兜底设计。

小结

开源闭源的选择不是省钱与否，而是在权重控制、许可边界、部署运维、数据合规四条轴上权衡。闭源 API 的本质是"用边际成本买省心和前沿能力"，开放权重自托管的本质是"用固定成本和运维复杂度换数据主权、可控性与规模化后的成本优势"。先问清楚自己的硬约束（数据能不能出内网、能不能商用、负载有多大），答案往往自己就浮现了——而对多数成长中的团队，混合架构是最务实的解。