大模型的工程原理 第7章 Mixture of Experts（MoE）架构

第7章 Mixture of Experts（MoE）架构

你将学会：

• 理解 MoE 的核心思想：稀疏激活与条件计算
• 掌握路由机制的多种设计方案
• 理解 DeepSeek-MoE 的 Shared Expert 和 Fine-Grained Expert 设计
• 掌握负载均衡问题及其工程解决方案
• 理解 MoE 在训练和推理中的特殊挑战

前置知识：第5章Transformer架构、第6章注意力效率
难度：⭐⭐

阅读引导（建议先看）：

• 先看每节开头的直觉解释，再进入公式细节。
• 遇到 Q/K/V、多头注意力等概念卡住时，先回看第6章 6.0 节。
• 看公式时优先确认符号含义和张量形状（输入/输出怎么变）。
• 再关注公式在解决什么工程瓶颈：算力、显存、稳定性或效果。
• 如果出现"公式懂了但不知道为什么"，先回到该节的问题定义再读推导。

7.1 MoE 的核心思想：稀疏激活与条件计算

一个简单的对比

Dense 模型：对每个输入 Token，模型的所有参数都参与计算。

LLaMA-70B: 70B 参数，每个 Token 激活 70B 参数

MoE 模型：模型有很多参数，但每个 Token 只使用其中一小部分。

DeepSeek-V3: 671B 总参数，每个 Token 只激活 37B 参数

这意味着：DeepSeek-V3 拥有 671B 模型的知识容量，但每次推理的计算量只相当于一个 37B 的密集模型。大容量、低计算量——这就是 MoE 的核心价值。

MoE 替换的是什么

MoE 并不替换整个 Transformer Block，只是替换其中的FFN（Feed-Forward Network）部分：

标准 Transformer Block: Attention → FFN MoE Transformer Block: Attention → MoE(FFN₁, FFN₂, ..., FFNₙ, Router)

具体来说，原来有一个 FFN，现在变成了NNN个 FFN（称为"专家"），加上一个**路由器（Router）**决定每个 Token 使用哪些专家。

形式化定义

设有NNN个专家{E1,E2,...,EN}\{E_1, E_2, ..., E_N\}{E1​,E2​,...,EN​}和一个路由函数GGG。对于输入xxx：

公式与符号阅读卡

在看本节公式前，建议先按这 3 步过一遍：

1. 先确认每个符号代表什么（变量含义、是否是可学习参数）。
2. 再看张量形状如何变化（输入维度 → 输出维度）。
3. 最后问一句：这个公式在解决什么工程问题（精度、效率、稳定性或成本）。

阅读提醒：如果推导中间某一步不直观，优先回到"问题定义"和"约束条件"，而不是死抠代数变形。

MoE(x)=∑i=1NG(x)i⋅Ei(x)\text{MoE}(x) = \sum_{i=1}^{N} G(x)_i \cdot E_i(x)MoE(x)=i=1∑N​G(x)i​⋅Ei​(x)

其中G(x)iG(x)_iG(x)i​是路由器给第iii个专家的权重。大多数G(x)i=0G(x)_i = 0G(x)i​=0（该专家不被激活），只有少数非零（稀疏激活）。

7.2 路由机制深入：Top-K Gating、Expert Choice、Soft MoE

路由器决定了"每个 Token 该找哪个专家"，是 MoE 最核心的组件。

Top-K Gating（最常用）

deftop_k_gating(x,expert_weights,k=2):""" x: (batch_size, d_model) — Token 的隐藏状态 expert_weights: (d_model, n_experts) — 路由器的可学习参数 """# 计算每个专家的得分logits=x @ expert_weights# (batch_size, n_experts)# 选出 Top-K 个专家top_k_logits,top_k_indices=logits.topk(k,dim=-1)# Softmax 归一化（只在选中的 K 个专家上做）gates=F.softmax(top_k_logits,dim=-1)returngates,top_k_indices

• 每个 Token 选择得分最高的KKK个专家（通常K=2K=2K=2）
• 用 Softmax 归一化后作为权重
• 输出 = 选中专家输出的加权和

优点：简单高效、计算量固定
缺点：可能导致负载不均——某些专家被频繁选中，其他专家闲置

Expert Choice Routing

反过来：不是 Token 选专家，而是专家选 Token。

每个专家从所有 Token 中选择与自己最相关的 Top-C 个 Token 来处理。这保证了每个专家处理相同数量的 Token——完美负载均衡。

缺点：部分 Token 可能被多个专家选中（计算浪费），部分 Token 可能没被任何专家选中（信息丢失）。

Soft MoE

不做硬选择，而是所有专家都参与，但权重由路由器决定的软权重加权。相当于把所有 Token 做一个加权组合后送给每个专家。

• 无离散决策，梯度传播更顺畅
• 但失去了"稀疏"的优势，计算量更大

各方案对比

7.3 Shared Expert 与 Fine-Grained Expert：DeepSeek-MoE 的架构创新

DeepSeek 在 MoE 设计上做了两项关键创新：

创新一：Shared Expert（共享专家）

问题：标准 MoE 中，不同 Token 激活不同的专家。但很多基础知识（如语法规则、常识）是所有 Token 都需要的。如果这些知识分散在各个专家中，每个专家都要存一份，造成参数冗余。

方案：设定若干共享专家（Shared Expert），它们被所有 Token 激活。其余为路由专家（Routed Expert），由路由器决定激活。

DeepSeek-V3: - 1 个 Shared Expert（所有 Token 都用） - 256 个 Routed Expert（每个 Token 选 8 个） - 每个 Token 实际使用 1 + 8 = 9 个 Expert

好处：

• 共享知识集中在 Shared Expert 中，避免冗余
• 路由专家可以更专注于特定领域/模式
• 提升参数效率

创新二：Fine-Grained Expert（细粒度专家）

思路：与其用少量大专家，不如用大量小专家。

标准 MoE: 8 个大专家，每个 Token 选 2 个 → 激活 25% 参数 DeepSeek: 256 个小专家，每个 Token 选 8 个 → 激活 3.1% 参数

更多更小的专家让路由更精细——模型可以更灵活地组合不同的"知识模块"。

标准 MoE (8 experts, top-2): 可能的组合: C(8,2) = 28 种 DeepSeek (256 experts, top-8): 可能的组合: C(256,8) ≈ 4.4 × 10^13 种 → 天文级别的组合灵活性

7.4 负载均衡工程：Auxiliary Loss 与动态调控

问题：专家负载崩塌

MoE 训练中最常见的问题是负载不均衡：路由器"偏爱"少数专家，大部分专家几乎不被使用。

极端情况下，路由器可能把所有 Token 都发给同一个专家——这就退化成了普通的 Dense 模型，失去了 MoE 的全部意义。

解决方案一：Auxiliary Loss（辅助损失）

在训练损失中加入一个额外的"均衡损失"，惩罚不均匀的专家使用：

L=LLM+α⋅Lbalance\mathcal{L} = \mathcal{L}_{\text{LM}} + \alpha \cdot \mathcal{L}_{\text{balance}}L=LLM​+α⋅Lbalance​

Lbalance=N⋅∑i=1Nfi⋅pi\mathcal{L}_{\text{balance}} = N \cdot \sum_{i=1}^{N} f_i \cdot p_iLbalance​=N⋅i=1∑N​fi​⋅pi​

其中：

• fif_ifi​= 第iii个专家实际处理的 Token 比例
• pip_ipi​= 路由器分配给第iii个专家的平均概率
• NNN= 专家数量
• α\alphaα= 均衡系数（通常 0.01-0.1）

当所有专家均匀使用时，这个损失最小。

解决方案二：Expert-Level Balance Loss

DeepSeek-V3 引入了更精细的均衡策略，不使用全局的辅助损失（因为它会干扰语言模型的训练），而是在每个专家层独立调控。

解决方案三：动态限容

为每个专家设定容量因子（Capacity Factor）：

C=CF×nNC = \text{CF} \times \frac{n}{N}C=CF×Nn​

当一个专家接收的 Token 达到容量上限时，多余的 Token 会被溢出（overflow）——要么丢弃，要么用残差连接"跳过"MoE 层。

# 容量因子 = 1.25：每个专家最多处理比均匀分配多 25% 的 Tokencapacity=int(capacity_factor*num_tokens/num_experts)

7.5 MoE 训练的分布式挑战：Expert Parallelism 与通信优化

Expert Parallelism

MoE 的专家天然适合分布式——每个 GPU 放几个专家：

GPU 0: Expert 0, 1, 2, 3 不同 GPU 上的专家独立计算 GPU 1: Expert 4, 5, 6, 7 GPU 2: Expert 8, 9, 10, 11 GPU 3: Expert 12, 13, 14, 15

但问题是：Token 的路由是动态的——一个 Token 可能需要 GPU 0 的 Expert 1 和 GPU 2 的 Expert 9。这就需要All-to-All 通信：每张卡把 Token 发给持有对应专家的卡，计算完再发回来。

All-to-All 通信开销

1. Dispatch（发送）: 每张卡把路由到其他卡的 Token 发出去 2. Compute（计算）: 每张卡对收到的 Token 做专家计算 3. Combine（回收）: 每张卡把计算结果发回给原始 Token 所在的卡

这个通信开销在大规模训练中不可忽视。DeepSeek-V3 通过以下手段优化：

• 通信-计算重叠：在发送下一批 Token 的同时计算当前批
• 压缩通信：用 FP8 传输，减少通信量
• 拓扑感知路由：让同一节点内的 GPU 尽量使用本地专家

7.6 MoE 推理优化：Expert Offloading、动态缓存、预测性加载

MoE 推理的特殊挑战

MoE 模型的总参数量巨大（DeepSeek-V3 = 671B），但每次只使用 37B。问题是：全部参数仍然需要加载到某个地方。

671B 参数 ×2 字节（FP16）=1.3TB——远超单台服务器的 GPU 显存。

Expert Offloading

思路：只把当前需要的专家放在 GPU 显存中，其余放在 CPU 内存或 SSD 中。

GPU (80GB): 当前激活的 8 个专家 + Attention 层 + Shared Expert CPU (512GB): 其余 248 个专家 SSD (NVMe): 模型权重的完整备份 每次 Token 路由后： 1. 查看需要哪些专家 2. 把 GPU 上不需要的专家换出 3. 把需要的专家从 CPU 加载进来

预测性加载

改进：根据上一层的路由决策，预测下一层可能需要的专家，提前开始加载。命中率可达 90%+。

动态缓存

类似操作系统的页面缓存——频繁使用的专家常驻 GPU，偶尔使用的按需加载。

llama.cpp 中的 MoE 推理

在消费级硬件上运行 MoE 模型（如 Mixtral 8x7B），llama.cpp 等引擎利用 CPU + GPU 分层推理：

Attention 层: GPU 计算（需要快速矩阵运算） Expert 层: CPU 计算（内存足够放下所有专家）

7.7 Dense vs. MoE 的工程决策：何时选择稀疏架构

MoE 的优势

MoE 的劣势

决策框架

你的场景是什么？ ├── 预训练大模型（>50B target capability） │ └── 强烈推荐 MoE（性价比高） ├── 小模型（<10B） │ └── 不推荐 MoE（收益小、工程复杂） ├── 微调/适配场景 │ └── 优先选择 Dense（更稳定、更易微调） └── 推理部署 ├── GPU 充足 → Dense 或 MoE 都可 └── GPU 有限但内存充足 → MoE + Offloading

现实中的选择

一页带走：本章 5 个核心结论

1. MoE = 总参数大但每次只激活一部分
2. Top-K 路由 + 负载均衡是 MoE 训练的两大难点
3. All-to-All 通信是 MoE 训练的瓶颈
4. MoE 推理框架支持度远不如 Dense
5. Shared + Routed 专家组合是当前最佳实践

本章小结

本章变量与术语速查

看到陌生符号或术语先回查这张表，不必死记。

MoE 张量维度流追踪

记BBB=batch、nnn=序列长、ddd=隐藏维、NNN=专家总数、KKK=Top-K：

输入 x (B, n, d) # 例 (2, 1024, 4096) │ ├── Router(x) (B, n, N) # 每 Token 对每个专家的得分 │ softmax + TopK → indices (B, n, K) # 选出 K 个专家 │ weights (B, n, K) # 归一化后的门控权重 │ ├── 对选中的专家执行： │ E_i(x_token) (d) → (d) # 每个专家就是一个 FFN │ └── 加权求和 y = Σ_k weights[k] · E_{idx[k]}(x) # (B, n, d)

工程含义：

1. 路由是一次(B⋅n)×d×N(B \cdot n) \times d \times N(B⋅n)×d×N的小矩阵乘 + softmax + TopK，开销可控。
2. 真正的瓶颈是Token → Expert 的重排（All-to-All）：当 EP（专家并行）跨多卡时，每张卡只持有部分专家，需要把本卡 Token 路由到对方卡上去算，再收回来。
3. weights的形状决定了反向传播时梯度怎么回到 router —— 这是 MoE 训练中梯度方差大的根源。

一句话直觉：MoE 的’稀疏激活’

MoE 不是把模型变小，而是把模型变大但每次只用一部分。像一家有 64 个专科医生的医院（总参数大），但每个病人只挂 2 个医生的号（激活少），单次诊费便宜，整体能力却覆盖广。

工程含义：到了线上意味着什么

• MoE 模型上线 ≠ 总参数小，需要的总显存反而更大（每张卡都要存自己负责的专家）——账要按总参数算，速度按激活参数算。
• EP（专家并行）的 All-to-All 是网络瓶颈，决定了你需要多好的 NVLink/InfiniBand。
• MoE 推理框架支持度远不如 Dense 模型成熟，选型时要看自己的推理引擎是否原生支持。

容易踩的坑

• 以为 MoE 的’激活参数小 = 显存小’ → 实际所有专家都得加载，总显存比 Dense 大得多。
• 专家不均衡（Expert Imbalance）→ 几个热门专家被打爆，冷门专家闲着，整体吞吐惨。
• 以为 MoE 推理 vLLM 都支持 → 实际特殊架构（如 DeepSeek-MoE）需要专门适配。

数字示例：Mixtral-8x7B 的’参数账’

Mixtral-8x7B 看似 56B（8×7B），实则：

• 总参数：约 47B（共享部分只算一次）
• 每次激活参数：~13B（Top-2 专家）
• 推理速度：和 13B 模型相当
• 显存占用：和 47B 模型相当

‘按 13B 速度，按 47B 装机’—— 这就是 MoE 的本质 trade-off。

跨章导航

• 依赖：第5章（标准 FFN）+ 第14章（并行）
• 承接：
  • 第8章 — 主流 MoE 模型对比
  • 第14章 EP 部分 — MoE 训练的并行策略
  • 第23章 — MoE 推理的特殊框架支持

选型速决：MoE vs Dense 选型

故障排查速查

下一章预告：第 8 章我们将横向对比主流大模型的架构设计——LLaMA、DeepSeek、Qwen、Mistral 各自做了什么技术选择？以及 Mamba、RWKV 等非 Transformer 架构是否有机会挑战 Transformer 的统治地位？