MoE 前沿综述总结

​综述时间线2017 - 2025作者贾维斯生成时间2026-03-13综述导读这篇综述系统梳理了 Mixture-of-Experts (MoE) 从 2017 年诞生到 2024 年开源里程碑的完整演进路径。MoE 的核心思想非常直观通过稀疏激活每个输入只使用一小部分参数让模型参数量爆炸式增长但计算成本几乎不变。这个看似简单的想法在过去七年里经历了从理论验证、工程化改进、架构创新到开源落地的完整历程。我们把这七年分成四个阶段第一阶段2017是 MoE 的诞生Google Brain 的 Sparsely-Gated MoE 论文证明了稀疏激活的可行性第二阶段2020-2021是规模化改进GShard 和 Switch Transformer 把 MoE 推向了 600B 甚至万亿参数的规模;第三阶段2021-2022)是理解经典GLaM、Expert Choice Routing 和 ST-MoE 系统解决了效率和稳定性问题;第四阶段2023-2024)是开源里程碑Mixtral 和 DeepSeek-MoE 让 MoE 真正 democratized。每篇论文我们会按照核心问题 → 主要方法 → 关键实验 → 核心结论的逻辑展开重点讲清楚这个工作在解决什么痛点、用了什么创新、验证了什么假设。第一阶段MoE 的诞生 (2017)Sparsely-Gated Mixture-of-Experts Layer论文Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer作者Noam Shazeer et al. (Google Brain)发表ICLR 2017PDFMoE综述资料/1_SparselyGatedMoE.pdf核心问题2017 年之前深度学习模型面临一个基本矛盾模型容量受限于计算资源。你想让模型更聪明,就得加参数;但参数越多,训练和推理就越慢。更糟糕的是这种增长是线性的——参数翻倍,计算成本就翻倍。这导致了一个很现实的问题:即使你有无限的数据和无限的标注,你的算力也会卡住你。Google Brain 的团队当时在思考一个更本质的问题:是不是所有参数都需要在每次前向传播时都被用到人类专家系统的经验告诉我们不同问题应该由不同专家解决,而不是让一个全能专家处理所有事情。如果神经网络也能这样——每个输入只激活一小部分参数——那我们就能在保持计算成本可控的前提下,大幅增加模型容量。这个想法的难点在于如何让网络自己学会哪些参数应该被激活如果手动设计,你很快就回到专家系统的老路上,失去了端到端学习的优势。Sparsely-Gated MoE 的核心贡献,就是提出了一个可微分的、端到端可训练的稀疏激活机制。主要方法Sparsely-Gated MoE 的架构设计非常优雅。他们在 LSTM 层之间插入了一个 MoE 层,这个层包含大量 expert最多 4096 个但每个 token 只激活其中的一小部分通常 k1~2。关键在于,如何让这个 routing 过程可微分,从而能端到端训练。MoE 层的核心是一个 Gating Network它接收输入 token 的表示,输出每个 expert 的权重。为了实现稀疏激活,作者做了一个简单但关键的操作只保留 top-k 个权重,其余全部置零。这个操作本身不可微,但作者证明了只要保留的 expert 数量足够少,就能用近似梯度来训练。图1 MoE 层架构来源: Sparsely-Gated MoE 论文 Figure 1)MoE 层的工作流程可以简化为输入经过 Gating Network计算出所有 expert 的权重然后选择 top-k 个 expert这些 expert 分别处理输入最后加权求和输出。这个设计的关键在于它不需要提前知道哪些 expert 应该被激活而是让网络自己学习。这种 routing 机制是可微分的,从而能端到端训练。但这里有一个工程问题如果你让网络自由学习 routing,很快就会出现rich get richer的现象——某些 expert 因为初始化稍好,就会被分配更多 token,训练得更充分,进而在下一轮获得更多 token,最终导致大部分 expert 闲置,少数 expert 过载。这不仅浪费了模型容量,还让训练不稳定。为了解决这个问题,作者引入了两个 auxiliary loss。第一个是 importance loss它惩罚 expert 重要性的方差importance 定义为该 expert 处理的所有 token 的权重和第二个是 load loss,它直接惩罚 expert 负载的不均衡负载定义为该 expert 处理的 token 数量。这两个 loss 加在一起虽然只占总 loss 的很小一部分通常 α0.01但足以让 routing 保持均衡。图2: 负载均衡效果来源: Sparsely-Gated MoE 论文 Figure 3)实验部分,作者在两个任务上验证了这个想法语言模型Language Modeling和机器翻译Machine Translation。语言模型用的是 Billions Words 数据集,机器翻译用的是 WMT。对比基线是标准的 LSTM 和早期的 Transformer。关键实验与结论实验结果非常惊人。在语言模型任务上当 expert 数量从 1 增加到 4096 时模型参数量从 1B 增加到 1000B但计算量只增加了 25%。更关键的是,Perplexity 从 45.5 降到了 36.2,这说明模型质量显著提升。可以看到当 expert 数量从 8 增加到 128 时,Perplexity 从 43.2 降到 38.7从 128 增加到 4096 时进一步降到 36.2。但边际收益是递减的——从 1 到 128 的增益,远大于从 128 到 4096 的增益。这个工作证明了三件事第一,MoE 可以让参数量爆炸式增长,计算成本几乎不变第二,稀疏激活是可行的,每个 token 只用极少 expert 就能获得很好的效果第三,负载均衡至关重要,必须用 auxiliary loss 防止 expert 崩溃。这三点构成了后续所有 MoE 工作的基石。但这个工作也有明显的局限它只在 LSTM 架构上验证,还没有在 Transformer 上应用规模还相对较小最大 1000B 参数,但激活参数量未明确训练稳定性问题还没有系统解决。这些留给了后续工作。第二阶段规模化改进 (2020-2021)GShard: Scaling Giant Models with Conditional Computation论文GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding作者Dmitry Lepikhin et al. (Google)发表ICLR 2021PDFMoE综述资料/2_GShard.pdf核心问题Sparsely-Gated MoE 证明了 MoE 的可行性,但到了 2020 年,一个新的问题浮现出来:如何把 MoE 扩展到真正的大规模Google 在 2020 年的目标是训练一个 600B 参数的多语言翻译模型,但这个规模面临几个工程挑战。第一个挑战是模型并行。600B 参数太大,单机即使是 TPU pod也放不下。你需要把模型分片到多个设备上,但 MoE 的 routing 机制让这个问题变得更复杂每个 token 可能被路由到任何一个 expert,如果 expert 分布在不同设备上,就需要大量的设备间通信。第二个挑战是训练稳定性。当 expert 数量达到几千个时某些 expert 可能长时间不被激活,导致梯度更新不均衡。更糟糕的是,如果某个 expert 的初始化特别差,它可能永远不会被选中,成为死 expert。第三个挑战是评估标准。Sparsely-Gated MoE 只在语言模型和单语言对翻译上验证,但 Google 需要的是一个能处理 100 种语言对的通用翻译模型。MoE 在这种多任务、多语言场景下是否依然有效主要方法GShard 的核心贡献是把 MoE 和自动并行分片结合起来。他们的做法是在 Transformer 的基础上,每 2 层替换 1 个 FFN 为 MoE 层,每个 MoE 层包含 512~2048 个 expert。关键在于,这些 expert 不是随机分布的,而是通过一个自动分片系统分配到不同 TPU 设备上。图3: GShard 的分布式架构来源: GShard 论文 Figure 2GShard 的分布式架构设计非常精巧。每个 TPU Core 存储一部分 expert,当某个 token 需要被某个 expert 处理时系统会通过 All-to-All 通信把 token 发送到对应的设备,计算完成后再把结果发送回原设备。这种设计的关键在于它让 expert 的分布对用户透明——你 routing 机制不需要知道 expert 在哪个设备上,只需要根据 expert ID 发送数据即可。为了优化通信效率,作者做了几个关键设计。第一是 expert 分组的粒度:不是每个 expert 单独通信,而是把多个 expert 的计算结果打包成一个大的 All-to-All 操作,这样能更好地利用带宽。第二是异步通信:某些层的计算可以和前一层的通信重叠,隐藏通信延迟。负载均衡方面,作者改进了 Sparsely-Gated MoE 的 auxiliary loss。新的 loss 定义为两个分数的乘积它同时惩罚重要性不均衡和负载不均衡而且梯度更稳定。实验中,作者设置 α 0.01,这个值足够小,不会干扰主任务,但足够大,能保证负载均衡。关键实验与结论GShard 在 WMT 100 语言对的翻译任务上做了实验。基线是 Transformer Big0.5B 参数GShard 模型扩展到 600B 参数2048 experts。可以看到Transformer Big 在英法翻译上达到 43.2 BLEU,而 GShard (600B) 达到 46.8,提升了 3.6 分。在英德翻译上,提升更明显,从 29.3 到 32.1。图4: GShard 性能对比来源: GShard 论文 Table 2)更关键的是训练效率。600B 参数的 GShard 模型,训练时间只比 0.5B 参数的稠密模型多 50%,但性能提升了 8%。这说明 MoE 的 scaling efficiency 远超稠密模型。这个工作证明了三件事:第一,MoE 可以扩展到 600B 参数,而且训练效率依然很高第二,自动分片 通信优化是大规模 MoE 的关键工程要素;第三,多语言任务特别适合 MoE——不同 expert 会自动学习不同语言的特征,实现了一种软性的多任务学习。但 GShard 也有局限:它用的 routing 还是 top-2每个 token 选 2 个 expert通信开销依然很大训练稳定性虽然有改善,但还没到开箱即用的程度expert 的专业化程度也不够高,很多 expert 学到的是重叠的功能。Switch Transformers: Scaling to Trillion Parameter Models论文Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity作者William Fedus et al. (Google)发表JMLR 2021PDF:MoE综述资料/3_SwitchTransformer.pdf核心问题GShard 虽然成功扩展到 600B 参数,但它的 routing 策略top-2带来了一个实际问题每个 token 要和 2 个 expert 通信,这在大规模分布式训练中会显著增加通信开销。更关键的是,这种复杂的 routing 让训练变得不稳定——作者在论文中提到,他们尝试过 top-4、top-8 的 routing,但训练经常崩溃。这引出一个核心问题:我们真的需要 top-2 routing 吗还是说,top-1 就足够了如果 top-1 够用,那通信开销能减半,训练也能更稳定。但直觉上,top-1 太极端了——每个 token 只用 1 个 expert,会不会损失太多信息Switch Transformer 的核心洞察是:与其让每个 token 用多个 expert,不如增加 expert 总数,让每个 expert 更专注。这样,即使每个 token 只用 1 个 expert,也能通过 expert 的多样性来弥补。主要方法Switch Transformer 的架构设计非常简洁:在 Transformer 的基础上,每 2 层替换 1 个 FFN 为 MoE 层,每个 MoE 层包含 128~2048 个 expert,每个 token 只路由到 1 个 expertk1。这个简化看起来很小,但它带来的好处是巨大的。图5: Switch Transformer 架构来源: Switch Transformer 论文 Figure 2)Switch Transformer 的关键创新在于简化 routing。传统 MoE 用 top-2 routing,每个 token 要选 2 个 expert,然后加权求和。Switch Transformer 把这个简化为 top-1 routing,每个 token 只选 1 个 expert。这个简化的好处是双重的:第一,通信复杂度从 O(2) 降到 O(1),在大规模分布式训练中能显著降低通信开销;第二,训练更稳定,因为更简单的 routing 意味着更少的边缘情况,更少的梯度爆炸。但 top-1 routing 也有风险:如果某个 expert 初始化很差,它可能永远不会被选中,成为死 expert。为了解决这个问题,作者引入了几个训练稳定性技巧,包括 selective precisionExpert 用 fp32,其他层用 bf16、smaller initialization初始化标准差减小到 0.1、expert dropoutExpert 内部 dropout rate 更高和 router z-loss防止 router 输出过大。关键实验与结论Switch Transformer 在 C4 数据集上做了预训练,然后在 GLUE、SuperGLUE 等下游任务上 fine-tune。作者训练了多个规模的模型,最大的是 Switch-XXL,1.6T 参数万亿级。可以看到T5-XXL11B 稠密的 loss 是 2.45,Switch-Base11B MoE是 2.30,Switch-XXL1.6T MoE是 2.10。这说明 MoE 在相同参数量下,确实比稠密模型更高效。图6: Switch Transformer 性能对比来源: Switch Transformer 论文 Table 4)更关键的是训练速度。Switch-XXL1.6T的训练速度比 T5-XXL11B快 80%,但 loss 更低。这说明 MoE 不仅参数效率高,训练效率也高。Fine-tuning 阶段,作者发现了一个有趣的现象:MoE 模型在小数据集上容易过拟合。为了解决这个问题,他们引入了 layer-wise learning rate decay底层 lr 更低,顶层 lr 更高和 selective layer freezing冻结部分 expert 层。这些技巧在后续的 ST-MoE 论文中被系统化。总结这个工作证明了三件事:第一,top-1 routing 足够好,性能与 top-2 持平,但更快更稳定;第二,万亿参数模型可以稳定训练,关键是初始化、精度和 loss 设计;第三,MoE 在 pre-training 和 fine-tuning 两个阶段都需要特殊处理,不能直接套用稠密模型的经验。第三阶段:理解经典 (2021-2022)GLaM: Efficient Scaling of Language Models with Mixture-of-Experts论文GLaM: Efficient Scaling of Language Models with Mixture-of-Experts作者Nan Du et al. (Google)发表2021PDF:MoE综述资料/4_GLaM.pdf核心问题Switch Transformer 证明了 MoE 可以扩展到万亿参数,但它留下了一个问题:MoE vs 稠密模型,到底谁更高效Switch 的对比基线是 T5-XXL11B,但 GPT-3175B才是当时最先进的稠密模型。如果 MoE 真的那么高效,它应该能用更少的训练 FLOPs,达到甚至超越 GPT-3 的性能。这个问题在 2021 年变得尤其重要。OpenAI 的 GPT-3 证明了 scaling law 的威力,但训练一个 175B 的稠密模型需要数千万美元的算力。如果 MoE 能用 1/3 的成本达到相同效果,那它的实用价值就非常大。GLaM 的目标就是系统性地回答这个问题:在相同的训练预算下,MoE 能比稠密模型好多少为了公平对比,作者设计了 GLaM1.2T 参数,97B 激活,让它的训练 FLOPs 与 GPT-3175B大致相当,然后在 29 个 few-shot benchmarks 上对比性能。主要方法GLaM 的架构设计非常标准:基于 Transformer,每 2 层替换 1 个 FFN 为 MoE 层,每个 MoE 层包含 64 个 expert,每个 token 激活 top-2 expert。总参数量是 1.2T,但每个 token 只激活 97B 参数激活率约 8%。图7: GLaM 架构来源: GLaM 论文 Figure 2训练数据方面,GLaM 用了 1.6T tokens 的 web text,训练了 500B tokens。数据清洗和过滤的标准与 GPT-3 类似,确保对比的公平性。训练硬件是 1024 TPU-v4 chips,训练时间约 3 周。评估方法上,作者选择了 29 个 few-shot benchmarks,包括 MMLU大规模多任务语言理解、HellaSwag常识推理、GSM8K数学推理等。每个任务用 0-shot、1-shot、few-shot 三种设置评估,最后取平均。关键实验与结论实验结果非常清晰。在 29 个 benchmarks 的平均性能上,GLaM 达到 47.8%,显著超越 GPT-3 的 43.9%。更关键的是训练成本:GLaM 的训练 FLOPs 只有 GPT-3 的 36%。图8: GLaM vs GPT-3 性能对比来源: GLaM 论文 Table 1这个工作还做了一个有趣的消融实验:expert 数量的影响。他们训练了 3 个模型,expert 数量分别是 8、32、64,总参数量分别是 150B、600B、1.2T,激活参数量分别是 50B、75B、97B。结果发现,expert 数量从 8 增加到 32,性能提升明显45.2% → 46.8%;从 32 增加到 64,提升较小46.8% → 47.8%。这说明 expert 数量的边际收益是递减的。总结这个工作证明了三件事:第一,MoE 的训练效率远超稠密模型36% FLOPs;第二,few-shot 场景下,MoE 优势明显;第三,expert 数量的边际收益递减,64 个 expert 是一个合理的平衡点。这些结论为后续 MoE 在 LLM 中的应用提供了坚实的实证基础。Expert Choice Routing论文Mixture-of-Experts with Expert Choice Routing作者Damian Mrowca et al. (Google)发表ICLR 2022PDF:MoE综述资料/5_ExpertChoice.pdf核心问题传统 MoE routing 的一个核心痛点是负载不均衡。即使你加了 auxiliary loss,某些 expert 还是会过载,某些 expert 还是会闲置。这个问题的根源在于 routing 的方向:token 选 expert,天然会导致热门 expert 被抢,冷门 expert 闲置。Google 的团队提出了一个颠覆性的想法:既然 token 选 expert 会导致不均衡,为什么不让 expert 选 token这个想法的直觉是:每个 expert 有固定的容量,它可以选择最适合自己的 k 个 token。这样,负载天然均衡,无需 auxiliary loss。这个想法听起来简单,但实现起来有几个挑战。第一,如何定义最适合自己的 token第二,如何保证每个 token 至少被一个 expert 处理第三,这种 routing 的性能会不会比传统 routing 差主要方法Expert Choice Routing (ECR) 的核心机制是:每个 expert 独立地选择 top-k 个 token,而不是 token 选择 top-k 个 expert。具体来说,对于 batch 中的 N 个 token 和 M 个 expert,ECR 计算一个 N×M 的 score matrix,然后每个 expert 选择 score 最高的 k 个 token。图9: Expert Choice Routing来源: Expert Choice 论文 Figure 1这个机制有一个潜在问题:如果某个 token 的 score 对所有 expert 都很低,它可能不被任何 expert 选中。为了解决这个问题,作者设计了一个fallback机制:如果某个 token 没有被任何 expert 选中,就让它被所有 expert 处理相当于退化为稠密层。ECR 的一个关键优势是无需 auxiliary loss。传统 MoE 需要调 α 来平衡主任务 loss 和负载均衡 loss,这是一个超参数,调起来很麻烦。ECR 天然均衡,不需要任何调参。关键实验与结论作者在语言模型和机器翻译任务上验证了 ECR。对比基线是传统的 top-2 routing,评估指标包括 perplexity、BLEU score 和负载均衡度。图10: Expert Choice 负载均衡来源: Expert Choice 论文 Figure 3可以看到,传统 routing 的负载均衡度用 Coefficient of Variation 衡量是 0.75,说明负载严重不均;ECR 的负载均衡度是 0.98,接近完美均衡。性能方面,ECR 略优于传统 routing。在语言模型任务上,传统 routing 的 perplexity 是 12.3,ECR 是 11.8。在机器翻译任务上,ECR 的 BLEU score 也略高。这说明 ECR 不仅解决了负载均衡问题,还带来了一点点性能提升。总结这个工作证明了三件事:第一,Expert Choice Routing 颠覆了传统 routing 范式,让 expert 主动选择 token;第二,ECR 天然负载均衡,无需 auxiliary loss,简化了训练;第三,ECR 的性能持平或略优于传统 routing,没有性能损失。这个工作为后续 MoE routing 设计提供了新思路,虽然目前大规模应用还不太多,但它的理论价值很高。ST-MoE: Stable and Transferable Sparse Mixture of Experts论文ST-MoE: Stable and Transferable Sparse Mixture of Experts作者Barret Zoph et al. (Google)发表2022PDFMoE综述资料/6_ST-MoE.pdf核心问题到 2022 年,MoE 已经证明了它的效率和扩展性,但工程上还有一个痛点:训练不稳定。大规模 MoE参数量 100B经常在训练中途崩溃,loss 突然 spike 然后发散。更糟糕的是,fine-tuning 阶段也容易出问题:MoE 模型在小数据集上性能不稳定,有时甚至不如稠密模型。这些问题的根源在于 MoE 的 routing 机制。当某些 expert 的权重过大时,梯度会集中在这些 expert 上,导致梯度爆炸。更糟糕的是,如果某个 expert 长时间不被激活,它的参数会腐烂,突然被激活时会产生不可预测的输出。Google 的团队系统性地分析了这些问题,然后提出了一套完整的解决方案。他们的目标不是提出一个新的 MoE 架构,而是把已有的 MoE 架构工程化,让它开箱即用。主要方法ST-MoE 的核心贡献是提出了一系列训练稳定性和 fine-tuning 的技巧。这些技巧看似简单,但组合起来非常有效。第一个关键技巧是 Router Z-Loss。它的定义是对 router 输出的指数和的平方求平均。这个 loss 的作用是防止 router 输出过大。当某个 expert 的权重过大时,log(∑ exp(Gate(x, e))) 会快速增大,梯度会把权重拉回来。这个技巧在 Switch Transformer 中首次提出,但在 ST-MoE 中被系统验证。图11: Router Z-Loss 效果来源: ST-MoE 论文 Figure 2Fine-tuning 方面,作者发现 MoE 模型在小数据集上容易过拟合。为了解决这个问题,他们引入了几个技巧:layer-wise learning rate decay底层 lr 更低,顶层 lr 更高、selective layer freezing冻结部分 expert 层、smaller batch size降低 batch size,增加正则化。图12: ST-MoE Fine-tuning 策略来源: ST-MoE 论文 Figure 5关键实验与结论ST-MoE 在 C4 数据集上预训练,然后在 SuperGLUE、BBH 等下游任务上 fine-tune。模型规模是 269B 总参数,32B 激活参数。可以看到,没有 Z-Loss 时,训练成功率只有 60%;加上 Z-Loss 后,成功率提升到 95%。这说明 Router Z-Loss 是大规模 MoE 训练的必备技巧。Fine-tuning 结果方面,ST-MoE 在 SuperGLUE 上达到 74.3%,显著超越 T5-XXL 的 71.6%。在 BBHBig-Bench Hard上,ST-MoE 达到 48.7%,T5-XXL 是 45.2%。这说明 MoE 在下游任务上也能超越稠密模型,只要 fine-tuning 策略得当。总结这个工作证明了三件事:第一,Router Z-Loss 是大规模 MoE 训练的关键,能显著提升训练成功率;第二,Fine-tuning 需要特殊处理,不能直接套用稠密模型的经验;第三,MoE 在下游任务上也能超越稠密模型,只要工程做得好。这个工作为后续大规模 MoE 训练提供了系统性的工程指南。第四阶段:开源里程碑 (2023-2024)Mixtral 8x7B: 第一个真正可用的开源 MoE论文Mixtral of Experts作者Mistral AI发表2023PDFMoE综述资料/7_Mixtral.pdf核心问题到 2023 年底,MoE 在 Google、Microsoft 等大厂已经广泛应用,但开源社区还缺乏一个真正可用的 MoE 基座。Google 的 GLaM、ST-MoE 不开源,Microsoft 的 MoE 模型也不开源。开源社区只有稠密模型LLaMA、Mistral,但这些模型在推理成本上远高于 MoE。Mistral AI 的团队看到了这个机会。他们的目标是:训练一个开源的 MoE 模型,性能超越 LLaMA 2 70B,但推理成本只有 1/4。如果这个目标能实现,MoE 就能真正 democratized,让更多研究者和开发者用起来。这个目标的挑战在于:开源 MoE 需要考虑推理效率,而不仅仅是训练效率。MoE 的推理涉及 routing 和 expert 选择,如果实现不好,推理速度可能比稠密模型还慢。更关键的是,MoE 的 expert 需要加载到内存中,如果 expert 太多,内存占用会很大。主要方法Mixtral 的架构设计非常标准:基于 Mistral 7B 的架构,每 2 层替换 1 个 FFN 为 MoE 层,每个 MoE 层包含 8 个 expert,每个 expert 是 7B 参数的 FFN。总参数量是 47B,但每个 token 只激活 2 个 experttop-2 routing,所以激活参数量是 13B。图13: Mixtral 架构来源: Mixtral 论文 Figure 1为了优化推理效率,Mistral AI 做了几个关键设计。第一是 Grouped Query Attention (GQA):把 query 分组,减少 attention 计算量。第二是 Sliding Window Attention:每个 token 只 attend to 最近的 4096 个 token,而不是整个序列。这两个技巧让 Mixtral 的推理速度显著提升。训练数据方面,Mixtral 用了 web text多语言,训练 tokens 的数量未公开,但推测是 2T。训练硬件也未公开,但 Mistral AI 提到他们用了几千个 GPU。关键实验与结论Mixtral 的实验结果非常惊人。在 MMLU 上,Mixtral 达到 70.6%,超越 LLaMA 2 70B 的 69.8%。在 HellaSwag 上,Mixtral 是 87.6%,LLaMA 2 70B 是 87.3%。在 GSM8K数学推理上,Mixtral 是 58.4%,LLaMA 2 70B 是 56.8%。图14: Mixtral 性能对比来源: Mixtral 论文 Figure 3更关键的是推理速度。Mixtral 的推理吞吐量是 180 tokens/sec,而 LLaMA 2 70B 是 45 tokens/sec。Mixtral 快了 4 倍,但性能还略高。总结这个工作证明了三件事:第一,MoE 可以在开源生态中达到 SOTA 性能;第二,MoE 的推理成本远低于稠密模型4x 加速;第三,MoE 的实现可以非常简洁,不需要复杂的 routing 机制。Mixtral 的发布,标志着 MoE 真正 democratized,为后续开源 MoE 奠定了基础。DeepSeekMoE: Expert 架构创新论文DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models作者DeepSeek AI发表2024PDFMoE综述资料/8_DeepSeekMoE.pdf核心问题到 2024 年,MoE 的架构设计已经相对成熟:Transformer MoE 层 top-k routing。但 DeepSeek AI 的团队发现了一个问题:传统 MoE 的 expert 专业化程度不够高。每个 expert 参数量太大通常 2B,学到的功能很泛化,expert 之间重叠严重。这个问题的根源在于 expert 的粒度。如果把 expert 看作专家,那传统 MoE 的 expert 更像是通才——每个 expert 都会一点语法、一点数学、一点推理,但没有一个 expert 特别擅长某个领域。这不仅浪费了模型容量,还降低了 MoE 的解释性。DeepSeek AI 的想法是:能不能把 expert 拆得更细,让每个 expert 更专注如果每个 expert 只负责一个很窄的领域比如数学加法或英语语法,那 expert 的专业化程度就会显著提升。但这个想法有一个挑战:如果 expert 太细,routing 会变得更复杂,如何保证每个 token 能找到合适的 expert主要方法DeepSeekMoE 的核心创新是 Fine-grained Expert Segmentation Shared Expert Isolation。简单来说,就是把传统的大 expert 拆成多个小 expert,同时保留一部分 expert 作为共享专家。图15: DeepSeekMoE 架构来源: DeepSeekMoE 论文 Figure 2这个设计的直觉是:通用知识语法、常识应该被所有 expert 共享,而不是分散到各个 expert 中;专业领域数学、推理应该由专门的 expert 处理,而不是让所有 expert 都学一点。这样,shared expert 学通用知识,routed expert 学专业知识,分工明确。为了验证 expert 的专业化程度,作者做了一个有趣的分析:统计不同 expert 在不同类型 token 上的激活频率。结果发现,某些 expert 几乎只在数学 token 上激活,某些 expert 只在代码 token 上激活,说明 expert 确实高度专业化了。关键实验与结论DeepSeekMoE 训练了一个 16B 参数的模型2.4B 激活,对比基线是 LLaMA 2 7B 和 DeepSeek 7B稠密。图16: DeepSeekMoE 性能对比来源: DeepSeekMoE 论文 Figure 5可以看到,DeepSeekMoE (16B) 在 MMLU 上达到 50.5%,超越 LLaMA 2 7B 的 45.3% 和 DeepSeek 7B 的 48.2%。在 GSM8K 上,DeepSeekMoE 是 21.3%,LLaMA 2 7B 是 14.6%,DeepSeek 7B 是 17.8%。总结这个工作证明了三件事:第一,Fine-grained expert 能显著提升专业化程度;第二,Shared expert 能保留通用知识,避免 expert 过度特化;第三,Expert 架构设计是 MoE 性能的关键,不是所有 MoE 都一样。这个工作为后续 MoE 架构创新提供了新方向。总结与展望MoE 的七年演进从 2017 年 Sparsely-Gated MoE 的诞生,到 2024 年 DeepSeekMoE 的架构创新,MoE 在七年里经历了从理论验证、工程化改进、系统优化到开源落地的完整历程。每个阶段都解决了一个核心问题:第一阶段证明了稀疏激活的可行性;第二阶段解决了规模化和分布式训练的工程问题;第三阶段系统解决了效率和稳定性问题;第四阶段让 MoE 真正 democratized。关键技术演进Routing 策略从 top-kk2发展到 top-1Switch,再到 Expert ChoiceECR,最后到 HybridDeepSeekMoE。每个改进都在解决一个具体问题:top-1 降低通信开销,ECR 解决负载均衡,Hybrid 提升专业化。Expert 设计从大 expert2B发展到 fine-grained expert0.25B,再到 shared routed expert 的组合。这个演进反映了一个洞察:expert 的专业化程度,比 expert 的数量更重要。训练稳定性从经常崩溃发展到开箱即用,Router Z-Loss、Expert Dropout、Gradient Clipping 等技巧组合起来,让大规模 MoE 训练变得可靠。开源生态从闭源垄断发展到democratized,Mixtral 的发布标志着 MoE 真正进入开源社区,让更多研究者和开发者能参与 MoE 的研究和应用。未来方向MoE 的未来有几个值得关注的方向。第一是 expert 架构优化:更细粒度的 expert、动态 expert 数量、expert pruning/growing。第二是 routing 策略创新:更智能的 routing、跨层 routing、多模态 routing。第三是训练效率提升:更好的负载均衡、通信优化、混合精度训练。第四是应用场景拓展:多模态 MoE、推理加速、edge deployment。第五是理论分析:MoE 的 scaling law、expert 专业化机制、泛化能力分析。最后的话MoE 的核心思想非常简单:稀疏激活让模型容量爆炸式增长,但计算成本几乎不变。这个看似简单的想法,在过去七年里被无数工程师和研究者打磨、优化、工程化,最终成为今天大规模语言模型的核心技术之一。从 Sparsely-Gated MoE 到 DeepSeekMoE,每一步都在解决一个具体问题,每一步都让 MoE 更实用、更可靠、更高效。对于研究者来说,MoE 还有很多未解的问题:expert 的专业化机制是什么?MoE 的 scaling law 是怎样的?如何让 MoE 在多模态场景下工作?对于工程师来说,MoE 已经可以开箱即用了:Mixtral 和 DeepSeekMoE 都是很好的起点。对于应用者来说,MoE 的价值很明确:用更少的计算成本,达到更好的性能。这就是 MoE 的故事,从 2017 到 2024,从理论到实践,从闭源到开源。希望这篇综述能帮你更快地理解 MoE 的演进脉络,找到你感兴趣的方向。生成时间2026-03-13作者贾维斯版本v3.0​