TL;DR
2026 年新建开源 MoE 栈，更省时间的起点是 DeepSeek 模板：64–128 routed experts + 1 shared expert（需要更大容量再到 256），负载均衡优先用 aux-loss-free 的 router bias EMA，router z-loss 从 1e-3 量级起步，并把前 ~2000 step 的 dead-expert 数、usage CV、token drop 当作硬门槛指标。[4][3][2][9] 这套模板的优势不在“每个基准都最好”，而在同时压低三类最常见事故：拥塞导致 token drop（吞吐抖动）、aux loss 的实现敏感性与梯度干扰、以及粗粒度专家难分化。[6][7][18] 反方最有信息量的质疑是 ROI：dense→MoE upcycling 的 scaling law 给出收益上限与饱和区间，并提示 token-rich 才划算；系统侧 all-to-all/dispatch 细节能吞掉理论稀疏收益。[1][11][13] 目前最缺的是 matched ablation：bias EMA 是否在质量上优于 aux loss，以及 fine-grained+shared 在计入系统成本后是否仍净赚。[3][7][13]
核心断言
§0 演进谱系：四次重写 + 两次分叉
Shazeer→GShard→Switch→ST-MoE 主线;Expert-Choice 与 aux-loss-free 是仅有的两次真正分叉
MoE 在 LLM 里经历了四次改写，每次都不只是“换路由”。[24] 提出 sparsely-gated 架构与 load loss 的雏形；[6] (GShard) 把它扩到模型并行，引入 capacity factor 与 token drop；[5] (Switch) 把 top-2 简化成 top-1，并把 aux loss 调成可大规模工程化的形式；[9] 针对 router 数值不稳引入 router z-loss，并整理出至今仍是默认项的 sparse 训练 stability checklist。这条主线在 2022 年遇到第一个分叉：[10] 提出 expert-choice routing，用“专家选 token”一次性解决均衡问题，但这个 trick 在自回归 LM 里需要看到全序列、与因果性不兼容，因此退到了编码器与训练期工具的位置。
2023–2024 是 MoE 在开源端的兑现窗口。[17] (Mixtral 8×7B) 把 token-choice + aux-loss-tuned 模板带进开源 LLM 主流。几乎同时，DeepSeek 的两次重写把 MoE 推到第二个分叉点：[2] 把 expert 数从“每层 8 个，每个 ~7B”推到“每层 64–128 个 fine-grained expert + 1 个 always-on shared expert”，把“公共成分”从 router 决策里剥离出来；[8] 把这套结构与 MLA 一起 ship 到 235B 总参 / 21B active 的实际 ladder 上验证；[4] 进一步把 [3] 的 aux-loss-free bias EMA 作为默认均衡机制，并保留 router z-loss 处理数值溢出。到 [16] 这一代，开源社区已经把 “fine-grained + 1 shared + bias EMA + z-loss” 当作 MoE 的默认 recipe；争论也从“路由怎么写”转向“ROI 是否兑现”——upcycling 饱和、dispatch / all-to-all 与 token packing 是否吃掉稀疏的纸面收益。
§1 默认模板：DeepSeek 把 MoE 的三类事故变成可监控的硬门槛
更稳的读法是：DeepSeek 模板的优势在于把 MoE 事故前移为早期可观测信号。结构上，它用 fine-grained routed experts（64–128 起步，容量不足再到 256）+ 1 shared expert，将公共模式从 routed experts 中剥离，降低专家相似化和分化失败。[2][8] 均衡上，它用 bias EMA 替代 aux loss，将均衡从主梯度中解耦，避免为了均衡牺牲表示学习，并降低实现敏感性。[3][7][4] 稳定性上，它把 token drop、usage CV、dead-expert 设为前 ~2000 step 的硬门槛指标：这些指标早期一旦失控，后续通常只能靠大幅降学习率/改并行策略/重启补救，代价高且结果不可预测。[4][5][6] 这也解释了为何 z-loss 仍保留：它处理 router logit overflow 的数值稳定性问题，与均衡目标正交，是低成本保险丝。[9][4]
把 MoE 当作“可控系统”而不是“可调超参集合”：早期指标硬门槛 + 外环均衡 + 结构上分离公共成分。[4][3][2]
§2 负载均衡的分歧点：aux loss 是“主梯度正则”，bias EMA 是“外环控制”
aux load-balancing loss 的核心问题不在目标（usage 更均匀），而在于它把均衡信号写入主梯度，带来两类副作用。第一是实现敏感性：Qiu et al. [7] 显示，micro-batch vs global 统计、是否 detach、跨 DP 同步方式会主导 usage CV 与分化结果，影响幅度可超过系数调参；这使“同一论文结论”在不同代码库中难以稳定复现。第二是梯度干扰：均衡项在早期强行拉平流量，可能压制本该自然形成的专家分化，在 coarse experts 或容量紧张时尤其明显。[6][18] bias EMA 的关键改变，是把均衡移到外环：主损失只学表示，均衡通过更新 router bias 调节流量分配；工程上它更像控制器而非正则项，因此更容易用 bias norm、dead-expert 恢复速度来监控与回滚。[3][4] 这一路线并不否认 aux loss 可用，而是把它降级为“必须产品化实现细节才能可靠使用”的选项：如果统计口径与同步策略没有锁死，aux loss 的系数调参通常是最后一层，而不是第一层。[7][3]
| 维度 | aux load loss（GShard/Switch 系） | bias EMA / sign 更新（DeepSeek/Wang 系） |
|---|---|---|
| 信号进入路径 | 主损失梯度里加正则项；与表示学习耦合 | 外环更新 router bias；主损失梯度不含均衡项 |
| 实现敏感性来源 | 统计口径、detach、DP 同步方式主导效果 | 主要体现在步长/EMA 系数与目标 usage；更易锁死 |
| 主要失败模式 | 均衡过强导致分化受抑；或实现差异导致“看似均衡但不分化” | 步长过大导致 bias 振荡；步长过小 dead-expert 恢复慢 |
| 可观测性与回滚 | loss 分解不直观；需要额外记录统计细节才能定位 | bias norm、usage CV、dead-expert 曲线直接对应控制环状态 |
| 代表性证据 |
§3 专家结构：为什么 64–128 + shared 往往比 8×7B 更稳
“细粒度 + shared”可以理解为对 MoE identifiability 的工程化处理：当 routed experts 同时承担公共模式和长尾差异时，路由器早期容易把大量 token 压到少数专家，其他专家则变成 dead experts 或学到相似功能，外显为 usage CV 高、分化弱，甚至表示塌缩。[18][5] DeepSeekMoE 将 routed experts 提到 ≥64，并加入 1 个 shared expert 承接公共成分，等价于给 routed experts 留出“只学差异”的空间；在相同 active 参数预算下报告 1.8–3.4 pp 的 zero-shot 增益区间，说明该效果不是某个小规模设定的偶然结果。[2] DeepSeek-V2 将这一结构扩展到更大规模，并公开 active/total 与评测，强化了“结构默认值可复刻”的属性。[8] 相比之下，Mixtral-style 的 coarse experts（例如 8 experts、top-2）更像是“扩大容量但不拆分公共成分”：在一些任务上仍然强，但更依赖均衡与容量因子来避免拥塞和相似化；这也是 2024 年后开源 MoE 模板从 coarse 转向 fine-grained+shared 的直接驱动力之一。[17][2][6] shared expert 不是免费午餐：它增加固定计算与参数常驻，通常换来更低的路由不确定性和更可控的分化过程。[23][4]
§4 ROI 争论的硬约束：upcycling 饱和 + 系统吞吐兑现
MoE 是否“更划算”，必须按训练路径拆账：从零训练的 MoE 用 active/total 结构拉开容量；dense→MoE upcycling 以复用既有权重与后训练资产为前提，收益上限更早到来。[4][1] Liew et al. [1] 给出一个可执行约束：upcycling 的有效 token 等效系数约 0.4–0.6×，且存在“加专家不加质”的饱和区间；因此 token-rich checkpoint 更可能划算，而 token 不足的 dense 直接 upcycle 可能边际收益为负。[1][11] 第二条硬约束是系统兑现：即使训练 FLOPs 下降，dispatch/all-to-all、token packing 与 kernel 调度也可能吞掉吞吐收益，甚至放大 tail latency 与故障域；在生产决策中，这些问题往往早于“多 1–2 pp 基准分”触发否决。[13][14] 这也是 dense 阵营在全生命周期 ROI 上更稳的原因之一：单机/小集群 serving、KV cache 常驻、后训练稳定性与可复现性更容易形成工程闭环。[15][16] 更务实的结论是：MoE 收益必须在“同一套系统栈 + 同一条训练路径”上对照；否则讨论会被路径差异与系统差异淹没。[13][1]
时间线
- GShard 固化 token-choice + capacity factor + aux load loss 的工业骨架[6]
- Switch 用 top-1 简化 MoE，实现门槛下降但更依赖均衡与容量控制[5]
- ST-MoE 引入 router z-loss，定位为数值稳定保险丝[9]
- expert-choice 把容量约束内化进路由，但 decoder-only 推理受 causal 约束[10]
- DeepSeekMoE 推出 fine-grained + shared 的结构默认值[2]
- aux-loss-free bias EMA 把均衡从主梯度剥离[3]
- DeepSeek-V3 把 bias EMA 与监控面板产品化，形成可复刻模板[4]
- upcycling scaling law 给出 ROI 上限与饱和区间[1]
研究立场对比
阵营 A：MoE 将成为 frontier 预训练默认骨干（dense 留给小模型/边缘）
立场 — 在固定训练 FLOPs 下，MoE 通过更大的 total 参数提供更高知识容量；随着 fine-grained+shared 与 aux-loss-free 均衡模板成熟，训练事故率下降到可接受水平，因此从零预训练更倾向直接上 MoE。
反方 — 需要把系统兑现与全生命周期成本算进去：dispatch/all-to-all 可能吞掉稀疏收益；并且 upcycling 路径在真实组织里更常见，收益存在饱和区间（修正 c-a25fb78820、c-364cf0aacb）。[13][14][1]
判词 — 更务实的定位：frontier 从零预训练优先 MoE，但前提是把系统实现与监控面板当作同等一等公民；否则 dense 的确定性更高。
阵营 B：dense 在全生命周期 ROI 上更稳，upcycling 让 MoE 的边际收益更早饱和
立场 — 真实组织更常见的是复用既有 dense 权重与后训练资产；upcycling scaling law 显示收益上限与 token-rich 依赖，且系统开销与稳定期成本会侵蚀稀疏收益，因此继续扩容 dense 更稳。
反方 — 这条论证多发生在 upcycling 路径；当目标是 frontier 级从零预训练且能复刻 DeepSeek 的监控与均衡模板时，MoE 的 active/total 结构仍能把容量拉开（保留 c-fcaf30ab3）。[8][4][3]
判词 — 结论层面的建议：如果组织的主路径是 dense checkpoint 复用与频繁后训练迭代，优先把 ROI 预算投在 dense；MoE 只在 token-rich 且系统兑现已验证的区间做。
阵营 C：学习路由/均衡被高估，随机/冻结路由也能接近（路由技巧 ROI 低）
立场 — 许多 MoE 增益来自更大总参数与稀疏激活的容量效应，而非精细路由；在部分设定下随机/冻结路由器也能接近学习路由的验证性能，因此把大量精力投入路由技巧不划算（保留 c-146ac8e7fd）。[19]
反方 — 把“路由是否聪明”与“拥塞是否可控”混在一起会误导工程决策：DeepSeek 的关键不是更复杂路由，而是用 bias EMA + 早期硬门槛把 token drop 与 dead experts 压到可控区间；这在吞吐与稳定性上直接影响训练是否能跑完。[4][3][7]
判词 — 一条更稳的读法：不需要追求花哨路由，但必须把均衡与拥塞控制当作一等工程目标；“随机路由也行”最多支持少做路由技巧，不支持少做监控与均衡。
阵营 D：MoE 主要用于预训练；后训练应切回 dense 或做阶段解耦
立场 — SFT/DPO/RLHF 更看重稳定优化与可控吞吐；稀疏路由引入额外噪声与系统复杂度，因此应采用 dense training + sparse inference，或把后训练资产从 dense 迁移到 MoE（保留 c-fc62560626、c-28626f3247）。[20][21]
反方 — DeepSeek-V3 报告在保持 256 experts 结构下完成对齐阶段并取得一线效果，说明“MoE 后训练不可行”更像是工程门槛而非结构性不可能（修正 c-d7ca5574a2）。[4]
判词 — 结论层面的建议：后训练默认先按 dense 方案设计吞吐与稳定性预算；只有当 MoE 的系统与监控已达到预训练同等级别的可观测与回滚能力时，再把对齐留在 MoE 上。
实践要点
可执行清单（2026 Q2）：
1) 默认结构：新建 MoE 栈直接落地 fine-grained 64–128 routed experts + 1 shared expert；只有在明确容量不足（例如 usage 长期饱和且 shared 负担过高）时再到 256。[2][4]
2) 监控先于调参：把 token drop、usage CV、dead-expert、router bias norm 做成训练面板的一级指标；前 ~2000 step 任一指标失控就停训定位，而不是“再跑跑看”。[4][5]
3) 均衡优先选 bias EMA：把 aux loss 视为“需要锁死统计口径/DP 同步/detach 细节才能用”的选项；如果代码库还在快速迭代，先不要把稳定性押在 aux loss 系数上。[3][7]
4) z-loss 当保险丝：router z-loss 从 1e-3 量级起步；它主要防 logit overflow 与早期流量塌缩，不要指望它替代均衡策略。[9][4]
5) 不要把“路由技巧”当主战场：除非有明确的 token drop/拥塞证据，否则优先把时间花在 dispatch、token packing、all-to-all 调度与 kernel 兑现上；系统没兑现时，路由再聪明也只是在更慢的系统上做更复杂的决定。[13][14]
6) upcycling 先做 ROI 体检：dense→MoE 前先确认 checkpoint 是否 token-rich；把 token 等效系数按 0.4–0.6× 做保守预算，并把稳定期成本计入总账；不满足就继续训 dense 或延后 upcycle。[1][11][12]
7) coarse experts 不是禁区，但要配套：如果选 Mixtral-style coarse（少量大专家），就把“分化失败/相似化”当作默认风险，提前准备更强的均衡与容量策略，并用分化指标做回归测试。[17][18][6]
8) 后训练默认按 dense 预算：SFT/DPO/RLHF 先用 dense 方案把吞吐与稳定性闭环；只有当 MoE 的监控与回滚能力达到预训练同等级别，再考虑把对齐留在 MoE 上。[20][4]
悬而未决的问题
- Q1.matched ablation：在同一代码库、同一并行策略、同一监控口径下，bias EMA 与 aux loss 的质量差异是多少（不仅是 usage CV），以及差异是否随 expert 数（64/128/256）改变？等待公开的 LLM 规模对照与训练日志。[3][7]
- Q2.fine-grained + shared 的“净收益”需要计入系统成本：在同一 serving 栈上，把 dispatch/all-to-all、token packing、KV cache 与常驻参数的成本算进去后，64–128+shared 相比 coarse MoE 与 dense 的端到端 $/token 是否仍更低？等待可复刻的系统基准。[13][14][2]
- Q3.expert-choice 在 decoder-only 下的 causal 约束是否有可用的工程折中（例如分块/两阶段 prefill），能否在不破坏推理语义的前提下降低 token drop？目前更多停留在机制层面，缺少开源实现与端到端评测。[10]
- Q4.MoE 后训练的稳定性边界：哪些不稳定来自 router gradient 稀疏与专家分化，哪些来自系统吞吐抖动与数据并行噪声？需要把对齐阶段的监控指标（token drop、usage CV、dead experts）与 reward/kl 曲线对齐做公开对照。[4][20]
- [1]Seng Pei Liew, Takuya Kato, Sho Takase. Scaling Laws for Upcycling Mixture-of-Experts Language Models. ICML, 2025论文
- [2]Damai Dai, Chengqi Deng, Chenggang Zhao, R. X. Xu, Huazuo Gao, Deli Chen. DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models. ACL, 2024论文
- [3]Lean Wang, Huazuo Gao, Chenggang Zhao, Xu Sun, Damai Dai. Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts. arXiv, 2024论文
- [4]
- [5]William Fedus, Barret Zoph, Noam Shazeer. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. JMLR, 2022论文
- [6]Dmitry Lepikhin et al.. GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding. ICML, 2021论文
- [7]Zihan Qiu, Zeyu Huang, Bo Zheng, Kaiyue Wen, Zekun Wang. Demons in the Detail: On Implementing Load Balancing Loss for Training Specialized Mixture-of-Expert Models. arXiv, 2025论文
- [8]DeepSeek-AI. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model. Technical report, 2024报告
- [9]
- [10]
- [11]Aran Komatsuzaki et al.. Sparse Upcycling: Training Mixture-of-Experts from Dense Checkpoints. LessWrong (post), 2022博客
- [12]
- [13]
- [14]et al.. Elephants in the Room: Serving and Systems Realities for Sparse Models. Industry talk, 2022演讲
- [15]Allen Institute for AI (AI2) et al.. OLMo 2 Technical Report / Release Notes. Technical report, 2024报告
- [16]Allen Institute for AI (AI2) et al.. OLMo 3 Technical Report / Release Notes. Technical report, 2025报告
- [17]
- [18]et al.. On Representation Collapse and Expert Specialization in Mixture-of-Experts (analysis paper). arXiv, 2022论文
- [19]
- [20]
- [21]
- [22]et al.. On the Convergence of Aux-Loss-Free Load Balancing for Mixture-of-Experts. OpenReview, 2025论文
- [24]Noam Shazeer, Azalia Mirhoseini, Krzysztof Maziarz, Andy Davis, Quoc Le, Geoffrey Hinton, Jeff Dean. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. ICLR, 2017论文