80万GPU小时之后，MoE训练最贵的坑才露出来

Hugging Face团队投入约80万GPU小时做MoE训练实验，把过程和结果整理成一份免费开放的手册，约7万词，附55个交互图示、可运行代码和实际实验数据。入口在这里：The Ultimate MoE Training Handbook。Thomas Wolf在推文里给了一个判断：今天20个最佳开源模型里18个是MoE，Dense基本结束；但训练好MoE的know-how还主要留在少数团队手里。于是他们把实验写了下来。

MoE到底省了什么。它把部分前馈网络换成多个专家，路由器给每个token选其中几个，再合并输出。模型可以增加总参数量，而不按相同比例增加每个token的计算量。文中示例有64个专家，每次选8个，每个专家宽度1024。对比宽度8192的稠密前馈层，它存储约8倍参数，每个token使用的专家总宽度却相同。省的是激活计算，不省全部参数的存储需求。整个示例模型约68.6亿总参数、12.2亿激活参数。部署时先算完整权重能不能放下，再谈每token少算了多少。有网友在回复里也强调了这一点。

真正难在三个环节。第一路由要稳定。专家选择依赖分数排序，低精度可能改变接近的分数和选择结果。手册强调路由计算采用FP32，并比较softmax、sigmoid、sqrt(softplus)等路由方法的取舍。第二专家负载要均衡。大量token涌向少数专家，其他设备就会等待。手册比较辅助损失、无需辅助损失的偏置调整等方法。强制均匀路由的对照实验约快1.5倍，但它舍弃了学到的路由，只能说明速度空间，不能直接当成训练方案。第三通信不能抵消计算收益。专家分布在不同GPU后，每层都要分发token、收回结果。文中一次性能分析里，未被计算掩盖的通信约占一步的一半；网络配置错误、通信退回普通socket的案例甚至慢了约25倍。标题里说的坑，主要在这里。

专家数量怎么选。Thomas Wolf在回复里给了手册的短答案：固定总参数和激活参数时，更细的专家有帮助，但到某个点就停。一个消融里，loss一直降到128个专家，每个宽度为原来的1/4，top-8，之后不再明显下降。已发布模型多集中在128到384个专家，top-4到top-8。再往上，更小的GEMM和更多all-to-all流量会吃掉step time。所以集群上的最佳专家数通常比单看loss建议的更少稀疏。细节和Megatron参数在这个章节。

手册还从训练延伸到部署和强化学习。部署时减少每次选中的专家数可以降低计算量，但不会自动减少模型权重的显存占用，也可能影响质量。强化学习有额外问题：生成训练数据的推理引擎，与训练引擎可能选出不同专家，造成执行路径不一致。这类问题在日志里不一定报错，排查成本高。手册建议先检查硬件和网络、建立稠密模型基线，再逐项加入MoE设置，不要一次打开所有优化。

有网友提到，能复现才算交付。按他的说法，训练镜像路径、代码提交和数据清单都应记入日志；工业项目还应绑定权重哈希、推理配置和验收集版本。现场指标变了，先回放当时的版本组合，再判断是模型、数据还是环境出了问题。另一个现实问题来自小团队：到什么规模上MoE才划算，小模型直接Dense是不是更稳。这个问题在素材里没有直接答案，但手册至少把决策需要的变量摆出来了。

有网友说，把烧钱实验写成公开checklist，比再发一张分数表有用。这份材料值钱的地方，是把80万GPU小时换来的失败和调参过程写成了可反复查阅的工程指南。少踩一个通信坑，可能就省下几周。先读路由稳定性和通信那两段，再决定要不要从头训练。

原文来自meng shao的推文，Thomas Wolf的推文在这里。