第7章 Mixture of ExpertsMoE架构你将学会理解 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只是替换其中的FFNFeed-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 步过一遍先确认每个符号代表什么变量含义、是否是可学习参数。再看张量形状如何变化输入维度 → 输出维度。最后问一句这个公式在解决什么工程问题精度、效率、稳定性或成本。阅读提醒如果推导中间某一步不直观优先回到问题定义和约束条件而不是死抠代数变形。MoE(x)∑i1NG(x)i⋅Ei(x)\text{MoE}(x) \sum_{i1}^{N} G(x)_i \cdot E_i(x)MoE(x)i1∑N​G(x)i​⋅Ei​(x)其中G(x)iG(x)_iG(x)i​是路由器给第iii个专家的权重。大多数G(x)i0G(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,k2): x: (batch_size, d_model) — Token 的隐藏状态 expert_weights: (d_model, n_experts) — 路由器的可学习参数 # 计算每个专家的得分logitsx expert_weights# (batch_size, n_experts)# 选出 Top-K 个专家top_k_logits,top_k_indiceslogits.topk(k,dim-1)# Softmax 归一化只在选中的 K 个专家上做gatesF.softmax(top_k_logits,dim-1)returngates,top_k_indices每个 Token 选择得分最高的KKK个专家通常K2K2K2用 Softmax 归一化后作为权重输出 选中专家输出的加权和优点简单高效、计算量固定缺点可能导致负载不均——某些专家被频繁选中其他专家闲置Expert Choice Routing反过来不是 Token 选专家而是专家选 Token。每个专家从所有 Token 中选择与自己最相关的 Top-C 个 Token 来处理。这保证了每个专家处理相同数量的 Token——完美负载均衡。缺点部分 Token 可能被多个专家选中计算浪费部分 Token 可能没被任何专家选中信息丢失。Soft MoE不做硬选择而是所有专家都参与但权重由路由器决定的软权重加权。相当于把所有 Token 做一个加权组合后送给每个专家。无离散决策梯度传播更顺畅但失去了稀疏的优势计算量更大各方案对比方案负载均衡梯度友好稀疏性代表模型Top-K Gating需要辅助损失有离散梯度问题严格稀疏Mixtral, DeepSeekExpert Choice天然均衡较好较稀疏某些 Google 模型Soft MoE天然均衡最好不稀疏ViT-MoE7.3 Shared Expert 与 Fine-Grained ExpertDeepSeek-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辅助损失在训练损失中加入一个额外的均衡损失惩罚不均匀的专家使用LLLMα⋅Lbalance\mathcal{L} \mathcal{L}_{\text{LM}} \alpha \cdot \mathcal{L}_{\text{balance}}LLLM​α⋅Lbalance​LbalanceN⋅∑i1Nfi⋅pi\mathcal{L}_{\text{balance}} N \cdot \sum_{i1}^{N} f_i \cdot p_iLbalance​N⋅i1∑N​fi​⋅pi​其中fif_ifi​ 第iii个专家实际处理的 Token 比例pip_ipi​ 路由器分配给第iii个专家的平均概率NNN 专家数量α\alphaα 均衡系数通常 0.01-0.1当所有专家均匀使用时这个损失最小。解决方案二Expert-Level Balance LossDeepSeek-V3 引入了更精细的均衡策略不使用全局的辅助损失因为它会干扰语言模型的训练而是在每个专家层独立调控。解决方案三动态限容为每个专家设定容量因子Capacity FactorCCF×nNC \text{CF} \times \frac{n}{N}CCF×Nn​当一个专家接收的 Token 达到容量上限时多余的 Token 会被溢出overflow——要么丢弃要么用残差连接跳过MoE 层。# 容量因子 1.25每个专家最多处理比均匀分配多 25% 的 Tokencapacityint(capacity_factor*num_tokens/num_experts)7.5 MoE 训练的分布式挑战Expert Parallelism 与通信优化Expert ParallelismMoE 的专家天然适合分布式——每个 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 字节FP161.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 8x7Bllama.cpp 等引擎利用 CPU GPU 分层推理Attention 层: GPU 计算需要快速矩阵运算 Expert 层: CPU 计算内存足够放下所有专家7.7 Dense vs. MoE 的工程决策何时选择稀疏架构MoE 的优势优势说明更大的模型容量同等计算量下知道更多知识训练效率每个 Token 的计算量更少推理速度激活参数少 → 推理快MoE 的劣势劣势说明内存占用大所有专家都要存储通信开销Expert Parallelism 需要 All-to-All训练不稳定负载均衡、路由崩塌等问题工程复杂部署、调优比 Dense 模型复杂得多微调不友好专家可能对微调数据过拟合决策框架你的场景是什么 ├── 预训练大模型50B target capability │ └── 强烈推荐 MoE性价比高 ├── 小模型10B │ └── 不推荐 MoE收益小、工程复杂 ├── 微调/适配场景 │ └── 优先选择 Dense更稳定、更易微调 └── 推理部署 ├── GPU 充足 → Dense 或 MoE 都可 └── GPU 有限但内存充足 → MoE Offloading现实中的选择模型类型总参数激活参数理由GPT-4 (推测)MoE~1.8T~280B顶级性能DeepSeek-V3MoE671B37B极致性价比LLaMA-3 70BDense70B70B简单可靠Qwen-2.5 72BDense72B72B生态成熟Mixtral 8x7BMoE47B13B小规模 MoE一页带走本章 5 个核心结论MoE 总参数大但每次只激活一部分Top-K 路由 负载均衡是 MoE 训练的两大难点All-to-All 通信是 MoE 训练的瓶颈MoE 推理框架支持度远不如 DenseShared Routed 专家组合是当前最佳实践本章小结知识点关键收获MoE 核心原理多个专家 FFN 路由器每个 Token 只激活少数专家Top-K Gating最常用路由选得分最高的 K 个专家Shared Expert所有 Token 共享的基础专家避免知识冗余Fine-Grained Expert更多更小的专家组合灵活性更高负载均衡Auxiliary Loss 容量限制防止专家崩塌Expert Parallelism专家分布在不同 GPU需要 All-to-All 通信推理优化Expert Offloading、预测性加载、动态缓存本章变量与术语速查符号 / 术语含义工程含义NNN专家总数常见 8、64、256DeepSeek-V3KKK每个 Token 激活的专家数Top-K常 2、8G(x)G(x)G(x)路由器输出每个专家的权重大多数为 0稀疏Ei(x)E_i(x)Ei​(x)第 i 个专家实质是一个 FFN替换原始 FFN 部分Shared Expert所有 Token 都激活的专家DeepSeek 创新沉淀通用知识Routed Expert由路由器决定激活的专家负责领域细分容量因子 CF每个专家最多比平均多承载多少 Token常 1.0-1.5Auxiliary Loss负载均衡辅助损失防止专家“偏科”All-to-AllToken 在 Expert 之间的跨卡通信MoE 训练主要瓶颈看到陌生符号或术语先回查这张表不必死记。MoE 张量维度流追踪记BBBbatch、nnn序列长、ddd隐藏维、NNN专家总数、KKKTop-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)工程含义路由是一次(B⋅n)×d×N(B \cdot n) \times d \times N(B⋅n)×d×N的小矩阵乘 softmax TopK开销可控。真正的瓶颈是Token → Expert 的重排All-to-All当 EP专家并行跨多卡时每张卡只持有部分专家需要把本卡 Token 路由到对方卡上去算再收回来。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 看似 56B8×7B实则总参数约 47B共享部分只算一次每次激活参数~13BTop-2 专家推理速度和 13B 模型相当显存占用和 47B 模型相当‘按 13B 速度按 47B 装机’—— 这就是 MoE 的本质 trade-off。跨章导航依赖第5章标准 FFN 第14章并行承接第8章 — 主流 MoE 模型对比第14章 EP 部分 — MoE 训练的并行策略第23章 — MoE 推理的特殊框架支持选型速决MoE vs Dense 选型方案适用场景 / 取舍典型选择Dense推理简单、生态成熟中小规模、推理框架受限稀疏 MoE同算力下能力上限高有强工程团队的大规模训练Shared Expert Routed兼顾通用 专精DeepSeek-V3 推荐组合故障排查速查症状可能原因处置建议MoE 训练 loss 抖动专家不均衡加 aux loss / 调 router temperatureEP 通信开销大All-to-All 走 PCIeTP×EP 重排到 NVLink 内MoE 推理崩推理框架不支持该 MoE 变体换 SGLang / 自适配下一章预告第 8 章我们将横向对比主流大模型的架构设计——LLaMA、DeepSeek、Qwen、Mistral 各自做了什么技术选择以及 Mamba、RWKV 等非 Transformer 架构是否有机会挑战 Transformer 的统治地位