混合专家模型（Mixture of Experts，MoE）通过门控网络把每个Token动态路由到若干个专家模块，从而在控制计算量的同时扩大参数量。然而训练过程中，路由网络容易退化成只选择少数几个专家，造成热门专家过载、冷门专家几乎不更新。这种现象会降低参数利用效率，也会让模型容量无法充分发挥。解决专家闲置通常有两条路径：一是在损失函数中加入辅助损失，直接约束路由分布的均衡性；二是调整容量因子，限制单个专家可接收的Token数量。下面分别讨论它们的原理、实现与调参经验。
一、为什么MoE会出现专家闲置
MoE层通常由门控网络和多个专家前馈网络组成。对每个输入Token，门控网络输出一组分数，经过Softmax后选择Top-K个专家进行计算。理想情况下，不同Token应该被分散到不同专家，使所有专家都能获得稳定梯度。但路由网络在训练早期可能表现出强偏好，一旦某个专家在部分样本上得分略高，它就会获得更多训练信号，而训练信号反过来进一步强化这种偏好，形成马太效应。
这种倾斜现象在固定路由策略下尤为明显。以Switch Transformer为例，每个Token只选择1个专家，如果路由网络初始化不够均匀，很容易出现个别专家接收大量Token，而其他专家的路由概率接近零。当专家闲置后，其参数几乎没有梯度，反向传播不能有效更新这些专家，导致它们在后续迭代中更不可能被选中。这样不仅浪费了模型容量，还会让训练变得不稳定，因为有效参与更新的专家数量其实远小于配置值。
从优化角度看，专家闲置本质上是一个资源分配问题。门控网络需要同时考虑Token特征和负载均衡，但原始训练目标只包含语言建模或分类损失，没有显式信号告诉路由器应当均匀分配。为此，研究者提出了多种负载均衡机制，其中辅助损失和容量限制是最常用的两类。
二、辅助损失：给路由加上均衡约束
辅助损失的思想很直接：在原有任务损失之外，增加一项衡量专家负载均衡程度的损失项。最常见的做法来自Switch Transformer，它统计每个专家被路由到的Token比例 f_i，以及门控网络对该专家输出的平均路由概率 P_i。如果两者乘积的总和越接近均匀分布的理想值，说明负载越均衡。具体公式可以写成：
import torch
import torch.nn.functional as F
def load_balancing_loss(router_probs, expert_indices, num_experts):
"""计算Switch Transformer风格的负载均衡损失。
Args:
router_probs: [num_tokens, num_experts] 门控概率
expert_indices: [num_tokens, top_k] 每个Token实际选中的专家索引
num_experts: 专家总数
"""
# 每个专家的平均路由概率
density = router_probs.mean(dim=0)
# 实际被选中的频率：先将索引展平再转成one-hot
flat_indices = expert_indices.reshape(-1)
one_hot = F.one_hot(flat_indices, num_classes=num_experts).float()
freq = one_hot.mean(dim=0)
# 均匀分布下 density 和 freq 都接近 1 / num_experts
# 因此乘以 num_experts 后，理想值接近 1
aux_loss = num_experts * (density * freq).sum()
return aux_loss
上面代码中，density表示门控网络输出概率的平均值，freq表示实际分配频率。若所有专家被均等使用，二者都接近 1 / num_experts，所以乘以 num_experts 后辅助损失接近1。当路由严重偏斜时，某些专家的 density 和 freq 会同时变大，乘积和偏离理想值，损失明显上升。
在实际训练中，辅助损失不会单独使用，而是与主损失加权相加：total_loss = task_loss + alpha * aux_loss。alpha 是均衡权重，通常取一个小值，例如 0.01。权重太小则起不到约束作用，权重太大会过度限制路由选择，迫使模型把Token平均分给所有专家，反而可能损害模型表达能力。调参时可以观察三个指标：辅助损失的数值变化、各专家接收Token的方差、以及验证集上的主任务指标。
辅助损失的优点是实现简单、训练信号连续可导，能够温和地推动路由分布趋于均匀。但它也有一定局限：它优化的是统计意义上的均衡，并不保证每个批次内严格均衡。例如某个专家在全局范围内被选中的概率接近平均值，但在单个训练步内仍可能出现瞬时过载。要处理瞬时负载尖峰，通常还需要配合容量因子。
三、容量因子：从Token分配上限制拥挤
容量因子是一种硬约束机制，它规定每个专家在一个批次中最多能处理多少个Token。这个上限通常由批次Token总数、专家数量以及容量因子共同决定。计算公式为：
def compute_capacity(num_tokens, num_experts, capacity_factor):
"""计算每个专家可接收的Token上限。"""
base_capacity = num_tokens / num_experts
capacity = int(capacity_factor * base_capacity)
return capacity
当 capacity_factor 等于 1.0 时，每个专家的容量刚好等于平均分配量；大于 1.0 时允许一定程度的超额负载，小于 1.0 时则会强制丢弃一部分Token。例如一个批次有 1024 个Token、8个专家，则平均每个专家接收 128 个Token。若容量因子设置为 1.25，则每个专家最多处理 160 个Token。超过该上限的Token会被视为溢出，通常直接跳过该专家的计算，或者通过残差连接原样传递到下一层。
容量因子与辅助损失的核心区别在于：辅助损失影响的是路由网络的训练目标，而容量因子作用于前向计算过程。前者是软约束，通过梯度调整路由偏好；后者是硬约束，直接改变Token的实际去向。两者可以同时使用。容量因子能够有效防止热门专家在单个批次内被塞入过多Token，避免出现显存峰值和计算延迟不可控的问题。
但容量因子也不宜设置过小。过小的容量因子会导致大量Token被丢弃，模型容量优势被削弱，训练速度可能下降，甚至影响收敛效果。通常推荐的起始值是 1.0 到 1.5 之间。对于Top-K路由中 K 大于1的情况，容量还需要乘以 K，因为每个Token会占用多个专家的容量。
四、联合调参与训练建议
在实际工程中，辅助损失与容量因子并非彼此独立。辅助损失负责长期均衡，容量因子负责短期限流，二者配合可以让MoE训练更稳定。一个常见的调参顺序是：先固定容量因子为 1.25，调整辅助损失权重，让各专家接收Token的方差下降到可接受范围；然后再适当降低容量因子，观察是否出现Token丢弃比例过高或验证损失反弹。
还可以引入一些改进策略。例如在训练初期使用较大的辅助损失权重，快速打破路由偏好；训练后期逐渐降低权重，让模型更专注于主任务。也可以使用动态容量因子，根据最近几个训练步的负载情况自动调整容量，而不是全程使用固定值。某些实现还会对专家层使用单独的优化器，或者对门控网络施加额外的噪声，以增强探索能力。
def train_step(model, batch, optimizer, alpha, capacity_factor):
inputs, targets = batch
logits, aux_loss, router_probs = model(
inputs, capacity_factor=capacity_factor
)
task_loss = torch.nn.functional.cross_entropy(logits, targets)
total_loss = task_loss + alpha * aux_loss
optimizer.zero_grad()
total_loss.backward()
optimizer.step()
return {
"task_loss": task_loss.item(),
"aux_loss": aux_loss.item(),
"total_loss": total_loss.item(),
}
上面示例展示了训练循环中如何将辅助损失与容量因子统一起来。模型前向时需要接收容量因子，并返回负载均衡损失与路由概率。实际框架中，前向计算会先根据门控概率选出候选专家，再按照容量上限截断Token分配，最后把丢弃的Token通过残差路径传递。由于不同专家处理的Token数不同，代码通常需要借助分组矩阵或可微的排序操作实现，这也是MoE工程实现中比较复杂的部分。
最后需要强调的是，专家闲置并不是单一因素造成的。数据分布、路由初始化、学习率、专家数量、Top-K取值等都会影响负载均衡效果。辅助损失和容量因子是当前最通用的两种控制手段，但并不能完全替代对路由机制的深入分析。在遇到专家闲置问题时，建议先从监控每个专家的Token接收分布入手，再结合辅助损失与容量因子进行针对性调整。
通过软硬结合的负载管理，MoE模型可以在保持稀疏计算优势的同时，让更多专家真正参与训练和推理，从而提升模型的整体容量利用率和收敛稳定性。