MoE训练最容易被忽略的坑，不是专家总数不够，而是"平均看起来很均衡，瞬时仍有专家被挤爆"。Ai2刚刚开源的OLMo-core 3把这个问题说得很直白：单一平衡分数会变好，真实路由却可能更差。对工程师而言，有用的结论是：路由验收必须分时间窗、分层、分GPU看。
发生了什么
Ai2于2026年10月1日发布OLMo-core 3，重写面向Mixture of Experts（MoE，混合专家）模型的训练系统。官方称，在每个Token仍选择4个专家的条件下，专家池从8扩到128，总参数从46亿增至470亿，吞吐降幅不到5%。在8张NVIDIA B300上，47B MoE的初步测试从每GPU每秒19400 Token提高至52000，约2.7倍。
这些都是官方基准，不是本文独立复现。更值得注意的是，技术报告记录了"token gerrymandering"：为均衡路由设计的分数可能上升，真实工作负载却更失衡。这种反例比峰值数字更值得团队带回去。
官方还报告，在4张B300的控制实验中，在适合使用MXFP8的部分开启低精度后，端到端训练吞吐比BF16高约21%，峰值活跃显存从103 GiB降至95 GiB。这一结果的边界同样重要：实验使用均匀专家分布，收益主要来自前馈计算与专家交换，不意味着任意路由失衡的真实任务都会得到同样收益。
关键事实与原理
MoE不是"参数白送"。路由器为每个Token选专家，未激活专家不参与本次计算，但权重仍要存放，Token仍要在GPU间交换。某个时间窗里，如果大量Token冲向少数专家，其他GPU空闲也无法缩短该批次耗时，因为整个步骤要等最慢的分片。
OLMo-core 3用分布式数据并行保持专家常驻GPU，再通过专家并行、流水线并行和分布式优化器分散状态。它还使用GPU驻留路由、分组GEMM（通用矩阵乘）与MXFP8精度减少数据搬运。但官方同时提醒：通信与计算重叠并不总是更快，性能对比甚至要匹配输入数值，不能只匹配矩阵形状。
所谓token gerrymandering，可以理解为"统计分组方式让表面结果好看"。若第一批只用专家0和1，第二批只用专家2和3，长时间汇总后四者数量一样，但每个批次都有一半专家空闲。训练时间由局部同步点决定，不是由整天的平均数决定。因此有效指标需要与调度和通信的时间粒度对齐。
最小实践：找出被全局均值隐藏的热点
依赖安装：无。保存为moe_audit.py，运行python3 moe_audit.py。
python
from collections import Counter
from statistics import mean, pstdev
windows = [
[0, 0, 0, 0, 1, 1, 1, 1],
[2, 2, 2, 2, 3, 3, 3, 3],
]
flat = Counter(x for window in windows for x in window)
all_counts = [flat[i] for i in range(4)]
aggregate_cv = pstdev(all_counts) / mean(all_counts)
window_peak = max(
max(Counter(window).values()) / len(window)
for window in windows
)
active_per_window = [len(set(window)) for window in windows]
print({
"aggregate_cv": aggregate_cv,
"window_peak": window_peak,
"active_per_window": active_per_window,
})
assert aggregate_cv == 0
assert window_peak == 0.5
assert active_per_window == [2, 2]四个专家全局各收到4个Token，变异系数aggregate_cv为0，看起来完全均衡；可每个时间窗只启用2个专家，单专家承担50%流量。本文代码已用Python 3.9.6实际运行，三条断言通过；示例仅验证统计逻辑，未安装OLMo-core 3，未使用GPU或复现官方吞吐。
对开发者的影响
第一，仪表盘要同时保留全局和分窗指标：每专家Token数、峰值占比、容量溢出、丢弃Token、All-to-All通信时间和每GPU等待时间。第二，回归基准要固定Token分布、专家数、Top-k、批大小、精度和通信拓扑，否则"提速"可能只是路由更均匀。第三，采用MXFP8不能只看显存，还要验收收敛质量、转换开销与目标硬件支持。
一个更完整的验收可以分三层。正确性层比较固定样本的损失、梯度与收敛曲线；系统层记录每步吞吐、峰值显存、通信占比与最慢GPU；路由层则观察专家热点、溢出、丢弃和分窗变异。只有三层同时不退化，才能说新配置真的更好。
上线前还应设置停机条件：任一分窗的单专家峰值占比超阈值、丢弃Token突然上升，或最慢GPU等待时间连续恶化，即使全局吞吐仍变好，也不应直接放行。这能防止用平均收益掩盖长尾故障。
我的判断及边界
OLMo-core 3最有价值的不是"万亿参数"标签，而是把失败尝试也写进开放技术报告。这让团队看见，并行策略、路由分布和数值精度是同一个系统问题。但官方的1.2万亿参数测试使用随机路由，2.38万亿是短时容量测试，它们证明"能跑到这个规模"，不证明长期训练的质量、成本或稳定性。
给实践者的立即建议是：不要先换路由损失，先用真实日志画出分层、分时间窗的专家热力图，并把通信耗时与丢弃Token对齐。看清堵点之后，再决定是调路由、容量因子，还是并行拓扑。
也要注意数据分布。合成随机Token能测系统上限，但不会还原多语言、代码、超长序列或特定业务样本造成的路由偏斜。回归集应包含真实数据切片和压力构造样本，两者缺一不可。
最后还要把监控开销计入基准，避免为了看见路由问题，反而制造新的同步瓶颈。
你会先为MoE训练补充时间窗负载、跨GPU通信，还是丢弃Token指标？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。