背景

LLM中的MoE（混合专家）

在LLM的上下文中，MoE通常指的是用MoE层替换Transformer模型中的前馈神经网络（FFN）层，如下图所示：

更具体地说，左侧展示了一组N个Transformer层，每层都有一个单一的多头注意力（MHA）子层，后面跟着一个前馈神经网络（FFN）子层。相比之下，右侧展示了一组N/2个Transformer层，其中下层Transformer层的FFN子层已被MoE层替换。换句话说，每隔一个Transformer层的FFN子层都将被MoE层替换。在实际应用中，我们可以实现MoE，以在指定的Transformer层间隔替换FFN。

如果我们进一步深入查看MoE层，会发现它包含一个门控操作，后面跟着一系列FFN，每个FFN的结构都与标准FFN子层相同。在MoE中，这些FFN层被称为“专家”，而门控操作经过训练，可以选择激活哪个专家来处理特定的输入。

MoE的一般架构可以更正式地描述如下：

其中：

• ul_t 分别是第l个Transformer层中第t个token的输入和输出隐藏状态。
• FFN_i 是N个专家中的第i个专家。
• g_{i, t} 是给定token t和专家i的门控值，通过对softmax输出应用TopK操作获得。
• 公式（5）中的e^l_i通常被称为第i个专家的质心，可以通过聚合过去所有被路由到第i个专家的输入token来计算：

现在，让我们从式（5）到式（3）逐步解释上述方程：

• 在式（5）中，ul_i的内积衡量了当前输入token与过去被路由到第i个专家的平均输入token的接近程度。直观地说，如果专家i处理过很多与当前token相似的输入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个会被激活，导致g_{i, t}值稀疏，因为K通常很小。通过这样的设计，模型中的总可训练参数会因为额外的FFN而增加，但在前向传递过程中只有一小部分会被激活。

这就是为什么我们经常看到采用MoE的LLM会描述其模型大小为“XX总参数，其中每个token激活YY个”，其中YY远小于XX，如DeepSeek-V3的示例：

“它包含2360亿个总参数，其中每个token激活210亿个……”

那么，如果MoE会引入更多参数，它的好处是什么？

MoE的好处和挑战

MoE的伟大之处在于它反映了许多具有相似原理的现实生活场景，因此我们可以使用这些例子来更直观地理解它。

现在，假设我们正在为一家提供中餐和意大利菜的餐厅招聘厨师，我们有两个选择：

• 选择1：聘请一位同时擅长中餐和意大利菜的厨师，这样他或她就可以独自处理每一道菜。这类似于标准的Transformer模型，其中一个单一的FFN子层会处理所有输入token。
• 选择2：聘请多位厨师，每位厨师专门负责中餐或意大利菜，外加一位主厨根据他们的专长分配订单。这类似于MoE方法，其中每位厨师充当一个专家，主厨充当门控机制来选择专家。

通过上述类比，很明显选择2不仅使招聘更容易，而且还能确保两种菜系都能以更高的质量准备。相比之下，找到一位掌握多种菜系的厨师要困难得多——如果不是不可能的话——并且我们可能不得不在菜品质量上做出妥协。

回到我们的LLM场景，MoE的动机部分与扩展假设有关，即当在大规模数据上扩展LLM时，可能会出现涌现能力，这就是为什么我们如今目睹了LLM变得越来越大，例如GPT模型已经从1.17亿扩展到1750亿。

然而，并不是每个人都有特权以如此规模训练LLM，而MoE提供了一种折衷方案：它允许我们扩展模型大小以增加模型容量，同时通过仅为每个输入token激活总参数的一小部分来保持训练和推理成本的可管理性。

你可以训练一个20亿参数的模型，其中只激活3亿个参数，或者训练一个160亿参数的模型，其中激活28亿个参数，甚至训练一个1450亿参数的模型，其中只激活222亿个参数。在每种情况下，一次只使用总参数的约1/7，显著提高了训练和推理效率。

然而，每种设计都有其自身的局限性，并带来新的挑战。在MoE的情况下，其性能严重依赖于门控机制的有效性，因为没有保证它总是会将每个输入token路由到最佳专家，并且有可能少数专家经常被大多数输入token激活，而其他专家则坐在那里而没有接触到足够的训练token。这通常被称为“专家崩溃”问题。

这还会导致其他问题，如负载不均衡（因为大多数输入token被路由到一小部分专家）和不稳定（当输入token被路由到没有在该任务上得到足够训练的专家时，结果不佳）。

这就是为什么在MoE架构中，我们经常看到很多关于负载均衡的讨论。

知识专业化与知识共享

在上述餐厅示例中做出招聘决策时，我们也在知识专业化与知识共享之间进行权衡：选择1优先考虑通才，但可能会牺牲深度，而选择2则优先考虑专业化。这种权衡在许多现实生活中的组织中都存在，如公司、团队等。

它也存在于MoE中，但方式更为隐含。理论上，每个专家应该专门负责特定方面，因为每个专家只处理一部分输入token，并且所有专家仍然共享一些共同知识，因为它们共享许多参数。与真实组织的情况不同，很难确定每个个别专家的专业化程度以及它们共享知识的程度。

在MoE架构中，权衡专业化和知识共享是一个关键的设计考虑因素，因为过度专业化和过度冗余都不是理想的。

在前一种情况下，拥有过度专业化的专家可能导致训练和推理不稳定，任何次优的路由都可能导致性能不佳。同时，这通常会导致容量利用不足，因为高度专业化的专家只能处理一小部分token。

在后一种情况下，如果专家变得过于相似，那么MoE引入的额外参数将不会带来与容量成比例的增益，这无疑是对有限计算资源的浪费。

DeepSeekMoE架构

DeepSeekMoE利用两项关键创新来平衡MoE中的知识专业化与知识共享，即细粒度专家分割和共享专家隔离。

图3

细粒度专家分割

在DeepSeekMoE中提出了细粒度专家分割，以促进专家的专门化，其背后的直觉非常简单：为输入标记激活的专家越多，处理该标记所需的知识就越有可能被分解并由不同的专家获取。

在我们之前的餐厅例子中，这类似于将每位厨师的技能进行细分，如下图所示。最初，我们有一位厨师负责准备所有中式菜肴，另一位厨师负责处理所有意式菜肴。应用细粒度专家分割后，每种菜系所需的技能被分配给多个专家，因此我们会有一组厨师负责中式菜肴，另一组负责意式菜肴，每位厨师只需掌握该菜系中的一项特定技能。

图4

这也如图3所示，其中子图(a)中每个输入标记被路由到N个专家中的2个，而在(b)中，每个标记将被路由到2N个专家中的4个。在更一般的情况下，我们可以将专家数量从N增加到mN，同时将每个专家前馈网络（FFN）的中间隐藏维度减少到1/m，并为每个输入标记激活m倍多的专家。这样，(a)和(b)的总体计算成本将大致保持不变。

尽管作者没有提供这一策略有效性的理论证明，但他们确实设计了实验来验证他们的想法，我们将在评估部分详细介绍。

共享专家隔离

DeepSeekMoE提出的另一项技术是隔离一定数量的共享专家以减少冗余，其背后的直觉是，如果我们保留一些共享专家来学习跨任务的通用知识，这可能会给其他专家更多的自由来摆脱这些通用知识，从而减少这些非共享专家之间的冗余。

在我们的餐厅例子中，这类似于将所有厨师进一步分为两组，如下图所示，其中上部分所示的第一组负责基本的烹饪技能，如基本的刀工、烹饪技术和调味原则，而第二组的厨师则更多地关注他们自己的特色菜肴。

例如，饺子厨师可以只专注于饺子的包制和蒸煮，而不需要担心摆盘技巧，意大利面厨师可以只专注于制作更好的意大利面，而不需要学习切割技巧。因此，厨师之间的知识冗余可以减少。

图5

图3 (c) 还展示了这一策略在DeepSeekMoE中的实现方式，其中一个专家被选为共享专家（以绿色突出显示），因此所有输入标记都会直接路由到该专家，而无需经过路由器。同时，激活的专门化专家数量从4个减少到3个，这样激活的专家总数与图3 (b) 中的保持一致。

综上所述，DeepSeekMoE架构可以通过下图右侧更正式地表示，我们将其与之前的通用混合专家（MoE）模型进行了比较，以突出其差异：

图6

其中

• 式（11）与之前的式（5）相同，
• 式（10）与式（4）相似，但在这里我们应用TopK从（mN — K_s）个专家中选择（mK — K_s）个专家，其中K_s表示共享专家的数量。
• 式（9）将式（3）中的第一项拆分为两个子项，分别对应共享专家和路由专家。

评估

如前所述，尽管这两种策略背后的直觉听起来很合理，但作者没有提供任何理论证明来支持它们，因此不清楚它们是否确实有助于解决专业化与知识共享之间的紧张关系，以及能在多大程度上起到帮助作用。

基本上，我们想弄清楚三个核心问题：

• DeepSeekMoE能否取得更好的结果？
• 细粒度专家分割能在多大程度上促进专业化？
• 共享专家隔离能在多大程度上减少冗余？

DeepSeekMoE能否取得更好的结果？

首先，作者研究了他们的方法是否能带来更好的整体性能。为了验证这一点，他们训练了一系列具有可比总参数/激活参数的模型，并在不同任务上对其进行评估。他们的主要结果总结在下表中，最佳指标以粗体显示。

以下几点值得注意：

• 蓝色高亮的列将标准Transformer（Dense）与两种混合专家（MoE）架构（Hash Layer [6]和Switch Transformer [7]）进行了比较，显示出在激活参数相当的情况下，MoE架构可以取得显著更好的性能。
• 绿色高亮的列进一步将DeepSeekMoE与另一种MoE方法GShard [5]进行了比较，显示出在激活参数相当的情况下，DeepSeekMoE取得了显著更好的性能。

然而，取得更好的性能并不一定意味着在专业化与知识共享之间取得了更好的平衡，因此我们仍然需要其他实验。

DeepSeekMoE是否有利于专业化？

直接衡量专家的专业化程度是困难的，相反，作者从一个相反的方向设计了一个有趣的实验，即通过禁用一些顶部路由专家来观察会发生什么。

直观地说，当专家更加专业化时，它们应该更不容易被替换，因此，禁用顶部路由专家应该对性能产生更大的影响。

更具体地说，他们在DeepSeekMoE和GShard x 1.5中禁用了顶部路由专家进行实验，后者作为基线，因为当没有禁用专家时，这两种方法的Pile损失相当，见下图中对应于比率0的最左侧点：

随着禁用的路由专家比例的增加，DeepSeekMoE始终产生更高的Pile损失，这表明DeepSeekMoE中的路由专家更加专业化，因此更难被其他专家替代。

DeepSeekMoE是否减少了知识冗余？

遵循类似的想法，作者还禁用了共享专家并激活了一个额外的路由专家，以观察共享专家是否可以通过增加一个额外的路由专家来替代。

结果，他们观察到“Pile损失显著增加，从1.808上升到2.414”，这证实了共享专家所获取的知识在某种程度上是独特的，而路由专家并没有得到充分的训练来涵盖这部分知识。换句话说，路由专家更加专业化，冗余更少。

总结

在本文中，我们通过餐厅的例子类比，解释了DeepSeekMoE，这是DeepSeek-V2和DeepSeek-V3等DeepSeek模型中采用的主要架构创新之一。

更具体地说，我们介绍了MoE的一般工作原理、其优点和挑战，以及专家专业化与知识共享之间的权衡。接着，我们解释了DeepSeekMoE中的两个关键要素：细粒度专家分割和共享专家隔离。我们还讨论了其在评估部分的性能表现。