技术日报 2026-04-14
摘要
混合专家模型（Mixture of Experts, MoE）已成为 2024—2026 年超大规模语言模型的核心架构。DeepSeek-V3（671B 参数，37B 激活）、Llama 4 Maverick（400B 总参，128 专家）、Qwen3-MoE 等顶尖模型均采用 MoE 架构。本期报告系统讲解 MoE 的发展脉络、路由机制数学原理、负载均衡技术、训练稳定性挑战，以及从专家并行到专家卸载、FP8 量化的完整推理系统优化体系，并附完整代码示例与工程配置指南。
一、MoE 发展脉络
1.1 历史起源与里程碑
MoE 的思想可追溯至 1991 年 Jacobs、Jordan、Nowlan 和 Hinton 的论文《Adaptive Mixtures of Local Experts》——提出由多个专门子网络各自处理不同类型的输入，并通过门控网络协调选择。这一思想在此后近 25 年内主要停留在学术层面，直到大规模 Transformer 时代才真正爆发。
| 年份 | 工作 | 核心贡献 |
|---|---|---|
| 1991 | Jacobs et al. | 提出 MoE 基本框架 |
| 2017 | Shazeer et al. Sparsely-Gated MoE | 引入稀疏门控 + Noisy Top-K，实现千亿级扩展 |
| 2020 | Google GShard | 条件计算 + 自动分片，跨设备分布式 MoE |
| 2021 | Google Switch Transformer | Top-1 路由极简化，扩展到万亿参数 |
| 2022 | Google ST-MoE | Z-loss 稳定训练，稀疏→微调深度分析 |
| 2022 | Expert Choice (Zhou et al.) | 翻转路由方向，专家主动选 Token |
| 2024.1 | Mixtral 8x7B (Mistral AI) | 开源 SMoE，Top-2，47B 参数 |
| 2024.1 | DeepSeekMoE | 细粒度专家分割 + 共享专家机制 |
| 2024.12 | DeepSeek-V3 | 671B 总参数，无辅助损失路由，偏置更新机制 |
| 2025 | Llama 4 Scout/Maverick | Meta MoE，Scout 16 专家，Maverick 128 专家 |
| 2026.4 | Routing-Free MoE | 消除中心化硬编码路由的新范式 |
1.2 架构演进核心趋势
专家粒度：粗粒度（8专家）→ 细粒度（256专家）
路由激活：50%（Top-4/8）→ 3-5%（Llama 4 Maverick）
负载均衡：辅助损失 → 无辅助损失偏置更新（DeepSeek-V3）
路由方向：Token Choice → Expert Choice → 混合路由
专家结构：仅路由专家 → 共享专家 + 路由专家（DeepSeekMoE）
门控函数：Softmax → Sigmoid（DeepSeek-V3，超大专家数下更高效）
二、MoE 架构基本原理
2.1 标准 Transformer 中的 MoE 层
在 Transformer 架构中，MoE 的核心思想是将每个 Decoder Layer 的 前馈网络（FFN） 替换为一个 MoE 层：
标准 Transformer Block：Input → LayerNorm → Attention → Add → LayerNorm → FFN → Add → OutputMoE Transformer Block：Input → LayerNorm → Attention → Add → LayerNorm → [Router → Top-K Experts] → Add → Output
MoE 层包含两个核心组件：
- 专家网络（Expert Networks）：N 个独立的前馈子网络，每个专家专注于不同类型的特征处理
- 门控路由器（Gating Router）：一个轻量级可学习网络，决定每个 Token 应该路由到哪些专家
2.2 稀疏激活的计算效益
MoE 的核心价值在于参数规模与计算成本解耦：
| 指标 | 传统稠密模型 | MoE 模型 |
|---|---|---|
| 参数量 | 100% | 极大（可达 10× 甚至 100×） |
| 推理 FLOPs | 100% | 仅激活参数的比例（~5-30%） |
| 显存（加载） | 线性于参数量 | 全部参数需加载，但计算只用激活部分 |
以 Mixtral 8×7B 为例：总参数 ~47B，每 Token 仅激活 2 个专家，实际计算量约等于 13B 稠密模型，但模型容量相当于 47B。
三、路由机制详解
3.1 Top-K 路由（Token Choice）—— Shazeer 2017 原始公式
Noisy Top-K Gating 是现代 MoE 路由的基础：
Step 1：带噪声的门控分数计算
$$H(x)_i = (x \cdot W_g)i + \text{StandardNormal}() \cdot \text{Softplus}\big((x \cdot W{\text{noise}})_i\big)$$
- $x$：输入 Token 的隐状态向量
- $W_g$：可学习门控权重矩阵
- $W_{\text{noise}}$：控制噪声幅度的可学习矩阵（训练时开启，推理时关闭）
- Softplus 确保噪声权重非负
Step 2：Top-K 稀疏化
$$\text{KeepTopK}(v, k)_i = \begin{cases} v_i & \text{若 } v_i \text{ 位于前 } k \text{ 大} \ -\infty & \text{否则} \end{cases}$$
Step 3：Softmax 归一化
$$G(x) = \text{Softmax}\big(\text{KeepTopK}(H(x), k)\big)$$
Step 4：加权输出
$$y = \sum_{i=1}^{N} G(x)_i \cdot E_i(x)$$
只有被选中的 $k$ 个专家有非零权重，实现稀疏激活。
噪声的作用：训练时注入探索噪声，防止门控过早收敛到少数专家，同时 $W_{\text{noise}}$ 可学习，自适应调整噪声幅度。
3.2 Switch Transformer 的 Top-1 路由（2021）
Switch Transformer 将 K 极简化为 K=1，每个 Token 只被路由到一个最高概率专家：
$$p_i(x) = \frac{e^{x \cdot W_r^i}}{\sum_j e^{x \cdot W_r^j}}, \quad \text{选中专家} = \arg\max_i p_i(x)$$
容量因子（Capacity Factor, C） 控制每个专家的最大 Token 处理数量：
$$K_{\max} = \left\lfloor C \cdot \frac{N_{\text{tokens}}}{N_{\text{experts}}} \right\rfloor$$
- $C > 1$（通常 1.1~1.5）允许一定过载
- 若专家已满，溢出 Token 将被丢弃（dropped），其表示直接透传残差
- Top-1 路由大幅简化通信逻辑，但丢弃率更高
3.3 Expert Choice 路由（Zhou et al., 2022）
颠覆性设计：传统 Token Choice 是每个 Token 选择专家；Expert Choice 反向操作——每个专家主动选择 Token。
对于每层，计算 Token-Expert 亲和度矩阵：
$$S = X \cdot W_r^T \in \mathbb{R}^{N_\text{tokens} \times N_\text{experts}}$$
每个专家 $e$ 从 $S_{:,e}$ 中选出得分最高的 Top-$k$ 个 Token：
$$\mathcal{T}e = \text{TopK}(S, k)$$
与 Token Choice 的核心对比：
| 维度 | Token Choice (TC) | Expert Choice (EC) |
|---|---|---|
| 路由方向 | Token → Expert | Expert → Token |
| 负载均衡 | 需要辅助损失 | 天然完美均衡 |
| Token 处理 | 每 Token 恰好被 K 个专家处理 | 不保证（某些 Token 可能被 0 次或多次处理） |
| 推理兼容性 | 好（自回归推理友好） | 较差（不保证每 Token 覆盖） |
| 代表模型 | Mixtral, DeepSeek | GLaM |
3.4 DeepSeekMoE 的细粒度专家分割
DeepSeekMoE（2024.1）针对传统 MoE 的两大问题提出解决方案：
问题 1：知识混杂——专家数量有限时，每个专家被迫处理多样化知识，专业化程度低
问题 2：知识冗余——不同专家学习了相同的通用知识，参数浪费
两大核心策略：
① 细粒度专家划分：将 FFN 中间隐藏维度拆分，专家粒度更细（V3 达 256 个路由专家）。每个专家聚焦更窄领域，组合更灵活，专业化程度更高。
② 共享专家隔离：设置 $K_s$ 个始终激活的共享专家，专门处理通用语言知识（语法、句法等），释放路由专家的专业化空间，消除知识冗余。
DeepSeekMoE V1 计算公式：
$$h_t^l = \sum_{i=1}^{K_s} \text{FFN}i(u_t^l) + \sum^{mN} \big(g_{i,t} \cdot \text{FFN}_i(u_t^l)\big) + u_t^l$$
其中 $g_{i,t}$ 为 Top-K 路由权重（非零仅对选中专家），第一项为共享专家输出，第二项为路由专家输出，第三项为残差连接。
3.5 DeepSeek-V3 的门控函数演进
V3 的重大变化：将门控函数从 Softmax 改为 Sigmoid：
$$s_{i,t} = \text{Sigmoid}(u_t^T e_i)$$
原因：V3 有 256 个路由专家，大维度下 Softmax 的计算（指数运算 + 求和 + 归一化）开销显著，Sigmoid 直接将每个专家得分映射到 $[0, 1]$，计算更高效，实验效果相当。
四、负载均衡技术
4.1 路由崩塌问题
MoE 训练中最核心的挑战是路由崩塌（Routing Collapse）：
正反馈死循环：某专家初始得分略高 → 获得更多 Token 训练 → 能力更强 → 吸引更多 Token → 其他专家饿死（Expert Death）→ 模型退化为单一专家
Softmax 的指数特性会急剧放大原始分数间的微小差距（分数差 1.0 → 概率比约 2.7×），使崩塌自我强化。
4.2 辅助损失函数体系
Switch Transformer 辅助损失（2021）：
$$\mathcal{L}{\text{aux}} = \alpha \cdot N \cdot \sum^{N} f_i \cdot P_i$$
- $f_i = \frac{1}{T}\sum_{x \in B} \mathbf{1}{\arg\max p(x) = i}$：专家 $i$ 实际处理 Token 的比例（不可微）
- $P_i = \frac{1}{T}\sum_{x \in B} p_i(x)$：路由器给专家 $i$ 的平均概率（可微，作为梯度代理）
- $N$：专家数，$\alpha = 10^{-2}$，最优时 $f_i = P_i = 1/N$
DeepSeek V1 专家级负载均衡损失：
$$\mathcal{L}{\text{ExpBal}} = \alpha_1 \sum^{N'} f_i P_i, \quad f_i = \frac{N'}{K'T}\sum_{t=1}^{T}\mathbf{1}(\text{Token } t \text{ selects Expert } i)$$
其中系数 $N'/K'$ 用于消除不同激活专家数量对损失幅度的影响，使损失值在不同配置下保持稳定。
Router Z-Loss（ST-MoE 2022）：
$$\mathcal{L}{\text{z-loss}} = \frac{1}{B} \sum^{B} \left( \log \sum_{j=1}^{N} e^{x_{b,j}} \right)^2$$
专门惩罚过大的门控 logits，防止 Softmax 产生过于尖锐的概率分布，改善训练数值稳定性。
4.3 DeepSeek-V3 无辅助损失策略（2024 最新）
核心创新：完全废弃三套辅助损失，用可学习偏置项 $b_i$ 替代：
$$g'{i,t} = \begin{cases} s & \text{若 } s_{i,t} + b_i \in \text{TopK} \ 0 & \text{否则} \end{cases}$$
- 偏置项只影响路由决策，不参与加权输出计算
- 训练中动态调整：高负载专家 $b_i -= \gamma$，低负载专家 $b_i += \gamma$
- 实际参数：前 14.3T Token 训练时 $\gamma = 0.001$；最后 500B Token 时 $\gamma = 0.0$（停止更新）
- 额外保留轻量序列级辅助损失（$\alpha = 0.00001$），防止单序列内极端不平衡
优势：消除辅助损失与主任务损失的梯度干扰，训练效果优于所有辅助损失方案。
4.4 负载均衡诊断指标
# 监控专家利用率的关键指标# 1. Token 分数（理想值 1/E）
token_fraction = [tokens_per_expert[i] / total_tokens for i in range(num_experts)]# 2. 负载不平衡因子（LIF = 1 时完美均衡，= E 时极度失衡）
LIF = num_experts * max(token_fraction)# 3. 变异系数（CV = 0 时完美均衡）
CV = std(token_fraction) / mean(token_fraction)# 4. 路由器熵（均匀分布时最大，下降是崩塌早期预警）
from scipy.stats import entropy
router_entropy = entropy(router_probs)
五、主流模型架构对比
5.1 参数规模横向对比
| 模型 | 总参数 | 激活参数 | 路由专家数 | 激活专家数 | 共享专家 | 上下文 |
|---|---|---|---|---|---|---|
| Mixtral 8x7B | ~47B | ~13B | 8 | 2 | 无 | 32K |
| Grok-1 | 314B | ~80B | 未公开 | ~25% | — | — |
| DBRX | 132B | 36B | 16 | 4 | 无 | — |
| DeepSeek V2 | 236B | 21B | 160 | 6 | 2 | 128K |
| DeepSeek V3 | 671B | 37B | 256 | 8 | 1 | 128K |
| Llama 4 Scout | ~109B | 17B | 16 | — | — | 10M |
| Llama 4 Maverick | ~400B | 17B | 128 | — | — | 1M |
| 华为盘古 Ultra | 718B | — | 256 | 8 | — | — |
5.2 DeepSeek V1 → V2 → V3 关键演进
V1（DeepSeekMoE）：- 细粒度专家划分（mN 个小专家，激活 mK 个）- 共享专家隔离（Ks 个共享 + N-Ks 个路由）- 专家级 + 设备级双重辅助损失V2 (+3 项改进)：- 设备受限路由（激活专家限制在 M≤3 个设备）- 通信负载均衡损失- Token 丢弃策略（按亲和值降序，超容量 Token 丢弃）V3 (+5 项改进)：- 门控函数 Softmax → Sigmoid（256 专家下更高效）- 废弃所有辅助损失，改用偏置项 b_i ± γ 动态调节- 保留序列级轻量辅助损失（α=0.00001）- 沿用设备受限路由- 取消 Token 丢弃策略（偏置项方案实现真正均衡）
六、MoE 训练挑战与解决方案
6.1 专家崩塌（Expert Collapse/Stagnation）
症状：训练中部分专家参数几乎不更新，形成"僵尸专家"；少数专家过度激活，退化为通才。
解决方案组合：
- 辅助损失 + 容量因子约束（被动防护）
- 噪声注入（Shazeer 2017 Noisy Top-K）促进探索
- 偏置项动态调节（DeepSeek-V3，主动引导）
- Router Z-Loss（ST-MoE，稳定 logits 分布）
6.2 训练稳定性技术
| 技术 | 适用场景 | 效果 |
|---|---|---|
| DSSN 深度缩放三明治归一化 | 超大 MoE（华为盘古 Ultra） | 降低梯度突刺率 |
| TinyInit 小参数初始化 | 专家参数初始化 | 减少初期梯度震荡 |
| Dropless 无丢弃策略 | 训练数据充分场景 | 避免 Token 信息损失 |
| 混合精度训练（BF16/FP8） | 大规模 MoE 训练 | 显存↓50%，速度↑120% |
| 梯度裁剪（max_norm=1.0） | 所有 MoE 训练 | 防止梯度爆炸 |
6.3 RL 后训练中的路由重放（2026 新进展）
MoE 在 RLHF 训练中面临特有挑战：
- 训练-推理不匹配：微小数值差异可能改变 Top-K 路由决策，导致行为骤变
- 策略滞后：策略更新改变路由分布，加剧 off-policy 问题
解决方案：路由重放（Routing Replay）
- R2（普通路由重放）：强制复用收集经验时选择的路由决策，缓解策略滞后
- R3（Rollout 路由重放）：强制复用推理引擎的路由决策，解决训练-推理不匹配
七、MoE 推理系统优化
7.1 推理核心挑战分析
挑战 1：显存压力
即使绝大多数专家未被激活，其参数仍必须常驻显存（或引入卸载延迟）：
- DeepSeek-V3（BF16 全量）：约需 1.3 TB 显存
- FP8 量化后：约需 670 GB 显存
- Mixtral-8x7B（BF16）：~94 GB 显存，有 72% 参数在推理时未激活
挑战 2：All-to-All 通信开销
专家并行（EP）中，每次前向传播需两次 All-to-All（Dispatch + Collect）：
通信量 = batch_size × seq_len × top_k × d_model × 2 × 数据类型字节数
在解码阶段（batch 小、seq 短），通信延迟比计算延迟更突出，可占 30%~70% 推理时间。
挑战 3：批处理效率与专家利用率
| Batch Size | 主要瓶颈 | 推理形态 |
|---|---|---|
| 1~4（在线推理） | 显存带宽（Memory-Bound） | 时延敏感 |
| 16~64（离线推理） | 计算（Compute-Bound） | 吞吐优先 |
| >128 | 通信 + 负载不均 | 高吞吐 |
7.2 专家并行（Expert Parallelism, EP）系统设计
并行策略组合：
推荐组合：小规模（2~8 GPU）： TP=8，关闭 EP 或 EP=TP中规模（8~32 GPU）： EP=8, TP=4（EP 覆盖 MoE 层，TP 覆盖注意力层）超大规模（>32 GPU）： EP=32~256（Wide-EP），PP=2~4
All-to-All vs. All-Gather+Scatter 对比：
| 策略 | 适用场景 | 通信量 | 特点 |
|---|---|---|---|
| All-to-All | 大 EP、专用互联（NVLink/IB） | O(N) | 低延迟，直接点对点 |
| All-Gather + 本地 Scatter | 混合 EP+TP、小规模部署 | O(N²/EP) | 实现简单，延迟稍高 |
TensorRT-LLM Wide-EP 性能数据（GB200 NVL72 系统）：
- EP32 vs EP8：在 100 token/s/用户条件下，吞吐提升 1.8×
- NVL72 提供 130 TB/s 聚合 NVLink 带宽，有效抵消 Wide-EP 通信开销
7.3 专家卸载技术
三层内存层次结构：
GPU HBM（最快，最贵）↕ PCIe（约 64 GB/s）
CPU DRAM（次快）↕ NVMe 控制器（约 7 GB/s）
NVMe SSD（最慢但最便宜）
Mixtral Offloading 项目核心技术：
- HQQ 混合量化：注意力层与专家层分别量化
- LRU 缓存：活跃专家保留在 GPU，近期使用专家缓存于 CPU，冷专家卸载 NVMe
- 推测性预取：根据路由历史预测下一层需要的专家，异步预加载，覆盖 I/O 延迟
- 计算-传输重叠：计算当前 Token 时，异步传输下一 Token 所需专家
实际效果：Mixtral-8x7B 可在 10 GB 显存 + 共享 CPU RAM 上运行，实现交互级推理速度。
专家激活的可预测性规律（用于预取）：
- 层级相关性：相邻层之间激活的专家集合存在统计相关性
- 语义聚集性：语义相似的 Token 倾向于激活相同专家
- 历史局部性：同一对话/文档中，专家激活模式重复率高
Speculative MoE（s-MoE，arXiv 2503.04398）利用以上规律通过专家语义聚类（s-EG）将本地激活率提升至 70% 以上，减少 32%~75% 的跨 GPU 通信量，在 DeepSpeed-MoE 上实现 DeepSeek-V2 吞吐 1.58×~2.34× 提升。
7.4 量化技术对 MoE 的影响
MoE 量化特殊挑战：
- 激活异常值：MoE 门控机制产生比稠密模型更极端的激活分布
- 专家权重多样性：不同专家权重分布差异大，统一量化策略精度损失不均
FP8 量化（主流高性能方案）：
DeepSeek-V3 首次在超大规模 MoE 上验证了 FP8 混合精度训练与推理的可行性：
精度分配策略：专家权重（Gate/Up/Down 投影）： FP8 存储 + FP8 计算（GEMM）注意力层（QKV 投影）： BF16KV Cache： FP8 压缩存储激活值（通信前后）： BF16（保留精度用于累加）
性能收益（H100 GPU）：
- BF16 → FP8：显存节省约 50%，计算吞吐提升约 1.5~2×
- DeepGEMM（针对 MoE 稀疏矩阵乘法）比标准 cuBLAS 快约 20%~40%
INT4 量化方案对比：
| 方案 | 适用场景 | 精度损失 | 速度提升 |
|---|---|---|---|
| GPTQ INT4 | 消费级 GPU（RTX 3090/4090） | 中等（~1-2% 下降） | 2~4× vs BF16 |
| AWQ INT4 | 边缘部署 | 较低（激活感知量化） | 2~3.5× |
| HQQ INT4 | 专家卸载场景（Mixtral） | 低（半二次量化） | 显存降低 75% |
八、主流框架 MoE 支持现状
8.1 SGLang —— 最全面的 MoE 专家并行支持
SGLang 目前（2026-04-14）提供业内最完整的 MoE 推理支持：
核心 EP 特性矩阵：
| 功能 | 实现 |
|---|---|
| All-to-All 后端 | DeepEP、Mooncake、NIXL、Flashinfer、MORI（AMD）、昇腾 FuseEP |
| MoE 计算后端 | DeepGEMM、CUTLASS、Triton、TRT-LLM（Blackwell FP4） |
| 负载均衡 | DeepSeek EPLB（静态/动态两种模式） |
| 计算通信重叠 | TBO（双批次重叠，最高 2× 吞吐）、SBO（单批次重叠） |
| PD 分离 | 支持，Prefill/Decode Server 独立部署 |
| 硬件支持 | NVIDIA（H100/A100/Blackwell）、AMD ROCm、华为昇腾 |
DeepSeek-V3 部署命令：
python -m sglang.launch_server \--model-path deepseek-ai/DeepSeek-V3 \--moe-a2a-backend deepep \--moe-runner-backend deep_gemm \--tp 8 --ep 8 \--enable-two-batch-overlap \--enable-eplb \--deepep-mode auto
96 H100 性能数据（LMSYS Blog，2025-05-05）：
- 输入吞吐量：52,300 tokens/s/节点（2000 token 输入）
- 输出吞吐量：22,300 tokens/s/节点
- 相比纯 TP16 基线，输出吞吐提升 5×
- 本地部署成本约 $0.20/百万 token（DeepSeek 官方 API 的 1/5）
8.2 TensorRT-LLM Wide-EP
NVIDIA TRT-LLM Wide-EP（2025-10-20）针对大规模 EP 的主要优化：
| 挑战 | 解决方案 |
|---|---|
| 权重加载瓶颈 | 优化 GroupGEMM 内核，提升计算密度 |
| All-to-All 通信 | 定制 NCCL 内核，支持动态大小非对称通信 |
| 负载不均衡 | 在线 EPLB，实时调整专家分布 |
| CUDA Graph 兼容 | 特殊处理动态路由导致的图中变长操作 |
8.3 vLLM EP 模式
# vLLM 启用专家并行
python -m vllm.entrypoints.openai.api_server \--model deepseek-ai/DeepSeek-V3 \--tensor-parallel-size 8 \--enable-expert-parallel \--quantization fp8
优化建议：
- 专家并行（EP）适合显存充足但算力有余的场景
- 推荐 EP=TP（如 EP=8, TP=8）以简化通信拓扑
- 大批量离线推理优先使用 DP，在线低延迟推理优先使用 EP+TP
vLLM + Mixtral-8x7B（双 A100 80GB）优化案例：
- 基线（BF16）：约 57 tokens/s
- 启用 FP8 + EP 后：约 120 tokens/s（2.1× 提升）
九、代码实战
9.1 简洁 MoE 层 PyTorch 实现
import torch
import torch.nn as nn
import torch.nn.functional as Fclass MoELayer(nn.Module):"""标准 Sparse MoE 层实现支持 Top-K 路由 + 共享专家 + 辅助负载均衡损失"""def __init__(self,d_model: int = 768,d_ffn: int = 3072,num_experts: int = 8,top_k: int = 2,num_shared_experts: int = 1,aux_loss_alpha: float = 1e-2,):super().__init__()self.num_experts = num_expertsself.top_k = top_kself.aux_loss_alpha = aux_loss_alpha# 路由专家self.experts = nn.ModuleList([nn.Sequential(nn.Linear(d_model, d_ffn, bias=False),nn.GELU(),nn.Linear(d_ffn, d_model, bias=False),)for _ in range(num_experts)])# 共享专家（始终激活）self.shared_experts = nn.ModuleList([nn.Sequential(nn.Linear(d_model, d_ffn // num_shared_experts, bias=False),nn.GELU(),nn.Linear(d_ffn // num_shared_experts, d_model, bias=False),)for _ in range(num_shared_experts)]) if num_shared_experts > 0 else None# 门控路由器self.gate = nn.Linear(d_model, num_experts, bias=False)def forward(self, x: torch.Tensor):"""x: [batch_size, seq_len, d_model]"""B, L, D = x.shapex_flat = x.view(-1, D) # [B*L, D]# --- 1. 路由计算 ---logits = self.gate(x_flat) # [B*L, num_experts]scores = F.softmax(logits, dim=-1)# Top-K 选择top_k_scores, top_k_indices = scores.topk(self.top_k, dim=-1)# 重归一化top_k_scores = top_k_scores / top_k_scores.sum(dim=-1, keepdim=True)# --- 2. 路由专家计算（稀疏激活）---output = torch.zeros_like(x_flat)for i in range(self.num_experts):# 找出路由到专家 i 的 tokenmask = (top_k_indices == i) # [B*L, top_k]token_mask = mask.any(dim=-1) # [B*L]if token_mask.sum() == 0:continueselected_tokens = x_flat[token_mask] # [n_tokens, D]expert_out = self.experts[i](selected_tokens)# 获取路由权重weights = torch.zeros(token_mask.sum(), device=x.device)for k in range(self.top_k):k_mask = mask[:, k][token_mask]weights[k_mask] += top_k_scores[token_mask][:, k][k_mask]output[token_mask] += expert_out * weights.unsqueeze(-1)# --- 3. 共享专家计算（始终激活）---if self.shared_experts is not None:shared_out = sum(expert(x_flat) for expert in self.shared_experts)output = output + shared_out# --- 4. 辅助负载均衡损失 ---# f_i: 实际路由到专家 i 的 token 比例（不可微）# P_i: 路由器给专家 i 的平均概率（可微，梯度代理）f_i = torch.zeros(self.num_experts, device=x.device)for i in range(self.num_experts):f_i[i] = (top_k_indices == i).float().mean()P_i = scores.mean(dim=0) # [num_experts]aux_loss = self.aux_loss_alpha * self.num_experts * (f_i * P_i).sum()return output.view(B, L, D), aux_loss# 使用示例
moe_layer = MoELayer(d_model=4096,d_ffn=14336,num_experts=8,top_k=2,num_shared_experts=1,aux_loss_alpha=1e-2,
)x = torch.randn(2, 512, 4096)
output, aux_loss = moe_layer(x)# 总损失 = 主任务损失 + 辅助均衡损失
total_loss = task_loss + aux_loss
9.2 DeepSeek-V3 风格无辅助损失路由
class AuxFreeRouter(nn.Module):"""DeepSeek-V3 风格：无辅助损失的偏置项路由用动态偏置项 b_i 替代辅助损失实现负载均衡"""def __init__(self, d_model: int, num_experts: int, top_k: int, gamma: float = 0.001):super().__init__()self.num_experts = num_expertsself.top_k = top_kself.gamma = gammaself.gate = nn.Linear(d_model, num_experts, bias=False)# 可学习偏置项（仅用于路由决策，不参与加权计算）self.bias = nn.Parameter(torch.zeros(num_experts))# 监控负载（用于更新偏置）self.register_buffer('expert_load', torch.zeros(num_experts))def forward(self, x: torch.Tensor):"""x: [n_tokens, d_model]"""# 使用 Sigmoid 门控（DeepSeek-V3 创新）scores = torch.sigmoid(x @ self.gate.weight.T) # [n_tokens, num_experts]# 路由决策时加入偏置项（偏置只影响选择，不影响权重）routing_scores = scores + self.bias_, top_k_indices = routing_scores.topk(self.top_k, dim=-1)# 加权使用原始 scores（不含偏置）top_k_scores = scores.gather(-1, top_k_indices)# 训练时动态更新偏置（非梯度操作）if self.training:with torch.no_grad():load = torch.zeros(self.num_experts, device=x.device)for i in range(self.num_experts):load[i] = (top_k_indices == i).float().mean()# 过载专家降低偏置，欠载专家提高偏置overload = load > (self.top_k / self.num_experts)underload = load < (self.top_k / self.num_experts)self.bias.data[overload] -= self.gammaself.bias.data[underload] += self.gammareturn top_k_scores, top_k_indices
十、MoE 技术发展趋势（2025-2026）
-
细粒度专家 + 共享专家成为主流范式（DeepSeek-V3、华为盘古 Ultra 均已采用）
-
门控函数从 Softmax 向 Sigmoid 演进：在超大专家数量（256+）下，Sigmoid 计算更高效，不需要全局 Softmax 归一化
-
无辅助损失负载均衡（偏置项方案）成为新趋势，消除辅助损失对主任务训练的干扰
-
MoE 与 MLA（多头潜在注意力）协同：MLA 将 KV Cache 压缩至潜在向量，解决 MoE 超长上下文的显存瓶颈（KV Cache 显存减少 93%）
-
Wide-EP 超大专家并行：EP=32~256 在高带宽互联（NVLink 130 TB/s）下成为可行选项，可将吞吐提升 1.8×
-
MoE + Speculative Decoding 协同：多 Token 预测（MTP）与专家并行叠加，进一步提升解码吞吐
-
Routing-Free MoE（2026.4）：消除中心化硬编码路由，用自适应机制替代，克服传统路由的"刚性归纳偏置"，代表下一代范式探索
参考资料
- Outrageously Large Neural Networks: The Sparsely-Gated MoE Layer - Shazeer et al. 2017
- Switch Transformers: Scaling to Trillion Parameter Models - Fedus et al. 2021
- Mixture-of-Experts with Expert Choice Routing - Zhou et al. 2022
- ST-MoE: Designing Stable and Transferable Sparse Expert Models - 2022
- Mixtral of Experts - Mistral AI 2024
- DeepSeekMoE: Towards Ultimate Expert Specialization - 2024
- DeepSeek-V3 Technical Report - 2024
- Routing-Free Mixture-of-Experts - 2026
- Fast Inference of MoE Language Models with Offloading - 2023
- Speculative MoE: Communication Efficient Parallel MoE Inference - 2025
- Efficient MoE Inference with Fine-Grained Scheduling (FinDEP) - 2025
- Scaling Large MoE Models with Wide EP on NVL72 - NVIDIA Blog 2025-10-20
- Deploying DeepSeek with Large-Scale EP on 96 H100s - LMSYS Blog 2025-05-05
- Expert Parallelism - SGLang Official Documentation
- MoE Post-Training Guide: Load Balancing, Routing Replay - LangCopilot 2026-03-25
- 万字解析DeepSeek MOE架构——从Switch Transformers到DeepSeek V1/V2/V3 - ExplorerMan 博客园
- MoE-Inference-Bench: Performance Evaluation - arXiv 2508.17467
- FireQ: Fast INT4-FP8 Kernel for MoE - arXiv 2505.20839