OLMo-core 3 发布：主攻混合专家训练与导出校验

Ai2 于 2026 年 10 月 1 日为 OLMo-core 打出 v3.0.0 版本标签，重心偏向混合专家（MoE）训练与导出：新增元数据来源的文档边界开关、可选 SwiGLU 反向优化、每头 Q/K 归一化增益与 EMO 路由，并给混合 MoE 的 Hugging Face 导出加上精确张量往返校验与一批拒绝规则。同时移除了 model_ladder API 及十一个相关训练脚本。

这次发布的是什么

Ai2（Allen Institute for AI）在 2026 年 10 月 1 日为 OLMo-core 打出了 v3.0.0 版本标签（GitHub Release 标注发布时间 2026-10-01T15:17:49Z，且不是预发布版本）。OLMo-core 是 OLMo 生态的 PyTorch 构建模块库，项目自我介绍是「Building blocks for OLMo modeling and training」，采用 Apache-2.0 许可，在 PyPI 上的包名是 ai2-olmo-core。

这个大版本的重心明显偏向混合专家（MoE）模型的训练与导出。新增项里连续出现了面向专家模块的 SwiGLU 反向优化、每注意力头独立的 Q/K 归一化增益、可缩放 softmax、EMO 文档池路由与全局负载均衡，以及混合 MoE 的 Hugging Face 导出增强。同时也有明确的破坏性变更：model_ladder 这一整套 API 与配套训练脚本被移除。

影响谁：自己预训练或继续预训练模型的团队，以及正在做 MoE 架构实验的研究组。只做推理、直接调 API 的团队基本感受不到这次改动。

可用性与限制

• 安装方式：PyPI 包名 ai2-olmo-core，也可以从源码安装。部分能力依赖可选的第三方组件，例如 flash-attn、ring-flash-attn、TransformerEngine、Liger-Kernel、torchao 与 grouped_gemm，用到才需要装。
• 有一处破坏性变更：model_ladder API、它的内部命令行封装、十一个 ladder 训练脚本、两个 Slurm 启动器与对应文档都被移除。已有的编排配置与命令要么回退到更早版本，要么自行改写。官方说明这不改变模型与优化器检查点的格式。
• 版本约束：实验性的 KDA 要求 CUDA 13 的 CuTe 编译器，环境不兼容时会在训练开始前就报错。
• 导出变严：混合 MoE 的 Hugging Face 导出新增了一批拒绝规则，旧配置有可能直接转不过去，而不再是静默改行为。
• 缓存会失效：启用了元数据边界之后，打包缓存键与数据集指纹的计算方式变化，旧的打包缓存需要重新生成。
• 缩写未定义： Release 说明里出现的 KDA、EMO、OLMoDDP 等缩写，官方没有在这条说明中给出完整展开，含义以项目文档为准。
• 国内可用性：GitHub 与 PyPI 在中国大陆的访问情况取决于网络环境，建议配置可信镜像源。

主要功能

• 掌控打包边界：新增 use_array_if_local 开关，改为从源元数据文件读取文档边界。
• 加装反向优化：面向专家模块的可选成对 SwiGLU 反向与 BF16 舍入的权重梯度累加。
• 细粒度注意力控制：每注意力头独立的 Q/K 归一化增益与可缩放 softmax。
• 路由与负载均衡：EMO 文档池路由与全局负载均衡。
• 导出校验加严：混合 MoE 的导出支持 KDA、可选 EMO 与潜在专家，并做精确张量往返校验。
• 缓存治理：把 sidecar 内容哈希纳入打包缓存键与数据集指纹。

技术原理

按 Release 说明，这次改动密度最高的地方是「打包数据集的边界判定」。原先的默认行为是扫描 token 数组里的结束符来推断每个文档到哪里为止，这种做法只有在每篇文档都以结束符收尾时才成立。一旦上游把文档截断并丢掉了终止符，被截断的那篇就会和它后面那篇粘成一整段，重截断策略又只保留合并后区间的头部，于是后一篇几乎进不了训练。

新加的 use_array_if_local 正是为此：显式设成 false 时，边界改为直接来自源元数据文件。这样做还有一层连带收益——文档长度既然来自元数据，块对角注意力掩码就不会把一篇没写结束符的文档并进下一篇。官方在同一条说明里提到，在某个微调缓存上做过测量，走推断路径到达实例的 token 比例明显低于走元数据路径，而两边的最大文档长度是一致的；具体百分比本文不抄录，结论是差别来自丢文档，而不是截断策略不同。

其余新增项围绕 MoE 训练的计算与通信开销：成对 SwiGLU 反向与 BF16 舍入的权重梯度累加压的是反向这一段的成本，可选的 FP32 梯度累加与 reduce-scatter 快速路径都带有硬件与版本守卫。导出侧的变化则是思路上的转向——从「尽力转、不行就变通」，改成「不兼容就明确拒绝」。

实际体验

本站没有跑训练，以下是可以自己复现的自查步骤。

第一步先看 Release 差异：在 GitHub 上打开 v3.0.0 的 Release 页面，对照自己当前锁定的版本逐条比对，重点看 Removed 那一节——破坏性变更都写在那里，也是最容易让流水线炸掉的一段。

第二步最小复现验证：如果你用过 model_ladder 的 API 或那批训练脚本，升级前先在最小用例上跑一遍，确认命令要不要回退到更早版本。官方说不改变检查点格式，但配置层必须先验证再上。

第三步把重打包算进排期：一旦启用元数据边界，打包缓存键与数据集指纹都变了，旧缓存会失效并重新生成。大规模数据集上这一步可能要花不少时间，不要等到训练窗口已经开了才发现。

第四步单独验证导出：如果你们依赖混合 MoE 的 Hugging Face 导出，先用现有规模的检查点跑一次往返转换并做张量比对，确认通过后再全量切换。特别留意可缩放 softmax 的生成缓存被禁用、显式使用缓存会被拒绝这两处行为变化。

项目地址与获取方式

仓库在 github.com/allenai/OLMo-core，Release 页面可以查到 v3.0.0 的完整变更清单；API 文档在 olmo-core.readthedocs.io；PyPI 上的包名是 ai2-olmo-core，许可为 Apache-2.0。

请通过官方渠道获取依赖。安装 kernel 类的第三方扩展时尤其要核对来源与版本签名，这类包直接参与训练计算，被篡改的代价远高于普通依赖。

适合谁用

• 自己预训练或继续预训练模型的团队：打包边界修正与 MoE 反向优化的收益最直接。
• 正在做 MoE 架构实验的研究组：每头 Q/K 归一化增益、可缩放 softmax、EMO 路由都是可以直接试的参数。
• 依赖 Hugging Face 导出链路的团队：新增的往返校验与拒绝规则能把转换问题提前暴露。
• 不必用的情况：只做推理服务、直接调用现成模型接口的团队，这批改动对你几乎透明。
• 被 model_ladder 移除波及的团队：先看 Removed 一节，再决定升级节奏，别在大版本窗口里硬切。

常见问题

这次有配套的新模型发布吗？

没有。OLMo-core 是训练框架，v3.0.0 是框架本身的版本升级，官方在这条 Release 说明里没有发布任何新的模型权重。是否会有配套的新模型，请以 Ai2 的官方公告为准，不要把框架升级当成模型更新。

升级到 v3.0.0 会不会炸流水线？

有一处明确的破坏性变更：model_ladder API、它的命令行封装、十一个 ladder 训练脚本、两个 Slurm 启动器与对应文档都被移除。如果你的编排依赖这些命令，需要回退到更早版本或自行改写。官方说明这不改变模型与优化器检查点的格式，所以权重本身不需要动。

use_array_if_local 该不该开？

它决定打包时文档边界从哪里来。默认是沿用原先扫描结束符的行为；如果你的数据管线来自多个上游、有可能出现没以终止符收尾的文档，把它设成 false 改从源元数据文件读边界，可以避免相邻文档被合并导致后一篇丢失。具体参数名与适用范围以 Release 说明和项目文档为准。

Release 里提到的那个测量为什么重要？

因为它说明推断路径确实会丢东西。官方在某个微调缓存上测量到，走推断路径到达实例的 token 比例低于走元数据路径，而两边最大文档长度一致——差别来自丢文档，不是截断更狠。具体百分比本文不抄录，以官方说明为准。数据管线越杂，这个坑越容易踩。

旧的导出配置还能转吗？

不一定。这次给混合 MoE 的 Hugging Face 导出加了一批拒绝规则：Q/K 归一化不兼容、KDA 输出归一化的 eps 不一致、混合 KDA 带滑动窗口注意力、以及在路由层里带受限评估池的 EMO 导出等，都会直接拒绝转换而不是静默改行为。升级后请先在旧配置上跑一次导出验证。

相关工具与内容

• /category/code — AI 编程分类，开发者侧的工具在这
• /tool/deepseek — DeepSeek，开源模型侧的常见对照
• /tool/qwen — 通义千问，开源权重模型的另一条路线
• /article/deepseek-ascend-kernels-open-source-2026-09 — DeepSeek 昇腾算子开源快讯
• /article/transformers-v5-18-release-2026-09 — Transformers v5.18 发布快讯
• /category/agent — AI 智能体分类，模型选型常在这一层落地