同一周三款“开放权重”，其中一款至今只能排队申请

2026 年 10 月的第一周，三家厂商几乎同时把“开放权重”四个字放进了自己的公告。一款说权重会在本月晚些时候开放，一款已经可以下载，一款把权重和微调平台打包端了出来。把它们的公告并排放在一起看，你会发现“开放权重”这四个字底下装着完全不同的东西。

这篇文章只回答一个问题：一个写着“开放权重”的发布，到底交付了什么。我们不用跑分去比谁更强，而是沿一条线把它拆开：先看一个还没交付的反例，再解释厂商为什么敢开放参数，接着对照两种都已经交付的契约，然后用一个经济学概念说清“拿走权重”和“真正可迁移”之间的缝隙，最后收敛成一份你自己可以逐项填写的核验清单。

一个自称开放权重的模型，为什么连权重都下载不到？

先看最反常的那个。Reflection 在 2026 年 10 月 5 日发布 Beam，一款 501B 总参数、23B 激活参数的稀疏 MoE 模型，公告标题就把“开放权重”四个字摆在了最前面。但翻到公告里“前路”那一节，原文写的是：本月晚些时候，将以 Apache 2.0 许可发布权重，以及文档和运行、评测、微调所需的整套工具。

“本月晚些时候”是一个承诺，不是一个日期。更关键的是，今天能拿到它的唯一入口，是一个邮箱候补名单。开发者的入口页面打开后是一张登录表单，一个邮箱输入框加一个服务条款勾选框，没有公开的 API 地址，没有下载链接。Beam

那到底交付了没有？公告次日，也就是 2026 年 10 月 6 日，四个公开渠道的查询结果很干净：

这就是“公告时点”和“交付时点”的分离。公告发布是一件已经发生过的事，权重可下载是另一件还没发生的事，而“开放权重”这个词把它们盖成了一件事。读者容易记住前者，于是默认后者也成了事实。

有人会说，公告里不是白纸黑字写了 Apache 2.0 吗？问题恰好在这里。许可的档位和交付的状态是两回事。Beam 承诺的 Apache 2.0，和另外两款模型已经在用的 Apache 2.0，是同一个许可档位；一份 2026 年 9 月修订的开放权重许可横评也提醒过，许可必须绑定到具体产物，不能绑定到公司名。DigiDai

所以判断一个“开放权重”的第一个动作，不是去读它的许可条款，而是查它今天到底能不能下载。Beam 连这一步都还没过。但 Beam 只是一个反例，它逼出的问题是：另外两款已经能下载的模型，为什么敢把参数放出来？

权重都公开了，价值为什么还留在厂商那边？

要回答这个，先得把“模型”这个词拆开。我们习惯把它当成一个整体，仿佛交付模型就等于交付了参数文件。但在厂商眼里，一个能赚钱的模型系统是一条链，链条上至少有五层，每一层的所有权都可以单独分配：

把权重那一层公开出去，不等于把整条链交出去。厂商完全可以只让出第三层，而把第一层、第二层和第五层握在手里。

第五层就是厂商眼中的价值循环。NVIDIA 在自己的术语表里把它画成了一个六步闭环，节点依次是 Enterprise Data、Data Processing、Model Customization、Model Evaluation、AI Guardrail 和 Information Retrieval。可下载的权重只是这个循环里的一环；数据摄取、护栏和反馈精炼，默认都留在厂商一侧。

图注：深色背景的环形闭环，中心是 NVIDIA 的品牌标识，六个白色圆形节点按顺时针连成循环：Enterprise Data、Data Processing、Model Customization、Model Evaluation、AI Guardrail、Information Retrieval。它展示的是厂商视角下的一条价值循环，提醒我们“可下载的权重”只是循环里的一环。NVIDIA

NVIDIA 把这条循环的核心价值说得很直白：真正值钱的是持续捕获用户反馈与系统行为。NVIDIA

但“有反馈闭环”并不自动等于“有护城河”。一份 2026 年 5 月的产业分析给出了一个更严格的三项门槛：每次交互都能产生关于结果好坏的可标注信号、这层数据难以在同等规模上被复制、并且随规模持续增值。三条都满足，反馈闭环才从“一次性领先”变成“长期差距”。InstPM

拿自动驾驶当例子会看得更清楚。驾驶员的每一次接管、急刹、介入，都是一条关于“模型刚才做错了”的现成标签，这是第一项门槛里“有结果信号”的典型。而要把这些信号收集到足够多，你得先有几十万上百万辆在路上跑的车，这是第二项“难以复制”的资本与时间门槛。最后，真正拉开差距的不是日常路况，而是施工区、异型车辆这些长尾场景，数据越多越值钱，这是第三项“随规模累积”。手机输入法补全、客服工单的“关闭且无后续回访”，是同一个道理在别的场景里的翻版。

理解了这条链，厂商开放权重就不再矛盾了。它放掉的是一层更容易被复制的东西，留下的是更难被复制的那一层。这提供了一种与案例相容的解释：厂商可以让出权重，同时把数据摄取、训练算力和反馈闭环留在自己手里，于是同一周里两款同样写着 Apache 2.0 的模型可以走成两个方向。不过要说清楚，这只是一种与摆在眼前的案例相容的拆解，它说的是“价值可以这样分层”这件事本身讲得通，并不能据此断言任何厂商真实的开放动机是什么；把权重放出来也可能出于生态、招人、合规叙事或单纯的品牌考虑，这些都和这套分层说法不冲突。

同样写着 Apache 2.0，Kolibri 和 Clef 到底差在哪？

先把两款的事实摆齐。Aleph Alpha 的 Kolibri 在 2026 年 10 月 3 日上到 Hugging Face，以 Apache 2.0 发布权重，78.1B 总参数、3.46B 激活参数的 MoE，团队在德国开发，模型在德国与芬兰的基础设施上训练，适用欧洲与德国法律，也遵循 GDPR 与 EU AI Act 的合规叙述。它的母公司还签署了 EU 的 GPAI 行为准则。Kolibri

Cloudflare 的 Clef 在 2026 年 10 月 1 日发布，基于 Qwen 底座的 27B 与 9B 两个尺寸，同样以 Apache 2.0 公开权重，同样上了 Hugging Face。但它在博客里同时端出了一个新的微调产品：先由前向部署工程师团队与客户共同设计微调方案，再抽象成客户自己动手的微调平台。官方把这套端到端能力部署在其自有栈上，RL 组件都在 Cloudflare 一侧；仅凭这些材料不能断言用户不能另行自部署或微调。在这套官方工作流里，AI Gateway 的作用是让所有 AI 流量经过，并自动为你的用例创建请求数据集，而这两款能对照出的差别，正落在官方工作流的依赖与数据回流位置上。Clef

把这条流程画出来，边界就一目了然：

图注：从 CAPTURE（用 AI Gateway 记录生产请求）到 PREPARE（数据管线），进入 RL TRAINING LOOP，里面依次是 GENERATE、EXECUTE+SCORE、UPDATE WEIGHTS 三个子模块，最后到 DEPLOY。底部一条虚线从部署回到准备环节，标注“新生产流量与反馈”。官方把这套采集、训练、再部署流程部署在其自有栈上，这正是“开放即入口”的形状。Clef

现在把两者放进同一张表，用五个维度逐项对照：

第一行、第二行完全一样，可下载，都是 Apache 2.0。差别从第三行往下才开始出现。Kolibri 的“主权”叙事并不只是营销，它有签署 GPAI 行为准则、欧洲司法管辖、欧洲基础设施这些可查的事实支撑；但它也不是“纯 Apache 2.0 即开箱即用”，运行需要厂商提供的那个推理插件，这是它的一条运行依赖。而 Clef 的差别则要限定在官方工作流的依赖与数据回流位置上来说：同样一个许可证，官方让出可下载的权重，同时把官方工作流所依赖的组件、以及生产请求回流的数据入口留在自己的平台上；仅凭这些材料，不能断言用户不能另行自部署或微调。

一句话，同一个许可证可以对应完全不同的控制权结果，而这个差别只落在官方工作流的依赖与数据回流位置上。差别不在许可文字里，而在许可没有写到的部分。

权重下载完之后，还有哪些决定权留在厂商手里？

“许可没有写到的部分”这句话，其实有一个现成的经济学名字。1990 年，Hart 与 Moore 在《政治经济学杂志》上这样定义所有权：所有权赋予对资产的剩余控制权，也就是除初始合同已经明确规定的用途之外，决定该资产如何使用的权利。HM1990

这个定义的关键在于合同是不完全的。合同不可能把未来所有情形都写进去，所以总有一部分决定权没被写明。这里有一个常见的误读要先纠正：许可证对某件事保持沉默，本身并不会把控制权判给厂商。按这套理论，剩余控制权跟着资产的归属走，谁拥有那份资产，没被写明的决定权才归谁。许可证把“你可以下载权重”写成了一条具体权利，而对部署算力、微调环境、反馈数据的接入往往一字未提。一字未提只说明这件事没有被约定，它既没判给采购方，也没判给厂商，而是悬置在那里。

需要说清楚的是，这套理论谈的是 1990 年的企业资产，把它套到 2026 年的模型部署上是一次类比，不是 Hart 与 Moore 对 AI 的原始主张。类比的落点在这里：只有当部署、训练环境或数据服务仍然由厂商持有、运营，或者另有合同把这些安排约定下来时，相关的选择权才可能留在厂商手里；如果这些资产与服务已经跑在采购方自己的设施上，那么即便许可证只字未提，控制权也不在厂商。换句话说，从“许可证没写”走到“厂商握着控制权”，中间必须补上一个事实前提，也就是那些资产和服务的实际归属与合同约定。单看许可证的沉默，推不出厂商拥有控制权。

所以下面这张表的右栏，写的不再是“厂商剩下的权利”，而是一条要逐项核验的问题：这一项可能由谁控制，须查哪一份合同、核哪一处资产归属。

回到 Clef，它能落进这张表的右栏，并不是因为许可证对它沉默，而是因为官方工作流所依赖的部署算力、流量采集、再部署链路和 RL 训练环境都跑在 Cloudflare 自有栈上，这些资产与服务的归属是可查的事实。所以核验的落点也很明确：去确认这些资产和服务的实际归属，以及合同有没有把它们约定下来，而不是把许可证的沉默直接读成厂商的控制权。

这种“开放核心、把增值层留下”的做法也不是 AI 独有的。软件业管它叫 open-core：核心以自由开源软件发布，增值组件以专有软件出售，这个说法由 Andrew Lampitt 在 2008 年提出，此后 Elastic、MongoDB、HashiCorp 等公司都在这条线上调整过自己的许可。

图注：一个大的粉红色矩形标注 Open Core，周围散布着五个深红色的小矩形，标注 Proprietary Bolt-Ons，细箭头从后者指向前者。它示意的是核心层开放、增值层作为外挂保留的分层模式。图中色块不指向任何具体公司。OCV

所以“可下载”只是一项被写进合同的具体权利。能不能真正迁移，取决于合同没写的那部分归谁。理解了这层张力，下一个问题就自然冒出来了：外部有没有一把尺子，能判定一个“开放”到底开放到了什么程度？

判断一个“开放”的成色，为什么一把尺子不够？

有，而且不止一把。问题在于它们回答的是不同的问题。

第一把尺子问“开放到什么程度”。《Model Openness Framework》把模型开放度拆成 17 个组件，再归成三个递进的档位：Class III 是地板，要求交出模型架构、参数、技术报告、评测结果、模型卡、数据卡等 7 项；Class II 在它之上再加训练、推理、评测的代码与数据；Class I 是天花板，还要加上研究论文、数据集、数据预处理代码和中间 checkpoint。每一个高档次都严格包含上一档。MOF

图注：一张两列三行的表。Class III. Open Model 列出 7 个组件，从模型架构、模型参数到模型卡、数据卡；Class II. Open Tooling 在 Class III 之上增加 6 项，包括训练代码、推理代码、评测数据与支持库；Class I. Open Science 再增加 6 项，包括研究论文、数据集、数据预处理代码与中间 checkpoint。这张表给出的是“开放到什么程度”的硬阶梯。MOF

用这把尺子量一个只交出权重和模型卡、没有训练数据与训练代码的版本，它大概只落在最低的 Class III 附近甚至更低，离可复现的开放科学还有很远。需要说明的是，框架本身不评级任何具体商业模型，这里只是用它说明阶梯的形状。

第二把尺子问“算不算开源 AI”。开源促进会 2024 年 10 月发布的开源 AI 定义把话说得很直：要被称为开源 AI，需要同时交出数据信息、代码与参数三层；只提供权重，不足以称为开源 AI。它还特别声明，自己只判定“是不是开源”，不判定“安不安全、合不合规”。OSAID

第三把尺子问的是完全不同的问题：能不能豁免。EU AI Act 的 Article 53 给 GPAI 供应商开了四项义务，Article 53(2) 的开源豁免只免掉其中两项，另外两项，著作权合规政策与训练内容摘要，仍然必须公开。而且一旦训练算力越过阈值，或者被委员会单独指定为系统级风险，豁免就不适用。换句话说，许可不是豁免的依据。

这里有个容易被忽略的细节：Kolibri 的母公司 Aleph Alpha、以及 Beam 的发布方 Reflection，都出现在 EU 的 GPAI 行为准则签署名单上。AI Act 但签署行为准则和获得开源豁免是两件事，前者是自愿的合规路径，后者有明确的门槛。这也印证了近期一篇政策报告的主张：开放不是“开”与“关”两个档，而是一段谱，开放度应当按风险评估与已证明的安全来决定。CFG

一个“开放”字样不能替你回答三把尺子的问题；同一版本需分别核验，结果可以相容也可以不相容。三把尺子分别回收三种问法：“是不是开源 AI”“开放到什么程度”“能不能豁免”。

下次看到一个“开放权重”，该逐项检查什么？

把前面的东西收成一张可以动手填的表。五项核验，按顺序问：

Beam 在第一项就不过。Kolibri 在五项里数据闭环归属最干净，交付不绑定反馈环，但要记得它的运行依赖那一条。Clef 在微调权与数据闭环归属两项上最重，官方的 RL 微调与再部署工作流位于其自有栈上；这一格只说明官方工作流的落点，不影响许可证本身的档位，所以还要另查许可证或合同有没有限制外部部署、微调和数据导出。

清单之外还有一句方法论要记住：许可必须绑定到具体产物，而不是公司名。把“某公司是开源的”这句话拆开，往往就站不住了；同一个品牌下不同版本的产物，可以有完全不同的许可与交付状态。DigiDai

最后补一道提醒：即便五项都过，许可证也不等于 EU AI Act 的豁免依据。开源豁免只免掉两项义务，著作权政策与训练内容摘要仍需公开。

所以“开放权重”已经不是一种状态，而是一份需要逐项审查的供给合同。下次看到这四个字，先查今天能不能下载，再逐项核验许可、运行依赖、微调权与数据闭环归属。判断应该落在这五项上，而不是落在“开放”两个字上。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. The Open Source AI Definition (OSAID) 1.0 — Open Source Initiative — https://opensource.org/ai/open-source-ai-definition
2. Kolibri Has Landed: A Sovereign Open-Weight Model — Aleph Alpha — https://aleph-alpha.com/en/blog/kolibri-has-landed-a-sovereign-open-weight-model/
3. Introducing Beam: Reflection's 501B open-weight model — Reflection — https://reflection.ai/blog/introducing-beam
4. Introducing Clef: our open-source decision models, and new RL fine-tuning platform — Cloudflare — https://blog.cloudflare.com/clef-decision-models/
5. Llama, Mistral, DeepSeek and Qwen: An Open-Weight Comparison — Gene Dai — https://digidai.github.io/2026/03/13/open-weight-ai-war-llama-mistral-deepseek-qwen/index.md
6. Data flywheel: What it is and how it works — NVIDIA Glossary — https://www.nvidia.com/en-us/glossary/data-flywheel/
7. The Model Openness Framework (MOF) — arXiv:2403.13784 — https://arxiv.org/abs/2403.13784
8. Property Rights and the Nature of the Firm — Hart & Moore 1990, JPE 98(6) — https://dash.harvard.edu/server/api/core/bitstreams/7312037c-4b76-6bd4-e053-0100007fdf3b/content
9. Open-core model — Wikipedia / Open Core Ventures Handbook — https://en.wikipedia.org/wiki/Open-core_model
10. The EU AI Act's Open-Source Exemption: Article 53 + GPAI Code of Practice — European Commission — https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
11. The Data Moat Strategy for AI Products: How to Build Defensibility — Institute of AI Product Management — https://www.institutepm.com/knowledge-hub/data-moat-strategy-ai-products
12. Beyond the Binary: A nuanced path for open-weight advanced AI — arXiv:2602.19682 — https://arxiv.org/abs/2602.19682