模型版图

模型名称并不等于部署选项。同一家机构可能公开一个模型的权重，通过 API 出售另一个模型，并为第三个模型附上不同条款。即使是同一个模型，也可能同时存在研究检查点、社区量化版本和托管服务。这些版本的行为、允许用途、数据处理方式和支持条件都可能不同。

经得起版本更迭的分类框架，不是一个从开放到封闭的单一分数，也不是实验室排行榜。应把每次发布视为一份发布契约：它提供哪些制品访问，授予哪些法律许可，承诺哪些运营访问，以及有哪些质量的证据支撑相关主张。这些是彼此独立的问题。可下载模型的条款可能很严格；文档完善的模型可能不提供下载；API 的运营保证也可能强于自行托管的检查点。每项判断还必须注明准确版本和快照日期。

先用准确的名词

几个听起来可以互换的词，其实指向不同对象。

• AI 系统不仅包括模型，还包括让模型发挥作用的外围软件、数据流、工具、政策和人工流程。
• 按照 Open Source AI Definition 的术语，模型由模型架构、学习得到的参数，以及运行模型所需的推断代码组成。
• 权重是学习得到的参数。它们是重要制品，但无法揭示训练语料、训练过程或部署控制措施。
• 托管服务允许客户向提供方运营的系统发送请求。客户通过接口调用系统的能力，却不一定能获得底层模型制品。
• 本书所说的开放权重，是一项描述性主张，表示权重可以在足够宽松、允许本地使用的条款下取得。行业用法并不统一。G7 在 2026 年提出的一套词汇，把权重和部署代码均按开源条款发布的系统称为「开放权重 AI」，把下载受限的系统称为「权重可用 AI」 (G7 Industry, Digital and Technology Ministers 2026)。无论团队采用哪套词汇，都必须记录实际提供的制品和条款，不能只依赖标签。
• 开源 AI是一个要求更高、已有明确定义的主张。Open Source AI Definition 1.0 要求系统允许使用、研究、修改和分享，并提供便于修改的首选形式，包括数据信息、完整的训练与推断代码，以及按符合要求的条款发布的参数 (Open Source Initiative 2024)。

有一个细节可以避免常见误解。该定义要求提供足够的数据信息，让具备相应技能的人能够构建功能大体相当的系统。这些信息包括数据来源、范围、选择与处理方式，以及可用数据的位置。如果数据不能合法分享，定义并不要求公开每一条训练样本。因此，它的要求高于只发布权重，却不等于必须发布完整语料库。Model Openness Framework 不假定一个可下载文件就能回答所有开放性问题，而是根据一份组件清单划分三个完整度等级。其中的分类由发布方自行申报，评估的是已披露组件和声明的许可证，并不会独立核实这些主张，也不会验证他人能否成功复现 (White et al. 2024)。

这些定义说明发布方提供了什么、允许了什么，并不证明模型准确、安全、无偏、低成本，也不证明它适合某项具体部署。

发布契约包含五个字段

这里把候选发布表示为一份带版本的证据记录：

$$R_r(v,t) = (A_r, X_r, P_r, O_r, E_r).$$

其中，$Q$ 表示一组硬性要求。发布闸门为

$$\operatorname{eligible}(r,Q) = \bigwedge_{q\in Q} \mathbf{1} \left[ \operatorname{evidence}(R_r,q)=\text{confirmed} \right].$$

其中：
  r       ：正在审查的候选发布
  v       ：准确版本标识、修订版或制品哈希
  t       ：针对可变页面、条款和服务的观察日期
  R_r     ：发布 r 在版本 v、时间 t 的发布档案
  A_r     ：可用访问渠道：下载、受限下载、托管 API 或不可访问
  X_r     ：已发布制品与文档
  P_r     ：法律许可、义务、限制，以及纳入契约的政策
  O_r     ：运营限制与服务承诺
  E_r     ：支撑发布相关主张的证据包
  Q       ：硬性部署要求的集合
  q       ：Q 中的一项要求
  evidence(R_r, q)
          ：文档证据给出的已确认、已否定或未知
  1[...]  ：括号内条件成立时取 1，否则取 0
  ⋀       ：所有硬性要求之间的逻辑与

这不是开放度指标，也不应变成加权排行榜。如果必须在本地运行，那么 API 得分再高也无法弥补权重缺失。如果必须再分发，那么基准质量再高也无法抵消条款中的禁止规定。未知不能通过发布闸门，它意味着仍有问题需要补充证据，或由责任人明确作出风险决定。

制品访问：实际能获得什么？

应分别记录每件制品，而不是在一个单元格里写「开放」。发布内容可能包括：

• 最终权重、架构文件、分词器文件和推断代码；
• 训练代码与配置，包括超参数和软件版本；
• 训练数据信息、数据配比或训练数据本身；
• 中间检查点、优化器状态、数据顺序和运行遥测；
• 评测代码、提示词、原始输出、模型卡和安全文档。

不同制品支持的审查工作各不相同。最终权重与兼容的运行时代码可以支持本地推断。训练代码能够展示训练过程，却无法还原未公开的语料。数据集清单无法恢复准确的数据顺序或过滤状态。中间检查点有助于研究学习动态，而继续训练时可能还需要优化器状态。

「可复现」也必须说明复现目标。在同一权重上重新运行已发布的评测代码，属于评测的计算复现。若要重复已发布的训练运行，团队需要数据、数据顺序、代码、配置、环境和资源。独立复制则要检验另一支团队或一批新数据能否得到实质相同的结果。无论哪一种，都不能单独证明部署安全，也不能证明模型卡完整 (Mitchell et al. 2019)。

法律许可：可以用它做什么？

持有制品和获准使用是两回事。采用可下载权重前，应由负有责任的审查者检查实际许可证，以及许可证纳入的每一项政策。清单通常包括版权授权、专利授权、再分发条件、使用限制、衍生模型的处理方式、署名与通知义务、商标规则和终止条款。自定义协议可能允许商业推断，却限制再分发，或要求下游用户继承某项使用政策。「社区」一词不能回答这些问题。

Apache 2.0 常被称为宽松许可证，因为它在满足明示条件的前提下，授予广泛的版权与专利权。模型专用协议可能在某一方面更宽松，在另一方面更严格。真正需要问的不是新闻稿是否写着「开放」，而是准确条款是否允许计划中的产品形态和分发路径。这是一份工程检查清单，不是法律意见。

运营访问：由他人运行时会发生什么？

对于托管服务，API 协议和产品文档都属于发布契约。应检查可接受使用政策、输入与输出数据的保留期限、是否用客户数据训练、可用地区、速率限制、版本固定、弃用通知、支持渠道和服务级别协议。还应记录哪些主张写进了合同，哪些只是产品当前的实际行为。

这些问题可能比权重是否可用更重要。受监管工作负载可能更适合在合规地区运营、且数据保留条款具有约束力的托管服务。必须离线工作的产品则会立即排除同一项服务。反过来，可下载检查点消除了提供方一侧的版本漂移，却要求运营者自己承担容量、修补、监控和事故响应。

证据质量：能够核实什么？

技术报告是一种证据，但不同报告回答的问题并不相同。应记录一项主张由什么支撑：可执行代码、已发布的原始结果、制品哈希、独立复现，还是仅有提供方摘要。还要记录评测范围，包括模型修订版、提示格式、采样设置、工具访问权限、评分器和比较基线。提出模型卡，正是因为只有一个汇总分数，却没有预期用途、局限和分组评测，不足以支持部署决策 (Mitchell et al. 2019)。

证据质量并不等于模型质量。能力有限的研究模型可以有很完整的来源记录。能力很强的托管服务可以有可靠的可用性承诺，却很少披露训练信息。应把这些事实分开，避免用一项亮眼属性悄悄替代另一项要求。

发布实例，而不是永久分级

下面列出的是截至 2026 年 8 月 7 日的证据快照。它们说明，分类对象应是具体发布，而不是实验室。条款和代码仓库都会变化，因此生产审查必须保存当时实际依据的准确文档。

Pythia：为训练动态研究而设计。 这篇 ICML 论文介绍了 16 个使用公共数据、按相同的数据顺序训练的语言模型。每个模型发布 154 个检查点，并提供重建训练数据加载器的工具 (Biderman et al. 2023)。这套组合支持仅凭最终检查点无法完成的研究。它不表示 Pythia 适合所有产品，也不等于每项报告结果都得到了独立复制。

OLMo 2：覆盖广泛的训练发布。 OLMo 2 发布权重、训练代码、训练数据与配比、训练日志、中间检查点和训练配方，其中包括为提高稳定性所作的修改，以及两阶段课程安排 (OLMo Team 2025)。这里的「完全开放」描述的是已发布的开发栈，不是对输出、下游微调版本或某项具体部署的普遍保证。

Llama 3、Qwen3 和 DeepSeek-V3：权重加上内容详实的报告。 它们的报告较为深入地记录了架构、训练选择和评测 (Grattafiori and others 2024; Yang and others 2025; DeepSeek-AI 2024)。它们都没有把完整预训练语料作为可重建的数据集公开，法律条件也各不相同：Llama 3 使用带版本的自定义社区条款，Qwen3 权重使用 Apache 2.0，DeepSeek-V3 的参考代码与原始权重采用不同许可证。用户能否运行和改造某次发布中的模型，取决于它的具体条款、格式和硬件要求；仅凭论文无法重复原始训练运行。

gpt-oss：混合产品组合中采用宽松许可证的权重。 OpenAI 于 2025 年 8 月 5 日按 Apache 2.0 发布 gpt-oss-120b 和 gpt-oss-20b，提供可下载权重、模型卡、分词器材料和参考推断实现 (OpenAI 2025)。页面只对以英文为主、仅含文本的训练数据作了高层说明，没有发布语料本身。同一家公司还运营只能通过托管产品使用的其他模型。因此，公司名称不能充当分类结果。

Gemma：版本会改变法律结论。 Gemma 1 至 3 的权重可供下载，但适用的自定义条款包含使用限制，并对分发和衍生模型设定条件 (Google 2026)。Gemma 4 则使用 Apache 2.0 (Google 2026)。如果审批记录里只写「Gemma」，就会掩盖决定法律审查结果的版本差异。

GPT-4 技术报告：有证据，但没有可复现的训练发布。 报告介绍了评测与安全工作，却明确不披露架构、模型规模、硬件、训练算力、数据集构建或训练方法，权重也没有发布 (OpenAI 2023)。对于报告实际检验的主张，它仍然是证据；对于没有披露的训练细节，它不是证据。

这里不是要授予永久等级。同一家机构后续发布的制品集合、许可证或服务契约都可能不同。决策必须针对具体发布。

公开报告能够说明什么，不能说明什么

公开发布和论文构成了一套宝贵的公共证据库。其他团队可以借此检查一种思路，在制品齐全时复现结果，并把方法用于新的系统。但必须区分三个历史问题：谁率先提出方法，谁在明确说明的规模上验证了方法，以及谁发布了足以重复实验的制品。公开文献无法证明某个未公开项目内部是谁最先使用某种方法。某种技术随开放权重一起出现，也不代表它因为权重开放才产生，更不代表所有闭源系统都采用了它。

应把公开记录理解为带日期、范围明确的贡献：

• FP8 格式论文提出 E4M3 和 E5M2 格式，并在最大 1,750 亿参数的语言模型上进行评测 (Micikevicius et al. 2022)。DeepSeek-V3 随后提供了在其报告规模下进行 FP8 训练的详细案例，并使用无辅助损失的专家路由偏置 (DeepSeek-AI 2024; Wang et al. 2024)。
• DeepSeek-V2 报告了用于压缩键值状态的多头潜在注意力 (DeepSeek-AI 2024)。ICML 的多词元预测论文提出带独立预测头的目标函数，DeepSeek-V3 使用的是顺序变体 (Gloeckle et al. 2024; DeepSeek-AI 2024)。两者是不同机制，不属于同一个注意力家族。
• 分组查询注意力论文定义了介于多头注意力和多查询注意力之间的设计，并演示如何从现有检查点继续训练 (Ainslie et al. 2023)。这篇论文是该项实验的证据，不能替所有后来的实现作证。
• Chinchilla 报告了其特定实验设置下的计算最优训练；面向推断成本的扩展研究则分析了为什么服务需求可能更适合用更多词元训练较小模型 (Hoffmann et al. 2022; Sardana et al. 2024)。
• Tensor Programs V 报告了最大更新参数化下的零样本超参数迁移，MiniCPM 则介绍 warmup-stable-decay 调度 (Yang et al. 2021; Hu et al. 2024)。
• Megatron-LM 记录了张量、流水线和数据三个维度的三维并行。CheckFreq 研究了采用异步持久化的频繁检查点 (Narayanan et al. 2021; Mohan et al. 2021)。

这段历史横跨不同的组织访问模式。Chinchilla 来自一家没有发布其前沿部署模型权重的实验室；GQA 来自 Google；DeepSeek 的报告则与可下载权重一同发布。论文能够支撑的主张是「已有公开文档」，而不是「由开放模型发明」。

把要求转化为准入闸门

应从预期用途出发，而不是从模型目录出发。本地私有助手可能要求本地推断和私密输入。受监管审计还可能要求训练数据来源。需要再分发的产品必须拥有明确的再分发权。这些都是不能通过平均分抵消的硬性条件。

下面的小例子用一个假想发布评估三种用例。True 表示文档证据确认要求成立，False 表示发布不满足要求，None 表示审查尚无结论。这个例子只演示闸门机制，不是法律分析，也不为真实模型打分。

release = {
    "local_inference": True,
    "private_inputs": True,
    "training_data_provenance": None,
    "redistribution": False,
}

use_cases = {
    "local-private": ["local_inference", "private_inputs"],
    "regulated-audit": ["local_inference", "training_data_provenance"],
    "redistributable-product": ["local_inference", "redistribution"],
}

def classify(requirements):
    refuted = [name for name in requirements if release[name] is False]
    unknown = [name for name in requirements if release[name] is None]
    if refuted:
        return f"ineligible ({', '.join(refuted)})"
    if unknown:
        return f"unresolved ({', '.join(unknown)})"
    return "eligible"

for use_case, requirements in use_cases.items():
    print(f"{use_case}: {classify(requirements)}")

预期输出：

local-private: eligible
regulated-audit: unresolved (training_data_provenance)
redistributable-product: ineligible (redistribution)

保存发布台账

模型、条款或提供方发生变化后，原有决定仍应可以复查。台账至少要保存：

• 准确的模型与修订版、制品哈希、访问渠道和快照日期；
• 许可证版本、条款版本、纳入契约的政策，以及它们的归档副本；
• 所需权限，以及负责确认权限的审查者；
• 来源证据、已发布制品和尚未解决的披露缺口；
• 评测范围、原始结果和部署专用验收阈值；
• 托管依赖、数据路径、容量负责人和事故联系人；
• 一项退出测试，确认权重、适配器、提示词和数据能否迁移到别处；
• 决策状态（合格、不合格或待解决），以及负责人和复查日期；
• 失效触发条件，例如新修订版、条款变化、提供方迁移、重大能力变化或安全事故。

不要把提供方主张复制进台账却不附来源。只有 URL 也不可靠：对于可以随时修改的条款，必须记录获取日期，并保存归档副本或哈希副本。

从版图走向选择

模型版图由不断变化的发布契约组成，不是一场只有一个赢家的竞赛。应分别审查制品、许可、运营和证据，固定版本与日期，再确认每项硬性要求是否都有证据支持。这种方法记录了产品实际能使用什么、机构必须运营什么，因此不会随排行榜变化而失效。

后续章节会继续推进这项决策。第 79 章 检查训练权利与部署权利是否有据可查；第 76 章 比较由提供方运营和自行托管两条路径的成本；第 81 章 把要求与评测结果转化为候选名单；第 89 章 则处理采用后的版本漂移。

延伸阅读