MoE 的设计很优雅——但如果你真的去训练一个，会发现它像一个精密但脆弱的生态系统：任何微小的不平衡都会被放大到灾难级别。这篇来聊怎么驯服它。

马太效应：为什么 Expert 会坍塌

想象你开了一家公司，有 8 个员工（experts）。刚开始大家水平差不多，但因为运气，Employee 1 接到了几个好项目，表现不错。老板（router）注意到了，开始优先把新项目分给 Employee 1。

Employee 1 得到更多项目 → 经验更丰富 → 表现更好 → 老板更信任 → 分配更多项目…

其他 7 个员工逐渐被边缘化，最终完全闲置。你花了 8 个人的工资，只有 1-2 个人在干活。

这就是 Expert Collapse（专家坍塌）——MoE 训练中最致命的问题。没有干预措施的话，它必然发生。

训练初期：均匀分配 训练后期：坍塌 E1 E2 E3 E4 E5 各 ~20% 负载 ✓ → 马太效应 E145% E330% E2 E4 ☠️ E5 2个expert干活，3个半死不活 ✗ 花了 5 个 expert 的钱，只得到了 2 个 expert 的效果 → 必须干预

辅助损失：强制维持公平

解决方案的直觉很简单：惩罚不均匀的分配。

我们需要两个信号：

  • f_i：Expert i 实际拿到了多少 token（”结果”）
  • P_i：Router 给 Expert i 分配的平均概率（”意愿”）

把它们乘在一起：如果某个 expert 既拿到很多 token，又被 router 给了很高概率，乘积就大，惩罚就重。这逼迫 router “分散投资”而不是”押注一个”。

但这里有个根本矛盾——惩罚系数 α 太大会让 router 变成随机分配器（只追求均匀，不考虑谁最合适）。太小则无法阻止坍塌。你不得不在”均匀性”和”路由质量”之间做权衡。

这个矛盾直到 DeepSeek-V3 才被优雅解决——后面讲。

容量因子：Expert 满了怎么办

即使有辅助损失，分配也不可能完美均匀。当一个 expert 收到的 token 超过缓冲区容量时：

Token Dropping（丢弃）：溢出的 token 直接跳过，只走 residual connection。简单但损失信息。

Token Rerouting（重路由）：发到第二选择 expert。保留信息但实现复杂。

容量因子 CF = 1.25 意味着给每个 expert 留 25% 的余量。CF 越大越安全，但越浪费内存。

三种急性训练不稳定

Routing Oscillation（路由振荡）

Token 在 expert 之间反复跳——就像一个频繁跳槽的员工，每份工作都干不长，所以每份都没学到深度。Expert A 刚开始学数学，router 觉得它学得太慢，转给 Expert B，B 也是从零开始…循环往复。

Expert Death（专家死亡）

比坍塌更极端——某个 expert 的路由概率降到恰好为零，永远不再接收 token。参数永远不更新，不可逆地”死”了。

Softmax 饱和

Router 的 logit 越来越大 → softmax 输出趋近 one-hot → 梯度接近零 → router 被”锁死”，无法调整路由。就像一个越来越固执的路由器：越来越确信自己对，同时越来越听不进新信息。

Router Z-Loss：驯服大 Logits

惩罚 logits 的尺度。具体方式：对每个 token 的 logits 算 log-sum-exp（所有 logit 最大值的平滑近似），取平方作为惩罚项。

logits 适度时惩罚几乎为零（不干扰正常训练），变大时快速增长（强力阻止）。和辅助损失正交——辅助损失管均匀性，Z-Loss 管数值稳定性，两者同时使用。

DeepSeek-V3 的突破：无辅助损失的负载均衡

DeepSeek 问了一个关键问题：能不能完全不通过梯度来实现均衡？

答案是动态偏置——给每个 expert 的路由分数加一个 bias bᵢ，但这个 bias：

  1. 只影响”谁被选中”（Top-K 决策），不影响选中后的权重
  2. 不参与反向传播——用简单规则更新：负载高了就减 bias，低了就加

这意味着 router 的梯度完全不受干扰——它可以纯粹优化”找最好的 expert”，均衡性由一个独立的、非梯度的机制来保证。

效果：比传统辅助损失方法性能更好。有时候最好的方案就是把”学习目标”和”约束机制”解耦。

Expert Parallelism：GPU 间的快递系统

256 个 expert 不可能塞进一块 GPU。解决方案：每块 GPU 放一部分 expert，token 按需在 GPU 间传输。

All-to-All 通信：每块 GPU 都要和其他所有 GPU 交换 token GPU 0 (Expert 1,2) 持有 token A,B,C GPU 1 (Expert 3,4) 持有 token D,E,F GPU 2 (Expert 5,6) 持有 token G,H,I GPU 3 (E7,8) token J,K,L All-to-All: token 按目标 expert 发送到对应 GPU 通信 (Dispatch) 本地 Expert 计算 通信 (Combine) 优化目标：让红色（通信）和绿色（计算）尽量重叠

流程：Router 决定 token 去哪 → All-to-All 把 token 发到对应 GPU → 本地 expert 计算 → All-to-All 把结果送回。

All-to-All 是最昂贵的集合通信操作——每块 GPU 都要和所有其他 GPU 交换数据。优化的关键是让通信和计算重叠，DeepSeek-V3 的 DualPipe 方案几乎完全做到了这一点。

下一篇预告

模型训好了——但怎么高效地跑推理？MoE 的稀疏激活给推理带来了独特的机会和挑战：prefill 时负载均衡、decode 时大部分 expert 闲置、内存里要装所有 expert 但每次只用几个…下一篇来聊 MoE 的效率哲学和未来方向。