开源模型和闭源模型的区别

你可能刚接完一个闭源接口，跑得挺顺，但老板问了一句「这模型能不能自己部署、数据出不出得去」，你就卡住了。或者反过来，同事推了个能下载权重的模型，你不知道它和官方 API 那套到底差在哪。这篇不评谁强谁弱，只把「开源」和「闭源」这条线怎么划、各自换来什么代价讲明白，最后给一张按场景对照的表。

老板那句「能不能自己部署、数据出不出得去」，其实问的是两件事：权重在谁手里，请求经过谁的服务器。这两件事决定了你后面所有的取舍，跟模型谁更聪明关系不大。刚接大模型的开发者最容易犯的错，是先比效果再想边界，结果原型跑通了才被合规一票否决，返工重来。

这篇不评谁强谁弱，只把「开源」和「闭源」这条线怎么划、各自换来什么代价讲清楚。看完你至少能回答三个问题：这个模型我拿到的是资产还是调用权、我的数据能不能出去、出问题的时候谁能兜底。最后给一张按场景对照的表和一份切换核对清单。

先分清：开源到底开的是什么

很多人把「能下载权重」直接等同于「开源」，这两件事差得远。拿到权重之后你能做的通常是本地推理和微调，但模型怎么训出来的、用什么数据、训练脚本长什么样，多数情况下你看不到。分不清这一点，后面谈商用、谈复现都是空中楼阁。

权重

模型参数文件，拿到它你能推理、能微调，但改不了网络结构本身

推理代码

跑起来需要的加载和前向逻辑，通常一起放出，但版本要和权重对得上

训练数据

决定模型偏好的原材料，绝大多数所谓开源模型不给，这直接影响你能不能复现

训练脚本

从数据到权重的完整流程，给得越全越接近「真开源」，但成本极高、放出的很少

另一头，闭源模型给你的是接口和服务承诺，你拿到的是调用权而不是资产。这意味着换厂商时，提示词、输出格式、计费口径、甚至部分业务逻辑都可能要重写，这笔迁移成本要在选型阶段就估进去，而不是等涨价或降速了才想起来。

• 只看权重能不能下，不看许可证条款，是新手最常见的误判
• 许可证决定了你能不能商用、能不能改名分发、能不能拿去做蒸馏
• 术语解释和分类到 /ai-dict/category/basics 与 /ai-dict 里逐条查，别凭印象理解
• 闭源侧要重点看服务条款里关于数据使用和日志保留的表述

控制权的分界线：数据、版本、停机谁说了算

数据流向是第一道分界，也是最硬的一道。闭源 API 的请求内容必然经过对方服务器，涉及个人信息、合同、病历这类数据时，先过内部合规再谈技术选型，顺序反了会白做。开源自部署则把数据留在你自己的网络里，但这也意味着安全责任跟着一起搬回来了。

判断口诀可以记一下：数据敏感度高、要求版本可复现，倾向自持权重；只是做原型验证、要求尽快上线，闭源接口省事。这条口诀在「团队没有运维能力」时会失效，因为自部署的可用性直接等于你的运维水平，人不到位，自持权重反而是负担。

成本结构不一样，别拿单价直接比

闭源是纯按量或订阅支出，随调用量线性上涨，前期几乎零投入；开源是固定成本加变动成本，机器或租卡、电费带宽、运维人力都要算。把两者简化成「每百万 token 谁便宜」是对比错位，因为一边是账单价，一边是账单加人。

• 调用量小的时候闭源一定更省，这是结构决定的，不是价格问题
• 量大到某个拐点后自部署的边际成本优势才出来，拐点位置随模型大小和卡价剧烈变化
• 别忘隐性成本：部署、量化、显存、并发调优都要人盯，很多团队这块比机器费还贵
• 算拐点的方法是自己代入当期单价建模，不要抄别人的结论

具体数字变化很快，当前各家的按量单价、租卡行情和显存估算口径，到 /inference 和 /compute/gpu-rental 看当时的价格，卡数估算参考 /compute/sizing。用 /tools/model-cost-calculator 把两种方案按月调用量各算一遍，看拐点落在哪个月。

能力差距在哪几个维度上最明显

通用对话和常识问答上，两者的差距在缩小，但具体差多少要看当期数据，别只看某个榜单第一名就下结论。长尾能力才是分水岭：小语种、特定行业术语、复杂工具调用，这些往往是闭源头部模型的优势区，开源侧要靠微调或外挂检索补上。

榜单是参考不是结论，题目饱和、任务不匹配都会让排名失真。多模态和超长上下文这两个方向的成熟度差异，一般比纯文本更大，涉及图像、语音时先去 /benchmarks 和 /crowd-radar 对照当期的实测，读榜方法参考 benchmark-reading-guide 那篇。

合规与许可证：真正会卡住项目的地方

许可证是第一道闸门。有的允许商用，有的按用户规模设门槛，有的要求署名或对衍生作品提开放要求，逐条读完再决定，不要只看 README 里「可商用」三个字。这三个字和完整条款之间的差距，是很多项目上线前才发现的雷。

1. 读许可证原文确认商用、分发、衍生、署名四类要求，把限制条件摘成一条条中文，交给法务复核
2. 查权重出处训练语料授权、是否涉及第三方数据，这些问题采购和法务一定会问，提前准备答案
3. 核对服务条款闭源侧重点看数据使用声明、日志保留期限、地区可用性，跨境业务尤其要确认
4. 留一份书面结论把「能不能用、怎么用、谁批的」写成文档存档，人员变动时不至于重新吵一遍

许可证与商用边界的系统梳理，站内已有 open-weight-license-basics 专门讲，这篇不重复。这里只强调一点：合规结论是选型的前置条件，不是上线前的收尾工作，顺序摆错了返工代价很大。

按场景对照：什么情况选哪边

把前面的维度收成一张场景表，遇到具体项目时对着找最接近的一行。注意表里给的是默认倾向，不是硬规则，资源约束和合规要求优先级更高时，可以推翻。

还有一种常见情况是混合：核心敏感链路自部署，边缘功能走闭源接口。这种做法能用，但要求你把两条链路的数据边界画清楚，否则敏感数据会顺着边缘功能漏出去。画完边界再动手接。

真要切换时的核对清单

切换模型本质上是一次小型重构，不是换个 base_url 就完事。提示词、输出格式、计费口径、失败重试逻辑都可能要跟着改。下面这份顺序是按踩坑概率排的，建议照做。

1. 盘点提示词与格式依赖把现有提示词和输出解析逻辑列成清单，逐条在新模型上重跑，别只看几个样例就宣布迁移完成
2. 重算成本口径新方案的分词方式和上下文计费口径不同，用 /tools/model-cost-calculator 按真实调用量重算一遍
3. 准备回退路径保留旧接口一段时间双跑，提前设定效果或延迟不达标的回退触发条件
4. 先定标准再测评测标准写下来再跑，否则很容易变成「感觉这个更聪明」的口水仗，结论无法复用

几个容易踩的想当然

最后清几个常见误解，它们大多来自把技术属性和商业条件混在一起谈。选型时先把这些想当然排掉，剩下的判断会清晰很多。

• 「开源就是免费」不成立：机器、带宽、人力都是钱，许可证可能还有商用门槛
• 「闭源就一定更安全」也不成立：安全取决于数据流向和对方运维水平，不是开放程度
• 「本地跑就一定更私密」要看有没有外发遥测和插件联网行为，部署完断网压测一次
• 「开源模型小所以弱」是过去式，规模和效果的对应关系要看当期实测，别用老印象选型

每一条都不是绝对反面，而是提醒你去看条件。比如本地跑是否私密，取决于断网之后它还能不能正常工作；如果断网就崩，说明它依赖了外部服务，私密性就要打问号。压测方法是把网络断开跑一轮完整业务流程，看有没有功能失效。

开源和闭源不是强弱之分，是你换来换去的那几样东西：控制权、成本结构、合规责任和迁移成本。