Ai2 发布 Olmo-core 3：MoE 扩大规模，关键不只在参数量

事件日期：2026 年 10 月 1 日 混合专家模型可以拥有大量参数，却让每个输入只调用其中一部分。这让 MoE 成为扩大模型容量的一条路线，但节省计算并不意味着训练自然变快：完整权重仍要存储，输入需要分配给不同专家，多个 GPU 之间还要交换数据。Ai2 昨天发布 Olmo-core 3，重点解决的正是这些系统问题。 官方发布了什么 根据 Ai2 团队原文，Olmo-core 3 是用于开发大语言模型的框架升级，重新设计了开放的 MoE 训练系统。它将成为下一代 Olmo 的基础设施之一。这里发布的是训练框架；下一代模型的能力、数据规模与上下文长度，在原文中仍属于研发目标，不能当成已经交付的模型规格。 新系统如何减少搬运 原来的 MoE 实现采用完全分片数据并行，在每个小批次中收集并重新分片模型权重。新实现改用基于分布式数据并行的方案，让专家驻留在 GPU 上，把相关数据路由给专家，减少反复收集权重的开销。 它还结合三类分工：专家并行把不同专家放到不同 GPU，流水线并行把模型层分配给不同 GPU 组，分布式优化器则分摊训练更新所需的状态。这样，单块 GPU 不必保存完整模型及全部训练状态，但通信与负载分配仍然需要精心组织。 原文进一步介绍了 GPU 内部的路由元数据管理，以及把多个小型专家计算合并执行的方式。Easycha 分析：这些设计的共同目标，是让计算资源少等数据，而不是单纯把某一个算子跑得更快。 看速度，要连同条件一起看 官方报告，在八块 NVIDIA B300 的初步测试中，一个总参数约 470 亿的 MoE，新系统每块 GPU 每秒处理约 52000 个 token，旧实现约为 19400，吞吐提升约 2.7 倍。这是新旧训练实现的比较，不是模型推理 API 的响应速度，也不表示同等倍数的回答质量提升。 另一个实验把专家数量从八个增加到一百二十八个，每个 token 仍选择四个专家，激活参数约保持在 32 亿，总参数从 46 亿增至 470 亿，训练吞吐下降不到百分之五。这个结果说明，在该配置下，增加专家容量未带来同等比例的额外开销；不能推导成任意硬件、任意路由都能保持相同效率。 万亿规模不等于万亿模型已经训练完成 原文还展示了在五百一十二块 B300 上运行总参数约 1.2 万亿配置的系统测试，并明确使用随机路由来测量系统性能，而非评估训练后的模型质量。另一个借助 DeepEP v2 达到约 2.38 万亿参数的配置，则只是短时容量测试，并非完整训练。 这些限定直接影响消息的含义：能容纳并运行某个规模，能长时间稳定训练，以及训练结果能否完成实际任务，是三件需要分别验证的事。本文没有独立复现上述数字，所有性能信息均来自发布方。 Easycha 观察：端到端结果比局部优化更重要 Ai2 还记录了几类不直观的发现：鼓励路由均衡的分数可能改善，但实际负载反而更不均衡；把通信与计算放到不同 GPU 流重叠执行，也不总能提高整体吞吐。相同矩阵尺寸下，输入数值变化甚至会影响计算耗时。 对于准备训练或改造 MoE 的团队，值得借鉴的是验证方法：固定硬件、输入和路由条件，同时观察整体吞吐、显存和真实负载分布，再判断某项优化是否有用。对于 API 使用者，这次发布提供了理解底层成本的新材料，但不能据此承诺某个服务会降价或提速。以上为官方资料整理与 Easycha 编辑分析。