
1. 先别急着站队这个标题到底在问什么“开源大模型正在‘杀死’闭源”——这个标题第一次出现在我时间线上的时候我的第一反应不是兴奋而是警惕。因为“杀死”这个词太重了重到它天然带着一种非此即彼的叙事陷阱。作为一个从2022年底就开始折腾各类大模型部署、微调和应用落地的人我见过太多“XX已死”的标题最后都被现实打了脸。所以这篇文章我不打算给你一个简单的“是”或“否”而是想把这个问题拆开看看它背后真正值得讨论的东西是什么。先说结论性的判断开源大模型没有在“杀死”闭源但它正在以一种非常具体、非常残酷的方式重新定义闭源模型必须提供的价值。换句话说开源模型不是在消灭闭源而是在逼着闭源回答一个它过去可以含糊其辞的问题——“你到底贵在哪里”这个问题对做技术选型的人来说太重要了。如果你是一个创业公司的技术负责人或者是一个在企业内部推动AI落地的工程师你每天面对的就是“用哪个模型”的决策。过去这个决策相对简单闭源API能力强、开箱即用开源模型能力差一截但便宜可控。但现在这个天平正在剧烈晃动晃到很多人不知道该往哪边站。我写这篇东西的目标很明确帮你建立一个判断框架让你在面对“开源还是闭源”这个问题时不再被标题党牵着走而是能根据自己的实际场景做出有依据的选择。不管你是刚入门想了解大模型生态的新手还是已经在做模型选型的老手我都尽量把话说透、把账算清。2. 开源模型这三年到底追到了什么程度2.1 从“能跑就行”到“真的能用”的分水岭我记得2023年初第一次在本地跑起来一个开源对话模型的时候那种感觉是“哇居然真的能对话”。但紧接着就是失望——问它稍微复杂一点的问题回答就开始胡言乱语逻辑断裂事实错误率高得离谱。那时候开源模型和闭源头部模型的差距用“代差”来形容一点不夸张保守估计在12到18个月。但这个差距的收敛速度超出了绝大多数人的预期。到2024年第一梯队的开源模型在通用对话、代码生成、基础推理这些维度上已经能摸到闭源中端模型的水平。而到2025年部分开源模型在特定基准上的表现已经和闭源旗舰模型互有胜负。注意我说的是“特定基准”和“互有胜负”这两个限定词很重要后面我会展开说为什么。这个追赶过程不是线性的。它经历了几个关键转折一是训练方法的公开化很多闭源团队引以为傲的训练技巧被开源社区快速复现和改进二是数据质量的提升开源社区在数据清洗和配比上积累了越来越多的经验三是算力门槛的下降随着训练效率的优化用更少的卡训练出可用模型成为可能。2.2 基准分数好看不等于生产环境好用这里我要泼一盆冷水。很多人在讨论开源和闭源的时候喜欢拿基准分数说事——“你看这个开源模型在MMLU上只差闭源旗舰3分”。但如果你真的在生产环境部署过模型你就知道这3分在真实场景里的体感差距可能是天壤之别。我举个具体的例子。我曾经在一个客服问答场景里同时测试过某开源模型和某闭源模型。在标准测试集上两者的准确率差距不到5个百分点。但上线之后用户的实际提问方式千奇百怪有错别字、有口语化表达、有隐含上下文的多轮追问。在这些“非标准”输入上闭源模型的鲁棒性明显更好它更擅长“猜”用户到底想问什么。而开源模型在遇到训练分布之外的输入时更容易给出看似合理但实际错误的回答。这就是基准分数和生产可用性之间的鸿沟。基准测试是标准化的、干净的、有明确答案的但真实世界是混乱的、模糊的、充满歧义的。闭源模型背后往往有更大的数据飞轮和更多的真实用户反馈来打磨这些“脏活累活”而开源模型在这方面天然吃亏。提示评估一个模型能不能用在你的场景里千万不要只看基准分数。自己构造50到100条真实业务场景的测试用例人工评估输出质量这个工作量不大但能帮你避开最大的坑。2.3 开源模型的“能力上限”和“能力下限”理解开源模型当前的水平我建议用“上限”和“下限”两个维度来看。能力上限指的是这个模型在最优条件下能达到的最好表现。在这方面第一梯队的开源模型确实已经非常接近闭源旗舰了。如果你愿意花时间做提示工程、做少样本示例、甚至做微调开源模型能给你交出相当漂亮的答卷。能力下限指的是这个模型在“你什么都不做”的情况下的默认表现。这方面开源模型和闭源旗舰的差距依然明显。闭源模型往往在出厂时就经过了大量的对齐调优你随便扔一个问题过去它大概率能给你一个及格线以上的回答。而开源模型如果你不做任何配置和调优它的默认输出可能相当不稳定。这个区别对不同类型的用户意义完全不同。如果你是一个有技术能力、愿意投入精力做优化的团队开源模型的上限足够高你能通过自己的努力把下限也拉起来。但如果你是一个希望“开箱即用”的团队闭源模型在省心程度上依然有明显优势。3. 闭源模型真正在卖的是什么3.1 不只是模型权重而是一整套服务很多人把“闭源”等同于“只是不给你模型权重”这个理解太窄了。闭源模型厂商卖的从来不只是推理能力而是一整套围绕模型构建的服务体系。首先是稳定性保障。你自己部署开源模型遇到流量高峰要扩容遇到硬件故障要容灾遇到模型输出异常要排查。这些事在闭源API那里都是厂商帮你扛的。你付的钱里有相当一部分是在买“不用操心”。其次是持续迭代。闭源模型厂商会持续更新模型版本修复已知问题提升能力边界。你不需要做任何事模型就在变好。而开源模型你拿到手是什么样基本就靠社区后续的维护了这个维护的及时性和质量是不确定的。第三是合规和安全。企业级应用对内容安全、数据隐私、合规审计有硬性要求。闭源厂商在这方面投入了大量资源做内容过滤、数据隔离、审计日志。你自己用开源模型搭一套同等水平的合规体系成本可能比省下来的API费用还高。3.2 那些“看不见”的工程成本我见过太多团队在算账的时候只算API调用费用和GPU租用费用的差价然后得出“开源便宜多了”的结论。但实际落地之后发现省下来的钱被各种隐性成本吃掉了。最典型的是推理优化成本。开源模型你拿到手默认的推理效率往往不高。要做量化、要做批处理优化、要做KV缓存管理、要做投机解码这些都需要专门的工程投入。一个成熟的推理优化工程师年薪不低而且不好招。然后是运维成本。模型服务的监控、告警、日志、灰度发布、AB测试这些基础设施你都要自己搭。闭源API把这些都封装好了你只需要调接口。自己搭一套同等水平的体系从零开始至少需要几个月的时间。还有模型更新的适配成本。开源模型社区更新频繁但每次更新你都要重新做评估、重新做微调、重新做上线验证。这个循环的成本在长期来看相当可观。3.3 闭源厂商的护城河正在被侵蚀但没有干涸公平地说闭源厂商的护城河确实在变窄。开源模型在能力上的追赶让“只有闭源才能做到”的领域越来越小。但护城河没有干涸它只是从“模型能力”转移到了“服务能力”和“生态能力”。我观察到的一个趋势是头部的闭源厂商正在从“卖模型”转向“卖平台”。它们提供的不再只是一个API而是包括模型微调、知识库管理、Agent编排、评估工具在内的一整套开发平台。这个转向很聪明因为平台的价值不在于单个模型有多强而在于它能帮用户多快地构建和迭代应用。对于开源阵营来说这个转向既是压力也是机会。压力在于如果闭源平台真的能把开发效率提升到某个临界点很多团队可能就不愿意自己折腾开源方案了。机会在于开源社区同样可以构建平台层的东西而且开源平台在灵活性和可定制性上有天然优势。4. 成本这笔账到底该怎么算4.1 一个真实的成本对比框架聊了这么多定性分析我们来点定量的。下面这个表格是我在实际项目中总结的一个成本对比框架你可以根据自己的情况往里填数字。成本项开源模型自部署闭源API调用硬件/算力GPU租赁或采购费用按推理量线性增长按Token计费无前期投入人力投入需要MLOps工程师、推理优化工程师几乎为零只需调用接口推理优化量化、批处理、缓存等优化工作厂商已完成无需操心运维监控自建监控告警体系厂商提供模型更新自行评估、微调、上线验证厂商自动更新合规安全自建内容过滤和审计体系厂商提供数据隐私数据完全自主可控依赖厂商的数据处理协议定制化可深度定制包括微调和架构修改受限于厂商提供的微调能力这个表格里最容易被低估的是人力投入和推理优化两项。很多团队在立项的时候觉得“我们有几个工程师可以兼顾”但实际做起来发现模型部署和优化是一个需要持续投入的领域不是一次性工作。4.2 什么量级下开源开始划算根据我的经验开源自部署和闭源API的成本平衡点大致在每月推理量达到一定规模之后出现。但这个“一定规模”因场景而异差别很大。如果你的场景是高频、短文本、低复杂度的推理比如简单的分类、抽取、改写开源模型经过量化优化后单位推理成本可以做到闭源API的几分之一甚至更低。这种情况下只要你的月调用量超过几百万次开源方案的经济性就非常明显了。但如果你的场景是低频、长文本、高复杂度的推理比如长文档分析、复杂推理链开源模型的推理成本优势会大幅缩小。因为长文本推理对显存和计算的要求更高优化空间更小而且复杂推理往往需要更大的模型硬件成本降不下来。还有一个容易被忽略的因素是流量波动。如果你的业务有明显的波峰波谷自部署开源模型意味着你要为峰值流量准备硬件但谷值时段这些硬件是闲置的。而闭源API是按量付费你只为实际使用的部分买单。这个差异在流量波动大的场景下可能非常显著。4.3 别忽略“机会成本”这个隐形杀手成本讨论里最容易被忽略的是机会成本。你团队花在部署和优化开源模型上的时间本可以用来做产品迭代、做用户增长、做商业拓展。这些时间的机会成本往往比省下来的API费用高得多。我见过一个团队为了省每月几千美元的API费用投入了两个工程师三个月的时间去搭建开源模型服务。三个月后服务上线了但这两个工程师本来应该在做的一个核心功能延期了导致产品错过了最佳上线窗口。这个损失远远超过了省下来的API费用。所以我的建议是在早期阶段除非你的推理量已经大到API费用成为显著成本项否则优先用闭源API快速验证产品。等产品验证成功、推理量上来了、成本压力真实存在了再考虑迁移到开源方案。这个顺序反过来做很容易在还没验证产品的时候就陷入技术细节的泥潭。5. 不同角色的选择逻辑完全不同5.1 个人开发者和研究者开源几乎是唯一选择如果你是一个个人开发者、学生或者研究者开源模型的价值是压倒性的。原因很简单成本门槛。闭源API虽然按量付费但对于没有收入来源的个人来说任何持续性的支出都是负担。而开源模型你可以白嫖可以在自己的机器上跑可以用免费的云端额度。更重要的是开源模型给了你完全的控制权和可解释性。你可以看到模型的每一层结构可以修改推理逻辑可以做各种实验。这种自由度对于研究和学习来说是不可替代的。闭源API是一个黑盒你只能通过输入输出间接观察它的行为很多底层的东西你永远看不到。我自己的很多技术认知都是在折腾开源模型的过程中建立起来的。当你亲手部署过一个模型、调过它的参数、看过它的注意力分布你对大模型的理解会和只会调API的人完全不同。5.2 创业公司分阶段策略最务实创业公司的选择逻辑要复杂得多。我的建议是分阶段策略。产品验证阶段优先用闭源API。这个阶段最重要的是快速迭代、快速验证产品假设。不要在这个时候分散精力去搞模型部署。API费用在这个阶段通常不是主要成本省这点钱不值得牺牲迭代速度。增长阶段开始评估开源方案。当产品验证成功、用户量开始增长、API费用开始变得显著的时候认真评估开源自部署的可行性。这个评估要全面不能只看API费用和GPU费用的差价要把人力、运维、优化都算进去。规模化阶段根据实际情况做混合部署。很多成熟的团队最终采用的是混合方案——核心场景用开源模型自部署来控制成本和保证数据隐私边缘场景用闭源API来保证效果和灵活性。这个混合策略往往是最务实的。5.3 大企业合规和可控性优先于成本大企业的逻辑又不一样。对于大企业来说成本通常不是第一考虑因素合规、安全、可控性才是。数据不能出企业边界这是很多大企业的硬性要求。在这个前提下闭源API的云端调用模式可能直接就不合规。这时候开源模型自部署几乎是唯一的选择哪怕成本更高、效果稍差也要接受。另外大企业往往有定制化需求。通用的闭源模型很难满足特定行业的专业需求而开源模型可以通过微调来适配。这个定制化能力对大企业来说价值很高。当然大企业也有资源来做开源模型的部署和优化。有专门的AI团队、有充足的算力预算、有完善的运维体系这些条件让开源方案在大企业里的可行性反而比创业公司更高。6. 那些“杀死”叙事背后的真实趋势6.1 不是替代是分层回到标题的问题。我的判断是开源大模型没有在“杀死”闭源而是在推动整个生态分层。顶层是能力天花板的竞争。闭源旗舰模型依然在追求最强的通用能力这个领域的投入是巨大的开源模型短期内很难完全追上。这个层级的客户是对效果有极致要求、对成本不敏感的场景。中层是性价比的竞争。这个层级是开源模型和闭源中端模型激烈交锋的地方。开源模型在这里的优势越来越明显因为它的成本结构更灵活而且能力已经足够覆盖大多数通用场景。底层是基础设施的竞争。这个层级比的是推理效率、部署便捷性、生态完善度。开源和闭源都在往这个方向发力但打法不同。闭源厂商倾向于做一体化平台开源社区倾向于做模块化工具。这个分层趋势意味着未来不会是“开源杀死闭源”或者“闭源压制开源”而是两者在不同层级上各自找到自己的生态位。6.2 闭源厂商的反击从模型到平台闭源厂商并没有坐以待毙。我观察到的一个明显趋势是头部闭源厂商正在从“模型提供商”转型为“平台提供商”。这个转型的核心逻辑是如果模型能力本身越来越难形成差异化那就把竞争维度拉到平台层面。平台的价值在于生态锁定——当用户在平台上积累了大量的微调数据、知识库、Agent配置、评估流程之后迁移成本就变得很高了。这个策略对开源阵营构成了新的挑战。开源模型可以追平模型能力但构建一个同等完善的开源平台生态难度要大得多。不过开源社区也在往这个方向走各种开源的工具链和平台项目层出不穷只是成熟度还需要时间。6.3 对普通用户来说这意味着什么说了这么多行业层面的分析回到最实际的问题对普通用户和开发者来说这个趋势意味着什么选择更多了。不管你是想要最强的能力、最好的性价比、还是最高的可控性市场上都有对应的方案。竞争带来的好处是实实在在的。切换成本在降低。随着标准化接口的普及和工具链的成熟从一个模型切换到另一个模型的成本越来越低。这意味着你不必被某个厂商锁定可以根据实际情况灵活调整。但选择也更难了。选项多了做决策的信息负担也重了。你需要了解不同模型的能力边界、成本结构、适用场景才能做出好的选择。这也是我写这类分析的原因——帮你降低信息负担建立判断框架。7. 我自己的选型决策清单7.1 先问清楚这五个问题经过这几年的折腾我总结了一个选型决策清单。在决定用开源还是闭源之前我会先问自己这五个问题第一我的数据能不能出边界如果数据涉及用户隐私、商业机密或者受监管的信息那基本只能选开源自部署。这个问题没有商量余地。第二我的推理量有多大月调用量在百万级以下闭源API通常更划算。超过千万级开源方案的成本优势开始显现。中间地带需要具体算账。第三我的团队有没有MLOps能力如果没有或者团队精力已经被产品开发占满那闭源API是更务实的选择。不要低估模型部署和优化的工程复杂度。第四我对效果的要求有多极致如果场景对准确率、鲁棒性有极高要求闭源旗舰模型依然是更稳妥的选择。如果场景对效果的要求是“够用就行”开源模型完全能胜任。第五我的流量模式是什么样的稳定高流量适合自部署波动大、有峰谷的流量适合按量付费的API。7.2 一个实用的评估流程问完这五个问题之后如果还是不确定我会走一个简单的评估流程构造测试集从真实业务场景里抽取50到100条代表性输入覆盖典型情况和边界情况。并行测试用候选的开源模型和闭源模型分别跑这个测试集人工评估输出质量。成本测算根据测试结果估算实际推理量下的成本包括API费用、GPU费用、人力成本。小规模试点选一个非核心场景做小规模试点跑一到两周观察稳定性和实际表现。决策基于试点结果做最终决策并设定一个复盘周期比如三个月后重新评估。这个流程看起来有点重但比起拍脑袋决策然后踩坑这点前期投入是值得的。7.3 混合方案往往是最优解最后我想强调的是不要陷入非此即彼的思维。开源和闭源不是互斥的混合方案在很多场景下是最优解。我自己的做法是核心的、高频的、对数据隐私敏感的推理用开源模型自部署边缘的、低频的、对效果要求高的推理用闭源API。这样既控制了主要成本又保证了关键场景的效果。这个混合策略的关键是抽象层设计。你需要一个统一的推理接口层让上层应用不感知底层用的是哪个模型。这样你可以根据实际情况灵活调度也方便后续调整。这个抽象层的开发成本不高但带来的灵活性价值很大。说到底模型只是工具工具的选择应该服务于你的业务目标。开源和闭源各有各的适用场景没有绝对的优劣。那些“杀死”叙事更多是吸引眼球的标题党而不是对现实的准确描述。真正重要的是你清楚自己的需求了解不同方案的取舍然后做出适合自己的选择。