Hugging Face 团队投入 ~80 万 GPU 小时开展实验，整理成免费开放的「终极 MoE 训练手册」
全文约 7 万词，配有 55 个交互图示、可运行代码和实际实验数据，围绕训练团队最常遇到的问题展开：专家数量与大小怎么选、跨卡通信为何拖慢训练、路由与负载均衡如何设置，以及该从稠密模型改造还是从头训练。是一份把分散的 MoE 训练经验系统公开、供实践者反复查阅的工程指南。
https://huggingface.co/spaces/huggingface/moe-blogpost
MoE 到底省了什么
MoE 把部分前馈网络换成多个专家，由路由器为每个 token 选择其中几个，再合并它们的输出。因此，模型可以增加总参数量，而不按相同比例增加每个 token 的计算量。
文中示例有 64 个专家，每次选 8 个，每个专家的宽度为 1024。相较宽度 8192 的稠密前馈层，它存储约 8 倍参数，每个 token 使用的专家总宽度却相同。省的是激活计算，不是全部参数的存储需求；整个示例模型约有 68.6 亿总参数、12.2 亿激活参数。
真正难在三个环节
1. 路由要稳定。 专家选择依赖分数排序，低精度可能改变接近的分数与选择结果。手册因此强调路由计算采用 FP32，并讨论不同路由方法的取舍。
2. 专家负载要均衡。 如果大量 token 涌向少数专家，其他设备就会等待。文章比较辅助损失、无需辅助损失的偏置调整等方法。强制均匀路由的对照实验约快 1.5 倍，但它舍弃了学到的路由，只能说明速度空间，不能直接当成训练方案。
3. 通信不能抵消计算收益。 专家分布在不同 GPU 后，每层都要分发 token、收回结果。文中一次性能分析里，未被计算掩盖的通信约占一步的一半；网络配置错误、通信退回普通 socket 的案例甚至慢了约 25 倍。
从训练延伸到部署与强化学习
手册建议先检查硬件和网络、建立稠密模型基线，再逐项加入 MoE 设置，而不是一次打开所有优化。
部署时，减少每次选中的专家数可以降低计算量，但不会自动减少模型权重的显存占用，也可能影响质量。强化学习还有额外问题：生成训练数据的推理引擎，与训练引擎可能选出不同专家，造成执行路径不一致。