编者按： 为什么说 DeepSeekMoE 的"共享专家隔离"设计，既能保留通用知识又能减少冗余？传统 MoE 的专家真的"专精"吗？传统 MoE 专家易"崩溃"，DeepSeekMoE 如何通过"更细粒度的专家分割"让每个专家专注更小领域，解决负载不均衡问题？
作者巧妙地用餐厅厨师的比喻，将抽象的技术概念形象化 ------ 是聘用一位熟悉多种菜系的厨师，还是聘用多位各有专长的厨师更明智？随后，文章深入剖析了 DeepSeekMoE 的两大创新：更细粒度的专家分割通过增加专家数量并降低单个专家的参数规模，促进了专家的专业化；共享专家隔离则通过预留部分专家处理通用知识，减少了专家间的知识冗余。实验结果表明，在相同计算成本下，DeepSeekMoE不仅性能更优，其专家的不可替代性也更强，知识冗余度更低。
作者 | Shirley Li
编译 | 岳扬
这是 DeepSeek-V3 系列的第二篇文章，本文将解析 DeepSeek[1,2,3] 模型的另一个关键架构创新：DeepSeekMoE[4]。
「DeepSeek-V3 技术解析」专栏其他文章：
具体而言，本文将解释混合专家系统（Mixture-of-Experts，MoE）的工作原理、为什么该技术在 LLMs 领域备受青睐及其面临的挑战。我们还将探讨 expert specialization（译者注：在 MoE 架构中，每个专家能够获取不重叠且聚焦的知识。） 与 knowledge sharing（译者注：指通过门控网络与专家模型的协同机制，使不同专家在独立处理特定任务的同时，仍能共享底层知识或通用特征，从而提升模型的整体性能和效率。） 之间的权衡，以及 DeepSeekMoE 如何实现更优的平衡。
最精彩的部分：为了让这些概念更直观，本文将通过餐厅这个场景来类比解析整个系统，借助厨房中厨师的角色来阐释 MoE 的各个要素。
本文目录：
- 技术背景：介绍 MoE 的工作原理、优势与面临的挑战，探讨 expert specialization 与 knowledge sharing 之间的权衡
- DeepSeekMoE 架构：解析更细粒度的专家分割（Fine-Grained Expert Segmentation）和共享专家隔离（Shared Expert Isolation）
- 评估：通过多个有趣实验讨论 DeepSeekMoE 的性能表现
- 总结
- 参考文献
01 技术背景
1.1 MoE（混合专家系统）在 LLM 中的应用
在 LLM（大语言模型）中，MoE 通常是指用 MoE 层替换 Transformer 模型中的 FFN（前馈神经网络）层，如下图所示：
图 1. MoE 层示意图，图片来自 GShard 论文[5]
具体来说，左侧展示的是由 N 个 Transformer 层组成的堆叠结构，每层包含一个 MHA（多头注意力）子层和一个 FFN 子层。而右侧展示的是由 N/2 个 Transformer 层组成的堆叠结构，其中下层 Transformer 的 FFN 子层被替换为 MoE 层。换言之，每隔一个 Transformer 层，其 FFN 子层就会被 MoE 层替代。实际应用中，可以按指定间隔将 FFN 替换为 MoE 层。
若进一步观察 MoE 层，会发现它包含一个门控（Gating）操作和一组具有相同架构的 FFN（与标准 FFN 子层一致）。这些 FFN 层在 MoE 中被称为"专家"，门控操作通过训练学习选择激活哪些专家来处理特定输入。
图 2. 包含门控操作和多个 FFN 专家的 MoE 层，图片来自文献[5]
MoE 的通用架构可形式化描述如下（公式编号沿用自文献[4]）：
其中：
- u^l_t 和 h^l_t 分别表示第 l 层中第 t 个 token 的输入和输出的隐藏状态（hidden state）。
- FFN_i 是 N 个专家中的第 i 个专家。
- g_{i, t} 是第 t 个 token 对第 i 个专家的门控值，该值通过对 Softmax 的输出应用 TopK 操作获得。
- e^l_i 在公式 (5) 中常被称为第 i 个专家的"质心（centroid）"，可通过聚合历史上路由到该专家的所有输入 token 计算得到：
该公式由原文作者创建
公式逐步解析（从公式 (5) 到公式 (3) 反向说明）：
- 公式 (5)：通过计算 u^l_t 与 e^l_i 的内积，衡量当前输入 token 与历史上路由到第 i 个专家的所有输入 token 的均值的相似度。若专家 i 处理过大量与当前 token 相似的输入，则其处理当前 token 的能力更强。随后对结果应用 Softmax，将其转换为概率分布。由于共有 N 个专家，每个 token 会得到N个 s_{i, t} 值。
- 公式 (4)：对 s_{i, t} 值应用 TopK 操作，生成稀疏的 g_{i, t} 值。
- 公式 (3)：利用稀疏的 g_{i, t} 值选择 K 个专家来计算输出的隐藏状态。
换言之，对于第 t 个 token，仅会激活 N 个专家中的 K 个（通常 K 远小于 N），导致门控值 g_{i，t} 呈现稀疏性。通过这种设计，模型的可训练参数总量会因增加的 FFN 而上升，但前向传播时仅激活其中一小部分参数。
这正是采用 MoE 的 LLM 在描述模型规模时常用 "总参数量XX，其中每个 token 激活 YY" 的原因 ------ 例如 DeepSeek-V3 ：
"模型总参数量 2360 亿，每个 token 激活 210 亿参数......"
那么，如果增加更多参数，MoE 有何优势？
1.2 MoE 的优势与面临的挑战
MoE 最妙的地方在于它体现了许多具有相似原理的现实场景，因此我们可以通过这些案例更直观地理解它。
现在假设我们要为一家同时提供中餐和意大利菜的餐厅雇佣厨师，有两种选择：
- 选项1：雇佣一位同时精通中餐和意大利菜的厨师，这样他/她可以独自处理所有菜品。这类似于标准 Transformer 模型，由单个 FFN 子层处理所有输入 token。
- 选项2：雇佣多位各有所长的厨师（比如中餐专家和意大利菜专家），再加一位主厨根据订单内容指派擅长该菜系的厨师处理。这类似于 MoE 方法，每个厨师充当专家，主厨则作为门控机制（Gating）来选择专家。
通过以上类比可以明显看出，选项 2 不仅更容易招聘人才，还能保证两种菜系都保持高水准。相比之下，要找到同时精通多种菜系的单一厨师难度极大（甚至不可能），我们可能不得不降低菜品质量要求。
回到 LLM 场景，构建 MoE 的动机部分源于"扩展假说"（scaling hypothesis），即在大规模数据上扩展 LLM 时更可能涌现出新的能力，这也是为什么我们看到现在 LLM 的规模越来越大的原因 ------ 比如 GPT 模型已从 117M 参数扩展到 175B 参数。
然而并非所有人都有机会训练如此大规模的 LLM，而 MoE 提供了一种折中方案：通过仅激活每个输入 token 对应的少量参数，我们可以在扩大模型规模（增加模型容量）的同时，保持训练和推理成本可控。
如文献[4]所示，你可以训练一个 2B 参数的模型仅激活 0.3B 参数，或训练 16B 参数模型仅激活 2.8B 参数，甚至还可以训练 145B 参数的模型仅激活 22.2B 参数。在每种情况下，每次仅使用总参数量的约 1/7，大大提升了训练和推理效率。
然而，每种设计都有其局限性，并会带来新的挑战。就 MoE 而言，其性能高度依赖门控机制的有效性 ------ 因为无法保证门控始终将每个输入 token 路由到最优专家，且可能出现少数专家处理大部分输入 token，而其他专家因缺乏训练机会无法充分发挥作用的现象。 这通常被称为"专家崩溃"（expert collapse）问题。
这还会导致其他问题，例如负载不均衡（多数 token 被路由到少数专家）和不稳定性（当 token 被路由到未经充分训练的专家时效果欠佳）。
这就是为什么我们在 MoE 架构领域中经常能够看到大量关于负载均衡的讨论。
DeepSeekMoE 也提出了若干负载均衡策略，但本文将聚焦其核心创新点，关于无辅助损失负载均衡（auxiliary-loss-free load balancing）[8]的深入解析将在后续文章中展开。
1.3 Knowledge Specialization vs. Knowledge Sharing
在上述餐厅案例中，我们做雇佣决策时其实也在权衡 expert specialization（译者注：在 MoE 架构中，每个专家能够获取不重叠且聚焦的知识。） 与 knowledge sharing（译者注：指通过门控网络与专家模型的协同机制，使不同专家在独立处理特定任务的同时，仍能共享底层知识或通用特征，从而提升模型的整体性能和效率。）：选项1追求通才但可能牺牲技能深度，选项2追求专精。这种权衡广泛存在于现实场景的各类组织中（如企业、团队等）。
在 MoE 中这种权衡同样存在，但呈现形式更为隐晦。理论上，每个专家都应具备特定领域的专长，因为每个专家仅处理部分输入 token；同时所有专家仍会共享部分通用知识，因为它们共享大量参数。与现实场景不同，我们很难界定每个专家的专精程度及他们掌握的通用知识范围的边界。
权衡 expert specialization 与 knowledge sharing 是 MoE 架构设计的关键考量因素，因为过度专精与过度冗余均非理想状态。
在前一种情况下，过度专精的专家会导致训练和推理的不稳定，任何次优的路由都可能显著影响性能。同时这往往会造成模型容量利用率不足，因为高度专精的专家只能处理极少数 token。
在后一种情况下，若专家间掌握的知识过于相似，MoE 引入的额外参数将无法带来成比例的容量提升，这显然是对有限计算资源的浪费。
下一节我们将看到 DeepSeekMoE 如何实现两者的更优平衡。
02 DeepSeekMoE 架构
DeepSeekMoE 通过两项关键技术创新来平衡 MoE 中的 knowledge specialization 和 knowledge sharing，即更细粒度的专家分割（fine-grained expert segmentation）和共享专家隔离（shared expert isolation）。
图 3. DeepSeekMoE 示意图。图片来自文献[4]。
2.1 更细粒度的专家分割
DeepSeekMoE 提出更细粒度的专家分割以促进专家的专业化，提出该技术的想法非常简单：对于每个输入 token，如果有更多专家被激活，那么处理该 token 所需的知识就更有可能被分解并由不同专家获取。
在前文的餐厅案例中，就类似于将每位厨师的技能进行专业化拆分，如下图所示。最初，我们让一位厨师负责所有中餐，另一位负责所有意大利菜。应用更细粒度的专家分割（fine-grained expert segmentation）后，每种菜系所需的技能被拆分给多个专家掌握，于是我们得到一组专精中餐的厨师和另一组专精意大利菜的厨师，每位厨师只需掌握该菜系的特定技能。
图 4. 用餐厅案例说明(a)应用前和(b)应用更细粒度的专家分割后的对比。由原文作者供图。
图 3 也说明了这一点：子图 (a) 中每个输入 token 被路由到 N 个专家中的 2 个，而子图 (b) 中每个 token 被路由到 2N 个专家中的 4 个。在更一般的情况下，我们可以将专家数量从 N 增加到 mN，同时将每个专家 FFN 的中间隐藏层维度降至1/m，并为每个输入 token 激活 m 倍的专家数量。通过这种方式，(a) 和 (b) 的总体计算成本将大致保持相同。
尽管作者未对该策略的有效性提供理论证明，但他们确实设计了实验来验证这一思路，我们将在"评估"部分详述。
2.2 共享专家隔离
DeepSeekMoE 提出的另一项技术是隔离部分共享专家以减少冗余，提出该技术的核心想法在于：若预留部分共享专家来学习不同任务的通用知识，可给其他专家更多的自由来剥离此类通用知识，从而减少非共享专家间的冗余。
在前文提到的餐厅案例中，这就类似于将所有厨师进一步划分为两组（如下图所示）：上方第一组厨师掌握刀工、火候、调味等通用烹饪技能，下方第二组厨师专注于自己的特色菜品。
例如，包饺子的师傅只需专注包捏与蒸煮饺子，无需考虑摆盘技巧；意面师傅只需钻研意面的制作，无需学习刀工。由此减少厨师间的知识冗余。
图 5. 基于图 4 的餐厅案例，进一步添加共享专家隔离的示意图。由原文作者供图。
图3 (c) 也展示了该策略的实现方式：选定一个专家作为共享专家（绿色高亮标记），所有输入 token 均不经路由层（Router）直接激活该专家，同时将激活的专项专家数量从 4 个减至 3 个，使总激活专家数量与图 3 (b) 保持相同。
综上，DeepSeekMoE 架构可形式化表示为下图右侧公式（左侧为传统 MoE 架构作为对比）：
图 6. (左) 传统 MoE vs. (右) DeepSeekMoE。作者根据文献 [4] 中的公式绘制该图。
其中：
- 式 (11) 与传统 MoE 的式 (5) 相同
- 式 (10) 与式 (4) 类似，但此处通过 TopK 从 (mN-K_s) 个专家中选择 (mK-K_s) 个，K_s 表示共享专家数量
- 式 (9) 将式 (3) 的第一项拆分为两个子项，分别对应共享专家与路由专家
原文同样未对该策略提供理论证明，但后续评估结果表明：引入共享专家既能提升性能，又能有效降低知识冗余。
03 Evaluation
正如前文所述，尽管两项策略的直觉依据看似合理，但作者并未提供理论证明，因此我们仍需验证：这些策略是否真能缓解 expert specialization（译者注：在 MoE 架构中，每个专家能够获取不重叠且聚焦的知识。） 与 knowledge sharing（译者注：指通过门控网络与专家模型的协同机制，使不同专家在独立处理特定任务的同时，仍能共享底层知识或通用特征，从而提升模型的整体性能和效率。）的冲突？其有效性程度如何？
我们主要关注三个核心问题：
- DeepSeekMoE 能否取得更好效果？
- 更细粒度的专家分割能否促进 expert specialization？其作用程度如何？
- 共享专家隔离能否减少冗余？其作用程度如何？
为解答这些问题，作者设计了系列实验，在此有必要详述。
3.1 DeepSeekMoE能否取得更好效果？
首先验证该方法能否提升整体性能。作者训练了总参数/激活参数规模相当的多个模型，并在不同任务上评估它们的性能。主要结果如下表所示（最优指标用粗体标注）：
图 7. 整体性能对比。作者根据文献 [4] 表 1 整理。
几点启示：
- 蓝色高亮列对比标准 Transformer（Dense）与两种 MoE 架构（Hash Layer [6]和Switch Transformer [7]）：在激活参数量相近时，MoE 架构性能显著更优。
- 绿色高亮列进一步比较了 DeepSeekMoE 与另一种 MoE 方法 GShard [5]：在激活参数量相近时，DeepSeekMoE 性能明显更优。
但性能提升并不直接等同于更好地平衡了 expert specialization 与 knowledge sharing 的冲突，因此仍需其他实验验证。
3.2 DeepSeekMoE 是否促进了专家的专业化？
直接衡量专家的专业化程度较为困难，作者转而设计了一项反向实验：禁用部分高优先级路由专家并观察性能变化。
从直觉上讲，专家专业化程度越高时其不可替代性越强，因此禁用高优先级路由专家应该会导致更明显的性能下降。
更具体一点，作者在 DeepSeekMoE 和 GShard x 1.5（作为 baseline）中逐步禁用高优先级路由专家。两种方法在未禁用专家时的 Pile loss 相当（对应下图中禁用比例为 0 时的最左侧数据点）：
图 8. 禁用高优先级路由专家时 DeepSeekMoE 与 GShard x 1.5 的 Pile loss 对比。图片来自文献[4]。
随着禁用路由专家比例的增加，DeepSeekMoE 的 Pile loss 持续高于 baseline，表明其路由专家具有更强的专业性，因此更难被其他专家替代。
3.3 DeepSeekMoE 是否能够减少知识冗余？
按照类似的思路，作者还尝试禁用共享专家并额外激活了一个路由专家，以观察共享专家是否可被替代。
实验结果显示"Pile loss 从 1.808 明显上升，至 2.414"，这证明了共享专家学习的知识具有独特性，而路由专家未能充分覆盖该部分知识。换言之，路由专家具有更高专业性且冗余度更低。
04 Summary
本文通过餐厅案例进行类比，解析了 DeepSeek-V2、DeepSeek-V3 等模型的核心架构创新之一 ------ DeepSeekMoE。
具体而言，本文首先介绍了通用 MoE 的工作原理、优势及面临的挑战，以及 expert specialization 与 knowledge sharing 之间的权衡关系。随后重点解析了 DeepSeekMoE 的两大核心设计：更细粒度的专家分割（fine-grained expert segmentation）与共享专家隔离（shared expert isolation），并通过实验验证了其有效性。
核心结论：DeepSeekMoE 在保持与通用 MoE 架构相当计算成本的条件下，通过促进专家的专业化实现了更优效果，从而实现更高的计算效率。
参考文献
1\] DeepSeek（[www.deepseek.com/）](https://link.juejin.cn?target=https%3A%2F%2Fwww.deepseek.com%2F%25EF%25BC%2589 "https://www.deepseek.com/%EF%BC%89") \[2\] DeepSeek-V3 Technical Report（[github.com/deepseek-ai...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fdeepseek-ai%2FDeepSeek-V3%2Fblob%2Fmain%2FDeepSeek_V3.pdf%25EF%25BC%2589 "https://github.com/deepseek-ai/DeepSeek-V3/blob/main/DeepSeek_V3.pdf%EF%BC%89") \[3\] DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model（[arxiv.org/abs/2405.04...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2405.04434%25EF%25BC%2589 "https://arxiv.org/abs/2405.04434%EF%BC%89") \[4\] DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models（[arxiv.org/abs/2401.06...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2401.06066%25EF%25BC%2589 "https://arxiv.org/abs/2401.06066%EF%BC%89") \[5\] GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding（[arxiv.org/abs/2006.16...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2006.16668%25EF%25BC%2589 "https://arxiv.org/abs/2006.16668%EF%BC%89") \[6\] Hash Layers For Large Sparse Models（[arxiv.org/abs/2106.04...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2106.04426%25EF%25BC%2589 "https://arxiv.org/abs/2106.04426%EF%BC%89") \[7\] Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity（[arxiv.org/abs/2101.03...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2101.03961%25EF%25BC%2589 "https://arxiv.org/abs/2101.03961%EF%BC%89") \[8\] Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts（[arxiv.org/abs/2408.15...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2408.15664%25EF%25BC%2589 "https://arxiv.org/abs/2408.15664%EF%BC%89") *Thanks for reading!* *Hope you have enjoyed and learned new things from this blog!* ***About the author*** ***Shirley Li*** I am a Machine Learning Engineer working on building multi-modality models to solve real-world problems. **END** **本期互动内容 🍻** ❓**文章中的餐厅厨师类比是否帮助你理解了这个概念？如果让你用身边的例子来解释 DeepSeekMoE 架构，你会用什么比喻？** **原文链接：** [ai.gopubby.com/deepseek-v3...](https://link.juejin.cn?target=https%3A%2F%2Fai.gopubby.com%2Fdeepseek-v3-explained-2-deepseekmoe-106cffcc56c1 "https://ai.gopubby.com/deepseek-v3-explained-2-deepseekmoe-106cffcc56c1")