“集市”的终结?当开源AI只剩下载:一项280万个仓库的实证研究揭示了什么

在传统开源软件（OSS）的黄金年代，Eric Raymond 提出的"集市"模式（Bazaar）被奉为开源协作开发的典范：开发者分布式参与，流程开放透明，用户可以自下而上驱动创新。从 Linux 内核到 Apache，再到PyTorch，无数成功案例证明了这一范式的强大生命力。然而，在人工智能时代，所谓的开源 AI 模型（以下简称 OSM）正在悄然背离这一经典范式。

北京大学开源软件分析实验室团队完成了一项大规模混合方法实证研究，结合大规模数据挖掘（GitHub 上 1,428,792 个OSS仓库 vs. Hugging Face 上 1,440,527 个 OSM 仓库）、社会网络分析、主题建模分析以及对数十名核心开发者与社区参与者的深度访谈，系统性地对比了传统开源软件与开源 AI 模型在协作模式上的差异，是目前该领域规模最大的跨平台实证对比研究。

核心发现可以概括为一句话：当前的开源 AI，在很大程度上是一种"只读式开源"：模型可以下载和使用，但协作开发的大门几乎是关闭的。 但故事并没有止步于此，在旧范式失灵的裂隙中，新的协作形态正在萌芽。

把近 288 万个仓库的数据摊开对比，可以发现开源 AI 社区的协作强度相比传统开源软件，不是略有下降，而是断崖式塌陷：

在核心开发指标上，传统 OSS 仓库的平均提交数（Commits）达到 1,464 次，而 OSM 仅为 10.65 次。一个典型的开源 AI 仓库的全部开发活跃度，可能还不如一个活跃的传统开源项目一个月的贡献频次。

传统 OSS 平均每个仓库的 Issue 数量为 35.94 条，而 OSM 仓库的社区讨论平均仅有 0.20 条（约 180 倍的差距）。绝大多数开源 AI 模型的仓库页面更像一个静默的文件下载站，而非一个活跃的协作社区。

社会网络分析进一步揭示，传统 OSS 的开发者协作网络在深度和广度上都远超 OSM。在 OSM 的提交网络中，头部项目的核心开发往往被同一小批内部成员包揽，外部节点极度稀疏。

开源的精髓不只是"结果可获取"，更在于"过程可参与"，但在当前的开源 AI 领域，这种参与的开放性几乎名存实亡。OSM 的直接贡献（代码/权重提交）极度封闭，98.91% 的贡献者来自发布机构内部或在线托管平台员工，外部开发者的直接贡献仅占 1.09%。换句话说，绝大多数开源 AI 模型的开发过程，外界几乎无从介入。而即便是传统商业公司主导的 OSS 项目，其外部开发者的贡献比例通常也能达到 56.7%。

数字背后是更根本的分歧：传统开源社区的对话围绕"如何一起把它改好"，而AI开源社区的对话围绕"我该怎么把它跑通"。基于数万条在线托管平台交流记录的主题分析印证了这一判断。

沟通内容高度集中于"Bug 报告"（42.7%）和"功能改进建议"（28.2%），用户以"共同开发者"的身份深度参与产品打磨。一条典型的 Issue 可能是："我发现某某函数在并发场景下存在竞态条件，附上复现代码和修复 PR。"

社区讨论的主流变成了"使用问题"（40.0%）和"性能评估"（22.3%）。一条典型的 Discussion 更像是："我在 4-bit 量化后推理结果出现乱码，有人遇到过同样问题吗？"

用户不再致力于改进模型本身，而是专注于在下游应用中进行环境适配和微调。他们正从"开发者"（Developer）演变为"适配者"（Adaptor）。这意味着所谓的开源 AI 社区在协作性质上更接近一个用户论坛，而非一个共建社区。

协作的塌陷不是偶然的，对数⼗名领域专家的深度访谈反复传递着同一个信号：不是人们不愿意协作，而是AI模型开发的技术现实和产业逻辑，从根本上堵死了传统协作的入口。

在 AI 领域，开源往往是企业竞争的战略棋子：构建生态锁定、争夺开发者、对抗竞争对手的封闭策略，而并非完全为了社区共建。正如一位受访者所言："虽然大家都在说开源，但大公司之间其实几乎不存在真正的协作，说到底还是商业竞争和垄断"，另一位受访者补充道："小公司也不太可能真正开源自己的模型，因为卖 API 就是它们的主营业务。大公司可以靠其他增值服务赚钱，但对小公司来说，模型本身就是全部家当“。这种策略性开放从动机层面就决定了社区参与的天花板。

传统软件的源代码是人类可读的文本，开发者可以逐行审查、定位问题、提交修改。但模型权重是高维的二进制数值文件，无法像读代码一样读懂一个 70B 参数模型的某一层为什么会产生某种输出。更关键的是，当前模型主流架构具有高度的全局耦合性，难以像传统软件那样实现清晰的模块化分工。代码是可以被理解的协作对象，而模型权重不是。

训练一个前沿大模型所需的算力投入，已经从"昂贵"升级为"天文数字"。一位受访者直接提及：“我们公司去年投入超过 5 亿美元，其中 70% 花在了算力上，个人开发者根本承担不起这种级别的参与。” 当核心开发的入场券标价数亿美元，独立开发者和小型团队就被彻底排除在了核心协作圈之外。

以Git为代表的、驱动了传统开源繁荣的版本控制基础设施，擅长追踪代码的逐行变更，却无法有效管理动辄数十 GB 的模型权重文件。当每次提交的具体修改内容都无法明确追踪的时候，模型审查和协作迭代就失去了基础。

如果故事止步于“集市”模式的失灵，那未免过于悲观。事实上，在传统协作范式瓦解的裂隙中，几种全新的协作形态正在自发生长。

被算力和技术壁垒挡在核心开发之外的贡献者，并没有彻底沉默。他们正在开辟另一条路径：不触碰模型权重本身，而是围绕模型构建独立于模型结构之外的知识公共财产，例如提示词库（Prompt Libraries）的集体编写、评测基准（Benchmarks）的共同开发、使用文档和最佳实践的社区积累。这些贡献并未改动模型的参数，却推进了模型被理解、被评估、被使用的方式。“改不了黑盒本身，就去改黑盒周围的一切”，这正是外围贡献者找到的协作突破口。

另一种引人注目的协作形态是，大量用户通过分布式的实验测试，协同探索模型的行为边界和能力极限。红队测试、对抗性提示、边界案例收集……这些看似零散的用户行为，汇聚起来构成了一种大规模的协同评估机制。即便核心训练过程仍然封闭，这些来自外围的信号也能反向引导上游开发者优化模型对齐，形成一种间接但真实的协作闭环。

传统软件可以通过功能模块的分解实现分工协作，但 AI 模型的不可分解性使得一种新的协作模式萌生：不再拆分任务，而是交换资源，大型机构贡献算力，合作方和社区贡献领域知识与专有数据。这种资源互补式的联盟，让大模型开发变成了参与方各出所长的联合行动，它不是集市，更像是一种以资源为纽带的协作联邦。

识别了问题的根源和新生的协作萌芽之后，一个自然的追问是：能否主动设计方案和工具，促使OSM中协作的发生？破局的关键不在于空泛地呼吁更多人来贡献，而在于重新定义什么叫贡献、重新设计协作的基础设施，上述实证发现和访谈洞察共同指向了四条通往AI协作新范式的路径。

完整复现一个大模型的算力门槛极高，但透明性可以通过另一条路径实现：将数据处理逻辑、超参数配置、环境规格等打包为标准化的训练配方，让社区无需重跑训练，也能评估和验证模型的构建过程。配方将开发逻辑与硬件需求解耦，社区参与者跑不起同样的训练不要紧，但至少能看懂它是怎么做出来的，这是弥合模型生产者与社区之间资源鸿沟的重要一步。

AI模型整体难以模块化切分，而包括但不限于PEFT（参数高效微调）技术和模型融合在内的新技术却正在模拟模块化，为更加解耦的开发流程铺路。将模型变体的生产从端到端的完整训练流程中剥离出来，独立贡献者无需重跑预训练，就可以开发面向特定任务的模型变体。这种"伪模块化"让协作可以异步发生，从而绕开了预训练阶段的巨额算力门槛，让更多人有机会真正参与到模型开发中来。

一套为 AI 协作设计的新工具链正亟待设计和实现，以面向大规模二进制文件的语义化差分存储与版本控制、标准化的插件式推理接口、低门槛的在线实验环境等。正如 Git 和 GitHub 催生了传统开源的黄金时代，AI 开源的繁荣同样需要属于自己的基础设施革命。

当前的开源贡献评估高度依赖代码提交（Commit）和合并请求（Pull Request），但在OSM开发语境下，许多关键贡献形式被系统性地低估了。正如第四部分所揭示的那样，外围知识生产、集体边界探测、资源互补协同，这些不写代码的协作形式对模型质量和安全同样至关重要，却长期游离在正式的贡献激励体系之外。承认并量化这些贡献，才能让更多样化的参与者找到协作的入口。

开源 AI 的未来不应止步于开放权重，真正需要的不仅是理念上的重申，更是技术基础设施、协作工具链和贡献评价体系的系统性重建。"集市"或许不会终结，但它需要一场深刻的自我革新：在算力障碍与黑盒架构的重压之下，重新找到人人可参与的协作之路，而那些正在萌芽的新协作形态，或许正是这场革新最有希望的起点。