你多半是在这么个节点卡住的：团队要上一个 AI 功能，同事说「直接调 API 最快」，另一个人说「模型权重得攥在自己手里」。两边都不算错，但判断依据不在谁更先进，而在你后面要付什么代价。这篇不评谁强谁弱，只把开源与闭源在几个关键维度上的分叉点摆出来，让你对着自己的场景挑。
你多半是在这么个节点卡住的：团队要上一个 AI 功能，同事说「直接调接口最快」，另一个人说「模型权重得攥在自己手里」。两边都不算错，但判断依据不是谁更先进，而是你后面要付什么代价。这篇只把开源与闭源在几个关键维度上的分叉点摆出来，让你对着自己的场景挑。
先定个基调：开源和闭源不是高低之分，是两种责任分配方式。闭源是把模型那部分责任外包出去，开源是把这部分责任收回来自己扛。谁更划算，取决于你团队有没有能力扛、以及业务允不允许把数据交出去。
先把「开源」这个词拆开看：开放的是哪一层
很多人一说开源就默认「什么都能改」，其实开放是分层的。权重能下、代码能看、训练数据公开、许可证宽松，这是四件独立的事，市面上大量模型只开放其中一两层，却统称开源。选型时把这几层分开问，能省掉后面很多返工。
- 权重开放
- 能下载到参数文件，可自行部署推理，但能不能微调、能不能商用是另一回事
- 代码开放
- 训练或推理代码可见，方便复现和改造，但通常不含数据
- 数据开放
- 训练语料可查，对合规评估最有价值，也最稀少
- 许可证开放
- 条款允许你做什么，商用边界、分发限制、署名要求都写在这里，必须逐条读
- 拿到一个模型名，先问三件事：权重要得到吗、许可证允许我做什么、出问题我能拿到什么级别的支持
- 权重能下载不等于能随便用，商用和再分发限制一定要单独确认
- 闭源那一侧的「不可见」也不只指权重，接口背后的版本策略、限流规则同样可能变
- 把这几条写进选型文档里，后面没人会记得当初为什么选它
可控性与总成本：两条完全不同的账
可控性具体体现在三个地方：能不能改（微调、蒸馏、改推理链路）、能不能锁版本、出故障时能不能自己排查。闭源方案这三项基本都在对方手里，好处是你省了事，代价是遇到问题只能等。开源反过来，主动权在你，但每一次改动都要自己验证。
成本别只看调用单价，那是最容易看错的一栏。完整的账至少四块：调用费、算力或机器费、人力维护费、以及将来换供应商时的迁移费。不同阶段这四块的占比差别很大，先判断哪块在你这里最重，再谈选谁。
| 维度 | 开源侧要自己承担 | 闭源侧通常由服务方承担 |
|---|---|---|
| 模型改动 | 微调、量化、蒸馏都要自己做 | 一般只能通过提示词和参数间接影响 |
| 版本稳定 | 你不升级就不会变，但要自己维护 | 升级节奏对方定，行为可能悄悄变化 |
| 故障排查 | 日志、显存、推理链路全在自己手里 | 多数情况下只能提工单等回复 |
| 扩容峰值 | 提前备机器，闲置也是成本 | 按量走，峰值贵但不用养机器 |
| 迁移成本 | 换模型只改适配层，相对可控 | 换供应商要重测提示词和输出格式 |
这里要提醒一句：自建不是把单价乘一遍就完事。运维值班、显存闲置、峰值扩容这些隐性开销经常被漏掉，一家 5 人小团队如果没有专职的人盯，长期维护成本很容易超过省下来的调用费。
数据、合规与隐私：分界线常常在这一栏画出
在不少行业里，数据能不能出内网、能不能被留存、日志归谁，比模型效果更早决定选型。处理个人信息或客户数据的场景尤其如此。这条线一旦画死，后面讨论模型强弱的意义就不大了。
- 闭源方案要问清三件事：数据是否用于训练、保留多久、有没有区域化部署选项
- 开源方案里数据安全责任全在自己，内网隔离、日志脱敏、访问审计都得自己搭
- 敏感行业的常见做法是混合：核心数据走本地或私有部署，非敏感环节调公开接口
- 判断标准是：如果这条业务线一旦数据外流就没法交代，那先做私有部署可行性评估，再谈效果
什么情况下这条线可以放宽？如果处理的是公开信息、或者业务本身就不介意数据被用于改进服务，那闭源接口的便利性可以直接吃掉。关键是把「不介意」写成明确结论，而不是默认略过。
迭代节奏与锁定风险：三到五年后你还想换吗
闭源模型的升级由别人决定。好处是能力提升你白拿，坏处是行为可能悄悄变，任何依赖提示词细节的功能上线后都要定期回归测试，不能一次调通就不管。开源模型的升级由你自己决定，但版本维护、安全补丁、依赖升级都需要有专人负责。
避免被锁定的实用做法，是把提示词、评测用例、调用层抽象成自己的一层。换模型时只改适配层，业务代码不动。这一层投入不大，但能把将来的迁移从「重写」降级成「替换」。
落地清单：按顺序问自己这几个问题
- 第一问：数据能不能出去列出这个功能会碰到的数据类型，标出哪些属于不能外流。只要有一条不能出去，就先按私有部署方向评估。验证方式：让法务或安全同事签字确认，而不是自己拍板。
- 第二问：调用量是否稳定可预测看过去几个月的量级和波动范围。如果长期稳定且规模可观，自建的固定成本能被摊薄；如果波动大或还在验证期，接口的弹性更划算。验证方式：到站内 /price-watch 核对当时的计费口径再算账。
- 第三问：团队有没有人能扛运维自建意味着有人要负责部署、监控、扩容、打补丁。确认有具体的人而不是「大家轮流」。验证方式：写一句值班安排，找不到人就说明还扛不住。
- 第四问：效果差距能不能接受用自己业务里的真实任务做一组评测用例，而不是看通用榜单。验证方式：先在站内 /models 把候选模型的能力与限制对一遍，再到 /benchmarks 看评测口径，别凭印象选。
前两问的答案偏「不能出去 + 稳定量大」，就往自建方向估算；偏「可以出去 + 波动大」，先把接口调通跑起来，过一段时间再回头看这笔账。两条路都不冲突，很多团队最后走的是混合方案。
下一步把候选模型和当时的调用成本放到同一张表里对比，比凭记忆争论快得多→常见问题
开源模型是不是效果一定比闭源差？
不一定，差距在不同任务上差别很大，而且闭源模型之间也不齐平。更靠谱的做法是用你自己的任务做小样本对照，而不是看通用榜单的高低。注意有些闭源模型背后其实就是开源权重加托管服务，这种情况下「开源 vs 闭源」的差别主要在服务层而不是模型本身。
预算有限的小团队应该先走哪条路？
通常先调接口，把功能跑通、把需求和用量摸清楚，再决定要不要转自建。原因是自建的固定成本里有一大块是人力和机器闲置，需求没定型之前很容易白花。等调用量稳定、成本曲线明显偏向自建时再迁，迁移成本也比想象中低，前提是你提前把调用层做过抽象。
选型时最容易被忽略的坑是什么？
一是许可证，权重能下载不等于能商用，条款要逐条读；二是版本漂移，闭源接口升级后老提示词可能失效，要留回归测试；三是退出成本，进场时没想好怎么换，后面就被绑住了。这三件事和模型效果没关系，但出问题时往往最难补。
