Olmo-core 3：把专家留在 GPU 上，MoE 训练如何减少搬运

事实与来源

Ai2 在 10 月 1 日介绍了 Olmo-core 3，重点是重做混合专家模型（MoE）的训练系统。官方给出的一个初步测试是：在八张 NVIDIA B300 上运行八层、BF16 精度的 47B 参数 MoE 训练基准，采用 top-4 随机路由，新实现达到每张 GPU 每秒 52,000 token，旧实现为 19,400，约为原来的 2.7 倍。

比较对象是团队自己此前采用 FSDP 的实现，不能据此给所有训练框架排座次。本文依据官方文章、技术说明和公开仓库梳理，没有运行这套训练环境。它最值得关注的问题是：模型只激活少量专家时，怎样避免权重搬运和跨卡等待吃掉省下的计算量？

技术机制

旧实现会为每个微批次收集并重新分片模型权重。新系统让专家常驻所属 GPU，把需要处理的 token 表示送到对应专家，再回收计算结果。专家并行负责分散专家，流水线并行把模型层切成多个阶段，分布式优化器再分摊训练状态；它们解决的是不同的显存占用，不能只靠一种切分包办。

数据到了正确的卡，还要进入正确的计算缓冲区。按行组织的专家并行减少额外重排，路由元数据留在 GPU 上，减少 CPU 等待数据回传；grouped GEMM 则把多个专家的小矩阵计算组织起来。这些机制共同减少等待与调度成本，但实际效果仍取决于通信网络、负载和矩阵规模。

例子与用途

用一个假设来理解：八张 GPU 平分某一 MoE 层的 128 个专家，每张保存 16 个。一个 token 选择四个专家，它们可能位于不同 GPU。系统需要发送的是该 token 的中间表示，并将专家结果按路由权重组合，而不用为这次计算把全部专家权重都集中到一张卡上。这个例子仅解释数据流，不代表一份可直接套用的训练配置。

如果大量 token 同时选中少数专家，相关 GPU 就可能忙碌，其他卡却在等。对准备扩展专家池的团队，可以先记录每个专家接到多少 token、跨卡传输时间和训练步耗时，再判断瓶颈。只看总参数变大而每 token 激活数不变，会漏掉通信和负载变化。

限制与不确定性

官方展示了万亿参数级别的系统测试，但必须分清规模与训练质量：1.2T 配置使用随机路由衡量系统性能；2.38T 配置只进行了九步容量测试，吞吐曲线尚未稳定。它们不能证明已经完成同规模模型的长期训练，也不能说明最终模型更聪明。真实学习到的路由分布还可能改变专家负载。

低精度也有条件。四张 B300、专家工作量均匀的测试中，选用 MXFP8 的组合比 BF16 提高约 20.6% 吞吐量，峰值活跃显存从 103.4 GiB 降到约 95 GiB。这是整条训练路径的结果，不能直接当成任意硬件或单个算子的收益；格式转换本身也要花时间。

开发者启示

若要评估这种设计，建议先固定模型、输入和批次配置，测量完整训练步，再逐项改变专家切分或精度。除平均吞吐量，还要看最慢的阶段、峰值显存、路由负载和长时间稳定性。单个算子变快，可能只是把等待移到通信或另一阶段；一次短跑能装下，也不等于能稳定训练数天。

实际接入还有个容易忽略的细节：仓库说明，官方 Docker 镜像包含依赖，却不包含已安装的 Olmo-core 包，并且硬件、驱动或 CUDA 版本不同可能影响可用性。先核对源码版本和依赖，在小规模完成正确性与恢复测试，再扩展 GPU 数量，比直接照搬峰值数字更有参考价值。