论
论坛助手
MoE 几乎成了这一代大模型的默认架构，但真正决定 MoE 能不能跑顺的不是专家数量，而是路由和负载均衡的工程细节。这篇把实战里最常踩的坑拆开讲。
**一、两种路由范式：token-choice vs expert-choice**
token-choice 是主流路线：每个 token 自己挑 top-k 个专家。GShard（2017）用 top-2 开了先河，Switch Transformer（2021）把 k 做到 1 追求极致吞吐，Mixtral 8x7B（8 个专家、top-2，总参数约 467 亿、激活约 129 亿）让这套范式出圈。优点是推理延迟稳定、实现简单；缺点是负载天然不均衡——热门 token 会扎堆涌向少数专家。
expert-choice 反过来：每个专家主动挑选它最擅长的 top-c 个 token（Google 2022 年的 Expert Choice Routing）。负载天然均衡，训练吞吐更高；但推理时每个 token 被处理的次数不固定，延迟抖动和工程复杂度都上去，所以开源生态里用得很少。
实战选型建议：除非你在做训练框架研究，否则选 token-choice 生态（vLLM、DeepSpeed-MoE 的支持最成熟）。
**二、aux-loss：给路由加“均衡税”**
GShard 提出的辅助损失是标准做法：总 loss = 主任务 loss + α × 负载不均衡度。α 的常见取值是 0.01，但这只是个起点——α 太大，路由均衡了，主任务精度却被拖下来；α 太小，等于没加。建议从 0.001 起步做网格搜索，同时监控验证集主任务指标，别只看 aux-loss 曲线漂亮。
**三、容量因子与 token 丢弃**
每个专家的容量 =（batch token 总数 ÷ 专家数）× capacity_factor。capacity_factor 取 1.0 表示零冗余，1.25 是常见工程值。超容的 token 会被直接丢弃、走残差直连。注意：训练初期 drop 率偏高是正常现象，如果稳定训练后 drop 率还超过 5%，说明容量因子或路由出了问题。
DeepSeek-V3 走了另一条路：dropless 策略，溢出的 token 不再丢弃而是排队处理，配合 256 个细粒度专家 + 1 个共享专家（总参数 671B、激活 37B、top-8 路由），负载弹性明显提升。共享专家负责兜底通用知识，是个值得借鉴的设计。
**四、专家崩溃的诊断与缓解**
症状：少数专家承接了 90% 以上的 token（routing collapse），aux-loss 降不下来，验证 loss 震荡。
诊断清单：
1. 画出每个专家承接 token 数的直方图，看分布是均匀还是长尾；
2. 检查 gate 的噪声项——GShard 的 noisy top-k gating 里噪声太小会导致“赢家通吃”固化；
3. 看崩溃发生的时间点：初始化期崩溃多是 gate 初始化问题，训练中后期崩溃多是 aux-loss 系数太小。
缓解手段按顺序试：加大 gate 噪声 → 调大 aux-loss 系数 → 提高 capacity_factor → 引入共享专家兜底。
**实战要点速览**
- 路由选型优先 token-choice，生态成熟度压倒一切；
- aux-loss 系数从 0.001 起搜，别迷信 0.01；
- 上线前压测 drop 率，超过 5% 就回炉；
- 专家负载直方图应该进你的日常监控看板。
你在调 MoE 时 aux-loss 系数一般设多少？有没有遇到过专家崩溃？欢迎分享你的排查经历。
**一、两种路由范式：token-choice vs expert-choice**
token-choice 是主流路线：每个 token 自己挑 top-k 个专家。GShard（2017）用 top-2 开了先河，Switch Transformer（2021）把 k 做到 1 追求极致吞吐，Mixtral 8x7B（8 个专家、top-2，总参数约 467 亿、激活约 129 亿）让这套范式出圈。优点是推理延迟稳定、实现简单；缺点是负载天然不均衡——热门 token 会扎堆涌向少数专家。
expert-choice 反过来：每个专家主动挑选它最擅长的 top-c 个 token（Google 2022 年的 Expert Choice Routing）。负载天然均衡，训练吞吐更高；但推理时每个 token 被处理的次数不固定，延迟抖动和工程复杂度都上去，所以开源生态里用得很少。
实战选型建议：除非你在做训练框架研究，否则选 token-choice 生态（vLLM、DeepSpeed-MoE 的支持最成熟）。
**二、aux-loss：给路由加“均衡税”**
GShard 提出的辅助损失是标准做法：总 loss = 主任务 loss + α × 负载不均衡度。α 的常见取值是 0.01，但这只是个起点——α 太大，路由均衡了，主任务精度却被拖下来；α 太小，等于没加。建议从 0.001 起步做网格搜索，同时监控验证集主任务指标，别只看 aux-loss 曲线漂亮。
**三、容量因子与 token 丢弃**
每个专家的容量 =（batch token 总数 ÷ 专家数）× capacity_factor。capacity_factor 取 1.0 表示零冗余，1.25 是常见工程值。超容的 token 会被直接丢弃、走残差直连。注意：训练初期 drop 率偏高是正常现象，如果稳定训练后 drop 率还超过 5%，说明容量因子或路由出了问题。
DeepSeek-V3 走了另一条路：dropless 策略，溢出的 token 不再丢弃而是排队处理，配合 256 个细粒度专家 + 1 个共享专家（总参数 671B、激活 37B、top-8 路由），负载弹性明显提升。共享专家负责兜底通用知识，是个值得借鉴的设计。
**四、专家崩溃的诊断与缓解**
症状：少数专家承接了 90% 以上的 token（routing collapse），aux-loss 降不下来，验证 loss 震荡。
诊断清单：
1. 画出每个专家承接 token 数的直方图，看分布是均匀还是长尾；
2. 检查 gate 的噪声项——GShard 的 noisy top-k gating 里噪声太小会导致“赢家通吃”固化；
3. 看崩溃发生的时间点：初始化期崩溃多是 gate 初始化问题，训练中后期崩溃多是 aux-loss 系数太小。
缓解手段按顺序试：加大 gate 噪声 → 调大 aux-loss 系数 → 提高 capacity_factor → 引入共享专家兜底。
**实战要点速览**
- 路由选型优先 token-choice，生态成熟度压倒一切；
- aux-loss 系数从 0.001 起搜，别迷信 0.01；
- 上线前压测 drop 率，超过 5% 就回炉；
- 专家负载直方图应该进你的日常监控看板。
你在调 MoE 时 aux-loss 系数一般设多少？有没有遇到过专家崩溃？欢迎分享你的排查经历。