开源模型和闭源模型，差的是能力还是工程

开源模型和闭源模型，差的是能力还是工程

同一个问题分别抛给两款模型，一款能把权重下载到本地，一款只能通过接口调用，答案读起来差不多。有人由此下结论：开源已经追平闭源，剩下的只是习惯问题。这个判断只说对了一半。

能力确实在靠近。工程上的距离不但没缩小，反而因为「能自己改」而变得更复杂。想把这件事看明白，得把「模型本身」和「把模型用起来」拆成两件事。

两者的分界线在哪

闭源模型卖的是服务。厂商把模型放在自己的机房里，你付钱买调用次数，拿到的是文本、图像、结构化的返回结果。权重不出门，训练数据不出门，模型结构也不公开。

开源模型卖的是文件。权重可以下载，结构公开，许可证写明能商用还是不能商用。下载完放在自己的服务器上，断网也能跑。

这条线的位置决定了很多后续问题。你要改一个回答风格，闭源那边只能靠提示词去劝，劝不动就没办法；开源这边可以直接动微调，改完就是新的模型。反过来，闭源那边的模型每隔几个月升级一次，你不用做任何事；开源这边升级要靠自己重新部署、重新测、重新调。

能力差距还剩多少

日常问答层面已经很难区分

写通知、改措辞、总结会议记录、把一段话翻译成英文，头部开源模型和主流闭源模型的表现拉不开身位。拿二十条真实工作指令去跑，两边各有胜负，胜负点更多落在语气偏好上，而不是对错。

这类任务对模型的要求集中在语言流畅和常识覆盖，训练数据的规模早就够用。差距被抹平是自然结果。

专业领域仍然有梯度

涉及法律条文交叉引用、医疗指南细节、复杂财务口径的任务，闭源头部的模型答得更稳。原因不在参数量，在数据配比和后训练投入。厂商愿意为一个垂直领域养一支标注团队，开源社区没有这个组织能力。

我们在实际接触中见过一个典型场景：让模型判断一份采购合同里的违约责任条款是否对等。闭源模型会指出具体条款编号并说明不对等的方向；开源模型给出的是「建议咨询专业律师」这类安全但无用的回答。这种差别不是调提示词能补上的。

长尾能力差得更远

多语言小语种、罕见的代码框架、冷门行业的术语，开源模型的覆盖面窄。它在这类问题上不是答错，是答得空。你问一个东南亚小语种的语法细节，它给出一段听起来合理的泛泛之谈。

真正拉开距离的是工程

推理成本要自己算

闭源按 token 计费，用多少付多少，没有前期投入。开源看起来免费，实际上要买卡、租机房、付电费、养人。一张能跑中等规模模型的显卡，采购价就够买几年的接口调用。

量大才划算。每天几十万次调用，自建的成本曲线会压过按次付费；每天几百次调用，自建纯属折腾。这个拐点跟模型大小、并发要求、响应时延都有关系，没有统一答案，只能按自己的量去算。

私有数据落地是开源的强项

有些行业的数据不能出内网。病历、客户名单、未公开的工艺参数、正在申请的专利文本，这些内容贴到外部接口上，合规上过不去。开源模型部署在内网，数据不出机房，这条限制就解开了。

这也是很多制造企业选开源的唯一理由。不是因为便宜，是因为没得选。

版本可控与不可控

闭源模型的版本由厂商决定。今天用的接口，下个季度可能换了一版行为，回答风格变了，某些边界被收紧了，你的产品表现跟着波动。厂商一般会给过渡期，但节奏不在你手上。

开源模型下载到本地之后，行为固定。这对需要长期稳定输出的系统很要紧，比如批量生成产品描述、自动归档工单分类。你不希望某天早上发现分类规则全变了。

代价是安全补丁和新能力都得自己跟进。社区出了新版本，你要评估、要测、要灰度，这套工作量不小。

运维是隐形成本

接口调用出问题，找厂商提工单。自建出问题，找谁？显存不够、并发上不去、批次调度卡住、驱动版本冲突，这些都要有人能接。没有懂行的工程师，开源模型的稳定性会明显低于接口服务。

时延也要自己盯。同一个模型在两张不同型号的卡上跑，首字返回时间能差出两三倍。上线之前不测，用户端就会抱怨慢。测的方法不复杂，拿真实请求压一轮，记录首字时间、完整回答时间、并发到多少开始排队。

还有一个绕不开的活是模型更新。社区每隔一阵会放出改进版，参数更大或者训练更细。换不换？换了要重测全部场景，不换会落后。很多团队干脆半年评估一次，集中做这件事，平时不动。

什么情况该选开源

数据不能出内网，这条是硬门槛，其它因素都要往后排。

调用量足够大，大到自建三五年能回本。这时候要把人力成本算进去，不能只算卡钱。

需要深度定制。比如要把企业自己的术语体系灌进去，要让输出严格符合内部模板，要在模型层面做内容过滤。这些在闭源接口上做不到，或者只能做到七成。

需要离线环境。工厂车间、野外作业、涉密场地，网络不通的地方只能用本地模型。

什么情况闭源更省事

团队里没有能维护推理服务的人。这一条足以否掉开源方案，模型跑不起来，一切都是空谈。

需求在快速变化。今天要做客服摘要，下个月要做合同审查，再下个月要接图像识别。闭源平台上换个接口就行，自建要重新选模型、重新部署。

对回答质量的要求高于对成本的要求。面向客户的场景，答错一次的损失可能超过全年省下的调用费。

用量小而不稳定。有活动时几千次，平时几十次，自建的固定成本摊不平。

许可证这一关很多人没看

开源不等于随便用。不同许可证对商用的态度差别很大，有的允许商用但要保留声明，有的限制月活用户规模，有的允许改但不许拿去做竞争性服务。

企业把自己的产品打包卖给客户时，模型许可证里的条款会连带影响产品的合规性。有些许可证要求下游用户也能拿到同样的权利，这一条在闭源商业产品里过不去。签合同前把许可证读一遍，比事后补救便宜得多。

还有一层是「开源」的成 {MOD}。权重开放但训练数据不开放，叫开放权重；权重和训练代码都开放，才接近完整开源。多数所谓的开源模型属于前者。这不影响部署，但影响你能不能自己从头复现一遍。

一个常见误判

把「模型能力」当成唯一变量，忽略了配套。开源模型的效果，七成取决于外围做了什么：检索库建得好不好、提示词模板设计得对不对、后处理规则严不严。同一款开源模型，两个人部署出来的效果可以差一倍。

闭源模型的效果也有波动，但波动来自厂商，你只能适应。开源模型的效果波动来自自己，好处是能改，坏处是要认。

实际选型时更靠谱的做法是先定约束，再看能力。约束包括数据能不能出门、有没有人维护、预算是按年付还是一次性付、版本要不要锁死。约束定完，可选项通常只剩一两个，能力对比才有意义。

还有一层容易被忽略：开源和闭源不是二选一。很多团队的做法是把重活交给闭源接口，把批量、重复、涉密的活交给本地开源模型，两边分工。这个组合的前提是有人能把两套都跑顺，否则维护两套的成本会吃掉省下的钱。

回到最初那个问题。能力上的差距在收窄，工程上的差距在分化。选哪个，取决于你手上有什么人、数据能不能出门、量有多大，而不是取决于榜单上差几分。