OLMo-core 3的token gerrymandering提醒：MoE路由要按时间窗验收
内容提要
Ai2 开源 OLMo-core 3，重写 MoE 训练系统，专家池扩至 128、参数达 470 亿，吞吐提升约 2.7 倍。报告指出“token gerrymandering”问题：全局均衡分数可能掩盖分时间窗的专家热点，导致局部拥堵。建议路由验收按时间窗、分层、分 GPU 进行，监控峰值占比、丢弃 Token 与通信等待，并设置停机条件。
延伸解读
全局均衡的假象：分时间窗监控的必要性
文章指出，token gerrymandering 问题在于全局均衡分数可能掩盖分时间窗的专家热点。例如，两个时间窗分别只使用专家0、1和2、3，全局统计完全均衡，但每个窗口内单专家承担50%流量，导致局部拥堵。因此，路由验收必须按时间窗、分层、分GPU进行，监控峰值占比、丢弃Token与通信等待，避免平均指标掩盖瞬时瓶颈。
MXFP8低精度收益的适用边界
官方在4张B300上实验显示，开启MXFP8后端到端训练吞吐比BF16高约21%，峰值显存从103 GiB降至95 GiB。但该实验使用均匀专家分布，收益主要来自前馈计算与专家交换。文章提醒，这不意味着任意路由失衡的真实任务都能获得同样收益，采用MXFP8还需验收收敛质量、转换开销与目标硬件支持。
三层验收框架：正确性、系统与路由
文章建议将验收分为三层：正确性层比较固定样本的损失、梯度与收敛曲线；系统层记录每步吞吐、峰值显存、通信占比与最慢GPU；路由层观察专家热点、溢出、丢弃和分窗变异。只有三层同时不退化，才能说新配置真的更好。此外，上线前应设置停机条件，如任一分窗单专家峰值占比超阈值、丢弃Token上升或最慢GPU等待时间恶化，即使全局吞吐变好也不应放行。
Q&A
OLMo-core 3 是什么？它主要解决了什么问题？
OLMo-core 3 是 Ai2 于 2026 年 10 月 1 日开源的面向 MoE 模型的训练系统。它重写了 MoE 训练系统，将专家池从 8 扩到 128，总参数从 46 亿增至 470 亿，吞吐提升约 2.7 倍，并指出了 token gerrymandering 问题。
什么是 token gerrymandering？为什么它会影响 MoE 训练？
token gerrymandering 指统计分组方式让表面结果好看，但真实路由可能更失衡。例如全局看每个专家收到的 Token 数相同，但分时间窗看，每个窗口只有部分专家活跃，导致局部拥堵。训练时间由局部同步点决定，因此全局均衡分数可能掩盖分时间窗的专家热点。
如何检测 MoE 训练中隐藏的专家热点？
可以编写脚本按时间窗统计专家使用情况，计算全局变异系数和分窗峰值占比。例如文章提供的 moe_audit.py 示例，通过对比全局均衡与分窗峰值，发现全局变异系数为 0 但分窗单专家占比达 50% 的情况。
MoE 路由验收应该监控哪些指标？
应同时保留全局和分窗指标：每专家 Token 数、峰值占比、容量溢出、丢弃 Token、All-to-All 通信时间和每 GPU 等待时间。回归基准要固定 Token 分布、专家数、Top-k、批大小、精度和通信拓扑。
OLMo-core 3 中 MXFP8 低精度训练有什么收益和限制？
在 4 张 B300 控制实验中，适合使用 MXFP8 的部分开启低精度后，端到端训练吞吐比 BF16 高约 21%，峰值活跃显存从 103 GiB 降至 95 GiB。但实验使用均匀专家分布，收益主要来自前馈计算与专家交换，不意味着任意路由失衡的真实任务都会得到同样收益。
上线 MoE 训练前应该设置哪些停机条件？
任一分窗的单专家峰值占比超阈值、丢弃 Token 突然上升，或最慢 GPU 等待时间连续恶化，即使全局吞吐仍变好，也不应直接放行。这能防止用平均收益掩盖长尾故障。
