闭源模型和开源模型区别

第一次给项目选模型的人常卡在同一个地方：榜上排在前面的是闭源模型，群里推荐的又是开源权重，两边都说自己好，但没人告诉你该比什么。这篇不讲谁更强，只讲两条路在花钱方式、能改多少、出事谁负责这三件事上的分界，并给一套按顺序自查的方法，让你在自己的场景里得出结论。

第一次给项目选模型的人，卡点几乎都一样：榜上排前面的是闭源模型，群里有人推开源权重，两边都说自己划算。但没人告诉你到底该比什么。这篇不讲谁更强，只讲两条路在花钱方式、能改多少、出事谁负责这三件事上的分界，最后给一套按顺序自查的方法，让你在自己场景里得出结论。

先记住一个态度：闭源和开源不是信仰问题，是采购问题。你要问的不是「哪个好」，而是「我这个量、这个数据敏感度、这个团队人力，哪条路更省事」。下面每一节都给判断标准和能动手的动作，看到某一节觉得不适用，直接跳过，别硬套。

先把词说准：闭源和开源到底差在哪一层

日常说的「开源模型」，严格讲多数是「开放权重」：权重文件能下载，但训练数据、训练代码、数据配方未必给。这个区别很关键，因为它直接决定你能改到什么程度。下载到权重不等于你可以随便用、随便卖，真正的约束在许可证里。

闭源

权重不公开，只能通过官方接口或授权的云厂商调用，行为由厂商控制

开放权重

权重可下载、可本地部署，但训练数据与训练代码未必一起给

许可证

决定你能不能商用、能不能改、改了要不要按同样条款开源

选型时别停在「开源还是闭源」这种二分上。同一家厂商可能既卖接口又放权重，同一个模型也可能有多个许可证版本。你要问的是：我这次拿到的到底是接口调用权、权重使用权，还是两者都有？条款细节到 /open-weight-license-basics 逐条对照，别靠转述。

成本结构完全不同：一个是按量付，一个是先付后省

闭源的钱跟着用量走：单价、缓存折扣、批处理折扣、限流档位，每一样都会影响你的月账单。开源的钱主要花在卡、电、机房和运维人力上，跟你调多少次关系不大。这两条线不是谁便宜，而是形状不一样。

1. 第一步：估自己的量把现在和未来一年的日调用量、平均输入输出长度列出来，别拍脑袋，翻日志。
2. 第二步：两边各算一次闭源侧到 /official-api 看计费口径，再到 /tools/model-cost-calculator 按你的量代入；自建侧看 /compute/tco 的算法，把卡、电、人力都填进去。
3. 第三步：找交叉点两条成本线交叉的位置就是分水岭，交叉点以下的量，折腾自建通常不划算。
4. 第四步：核对当时的数字单价和规格会变，结论只对当时有效，回头到 /price-watch 看有没有调价。

提醒一句：别只看单价。闭源要看限流档位和失败重试怎么计费，开源要看闲置卡的浪费和运维排班。把这些都填进上面两步，算出来的数才有意义。

可控性差异：你能改到哪一步

闭源能调的通常只有提示词、少量参数和有限的微调接口，模型本身的行为由厂商决定，升级和下线可能不提前通知。开源你可以换量化档位、换推理框架、做 LoRA 微调、塞进内网，但代价是这些活全变成你自己的。

• 需要长期稳定输出、可回归测试：开源更容易锁版本，把权重冻结住
• 需要频繁换量化、调推理性能：开源给你空间，闭源只能提工单
• 需要跟着最强能力走、不想维护：闭源更省事，升级由厂商推
• 团队没有运维人力：自建的隐性成本会迅速超过预期

判断标准可以简化成一句：你的需求里「不能变」的部分多，还是「要跟上」的部分多。前者倾向开源，后者倾向闭源。但注意，锁版本也有代价，你会错过能力更新，把这一点写进决策记录里。

合规与数据流向：谁在替你承担责任

闭源意味着数据要出你的边界。是否留存、留存多久、用于不用于训练，取决于厂商条款和部署形态，逐条读，别信口头描述。开源把数据留在自己机器上，但数据来源合法性、模型输出的责任，转回到你自己这边，出了事没有厂商兜底。

涉及行业监管时，除了模型本身，还要看日志、审计、可解释性这些要求。术语和口径先对齐，到 /safety 和 /ai-dict/category/safety 把概念查清楚，再和法务过条款，不要拿技术文档当合规依据。

能力差距怎么判断，别只看排名

榜单分数和你的任务不是一回事。有人用榜单第一的模型做结构化抽取，效果反而不如排名靠后的，因为题型不同。先看 /ai-benchmark-ranking-reading 和 /benchmarks 学会怎么读榜，再挑跟你任务同类的题目做小样本对比。

1. 收集真实输入从自己的业务里挑一批有代表性的真实请求，覆盖常见和边界情况，别用公开样例。
2. 两边同题各跑一遍同批输入分别走闭源接口和自建开源，用同样的提示词和参数，减少干扰变量。
3. 记录四个数可用率、返工次数、人工兜底比例、平均处理时长，这四个比跑分有用。
4. 写成带条件的结论结论要写清「什么任务、什么时间、哪两个型号比出来的」，到 /models 核对当时的规格。

如果团队没有精力长期维护评测集，至少要保住最小版本：一个固定输入文件加一个打分表，换模型时重跑一次，成本很低但能避免拍脑袋。

一套按顺序走的选型路径

别一上来就比能力，顺序错了会白忙。先过硬约束，再算账，最后才比效果。下面四步按优先级排，前面一步过不了就别往后走。

1. 第一步：数据能不能出去不能出边界，直接走开源或私有化部署；只有存在合规托管方案时，闭源才进入候选。这一步不通过，后面都不用算。
2. 第二步：估算用量与增长按现在的日调用量和未来一年的增长，到 /tools/model-cost-calculator 和 /compute/tco 各算一遍，看两条成本线在哪里交叉。
3. 第三步：问改不改需要频繁微调、换量化、锁版本，倾向开源；只需要一个稳定接口，倾向闭源。把不能变的需求列成清单。
4. 第四步：小规模并行两边各跑两周真实业务，比可用率和人工介入成本，再定主次。别一次全切，留回退路径。

如果第四步的结果和预期相反，不要慌，大概率是评测集没代表性。回到能力差距那一节，补一批边界输入再跑一次，比直接换方向更省时间。

这些判断在什么情况下不成立

上面那套路径默认你有一定调用量和选择空间。下面几种情况，硬套反而浪费时间，直接按例外处理会更快。

• 调用量极小、只是做验证或内部小工具：算账没意义，用现成接口最快，别折腾自建
• 被生态绑定：如果整套工具链只支持某家的接口或格式，换路的迁移成本可能远超模型差价
• 强时效任务：等你能把开源模型调好，业务窗口可能已经过了，闭源的速度优势是真实价值
• 只是个人试验或学习：结论对团队选型没有参考价值，别把个人体验当采购依据

还有一个常被忽略的例外：如果业务本身随时可能被砍掉，投入自建的人力沉没成本会很难看。这种情况下按量付费的闭源接口反而是更理性的选择，哪怕单价看起来不便宜。

下单前照着勾一遍的清单

最后把决策前要确认的事压成一张清单。每一项都能在站内找到对应材料，别凭印象打勾，逐条落实再签字。

选型不是挑最强的模型，是挑最不给你添麻烦的那条路。