Olmo-core 3：总参数10倍，训练吞吐量只降5%

MoE（混合专家模型）的思路是让模型装下更多参数，但每个输入只调用其中一部分。比如一个模型有47B参数，处理一个token可能只激活3.2B。Olmo-core 3要做的，是把这种训练模式推到万亿参数规模，同时不让效率掉下来。

麻烦在训练。全部参数不管激活多少，都得放在GPU内存里，训练时还要整体更新。输入要找到合适的专家，专家之间要通信协调。MoE越大，这些开销越重，把“只激活部分参数”的效率优势慢慢吃掉。

Olmo-core 3的应对是重做底层并行方式。旧实现基于FSDP，新框架改用DDP，让专家常驻GPU，把数据送到专家那里，不再反复收集权重。

分布模型靠三样东西：专家并行、流水线并行、分布式优化器。路由和计算路径也各有优化：行式专家并行、GPU驻留路由、分组GEMM。

基准测试里，专家池从8个加到128个，每个token仍然只选4个专家，活跃参数维持在约3.2B。总参数从4.6B涨到47B，训练吞吐量只掉了不到5%。同一套基础设施还跑过总参数超过一万亿的基准测试。

在8个NVIDIA B300 GPU上，一个47B参数的MoE用新框架每秒每GPU处理5.2万个token。旧实现只能到1.94万个，吞吐量提升约2.7倍。打开MXFP8低精度格式后，训练吞吐量比BF16高约21%，峰值活跃内存从103 GiB降到95 GiB。

再往上，团队在512个GPU上跑了一个1.2万亿参数的模型，每个token激活58.36B参数。最高吞吐量858 TFLOP/s/GPU。他们还用DeepEP v2做了一次短期容量测试，总参数推到2.38万亿——只测容量，不是完整训练。

还有几个反直觉的发现。一个鼓励路由均衡的分数上升，实际工作负载却变得更不均衡。团队管这叫token gerrymandering。降低专家的学习率没有改善结果。GPU处理不同输入值时，计算时间会波动。重叠通信和计算也不总是能加快训练。

Olmo-core 3完全开源。研究者和开发者可以拿来训练自己的MoE，适配不同硬件，也可以尝试改动路由和并行逻辑。下一代Olmo会用MoE架构，计划上更大的数据集、更长的上下文窗口。Olmo-core 3就是为它准备的地基。

训练成本降下来之后，有机会自己训练模型的不再只是大公司。但小团队能不能真用起来，还要看文档和社区贡献，目前没有答案。