大模型｜DeepSeek MoE 混合专家系统介绍

MoE（Mix of Expert）混合专家系统在训练和推理时，相比于稠密模型具有明显的优势，但同样也面临训练不稳定，知识混杂和知识冗余问题。本节在经典MoE的基础上介绍deepseek对MoE系统的优化，使其训练更稳定，计算更高效的方式。主要内容包括：

1）经典混合专家系统的定义和两个主要问题 2）deepseek MoE系统的细粒度专家划分和共享专家隔离方案 3）两个优化方案的消融实验和负载均衡方案

1，经典MoE系统

1.1，经典MoE系统定义

在经典的transformer架构中，每层包含两部分，自注意力和前馈网络。可用如下公式表示：

这里的 l 表示对应的层， 表示第 l−1层输出的所有 token（从 1 到 T），Selfatt是自注意力计算， 是经过注意力层后的中间结果；随后每个 token 会经过前馈网络FFN，最终得到第 l 层的输出 。

经典的 MoE系统对 Transformer 做了一个关键修改：将前馈网络 FFN 替换为 MoE 层。这个 MoE 层由多个 "专家" 组成，每个专家本质上是一个小型的 FFN 网络。当输入一个 token 时，模型会通过一个 “路由器"门控网络，决定这个 token 应该由哪些专家处理，通常是 1 到 2 个。经典 MoE 的运行机制可以用以下公式表示：

简单来说，公式5中的 是第l层第i个专家的门控参数，通过 Softmax 计算每个专家对 tokenT的 "匹配度"；公式4中，只保留匹配度最高的 K 个专家（比如 Top2）的权重，其他专家权重为 0；最后将这 K 个专家的输出加权求和，再与原始输入 相加，得到最终结果。

1.2，MoE 知识混杂问题

知识混杂（knowledge hybridity ），经典 MoE 系统通常只使用少量专家（比如 8 或 16 个），这会导致一个问题：分配给同一个专家的 token 往往涵盖非常多样的知识。例如，一个专家同时处理 "数学计算" 和 "情感分析" 的 token，它的参数就必须同时学习这两种完全不同的知识。但模型参数很难同时高效调用两种差异巨大的知识，就像一个人同时精通数学和文学虽然可能，但效率远不如两个人分别专精其一。这种 "一个专家被迫学太多" 的现象，就是知识混杂，会降低专家的专业化程度。

1.3，MoE 知识冗余问题

知识冗余（knowledge redundancy），不同的专家可能需要处理相同的基础常识，比如，无论处理 "科学推理" 还是 "日常对话" 的专家，都需要掌握 "主谓宾语法结构" 这种基础语言知识。结果是，多个专家的参数中都会重复存储这些常识，导致参数浪费。就像两个老师分别教数学和语文，却都要花时间讲解相同的拼音知识，显然不够高效。

小结：知识混杂和知识冗余共同导致了经典 MoE 系统中的专家难以真正 "专业化"，使其性能无法达到理论上限。

2，Deepseek MoE 优化方案

图1，deepseek MoE 混合专家系统优化策略

2.1，细粒度专家划分

细粒度专家划分（Fine-Grained Expert Segmentation）为解决知识混杂问题，Deepseek MoE 在保持总参数不变的前提下，通过拆分 FFN 的中间隐藏层维度，将专家进行更细粒度的拆分。例如，经典 MoE 可能用 16 个专家，每个专家的中间层维度是 8192；而 Deepseek MoE 会把每个专家拆成多个小专家（比如将 16 个拆成 256 个），每个小专家的中间层维度相应减小（比如从 8192 降到 512），总参数仍保持不变。

同时，为了保证整体的效果，Deepseek MoE 会激活更多的细粒度专家（比如从激活 Top2 变为激活 Top8）。这样做的好处是：

• • 多样的知识可以被更精细地拆分到不同专家中。比如，原本 1 个专家要同时学 "加法"、"乘法"、"方程求解"，现在可以拆成 3 个专家分别专精，避免知识混杂。
• • 激活更多专家后，模型能更灵活地组合不同专家的知识。例如处理 "复杂方程" 时，可以同时调用 "乘法专家" 和 "方程求解专家"，而不是依赖一个 "全能但不精" 的专家。

相对于经典MoE系统，在公式上有两个微小的变化：

公式 7 中，总的专家个数由 N 个到 mN 的，需要激活的专家个数由 K 个到 mK 个。公式6中，需要对 mN 个专家的结果求和。

小结：deepseek的MoE系统为了达到“专人专事”的效果，将专家拆分的更多，同时激活的更多。

2.2，共享专家隔离

共享专家隔离（Shared Expert Isolation）为解决知识冗余问题，Deepseek MoE 专门划分了一部分 "共享专家" ，这些专家始终被激活，专门学习所有场景都需要的通用知识，比如基础语法、常用词汇、简单逻辑等。

这样一来，其他 "专用专家" 就无需重复学习这些常识，可以专注于自己的细分领域。例如：

• • 共享专家负责处理 "句子主谓宾是否完整" 这种通用问题。
• • 专用专家则分别专注于"加法"、"乘法"、"方程求解"等，不再浪费参数存储基础语法知识。

通过这种方式，参数效率显著提升，专用专家的专业化程度也更高。相对于经典MoE系统，在公式上有微小的变化：

公式 10 中，可以被激活的“专人专事”专家的数量变为，公式 9 中需要把共享专家的结果加和。

小结：为了避免每个专家都学习通用基础知识，将几个专家每次固定激活，来提供共享基础知识。

3，消融实验和专业性分析

图2，deepseek MoE 消融实验结果。

3.1，消融实验结果

所有参与比较的模型拥有相同的参数量，且被激活的专家的总参数量也相同。

• • 共享专家隔离策略有效

在GShard（0 shared expert + 2 out of 16 routed experts）基础上将一个专家隔离为共享专家（+shared expert isolation）。从上图中可以看出，与GShard相比，有意隔离共享专家在大多数基准测试中都带来了性能提升。

• • 细粒度专家分割很有效

将专家进一步细分为更细粒度来进行更详细的比较。每个专家分割为2个或4个更小的专家，总共得到32个（1个共享+31个路由）或64个（1个共享+63个路由）专家。上图显示了一个一致趋势：专家分割粒度的持续细化对应于整体模型性能的持续提升。这些发现为细粒度专家分割策略的有效性提供了支撑。

• • 共享vs路由专家比例影响不大

为研究了共享专家和路由专家的最佳比例。基于总共64个专家的最细粒度，并保持专家总数和激活专家数不变，尝试隔离1个、2个和4个专家作为共享专家。发现共享专家和路由专家的不同比例对性能没有显著影响，1个、2个和4个共享专家分别实现了1.808、1.806和1.811的Pile损失值。考虑到1:3的比例产生了略微更好的Pile损失值，在扩展DeepSeekMoE时，将共享专家与激活路由专家的比例保持为1:3。

小结：DeepSeekMoE采用共享专家隔离+细粒度专家分割的组合策略，其中共享专家与激活路由专家的比例为1:3，这一设计在保持高效的同时显著提升了模型性能。

3.2，专家“专业性”分析

实验用模型：deepseek MoE 2B，64个专家，1个共享专家，7个被激活的路由专家。比较对象GShard×1.5。

• • 路由专家间表现出较低冗余度

为了评估路由专家间的冗余度，将不同比例的前沿路由专家禁用，并评估Pile损失值。即对于每个token，屏蔽一定比例的具有最高路由概率的专家，然后从剩余的路由专家中选择top-K专家。

结论： 与GShard×1.5相比，DeepSeekMoE对禁用前沿路由专家更加敏感。这种敏感性表明DeepSeekMoE具有较低水平的参数冗余，因为每个路由专家更加不可替代。相比之下，GShard×1.5在其专家参数中表现出更大的冗余度，因此当顶尖路由专家被禁用时，它能够缓冲性能下降。

• • 共享专家不可被路由专家替代

为了研究共享专家在DeepSeekMoE中的作用，将其禁用，并激活一个额外的路由专家保持激活参数一致。

结论： 在Pile上的损失值显著增加，这表明共享专家捕获了路由专家不具备的基础和必要知识，使其无法被路由专家替代。

• • DeepSeekMoE更准确地获取知识

为了验证激活专家组合的更高灵活性，是否有助于更准确和有针对性地获取知识的假设。将激活的路由专家数量从3个变化到7个，并评估由此产生的Pile损失值，评估DeepSeekMoE 是否能够用更少的激活专家获取所需知识。

结论： 实验表明即使只激活4个路由专家，DeepSeekMoE 也能达到与GShard相当的Pile损失值。支持了DeepSeekMoE能够更准确、更高效地获取所需知识的论点。

4，负载不均衡问题

Deepseek MoE 用了两种策略：

动态偏置调整：实时统计每个专家的激活频率，对过于 "忙碌" 的专家，降低其被选中的概率；对过于 "空闲" 的专家，提高其被选中的概率（类似老师调整学生发言机会）。

设备感知调度：将专家均匀分配到多个计算设备（如 GPU），限制一个 token 激活的专家最多分布在 3 个设备上，减少设备间的数据传输开销。

总结

DeepSeekMoE通过细粒度专家分割和共享专家隔离两大创新，实现极高的专家专业化。该架构在多个规模验证卓越：16B模型以40%计算量达到DeepSeek 7B和LLaMA2 7B性能；145B模型仅用28.5%计算量即可媲美DeepSeek 67B。相比经典MoE架构GShard，DeepSeekMoE专家专业化程度更高、参数效率更优，有模型可以支持单40GB GPU部署，推动大模型发展，降低了应用门槛。

参考：arXiv:2401.06066