MoE 专家负载不均衡：不是调个参数就能解决的事

MoE 的负载不均衡是个老问题，但真正在生产里踩过一轮的人会发现，它很少表现为“某个专家被选得太多”这么单纯。它更像一条连锁反应：早期路由偏差 → 少数专家被训练得更充分 → 这些专家输出更可靠 → 门控更偏向它们 → 其余专家逐渐变成参数上的摆设。IBM 在介绍 MoE 时把这种情况称为自我强化循环，并指出少数专家会承担过多 token，剩下的专家“沦为累赘”。Qwen 团队在全局负载均衡的博客里也写了类似的机制：被频繁选择的专家被优化得更多，进一步被更频繁地选择。

下面把我对这个问题的理解拆开讲，重点在工程上哪些地方会真的疼。

先分清两层：训练时的均衡与部署时的均衡

负载均衡损失（load balance loss，LBL）是训练侧的常规手段。Red Hat 的解释比较直白：当门控网络因为反复选同一个专家而被惩罚，它就学会把 token 摊开。但这只解决训练侧。推理时的问题换了个形状：专家并行把专家分到了不同 GPU 上，门控把太多 token 路由到同一张卡上的专家，那张卡就成了瓶颈，其余卡在等。这是调度层面的不均衡，跟 LBL 数值好看不好看关系不大。

所以看到“负载均衡指标正常”就放心，是不太可靠的。训练日志里的均衡度和线上的 TPOT、GPU 利用率峰值，往往对不上。

Top-k 路由的容量因子，是个减法不是加法

控制单个专家负载最直接的手段是容量因子（capacity factor）。常见配置是 top-2 路由加 1.25 容量因子，即每个 token 选两个专家，每个专家处理其平均容量的 1.25 倍。超过这个容量的 token 会被丢弃或绕过该专家，也就是所谓的 token dropping。

这里有个容易被忽略的取舍：容量因子调小，算力和显存更可控，但长尾分布的输入会丢 token，表现为某些领域、某些语种的质量掉得厉害；调大则在不均衡时保留更多 token，但显存峰值和通信量上去。工程上很难两头都占。一个务实的做法是按输入领域分别看丢 token 率，而不是只看全局平均值。

Noisy top-k 与 GShard 的两条路

Shazeer 等人在 2017 年的稀疏门控工作里用了 noisy top-k gating：给每个专家的概率加一点高斯噪声，引入随机性推动分布均匀，同时加上负载均衡损失和专家多样性损失两个可训练正则项。这是最经典的一组手段。

Google 2020 年的 GShard 论文另外给出了两类做法，思路偏向系统层：用辅助损失约束路由分布，以及用容量约束配合随机路由来限制单专家的 token 数。前者是软的，影响模型学到的路由结构；后者是硬的，影响实际计算图的形状。选哪个，取决于你能接受训练行为被改变，还是愿意放弃一部分 token。

分组路由：用减少选项换来均衡

当专家数量上去（超过 32 个左右）时，逐个专家做全局选择的通信开销很可观。DeepSeek-MoE 采用的是两级选择：先选 Top-N 个组，再在组内选 Top-K 个专家。这个设计有个朴素的直觉：备选项变少，把负载分摊均匀更容易。同时组级调度让通信变得更有规律，训练吞吐能受益。

不过分组本身会带来新的偏向。如果分组方式跟数据分布暗合，某几个组会系统性更热，局部均衡还好，组间可能又开始倾斜。所以分组策略上线后，组级别的路由分布也得单独看。

DeepSeek-MoE 另一个出现在公开描述里的手段是偏置调整：每个专家维护一个偏置值参与门控，被过度使用的专家偏置调高、降低被选中的概率，负载轻的专家反向调整。这相当于把均衡做成一个在线反馈环路，而不是靠一次性损失项。代价是多了一套需要观测和调参的运行时状态，极端情况下可能振荡。

Qwen 的全局均衡：放松局部，换专家特异化

Qwen 团队公开的实验结果值得单拎出来：主流框架里的 LBL 实际上是局部的负载均衡，要求每一批局部输入都均匀分给不同专家。但局部 batch 往往只来自少数领域，强行均分反而压制了专家按领域分化的倾向。他们把局部均衡放松为全局均衡后，专家特异化明显增强，模型效果提升；副作用是局部均衡指标变差，给计算效率带来一定影响。于是他们的方案是主用全局均衡、训练中再掺一点局部均衡（默认的 LBL）。

这一点的工程含义是：你不能简单把“每个 batch 内专家利用率方差”当核心指标去优化，那个指标和模型质量之间并非单调关系。

上线时我会先看什么

• 专家级 token 计数的长尾分布，而不是均值。头部的那些专家是不是稳定地占了几倍于均值的量。
• GPU 维度的等待时间。判断瓶颈是算力、通信还是排队。
• token dropping 率按领域拆分，识别被系统性牺牲的输入类型。
• 路由分布的漂移。同一个部署跑几天后，分布是否慢慢向某些专家聚拢。

负载不均衡不是一个要“消灭”的状态，而是一个需要持续观测并在质量、吞吐、成本之间反复找平衡的状态。把它当成一条有反馈环路的动态系统，比当成一个可以一口气调好的超参，要更接近实际。