Introducing Olmo-core 3: Open, scalable training infrastructure for large MoEs

介绍 Olmo-core 3：面向大型 MoE 的开放、可扩展训练基础设施

返回文章

[0

[-1

企业

]

文章

发布日期：2026年10月1日

点赞

10

[

• +4

Kyle Wiggers

Ai2Comms

关注

allenai

📄 技术报告 | 💻 代码 | 🧩 交互式演示

今天，我们发布了 Olmo-core 3，这是我们在开发大型语言模型框架方面的重大升级，采用了重新设计的开放专家混合（MoE）训练系统。

Olmo-core 3 的设计目标是将 MoE 训练扩展到万亿参数级别，同时保持计算效率。它是下一代 Olmo 的核心系统之一，也是我们持续致力于开放每款新模型背后工具和训练基础设施的承诺的一部分。

训练大型 AI 模型需要大量计算资源，导致成本和能耗上升，使许多学术研究者和小型实验室难以进行先进模型开发。MoE 模型提供了一种更高效的方法——它们可以包含更多学习组件（参数），而无需每个输入都使用所有参数。但整个模型仍需存储在 GPU 内存中并在训练期间进行更新，而将输入路由到 MoE 中的正确专家（专用组件）时，跨集群的通信和协调成本会带来额外开销。随着 MoE 规模扩大，这些成本可能会抵消大部分仅使用部分模型参数的计算优势。

Olmo-core 3 的设计正是为了解决这一问题。在一项基准测试中，我们将专家池从 8 个扩展到 128 个，同时仍保持每个 token（语言模型处理的文本基本单位）仅选择 4 个专家，使每个 token 的活跃参数数量保持在约 32 亿左右。总参数容量从 46 亿增长到 470 亿，而训练吞吐量下降不足 5%。

同一套基础设施在另一项基准测试中已实现超过 1000 亿总参数的规模。

围绕 MoE 实际工作原理构建训练体系

Olmo-core 随着每一代 Olmo 的发展而不断演进。

我们对稀疏模型的研究始于 OlmoE，该模型采用包含 64 个路由专家的 MoE 架构。相比之下，Olmo 3 使用了密集架构，意味着几乎所有模型参数在处理每个 token 时都处于活跃状态，其训练体系也是围绕这一设计构建的。Olmo-core 3 则扩展了该框架，引入了专为更大规模 MoE 模型设计的训练系统。

早期 Olmo-core 的 MoE 实现采用全分片数据并行（FSDP），配置为针对每小批训练数据收集并重新分片模型权重。Olmo-core 3 转而采用基于分布式数据并行（DDP）的系统。它将专家常驻在 GPU 上，并将相关数据路由到这些专家，避免了重复的权重收集过程。

NVIDIA 的 Megatron-Core 是训练大型 MoE 的成熟方案。Olmo-core 3 为 Olmo 框架带来了集成的 MoE 训练体系，通过重新设计显著提升了吞吐量。在一项初步测试中，使用 8 块 NVIDIA B300 GPU 运行 470 亿参数的 MoE 模型，新体系实现了每 GPU 每秒处理 52,000 个 token，而早期实现仅能达到 19,400 个 token——新体系的吞吐量是旧方案的约 2.7 倍。

扩展和优化 MoE 训练

Olmo-core 3 结合了多种技术，用于在 GPU 集群中分布大规模 MoE 模型，并通过优化使路由和计算更加高效。

三种技术决定了模型及其训练状态如何在硬件之间进行划分：

• 专家并行将专家分布在多个 GPU 上，使得每个 GPU 仅存储完整专家池的一部分。
• 管道并行将模型的层（输入经过的连续处理阶段）分布在 GPU 组之间，从而减少每个 GPU 需要保留在内存中的模型量。
• 分布式优化器将优化器状态（训练过程中用于计算和应用更新的附加数据）分散到多个 GPU 上，而不是在每个 GPU 上存储完整的副本。

这些技术的结合使得 MoE 能够扩展规模，而无需每个 GPU 都存储完整的模型及其训练状态。

Olmo-core 3 还降低了将数据路由到正确专家并执行其计算的成本。行级专家并行将路由数据直接放入专家输入缓冲区，最大限度地减少重新排列数据所需的额外工作。GPU 本地路由将路由元数据保留在 GPU 上，使 CPU 可以在不等待信息回传的情况下排队处理任务。而分组 GEMM 将许多小规模的专家计算合并，使 GPU 能更高效地执行这些操作。

最后，Olmo-core 3 支持 MXFP8，这是一种使用更少位数表示某些值的低精度数值格式。只要这种节省的开销超过格式转换的成本，它就可以减少计算量和 GPU 之间的数据传输量。

我们在四块 NVIDIA B300 GPU 上进行了受控基准测试，均匀地将工作分配给专家，测量了 MXFP8 对端到端训练吞吐量的影响。在系统中 MXFP8 起作用的区域启用该格式后，训练吞吐量比我们用作基准的更高精度 BF16 格式提高了约 21%，峰值活动内存也从 103 GiB 降至 95 GiB。大部分增益来自前馈计算和专家之间的数据移动，而非仅注意力机制。

这些技术和优化必须协同工作。加快训练某一部分可能会在其他地方产生成本；更快的计算可能需要更多的数据移动，而减少传输的比特数可能无法带来帮助，如果数据转换耗时过长的话。Olmo-core 3 围绕整个训练过程中的这些权衡构建，使我们和使用开源堆栈的研究人员能够控制这些组件如何配合。

通过我们的交互式演示，了解数据并行、专家并行和管道并行如何协同工作，以扩展 MoE 训练规模——从单个 GPU 到多个 GPU。

扩展至万亿参数级别

我们在 NVIDIA B300 GPU 上对 Olmo-core 3 进行了多种配置的基准测试，包括一个 1.2 万亿参数的模型，在 512 块 GPU 上每 token 激活 583.6 亿参数。其最高观察吞吐量为 858 TFLOP/s/GPU——衡量每个 GPU 每秒有用模型计算量的指标。这些测试使用随机路由来衡量系统性能，而非训练模型的质量。

我们还尝试了 DeepEP v2，这是一种处理跨 GPU 专家通信的替代方法，达到了 2.38 万亿总参数的配置。这是一次短容量测试，而非完整的训练运行，因此它展示了 Olmo-core 3 可达到的规模，而非持续的训练性能。

在这些规模下，系统性能只是问题的一部分。我们的技术报告还记录了指导我们如何训练专家混合模型（MoEs）并衡量其性能的实验。例如：

• 一个旨在鼓励负载均衡的评分指标可能在实际工作负载变得不那么均衡时反而提升。我们将这种失败现象称为“令牌操控”（token gerrymandering）。

• 由于专家处理的令牌更少，降低专家的学习率（即训练更新的幅度）在我们测试的模型系列中并未提升效果。

• 即使矩阵维度相同，当处理的数值发生变化时，GPU计算所需的时间也会不同。因此，性能比较不仅需要匹配的输入值，还需要匹配的形状。

• 在独立的GPU流上重叠通信和计算并不总是能加快训练速度。在某些测试中，这反而会减慢端到端执行速度——这提醒我们，更多的重叠并不一定意味着更高的吞吐量。

报告解释了这些发现，并说明了我们测试过的方法以及未采纳的方案。

为下一代Olmo打造，向所有人开放

Olmo-core 3是我们下一步构建的基础。我们下一代的Olmo将采用专家混合架构（MoE），我们目标是打造迄今为止功能最强的Olmo，使用我们最大的数据集进行训练，并具备最长的上下文窗口。

新的技术栈使我们能够超越之前的MoE工作，同时为我们适应模型和硬件的演进提供更大的灵活性。它完全开源——研究人员和开发者可以使用Olmo-core 3来训练自己的MoE，将其适配到不同的硬件上，并对路由、并行性及其他系统组件进行实验。

这是我们对开放模型开发的思考方式——当模型权重背后的基础设施和训练决策也开放时，模型权重才更具价值。

如需深入了解系统设计、实验、消融分析及我们测试的其他方法，请阅读我们的技术报告，并在GitHub上探索Olmo-core 3。

更多该作者的文章

BenchMIRT：大型语言模型基准实际在衡量什么？

27

2026年9月1日

介绍OlmoEarth嵌入：来自OlmoEarth Studio的自定义嵌入导出用于下游分析

19

2026年8月12日

社区

编辑

预览

通过拖拽、粘贴或

点击此处

上传图片、音频和视频。

点击此处上传图片

评论

· 注册或登录以评论