开源与闭源怎么选
闭源 API（GPT、Claude、Gemini）能力上限高、零运维、按量付费；开放权重（Qwen、Llama、DeepSeek 等）可私有化、可微调、成本自主但硬件与运维要自担。选型不是二选一的信念问题，而是四个变量的组合：数据合规要求、任务难度分布、调用量级、团队运维能力。多数落地场景最终会走向混合架构。
核心维度对照
| 维度 | 闭源 API | 自托管开放权重 |
|---|---|---|
| 能力上限 | 通常最高，迭代快 | 差距在缩小，旗舰级需要大显存 |
| 数据流向 | 出域，依赖厂商条款 | 留在内网，可审计 |
| 成本形态 | 按 token 付费，随用量弹性 | 硬件折旧与运维人力，固定投入 |
| 定制深度 | 以厂商开放的微调能力为限 | 权重可改、可量化、可蒸馏 |
| 运维负担 | 无 | 部署、扩容、监控、升级自担 |
| 版本控制 | 厂商迭代，行为可能漂移 | 权重固定，行为可复现 |
必须自托管的信号
- 数据不能出内网：涉及个人信息、机密文档或行业监管要求
- 调用量极大且任务稳定：固定成本摊薄后总支出低于按量付费
- 需要深度定制：要微调、要改权重、要做蒸馏或剪枝
- 要求行为可复现：版本锁定是硬性验收条件
优先用闭源 API 的信号
- 任务难度跨度大：需要旗舰模型的能力上限兜底
- 调用量小或波动大：按量付费比养机器划算
- 团队没有 GPU 运维能力：把部署与扩容交给厂商
- 要快速验证：先用 API 跑通业务价值，再谈替代方案
总拥有成本的构成
| 成本项 | 闭源 API | 自托管 |
|---|---|---|
| 硬件 | 无 | GPU 采购或租赁，折旧周期内分摊 |
| 运维人力 | 无 | 部署、监控、故障处理与升级 |
| 用量费用 | 按 token 线性增长 | 电费与机房成本 |
| 隐性成本 | 数据出域的合规评估 | 版本落后、效果差距带来的返工 |
混合架构的路由思路
混合架构的路由思路
# 网关层统一 OpenAI 协议，业务代码不感知供应商差异
if 命中敏感数据标签: return 本地模型(...) # 数据不出内网
elif 任务难度高: return 闭源旗舰(...) # 质量优先，占比要低
else: return 小模型(...) # 高频任务压低成本
# 兜底：本地模型返回低置信度或失败时，升级到闭源模型重试一次先算真实成本再决策：把调用量、平均 token 长度与并发峰值代入，加上运维人力折算，才看得出自托管何时回本。
一次性全量自建风险高：模型迭代快，刚建好的集群可能很快落后于新版本，建议先用小规模验证并保留 API 兜底。