混合专家模型（Mixture of Experts，MoE）的核心优势，是让模型拥有大量专家参数，却只为每个 token 激活少数专家，从而在控制计算量的同时扩展模型容量。不过，这种稀疏激活也引入了一个关键问题：如果路由器长期偏向少数专家，模型不仅无法充分利用全部参数，还可能出现设备拥塞、token 溢出、梯度波动和训练发散。因此，路由负载均衡并非单纯的性能优化，而是连接专家利用率、系统效率与训练稳定性的核心机制。
路由器为什么容易偏向少数专家
在典型 MoE 层中，路由器根据 token 的隐藏状态计算每个专家的得分，再通过 Softmax 得到路由概率，并选择 Top-1 或 Top-2 专家执行计算。问题在于，Top-k 选择具有明显的竞争性：某个专家在训练初期只要略占优势，就可能接收更多 token，获得更密集的梯度更新，随后进一步提高被选中的概率。这种正反馈如果缺乏约束，最终可能形成“热门专家越来越忙、冷门专家越来越闲”的专家坍塌现象。
专家坍塌首先会降低有效模型容量。虽然参数规模没有变化，但长期参与计算和学习的可能只有少数专家，其余专家既缺少训练样本，也难以形成有价值的专业分工。与此同时，热门专家接收的 token 数量超过预设容量后，系统可能丢弃部分 token、转交次选专家，或者扩充缓冲区，而这些处理都会影响计算效率或模型输出质量。
负载均衡如何改善专家利用率
经典方案是在语言模型主损失之外增加负载均衡辅助损失。以 Switch Transformer 的思路为例，可以同时统计专家实际接收的 token 比例，以及路由器分配给该专家的平均概率，再对两者的偏斜程度施加惩罚。这样，路由器不仅要选择当前最合适的专家，还要避免长期把大量 token 推向同一组专家。相关定义可参见 来源链接 Transformer 论文。
当负载更加均匀时，各专家都能持续获得训练样本和梯度，参数利用率随之提高。更重要的是，均衡不等于要求每个专家处理完全相同的内容，而是避免分配数量严重失衡。在合理约束下，专家仍然可以面向代码、语法、实体知识或特定表示模式形成差异化能力，只是这种专业化不能以大批专家长期闲置为代价。
理想的路由目标不是机械地平均分配，而是在“专家专业化”与“硬件可执行的负载范围”之间取得平衡。
负载失衡为什么会破坏训练稳定性
路由失衡会改变每个专家获得梯度的频率和规模。热门专家在单个训练步骤中处理大量 token，参数更新更集中；冷门专家则可能连续多个步骤几乎没有有效梯度。随着两类专家的学习速度逐渐分化，路由器的选择又会进一步偏向已经训练充分的专家，从而放大早期随机差异，使损失曲线出现震荡。
在分布式训练中，这个问题还会扩展为系统层面的不稳定。专家通常分布在不同加速器上，token 需要通过 All-to-All 通信送往目标设备。如果少数专家持续过载，一部分设备成为瓶颈，其他设备却处于等待状态，单步训练时间便由最繁忙的设备决定。GShard 使用专家容量和溢出处理来获得规则的计算形状，同时通过辅助损失改善分配，其机制可参考 来源链接 论文。
专家容量因子也是稳定性与效率之间的重要旋钮。容量设置过小，轻微的路由偏斜便可能造成 token 溢出或丢弃；容量设置过大，则需要预留更多内存与计算空间，削弱稀疏模型的效率优势。因此，容量因子不能脱离实际负载分布单独设置，应结合每层专家负载、溢出率和通信等待时间共同评估。
均衡约束并不是越强越好
负载均衡损失权重过低时，路由器可能无法摆脱赢家通吃；权重过高时，模型又可能为了满足均匀分配而忽略 token 与专家之间的语义匹配。其结果是路由器看似均衡，专家却难以形成清晰分工，甚至损害主任务质量。因此，辅助损失应被视为柔性约束，而不是要求每个批次都达到绝对平均。
统计粒度同样会影响效果。如果只在很小的局部批次内计算负载，样本波动可能让辅助损失产生噪声；如果直接混合不同 MoE 层的统计结果，又可能掩盖某一层内部的严重失衡。实践中应按层监控，并明确统计范围是否覆盖数据并行组、专家并行组以及被掩码的填充 token，避免指标本身出现偏差。
平衡不等于数值稳定
即使专家负载接近均匀，路由器的 logits 仍可能不断增大，使 Softmax 趋于饱和。此时，专家排名对微小误差更加敏感，而未被选中专家获得的有效梯度变弱，路由决策可能提前固化。ST-MoE 提出的 router z-loss 通过惩罚过大的路由 logits，改善数值稳定性；它解决的是路由器输出尺度问题，与负载均衡损失互补，而不是相互替代。相关分析见 来源链接 论文。
工程实现中，还应关注路由计算精度、初始化、学习率和梯度裁剪。路由器参数量虽然通常不大，但其决策直接决定哪些专家获得计算与梯度，因此可以考虑让 logits、Softmax 和辅助损失使用较高精度计算，并单独观察路由器梯度范数。仅查看语言模型总损失，往往无法及时发现专家利用率正在恶化。
训练时应该重点监控什么
- 专家负载分布：记录每层各专家接收的 token 数量、最大值与最小值，并观察是否长期偏斜。
- 有效专家比例：统计持续获得有效 token 和梯度的专家数量，识别几乎从不被激活的“死专家”。
- 溢出或丢弃比例：判断专家容量是否过紧，以及负载均衡约束是否真正发挥作用。
- 路由概率与熵：过低的路由熵可能意味着决策过早固化，过高则可能说明专家选择缺乏区分度。
- 通信与等待时间：结合设备级耗时判断负载问题究竟来自路由分配，还是来自网络拓扑与实现方式。
- 主损失和辅助损失：分别观察两者的变化，避免均衡目标压过语言建模目标。
更稳妥的调优顺序
- 先验证路由统计口径，确保填充 token、不同层及 Top-k 分配次数被正确处理。
- 使用较温和的均衡约束启动训练，观察是否存在持续性的专家坍塌，而不是追求瞬时平均。
- 结合溢出率调整容量因子，避免用无限扩大容量来掩盖路由失衡。
- 同步监控路由 logits、梯度范数与损失尖峰，必要时引入 z-loss 等数值稳定手段。
- 最后再调节专家数量、Top-k 和并行布局，因为这些结构参数会同时改变计算、通信与路由难度。
总结
MoE 路由负载均衡的本质，是控制稀疏选择带来的自我强化效应。均衡不足会造成专家闲置、热门专家过载、token 溢出和分布式设备等待，并通过梯度差异进一步破坏训练稳定性；均衡过强则可能压制专家专业化，损害主任务表现。更可靠的做法，是把辅助负载损失、专家容量、路由数值稳定性和分布式通信放在同一套监控框架中，以“负载不过度偏斜、专家保持差异化、训练没有异常尖峰”为共同目标。只有做到这一点，MoE 扩大的才是可用模型容量，而不只是账面参数数量。
