【Transformer 与注意力机制】44｜MoE：稀疏激活的万亿模型路径

Dense Transformer 有一条铁律：参数越多，每个 token 前向要做的乘加也越多。MoE（Mixture of Experts，混合专家）想打破这条铁律——但打破的方式不是免费的，它把”扩容量”这件事从模型结构问题变成了路由问题：谁决定一个 token 该去哪个专家，决定错了会怎样，决定的过程本身要花多少通信。

这篇不重复”MoE 是什么”的科普讲法。本文准备讲清楚三件训练过 MoE 才会撞到的事：容量因子和辅助损失背后对应的是过载丢 token、专家塌缩、路由抖动三种具体症状；专家并行的 All-to-All 通信为什么是理论 FLOPs 优势的头号对手；以及”MoE 是免费容量”这句话在哪些前提下成立、在哪些前提下不成立。

本篇能让你学会三件事：

1. 参数量和每 token FLOPs 为什么能解耦，以及为什么 MoE 常换 FFN 不换 attention；
2. capacity factor 和 aux loss 对应的三种训练期症状，各自的成因和边界；
3. MoE 是不是”免费容量”这场争论，以及推理时专家利用率变差是怎么发生的。

一、参数量与每 token FLOPs 的解耦

Dense Transformer 里，一个 token 前向要走过全部参数，每 token 前向 FLOPs 近似 \(2N\)（\(N\) 为非嵌入参数量，推导见本系列 34｜Scaling Laws）。总参数量涨一倍，每 token 计算量也跟着涨一倍——容量和成本被死死绑在一起。

MoE 把 FFN 换成 \(E\) 个并列的专家，每个 token 只路由到其中 \(k\) 个（\(k \ll E\)）。总参数量和激活参数量因此分开计算：

\[ N_{\text{total}} = N_{\text{attn+embed}} + E \times N_{\text{expert}} \]

\[ N_{\text{act}} \approx N_{\text{attn+embed}} + k \times N_{\text{expert}} \]

每 token FLOPs 近似 \(2N_{\text{act}}\)，和 \(E\) 无关。这就是解耦的全部含义：想要更大的模型容量，加专家数 \(E\)；想要控制每 token 的计算成本，只调 \(k\)。两个旋钮互相独立，这在 dense 模型里是做不到的。

但”无关”只在 FLOPs 这一个维度上成立。\(E\) 变大时，总参数量、显存占用、路由决策的组合空间都在涨——这些代价不会消失，只是从”每 token 计算量”这一项移到了别的项上。后面几节要讲的容量因子、通信、推理利用率，都是这次移动去了哪里的答案。

二、为什么常换 FFN，不换 attention

MoE 论文几乎全部只把 FFN 换成专家，attention 保持 dense。原因不是”没人想过”，是 FFN 和 attention 在计算结构上有一个关键差异：FFN 对每个 token 独立、逐位置地计算，\(y_i = W_2 \, \sigma(W_1 x_i)\)，token \(i\) 的输出只依赖 \(x_i\) 自己。这意味着”把 token 送到哪个专家”是一个纯粹的路由问题：只要把 \(x_i\) 这个向量搬到某台设备上算完再搬回来，结果就是正确的。

attention 不是这样。token \(i\) 的输出依赖序列里其他 token（在因果 mask 允许的范围内）的 key/value。如果让 attention 本身按 token 路由专家，一个 token 选中的”专家”要处理的不只是这个 token 自己的向量，还牵涉到它能看到哪些其他 token 的 K/V——路由决策和 token 间的连接图绑在一起，All-to-All 不再是”搬一个向量过去再搬回来”这么简单，而要处理”这个专家该看到整个序列里的哪一部分”。

这不是假设性的困难。Zhang et al.（Mixture of Attention Heads，EMNLP 2022）确实做过一版”attention 里的 MoE”：路由器为每个 token 挑选一部分注意力头（而不是挑选 K/V 的计算本身），K/V 的计算仍然是共享、dense 的，只有”用哪些头的参数”是条件计算。即便是这种保守得多的设计，也没有成为主流——这从另一个角度印证了，只要触碰 token 间的连接关系，MoE 的”独立路由”优势就会打折扣。

另一个现实原因是参数分布。标准 Transformer 里 FFN 的隐藏维度通常是 \(d_{\text{model}}\) 的 4 倍（原始论文 \(d_{\text{model}}=512\)、\(d_{\text{ff}}=2048\)），FFN 参数量本身就比 attention 的 QKVO 投影更大，也承担了更大比例的 FLOPs（细节见本系列 26｜前馈网络）。换掉参数量更大、计算结构更独立的那一半，收益自然更直接。

三、router 与 top-k：从 noisy gating 到 Switch 的 top-1

router 是一个线性层，把 token 的隐藏状态映射到 \(E\) 个专家上的分数：

\[ g(x) = \mathrm{softmax}(W_g x) \in \mathbb{R}^E \]

top-k routing 选出分数最高的 \(k\) 个专家，只在这 \(k\) 个之间重新归一化权重，其余专家分数视为零，不参与这个 token 的计算。

Shazeer et al.（ICLR 2017）在提出这个结构时已经发现，纯粹的 top-k 会让路由器很快收敛到”总选那几个专家”——因为随机初始化下某个专家哪怕只是稍微领先，它就会拿到更多梯度更新，变得更擅长处理被送来的 token，于是被路由器更频繁选中，形成正反馈。他们的对策是 noisy top-k gating：在门控 logits 上加一个可学习幅度的高斯噪声再取 top-k，

\[ H(x)_i = (xW_g)_i + \epsilon \cdot \mathrm{softplus}((xW_{\text{noise}})_i), \quad \epsilon \sim \mathcal{N}(0,1) \]

噪声在训练早期给路由器足够的探索空间，避免过早锁死在少数专家上。

Switch Transformer（Fedus et al., JMLR 2022）把 \(k\) 从 2 降到 1：每个 token 只进一个专家。这不只是简化，也是一次真实的取舍——top-1 下通信量直接减半，路由决策的组合空间也从”选 2 个”降成”选 1 个”，训练更稳定；代价是单点故障：如果路由器为某个 token 选错了专家，没有第二个专家的输出可以拉一把。Switch 论文的实验结论是，在他们测试的规模下 top-1 能达到接近甚至超过 top-2 的质量,同时省下一半通信——这也是”MoE 可以粗暴工程化”这条路线的起点。GShard（Lepikhin et al., ICLR 2021）走的是另一条路：top-2 路由，并且给第二名专家加入按权重比例的随机路由,增加探索性。\(k\) 的选择因此是质量、稳定性和通信成本三者的权衡，不存在唯一正确答案。

四、capacity factor 与 aux loss：三个生产症状

路由器学到”该把 token 送到哪”之后,还有一个工程约束:每个专家能同时处理的 token 数是有限的（GPU 显存和 batch 内固定的 tensor 形状决定了这一点）。这个约束和路由器的学习目标合在一起,会在训练现场表现为三种具体症状。

4.1 过载丢 token

每个专家设一个容量上限：

\[ \text{capacity} = \text{capacity\_factor} \times \frac{\text{tokens\_per\_batch} \times k}{E} \]

capacity_factor 通常取 1.0 到 1.25。如果某个 batch 里恰好有一批 token（比如同一段代码、同一种语言、同一个话题）都被路由到同一个专家，超出容量的 token 会被丢弃——不是丢弃整个样本，而是这个 token 跳过 FFN，只走残差连接,相当于这一层对它什么也没做。GShard 和 Switch 都是这样处理溢出的。

这个症状的麻烦之处在于它不是均匀的性能损失。丢 token 只发生在负载恰好集中的那批数据上,所以模型质量的下降会集中在特定的 batch、特定的领域或特定的输入分布上,而不是整体小幅下降。这也是为什么 drop 率必须作为训练期的常规监控指标,而不能只看平均 loss。

4.2 专家塌缩

前一节提到的”赢者通吃”如果没被压住,会发展成专家塌缩：少数专家持续吸收几乎所有流量,其余专家长期收不到 token、梯度接近零、参数基本不再更新。这不是理论风险,是 Shazeer et al.（2017）在最早的 MoE 论文里就要专门用噪声和显式的负载均衡损失去对付的问题——如果这个问题不存在,后续 GShard、Switch 也不需要在辅助损失上做文章。

GShard 和 Switch 采用的辅助损失形式基本一致：

\[ L_{\text{aux}} = \alpha \cdot E \sum_{i=1}^{E} f_i P_i \]

其中 \(f_i\) 是实际路由到专家 \(i\) 的 token 比例，\(P_i\) 是路由器给专家 \(i\) 的平均概率质量。这一项在 \(f_i\) 和 \(P_i\) 都均匀时取得最小值，用来把负载往均匀方向拉。系数 \(\alpha\) 通常在 0.01 到 0.1 之间——这个系数本身就是一个尚未有定量答案的权衡，第十一节会展开。

4.3 路由抖动

即使平均负载均衡,单个 token 的路由决策也可能在训练过程中反复跳变：两个专家的门控分数很接近时，一点点噪声、精度误差或参数更新就能让选择的专家从这一步到下一步发生变化。这会导致相近的输入在连续几步里被送进完全不同的专家，梯度方向随之剧烈波动。

Zhou et al.（Mixture-of-Experts with Expert Choice Routing，NeurIPS 2022）把这个问题归因为 token-choice 路由本身的结构：每个 token 独立选专家，任何两个专家之间的微小分数差都可能翻转选择，天然容易抖动和负载不均——他们的方案是反过来让专家去挑 token（每个专家从全 batch 里挑分数最高的若干 token），负载均衡因此从”训练目标”变成”结构保证”，不再需要辅助损失，据其报告在同等计算预算下把训练收敛速度提升了两倍以上。这是一个真实存在、且已经有替代方案的问题,不是臆测。

另一个放大抖动的因素是数值精度。Zoph et al.（ST-MoE，2022，arXiv 未经 peer review）发现门控 logits 在 bf16 等低精度下容易数值膨胀，进而让 top-k 的选择变得不稳定，为此引入 router z-loss（惩罚 \(\log \sum_i e^{x_i}\) 的平方）把 logits 压在一个较小的范围内。这篇论文同时报告了一个和第十一节直接相关的现象：负载均衡相关的超参数取得不好时,预训练 loss 看起来正常,但下游微调收益几乎消失——说明训练期”看起来稳”和”真的没有隐藏代价”是两件事。

五、通信：All-to-All 为什么是成本中心

前四节的路由决策发生在数学层面，但专家并行（Expert Parallel，EP）训练时,专家分布在不同设备上,路由决策必须变成真实的数据搬运：一个 token 的隐藏向量要从它所在的设备,发送到它被路由到的专家所在的设备,算完之后再发回来。这是两次 All-to-All 通信——dispatch 把 token 送过去,combine 把结果收回来。

flowchart LR
    T["Token hidden state"] --> R["Router: top-k gate"]
    R --> D["Dispatch (All-to-All)"]
    D --> E1["Expert on device A"]
    D --> E2["Expert on device B"]
    E1 --> C["Combine (All-to-All)"]
    E2 --> C
    C --> O["Weighted sum → output"]

这次通信和张量并行、流水线并行里的通信有一个本质区别：TP、PP 的通信目标是固定的,哪张卡发给哪张卡在计算图确定时就已经确定,可以静态调度、和计算重叠；MoE 的 dispatch 目标是路由器在运行时算出来的,同一层里不同 batch 的通信模式完全不同。这种数据依赖性让调度和重叠都更难做。

通信量近似和 \(\text{tokens} \times k \times d_{\text{model}}\) 成正比——\(k\) 越大（细粒度专家路线普遍走高 \(k\)）,通信量越大。第一节讲的”每 token FLOPs 和 \(E\) 解耦”是理论账,这里的通信成本是要用真金白银的网络带宽去还的账。如果集群互联跟不上,理论 FLOPs 优势会被 All-to-All 的等待时间吃掉大半——这正是”MoE 是不是免费容量”这场争论里,通信这一侧的论据（第七节展开）。

All-to-All 具体怎么在 NVLink/IB 拓扑上跑、DeepEP 之类的定制通信库如何做 FP8 传输和内核级重叠、EP 并行度怎么和 TP/PP/DP 组合,这些实现细节不在本文展开,详见 llm-infra｜08 MoE 训练工程。本文只钉住一件事：All-to-All 不是”MoE 训练的一个实现细节”,而是决定 MoE 稀疏激活的理论优势能不能兑现的成本中心。

六、Mixtral 与 DeepSeek-V3：两条边界句

公开权重的 Mixtral（Jiang et al., arXiv:2401.04088, 2024, 未经 peer review）站在”少而粗”这一端：8 个专家、top-2 路由,没有共享专家,总参数约 46.7B、激活约 12.9B,证明了这类粗粒度 MoE 可以做到接近 GPT-3.5 级别的质量并开放权重。

DeepSeek-V3（DeepSeek-AI, 2024, arXiv 技术报告, 未经 peer review）站在”多而细”这一端：256 个路由专家加 1 个共享专家、top-8,总参数 671B、激活 37B,并且把负载均衡从辅助损失换成了不进入梯度的 bias 调整——这个设计选择和第四节的辅助损失干扰主任务梯度的问题直接相关。

这两条路线各自需要的并行策略、通信库和训练调参完全是另一套工程问题,不在本文展开,见 llm-infra｜08。这里只需要记住：它们是同一个设计空间（专家粒度、\(k\)、负载均衡机制）上的两个边界点,不是”谁更先进”的关系。

七、争论：MoE 是不是”免费容量”

GShard 和 Switch 的核心论据是：在相同 FLOPs 预算下,MoE 能达到更大 dense 模型才有的质量,这几乎是”免费”拿到了额外容量。这个论据在预训练 loss 这一个指标上有扎实证据支撑。

但 Artetxe et al.（Efficient Large Scale Language Modeling with Mixture-of-Experts, EMNLP 2022）做了一次更系统的对照,结论给这句话加上了限定：除了微调之外,MoE 在计算效率上确实明显优于 dense——较小训练预算下,MoE 能用大约四分之一的算力匹配 dense 模型的效果,他们的 1.1T 参数 MoE 也持续优于算力等价的 6.7B dense 模型。但论文明确指出,这个优势在不同任务和领域上的表现差异很大,MoE 和 dense 模型的泛化方式并不相同——微调阶段的表现是这句”免费”论据里最不稳固的部分。

把第五节的通信成本也算进来,“免费容量”这个说法需要拆成两半看：在”每 FLOP 能装多少参数”这个维度上,证据是充分的；但”每 FLOP 免费”不等于”每张卡的每一步训练时间免费”（通信可能吃掉理论收益）,也不等于”在所有下游任务和微调场景下都免费”（Artetxe 等人的发现）。没有哪一派认为对方是错的,这是一个还没有跨规模统一答案的权衡,选型要看具体任务和硬件预算,而不是抽象地问”MoE 好不好”。

八、推理时的另一半代价：batch 小、专家利用率差

前几节的成本主要发生在训练。推理还有一个训练时不明显的问题：专家的矩阵乘法效率取决于分到这个专家的 token 数够不够多。一个 batch 里的 token 经过路由后,平均每个专家收到大约 \(\dfrac{\text{tokens} \times k}{E}\) 个 token；如果整体 batch 很小（交互式服务、低并发、自回归 decode 阶段每步只产出 1 个新 token）,这个数字可能远小于让 GPU/TPU 矩阵单元跑满所需的行数,矩阵乘法从算力受限变成内存带宽或调度开销受限,专家计算的硬件利用率随之下降。

Rajbhandari et al.（DeepSpeed-MoE, ICML 2022）指出这类模型的推理挑战本质是带宽问题：同等质量的 MoE 模型比 dense 模型大出数倍,要在相同延迟下服务,需要数倍的聚合内存带宽和并行度,而不是数倍算力——这和训练阶段”少算多存”的收益结构正好相反。Gale et al.（MegaBlocks, MLSys 2023）从另一个角度指出了同一个问题的工程后果：现有框架把 MoE 计算表达成批量矩阵乘法时,面对负载不均的路由结果,只能在”丢 token”和”用 padding 把每个专家补齐到同一行数”之间选一个——padding 补齐正是小 batch、负载不均场景下利用率下降的直接体现，专家实际收到的有效 token 越少，浪费在填充上的算力比例越高。

这解释了为什么 MoE 的训练收益和推理收益不对称：训练时全局 batch 通常足够大,分摊到每个专家的 token 数比较充分；推理时,尤其是低并发或单请求 decode,每步送到每个专家的 token 数可能小到让专家计算本身变得低效,这时”每 token 少算”的理论优势不一定能换成实际的低延迟或高吞吐。

九、关键概念回顾

• 激活参数（activated params）：一次前向实际参与计算的参数量，\(N_{\text{act}} \approx N_{\text{attn+embed}} + k N_{\text{expert}}\)，和总参数量 \(N_{\text{total}}\) 分开计算。
• router / gate：把 token 隐藏状态映射到各专家分数的小网络。
• top-k routing：只保留分数最高的 \(k\) 个专家参与计算；Switch 取 \(k=1\)，GShard/Mixtral 取 \(k=2\)。
• capacity factor：限制单个专家单个 batch 最多接收的 token 数，超出的 token 被丢弃只走残差。
• aux loss（负载均衡辅助损失）：\(\alpha E \sum_i f_i P_i\)，惩罚负载不均，但会和主任务梯度产生张力。
• 专家塌缩：少数专家持续吸收几乎全部流量，其余专家梯度接近零。
• 路由抖动：相近输入在训练步之间被路由到不同专家，导致梯度方差增大。
• Expert Parallel（EP）与 All-to-All：专家分布到不同设备后，dispatch/combine 两次 All-to-All 是通信成本的主要来源。

十、常见误解

10.1 “MoE 推理免费，因为每 token 激活参数少”

不对。第八节说明了专家计算效率依赖每专家的 token 数，小 batch 下 GEMM 利用率下降；加上 All-to-All 通信、显存墙，推理成本结构和训练完全不同，“少算”不直接等于”更快更省”。

10.2 “MoE 就是无代价的免费容量”

第七节的争论说明这句话只在预训练 loss / FLOPs 这一个维度上有证据支撑；微调泛化差异（Artetxe et al., 2022）和通信成本（第五节）都是要还的代价，不是隐藏 bug，是设计取舍。

10.3 “专家会自动学成人类能理解的领域专家”

不一定。专家分化取决于训练数据分布、路由损失系数、容量设置和优化过程；专家塌缩（4.2 节）恰恰是这个”自动分化”过程失败的一种表现，不能假设它总会朝着可解释的方向收敛。

十一、开放问题：负载均衡与质量的权衡如何定量

三条负载均衡路线目前分别有各自的局部证据，但没有一个跨规模、跨架构的统一比较：

1. 辅助损失系数的代价还没有定量刻度。第四节的 \(L_{\text{aux}}\) 加在主 loss 上，系数太小压不住专家塌缩，系数太大会干扰主任务梯度——ST-MoE（Zoph et al., 2022）报告了坏的负载均衡超参数会让预训练 loss 正常但微调收益几乎消失，但论文给出的是具体配置下的观察，不是可以直接套用到任意规模和数据分布的公式。
2. aux-loss-free 的 bias 调整（DeepSeek-V3）避免了梯度干扰，但代价是什么还不清楚。bias 只影响路由选择不进入梯度，理论上解耦了负载均衡和任务学习，DeepSeek-V3 技术报告称在他们的规模上负载分布均衡；但这个方法和传统 aux loss 之间是否存在其他维度的权衡（比如收敛速度、对分布漂移的响应速度），目前没有公开的受控对照实验回答。
3. Expert Choice 用结构保证替代了训练目标，但改变了语义（每个 token 可能被 0 个或多个专家处理，而不是固定 \(k\) 个），这和 token-choice 路线在下游任务上是否等价，需要在相同预训练预算下做跨路线对比，公开文献里这类对比仍然有限。

三条路线各自在自己的论文里都表现良好，说明负载均衡问题”有解”；但把”负载不均程度”和”下游质量损失”之间建立一个可以跨论文引用的定量关系，仍然是开放问题——目前只能在同一个训练配置内部做消融，不能跨规模、跨路由机制直接比较数字。

十二、下一步

MoE 说明 Transformer 的容量和计算成本可以部分解耦，但解耦不是没有代价：代价从”结构固定”转移到了”路由是否稳定、通信能不能扛住、推理批量够不够大”。下一篇转向视觉：ViT 如何把图像切成 patch，让图片也变成 token 序列。

十三、参考文献

核心论文

1. Shazeer, N. et al. “Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer.” ICLR 2017. 定义 top-k 门控、noisy gating 与负载均衡损失的奠基工作。
2. Lepikhin, D. et al. “GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding.” ICLR 2021. MoE 落到 Transformer FFN 层，引入 capacity factor 与 Expert Parallel。
3. Fedus, W. et al. “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity.” JMLR 2022. top-1 路由简化，1.6T 参数规模验证。
4. Zoph, B. et al. “ST-MoE: Designing Stable and Transferable Sparse Expert Models.” arXiv:2202.08906, 2022. 未经 peer review；router z-loss 与负载均衡超参数敏感性的经验证据。
5. Zhou, Y. et al. “Mixture-of-Experts with Expert Choice Routing.” NeurIPS 2022. 用专家选 token 替代 token 选专家，结构性解决负载不均。
6. Artetxe, M. et al. “Efficient Large Scale Language Modeling with Mixture-of-Experts.” EMNLP 2022. 系统对照 MoE 与 dense 在预训练、微调、跨任务上的效率差异，“免费容量”争论的关键证据来源。
7. Gale, T. et al. “MegaBlocks: Efficient Sparse Training with Mixture-of-Experts.” MLSys 2023. 块稀疏矩阵乘法，指出丢 token 与 padding 之间的效率取舍。
8. Rajbhandari, S. et al. “DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale.” ICML 2022. MoE 推理的带宽瓶颈与小 batch 利用率问题。
9. Jiang, A. Q. et al. “Mixtral of Experts.” arXiv:2401.04088, 2024. 未经 peer review；粗粒度 top-2 MoE 的开放权重代表。
10. DeepSeek-AI. “DeepSeek-V3 Technical Report.” arXiv, 2024. 未经 peer review；细粒度专家 + aux-loss-free 负载均衡的代表。
11. Zhang, X. et al. “Mixture of Attention Heads: Selecting Attention Heads Per Token.” EMNLP 2022. attention 侧条件计算的少见尝试，用于对照”为什么常换 FFN 不换 attention”。

站内关联

• 26｜前馈网络（FFN）：FFN 的参数分布与逐 token 独立计算结构。
• 34｜Scaling Laws：每 token FLOPs 与参数量的关系推导。
• llm-infra｜08 MoE 训练工程：Expert Parallel、All-to-All 实现、DeepEP/MegaBlocks 等通信栈与集群工程细节。

← 上一篇：43｜稀疏与局部注意力　|　下一篇：45｜ViT →