MoE：更聪明的扩容，还是把模型问题搬进了系统深水区？

从稀疏激活的数学直觉到分布式系统的工程现实——一个 MoE 架构的全景剖析

开篇：671B 参数，37B 激活——复杂性去哪了？

DeepSeek-V3 有 671B 总参数，每个 token 只激活 37B。Mixtral 8x7B 有 47B 参数，每个 token 激活约 13B。Qwen3-235B 有 235B 参数，每个 token 激活 22B。

一个显而易见的问题是：参数量暴涨了好几倍，但每个 token 的计算量（FLOPs）控制住了——那些"多出来的参数"带来的复杂性，到底去哪了？

答案是：复杂性没有消失，而是换了一个地方住。 它从"每个 token 都要算的 dense 矩阵乘法"搬进了"路由决策、专家调度、分布式通信"这个系统层面。MoE 的本质不是"更便宜的大模型"，而是选择了一种不同的复杂性承载方式：你不再为每个 token 做全量计算，但你得为每个 token 做一次路由决策，把它发到对的专家那里，再把结果收回来。

这就引出了整篇文章的核心问题：这种复杂性的转移划不划算？什么条件下划算？什么团队能承受这种转移后的新复杂性？

说白了，MoE 表面上是模型架构的改动——在 FFN 层放多个 expert，加一个 router。但真正落地时你会发现，它改变的是整个训练和推理的系统设计。从 all-to-all 通信到 expert parallel 策略，从路由稳定性到推理时的 expert locality，MoE 把很多原本在 dense 模型中"不存在的问题"带进了工程现实。

而"这些新问题能不能被解决"，才是决定 MoE 值不值的关键。

一、Dense 扩容到底卡在哪？

MoE 在 2024-2025 年重新成为主流不是因为它突然变好了，而是因为 dense Transformer 的扩容路线遇到了经济性瓶颈。

Scaling laws 告诉我们一件简单但残酷的事：想让模型更强，你需要更多参数和更多训练数据。Dense 模型在这件事上是"全耦合"的——参数增加多少，每个 token 的计算量就增加多少。一个 70B 的 dense 模型每个 token 的 FLOPs 大约是 7B 模型的 10 倍，没有任何折扣。

训练成本上，总 $FLOPs ≈ 6 × 参数量 × 训练 token 数（Chinchilla 近似）$。参数翻倍，训练成本直接翻倍。推理成本上更直接：dense 模型推理时激活所有参数，吞吐量和参数量几乎成反比。你想要一个 200B 的 dense 模型的知识容量，那么它在推理时的速度就是 20B 模型的大约 1/10。

这条路走到几百 B 规模时，成本曲线变得极其陡峭。以 Llama 2 70B 为例，Meta 用了约 170 万 A100 GPU hours 来训练它。如果你想训练一个 700B 的 dense 模型，简单线性外推就需要 1700 万 GPU hours——且推理吞吐量会降到无法接受的水平。

这就是 MoE 重新进入视野的背景：不是因为 MoE 比 dense"更好"，而是因为 dense 路线的成本曲线太陡，而 MoE 提供了一条"亚线性"的替代路线。 你想要 600B 参数的知识容量？可以。但每个 token 只需要付 30-40B 的 FLOPs——前提是你能搞定路由和系统调度。

二、MoE 的核心承诺：稀疏激活如何解耦参数量与计算量

MoE 的核心思路可以用一句话概括：在 Transformer 的 FFN 层，把一个大 FFN 替换为 N 个小 FFN（叫做 experts），每个 token 只通过其中 K 个（K << N）。

这意味着：总参数量约为原来的 $N/K$ 倍（只算 FFN 部分），但每个 token 的 FLOPs 基本不变。参数量和计算量被解耦了。

路由的基本数学

每个 MoE 层有一个 router（或叫 gating network），本质是一个小的线性变换加 softmax：

其中 $x$ 是 token 的 hidden state，$W_r$ 是 router 的权重矩阵（维度是 $[hidden_size, num_experts]$）。softmax 输出一个长度为 $N$ 的概率分布，表示这个 token 应该分配给哪些专家。

然后做 top-K 选择，只把 token 发给得分最高的 $K$ 个 expert，最终输出是这 $K$ 个 expert 输出的加权和：

这个公式看起来极其简洁。但如果你从系统角度看，里面每一步都有代价：softmax 需要 float32 精度才稳定（在 bfloat16 下会抖动）；TopK 选择是一个离散决策，导致梯度不连续；把 token "发给"不同 expert 在分布式场景下意味着 all-to-all 通信；不同 expert 收到的 token 数量不一样，导致负载不均。

为什么 MoE 只替换 FFN，不替换 Attention

一个常见问题是：为什么不把 attention 也做成 MoE？答案是 Transformer 中 FFN 参数占比远大于 attention（通常 2/3 vs 1/3），而 attention 需要全局上下文交互——每个 token 需要"看到"所有其他 token。把 attention 稀疏化的收益-代价比远不如 FFN。

近期确实有 attention MoE 的研究（Multi-Head MoE 等），但目前主流方案仍然是 attention 保持 dense，只对 FFN 做 MoE。

Top-1、Top-2 和 Top-K 各自意味着什么

Top-K 的 K 不只是一个超参，它直接决定了三个层面的工程代价：

• 计算量：$K$ 越大，每个 token 激活的 expert 越多，FLOPs 越高。Top-2 的 FLOPs 是 Top-1 的约两倍（在 MoE 层）。
• 通信量：每个 token 被发往 $K$ 个 expert。如果这些 expert 分布在不同 GPU 上，就需要 K 次 token 发送。K=1 时通信量最小。
• 信息瓶颈：$K=1$ 意味着每个 token 只能获取一个 expert 的处理。这对模型表达能力有约束。

Switch Transformer 选了 K=1——它用最小的计算和通信代价，换来了 7 倍的训练加速。GShard 和 Mixtral 选了 K=2——增加了一倍的 MoE 层计算量，但提供了更强的模型容量。DeepSeek-V2 选了 K=6（从 160 个 routed expert 中选 6 个），细粒度的选择提供了更灵活的组合空间，但通信代价也更大——所以 DeepSeek 不得不引入 device-limited routing 来控制通信开销。

Token-level 还是 Sequence-level

主流 MoE 用的是 token-level routing：序列中的每个 token 独立地决定去哪个 expert。这意味着同一个句子里，不同 token 可能去不同 expert。好处是灵活，坏处是引入了更大的负载均衡压力——你没法预测一个 batch 里每个 expert 会收到多少 token。

也有 sequence-level routing 的方案（比如让整个序列都去同一组 expert），但这种方案的灵活性差很多，且不适合通用语言模型场景，所以基本只出现在少数特定任务中。

三、路由：整个 MoE 系统的脆弱点

路由看上去只是一个 softmax 加 top-K，但它是 MoE 区别于 dense 模型的核心复杂性来源。一旦路由出了问题，MoE 的所有理论优势都可以归零。

Cerebras 2025 年的一篇分析文章说得很直接：你可以有完美的 expert 结构、精调过的超参、无限的算力，但如果 router collapse 了，你实际上训出来的就是一个比 dense 还差的模型。

3.1 Routing collapse：自增强的死亡螺旋

Routing collapse 是 MoE 最经典的失败模式。现象是：gating 网络逐渐收敛到只给少数 expert 高权重。这形成一个自增强循环——被选中的 expert 收到更多 token、获得更多梯度更新、变得更强、更容易被选中。最终大部分 expert 处于"饿死"状态，模型退化为一个更小的 dense 模型，那些闲置的 expert 白白占着显存。

工程上的诡异之处在于：routing collapse 通常不会导致训练 loss 上升。 Loss 看起来在正常下降，但实际上只有 2-3 个 expert 在工作。你不做专门的 expert 利用率监控，很难发现这个问题。

3.2 Auxiliary loss：一个标准方案和它的内在矛盾

为了对抗 routing collapse，从 Shazeer 2017 的原始 MoE 论文开始，几乎所有 MoE 实现都引入了 auxiliary load balancing loss。核心思路是：在主任务 loss 之外，额外加一个惩罚项，鼓励 router 把 token 均匀分配给所有 expert。

具体来说，这个 loss 通常是 expert 级别的 token 分配比例的方差或乘积：

其中 $f_i$ 是 expert i 实际收到的 token 比例，$P_i$ 是 router 分配给 expert i 的平均概率，$α$ 是平衡系数。当所有 expert 收到的 token 比例相等时，这个 loss 最小。

问题是，这个 loss 和主任务目标是天然冲突的：

• α 太大：router 被迫均匀分配 token，不管 token 的语义内容。Expert 失去了专业化的机会，模型退化为"每个 expert 都做一样的事"。
• α 太小：均衡力度不足，routing collapse 依然发生。

这不是一个可以通过精调 α 来"解决"的问题——它是 MoE 路由设计的结构性矛盾。负载均衡和专家专业化在 auxiliary loss 框架下是一对天然对立的目标。

DeepSeek-V3 做了一个重要的改变：直接去掉 auxiliary loss，改用一种 bias 调节机制。在训练过程中，监控每个 expert 的负载，如果某个 expert 过载，就降低它在路由中的 bias（降低被选中的概率），反之提高。这样负载均衡和路由决策被解耦了——router 可以纯粹基于 token 语义做选择，均衡由 bias 来保证。

DeepSeek-V3 的实验直接表明：auxiliary-loss-free 方案在多数 benchmark 上优于使用 auxiliary loss 的版本。这不是微调改进，而是一种路由哲学的转变——从"用一个 loss 同时优化两个目标"到"把两个目标分开解决"。

3.3 专家看的是 token ID，不是语义

关于 MoE 路由还有一个反直觉的发现：大多数 MoE 的路由行为是 context-independent 的——同一个 token 无论出现在什么上下文，几乎总是被路由到同一个 expert。

OpenMoE 的分析详细展示了这个现象。比如 token "an" 无论出现在 "an apple" 还是 "another" 中，都被路由到同一个 expert。"have""has""had" 被发到同一个 expert，"=""and""\n" 也被发到同一个 expert。

这意味着什么？Router 并没有学到"什么知识找什么专家"，而是学到了一种 token 分片策略——根据 token 的统计特征（主要是 token ID）把 token 分配到不同的 expert。这种分片在训练早期就固化了，后续训练几乎不再改变。

你可以说这也是一种"专业化"，但它和"数学问题找数学专家、代码问题找代码专家"那种直觉想象差得很远。后面我们会专门讨论专家专业化的问题。

3.4 Token dropping 和 capacity overflow

MoE 还有一个 dense 模型完全不存在的问题：token dropping。

每个 expert 有一个 capacity 上限，通常定义为：

如果路由不够均匀，某些 expert 会收到超出 capacity 的 token。超出的 token 怎么办？两种主要处理方式：要么直接 drop（token 走 residual connection 绕过 MoE 层），要么溢出到其他 expert。

• Drop 比例高了，模型质量受损——有些 token 没有得到 MoE 层的处理。
• Capacity factor 设得大一些可以减少 drop，但意味着更多的零填充（padding），浪费计算和显存。

细粒度专家（比如 DeepSeek 的 256 个 routed expert）让这个问题更棘手：每个 expert 更小、capacity 更紧，overflow 概率更高。DeepSeek-V2 在训练中引入了 token-dropping 策略，对不重要的 token 做 drop，但判断"哪些 token 不重要"本身就是一个需要谨慎处理的问题。

四、系统代价：All-to-All 通信和 Expert Parallel 的工程现实

讲完了路由层面的问题，接下来是更硬核的部分：MoE 在系统层面引入的开销。 这部分往往被低估，但它常常是决定 MoE 值不值的关键。

4.1 All-to-all：MoE 独有的系统税

Dense 模型训练的通信模式主要是 AllReduce（梯度同步），这是一个已经被高度优化、通信库深度支持的原语。MoE 训练在此之上，每个 MoE 层额外引入两次 all-to-all 通信：

1. Dispatch：前向传播时，把 token 从当前 GPU 发到它对应的 expert 所在的 GPU。
2. Combine：expert 计算完成后，把结果发回 token 原来所在的 GPU。

反向传播还要再来一轮。也就是说，每个 MoE 层在一个训练 step 中需要 4 次 all-to-all。

这个开销有多大？ByteDance 的 MegaScale-MoE（EuroSys 2026 论文）给出了一手数据：训练 MoE 模型时，通信在 forward pass 中占 43.6%，在整体训练中占约 32%。 Occult（2025）的数据更激进：在大规模训练中，all-to-all 通信占总 runtime 的 40% 以上。

而且这个问题在变严重而不是变好——因为 GPU 计算能力的增长快于互联带宽的增长。从 A100 到 H100 到 B200，FLOPs 翻了好几倍，但 NVLink 和 InfiniBand 的带宽增长有限。FP8 训练进一步压缩了计算时间，让通信在总时间中的占比更加突出。

说白了：MoE 在 FLOPs 上省下来的计算量，有相当一部分被 all-to-all 通信吃回去了。 只看理论 FLOPs 来评估 MoE 的性价比，会得出过于乐观的结论。

4.2 Expert Parallel 的工程复杂度

Expert Parallel（EP）是 MoE 训练和推理的基本并行策略：不同 GPU 放不同 expert，token 通过 all-to-all 发到对应 GPU 上的 expert 做计算。

但 EP 不是孤立存在的——它需要和 TP（Tensor Parallel）、DP（Data Parallel）、PP（Pipeline Parallel）、SP（Sequence Parallel）组合使用。这种组合的复杂度远超 dense 模型：

• Dense 模型：通常只需要 TP + DP，或者 TP + DP + PP 三维并行。
• MoE 模型：需要在上面加 EP 维度，而且 MoE 层和 attention 层可能需要不同的并行策略（attention 用 TP 或 DP attention，expert 用 EP）。

以 Megatron Core 为例，它支持 TP + EP + PP + SP + CP 的五维组合，但要找到最优配置需要大量实验和系统知识。配置不当的后果是显著的——错误的并行策略可能让训练 MFU 低于 dense 模型的一半。

4.3 通信优化：不是锦上添花，而是前置条件

MoE 的通信优化不是"有了更好、没有也行"的事情——没有它，MoE 的实际训练效率可能远低于同 FLOPs 的 dense 模型。这就是为什么 MoE 实际上对系统团队的能力要求极高。

几个代表性的优化方向：

MegaScale-MoE 的做法： 把 MoE 层限制在单个节点内，全部用 NVLink 通信（600+GB/s），不让 expert 跨节点分布。这样 all-to-all 通信全部走高带宽链路。非 MoE 层（attention）用 sequence parallel 做跨节点并行。这个做法在 1440 个 H800 GPU 上训练 352B MoE 模型，相比 Megatron-LM 实现了 1.88 倍的 MFU 提升。

NVIDIA Hybrid-EP： 利用节点内 NVLink 和节点间 InfiniBand/Spectrum-X 的层级拓扑，设计两阶段通信：节点内用高带宽 all-to-all，节点间用低延迟 RDMA。在 Megatron Core 中集成后，训练 DeepSeek 级模型获得 514% 的吞吐提升。

Occult 的 co-location 优化： 观察到如果两个 expert 经常被同一个 token 同时激活（co-activated），把它们放在同一张 GPU 上可以避免冗余通信——同一个 token 只需发送一次而不是 K 次。在理想情况下，如果 Top-K 的 K 个 expert 全部 co-located，通信量可以减少 (K-1)/K。

DeepSeek-V2 的 device-limited routing： 细粒度专家（256 个）会导致每个 token 的 expert 分布在很多设备上。DeepSeek-V2 引入了一个限制：每个 token 的目标 expert 最多分布在 M 个设备上（M ≥ 3）。这直接限制了每个 token 的通信扇出。实测表明 M=3 时性能接近无限制的 top-K routing。

这些优化的共同特点是：它们都在解决 MoE 自身引入的问题。 Dense 模型不存在 all-to-all、不存在 device-limited routing、不存在 co-location 优化的需求。这再次说明 MoE 是把复杂性从计算层搬到了系统层。

4.4 训练稳定性

MoE 训练比 dense 更容易不稳定，原因是路由的 top-K 选择是一个离散决策，导致梯度不连续。不同 expert 收到的 token 数量差异大，梯度方差也大。

Switch Transformer 在论文中专门讨论了精度问题：bfloat16 下 router 的 softmax 计算不够稳定，会导致 routing 抖动。他们的解决方案是只在 router 内部用 float32，其他地方保持 bfloat16——这带来了"选择性精度"的额外工程复杂度。

ST-MoE 进一步引入了 router z-loss，通过惩罚 router logits 的绝对值来防止 softmax 溢出。这个 loss 使得之前因为不稳定而无法训练的"高 FLOPs MoE"（更少但更大的 expert）变得可行。

总的来说：MoE 训练比 dense 更脆弱、调参空间更大、debug 更难。发生问题时，你需要区分"是路由出了问题、是某个 expert 退化了、还是通信出了 bug"——而在 dense 模型中，这类问题要么不存在，要么更容易定位。

五、专家到底学到了什么？

这是 MoE 社区争议最大的话题之一。直觉上，我们希望不同 expert 学到不同的"知识领域"——比如一个 expert 擅长数学、一个擅长代码、一个擅长文学。但实际证据的画面要复杂和模糊得多。

5.1 从实验中看到的真实情况

多项研究（OpenMoE、Switch Transformer、ST-MoE、Mixtral 分析）对路由行为做了详细的可视化和统计分析，得出了几个比较一致的观察：

1. Expert 不按"领域"分工。 不同领域的文本（新闻、代码、科学论文）被分配到各 expert 的比例大致相似，没有出现"expert A 专门处理代码、expert B 专门处理自然语言"的清晰分工。
2. Expert 按 token 的统计特征分工。 同一个 token（比如 "the" "=" "\n"）无论出现在什么上下文，几乎总是去同一个 expert。这种 context-independent specialization 是 MoE 路由的主要模式。
3. 连续 token 倾向于被发到同一个 expert。 这说明路由有某种"局部性"，但更像是位置效应而非语义效应。
4. 路由模式在训练早期就固化。 训练前 10-20% 的 step 基本决定了每个 token 的路由归属，之后变化很小。

这些发现说明：MoE 的"专家分工"更像是一种 learned token partition，而不是 knowledge-level specialization。 说白了，expert 学到的不是"我擅长数学"，而是"这些 token ID 归我处理"。

5.2 细粒度专家：更灵活的分片

DeepSeekMoE 提出了 fine-grained expert segmentation：把 N 个 expert 拆成 mN 个更小的 expert，同时激活 mK 个。比如原来 16 个 expert 激活 2 个，变成 128 个小 expert 激活 16 个。总参数量和 FLOPs 不变，但可选的 expert 组合数量从 C(16,2)=120 变成了 C(128,16)——组合空间爆炸式增长。

这种做法的效果是实际的：DeepSeekMoE 2B 以约 40% 的计算量接近了同参数量 dense 模型的性能上界。但它是否真正实现了"更好的专业化"？DeepSeek 论文中的 ablation study 显示了改进，但严格来说，这种改进也可以解释为"更灵活的 token 分配方式"——不一定是 expert 学到了更不同的知识，也可能只是每个 token 找到了更匹配的处理路径。

5.3 共享专家：承认有些知识不该被路由

DeepSeekMoE 的另一个关键设计是 shared expert isolation：单独拿出几个 expert 作为"共享专家"，它们始终激活，不参与路由。所有 token 都经过这些 shared expert。

这个设计的工程含义很深刻：它其实是在承认，不是所有的计算都适合稀疏化。 有些基础的语言模式（常见的语法结构、高频 token 的处理、通用的上下文建模）是每个 token 都需要的。如果把这些通用知识也交给路由来分配，要么每个 routed expert 都会冗余地学一份，要么某些 token 会因为被路由到"不擅长"的 expert 而质量下降。

Shared expert 把这些通用知识集中处理，释放了 routed expert 的"专业化空间"——它们不需要再学通用语言模式，可以专注于更细分的 token 处理。DeepSeek 的 ablation study 显示移除 shared expert 后，routed expert 之间的冗余增加，整体性能下降。

5.4 专业化的定量分析

2025-2026 年的研究开始用更量化的手段来衡量专业化程度：

• Expert 权重的 cosine similarity：如果不同 expert 的权重矩阵很相似，说明它们学到了类似的函数，专业化程度低。
• Routing entropy：如果 router 对每个 token 给出的概率分布很均匀（高 entropy），说明它无法有效区分 expert；如果分布很尖锐（低 entropy），说明它有明确的偏好。
• Activation variance：不同 expert 对同一 token 产生的 activation 差异越大，专业化越强。

OMoE（Orthogonal MoE）提出了一个有意思的方向：用 Gram-Schmidt 正交化来强制 expert 权重正交。另一项 2026 年初的研究引入了 orthogonality loss（鼓励 expert 处理不同类型的 token）和 variance loss（鼓励路由决策更有区分度）。实验显示这些方法可以减少 expert 重叠达 45%，提高 routing score variance 超过 150%。

但一个开放问题是：更强的专业化一定带来更好的模型性能吗？ 目前的证据是"通常是的，但不是线性关系"。专业化不足会导致冗余，但过度专业化可能导致某些 token 无法找到合适的 expert。

5.5 Expert 数越多越好吗？

不是。这是另一个反直觉的点。

Switch Transformer 的实验显示，expert 数量从 2 增加到 256 时，性能持续改善（在固定 FLOPs 下）。但到 512 以上，改善明显放缓。Fine-grained MoE 的 scaling law 研究进一步表明：当 granularity（expert 数量 × 每 expert 大小的组合）增加到一定程度后，routing 本身的计算开销会反噬性能增益。

原因很直观：expert 越多，router 需要做出越精确的选择。但 router 本身只是一个简单的线性变换——它的"判断能力"是有限的。当 expert 数量远超 router 能有效区分的范围时，路由质量下降，多出来的 expert 实际上是浪费。

六、架构演进：每一步到底在解决什么问题

不做模型盘点。这里只追踪 MoE 架构面临的核心问题在不同阶段是如何被回应的。

第一阶段：证明"稀疏激活在语言模型上可行"

Shazeer 等人 2017 年的 Sparsely-Gated MoE 论文是现代 MoE 的起点。它在 LSTM 语言模型上用了上千个 expert，证明了稀疏激活可以大幅提升性能而不成比例增加计算量。同时也暴露了路由不稳定和 routing collapse 的问题，引入了 auxiliary loss 作为应对。

第二阶段：工程化扩展

GShard（2020）把 MoE 扩展到 600B+ 参数的 Transformer 做多语言翻译，引入了 capacity factor 和 token dropping 机制——这是第一次在 MoE 中正式处理"expert 过载怎么办"的问题。它也引入了 top-2 routing（第一个 expert 确定性选择，第二个按概率选择）来增加专家利用率。

第三阶段：极简化

Switch Transformer（2022，JMLR）做了一个关键判断：top-1 就够了。 它把路由简化到每个 token 只选一个 expert，把 MoE 的计算和通信代价降到了最低。结果是在相同 FLOPs 下获得 7 倍的训练加速。Switch Transformer 还解决了一个实际问题：通过 selective precision（只在 router 中用 float32），第一次让 MoE 在 bfloat16 下稳定训练。

但 top-1 的代价也明显：每个 token 只经过一个 expert，信息瓶颈更窄。对于需要更高质量的通用语言模型来说，这个限制后来被认为过于激进。

第四阶段：稳定化

ST-MoE（2022）发现之前的高 FLOP MoE（更少但更大的 expert）训练不稳定，引入 router z-loss 解决了这个问题。它的核心贡献不在架构创新，而在提供了一套 MoE 训练的最佳实践——什么时候该做 dropout、capacity factor 怎么设、auxiliary loss 的系数该怎么选。

第五阶段：现代 LLM 集成

Mixtral 8x7B（2024 年初）是第一个引起广泛关注的 MoE 通用 LLM。它证明了 MoE 不只是 Google 内部的实验——一个中等规模的团队可以训练出在 top-2 routing、8 个 expert 配置下和 70B dense 模型竞争的开源模型。

Mixtral 的关键信号不在于架构创新（它的 MoE 设计相当传统），而在于证明了 MoE 在通用 LLM 场景的可行性和可部署性。

第六阶段：精细化与经济化

DeepSeekMoE 到 DeepSeek-V2 到 DeepSeek-V3 是 MoE 架构近两年最重要的演进线。这条线的核心推进是：

1. 细粒度专家（mN 个小 expert 替代 N 个大 expert）提供了更灵活的组合空间
2. 共享专家把通用计算和稀疏计算分离
3. Device-limited routing 控制通信扇出
4. Auxiliary-loss-free 解耦负载均衡和路由决策
5. MLA（Multi-head Latent Attention）压缩 KV cache 93.3%
6. FP8 混合精度训练进一步压缩计算时间
7. Computation-communication overlap 让通信"隐藏"在计算背后

DeepSeek-V3 的 2.788M H800 GPU hours（约 600 万美元）是一个标志性数字——它训练了一个 671B 参数、性能接近 GPT-4 的模型，训练成本比同级别 dense 模型低了一个数量级。但这个成本数字背后是上述所有系统优化的叠加。没有这些优化，这个成本是达不到的。

第七阶段：实用化信号

Qwen-MoE 系列（Qwen1.5-MoE、Qwen3-MoE 等）的意义不在于架构创新，而在于释放了一个工程信号：MoE 不再只是研究实验或超大规模团队的专利，它在中等规模也开始可用。 Qwen3-30B-A3B（30B 总参数，3B 激活）提供了一个适合单卡或双卡部署的 MoE 模型选项。

七、推理侧的独特挑战

很多 MoE 讨论集中在训练，但真正决定"值不值"的往往是推理——因为推理成本是持续的、规模化的，一个模型可能训一次但推理千万次。MoE 在推理侧有几个 dense 模型不存在的独特挑战。

7.1 显存悖论

MoE 的 FLOPs 是"稀疏"的，但显存是"密集"的。所有 expert 的参数都要驻留在显存（或至少在可快速加载的位置），即使每个 token 只用一小部分。

Mixtral 8x7B 名义上是"8×7B"，但因为 attention 和 embedding 参数共享，实际总参数约 47B。推理时需要加载 47B 参数的显存，虽然每个 token 只激活约 13B。和一个 13B 的 dense 模型相比，Mixtral 的显存需求高了约 3.6 倍，但 FLOPs 相当。

DeepSeek-V3 更极端：671B 参数，推理时需要的显存远超同 FLOPs 的 37B dense 模型。全精度需要 1.3TB+ 显存，即使用 FP8 也需要 ~670GB——需要多张高端 GPU。

7.2 小 batch 下的效率塌陷

MoE 推理的另一个大问题是：在小 batch 或低并发场景下，expert GEMM 的效率极低。

原因是：decode 阶段每个 token 独立生成，batch size 通常不大。如果模型有 256 个 expert，每个 token 选 8 个，那平均每个 expert 在一个 batch step 中可能只处理极少量的 token。GPU 的 GEMM kernel 在极小矩阵上的利用率很低——你本质上是在用一张设计来做大矩阵乘法的硬件来做大量的小矩阵乘法。

细粒度专家让这个问题更严重：每个 expert 更小（hidden dimension 更低），GEMM 的矩阵更小，GPU 利用率进一步下降。

这就是为什么 MoE 在高并发场景下（大 batch、多用户同时请求）比在低并发场景下更有优势。大 batch 意味着每个 expert 有更多 token 可以一起处理，GEMM 效率更高。

7.3 EP 推理部署的复杂度

vLLM 从 2025 年开始原生支持 MoE 的 EP 推理，但它的部署复杂度远超 dense 模型。

vLLM 对 MoE 引入了 "DP Attention + Expert Parallel" 模式：attention 层在每张 GPU 上独立处理各自的请求（数据并行），expert 层通过 all-to-all 通信在 GPU 之间交换 token。这意味着：

• 所有 DP rank 的 forward pass 必须对齐： 即使某些 GPU 当前没有请求，也要做 dummy forward，因为 expert 层需要全局同步。低并发时，这会导致部分 GPU 空转但无法释放。
• 通信后端需要专门配置： vLLM 支持 DeepEP 的 high-throughput 和 low-latency 两种后端，分别优化 prefill 和 decode 阶段。
• 负载均衡需要动态调整： vLLM 提供了 EPLB（Expert Parallel Load Balancer），运行时监控 expert 负载，定期重新分配 expert 到 GPU。配置项包括 window_size、step_interval、num_redundant_experts 等。

相比之下，dense 模型的 TP 推理部署几乎只需要设一个 tensor_parallel_size。

7.4 Prefill/Decode 分离

MoE 推理的 prefill 和 decode 阶段特性差异比 dense 更大：

• Prefill（处理输入 prompt）：大量 token 同时处理，expert GEMM 效率高，是 compute-bound 的。
• Decode（逐 token 生成）：每步只处理少量新 token，expert GEMM 效率低，是 memory-bandwidth-bound 的。

对于 dense 模型，这种差异存在但程度较轻。对于 MoE 模型，两个阶段的最优并行策略可能完全不同。vLLM 和 TensorRT-LLM 开始支持 disaggregated serving：prefill 和 decode 用不同的实例、不同的通信后端、甚至不同的硬件配置。

这进一步增加了部署的工程复杂度。

八、Dense vs MoE：一个有判断力的选型框架

不回避给出明确建议。

什么时候 dense 更合适

1. 目标模型的激活参数 < 20-30B：在这个尺度下，MoE 的路由和通信开销占比太高，不如直接 dense。
2. 推理场景以低延迟/低并发为主：比如边缘部署、单用户交互场景。小 batch 下 MoE 的 expert GEMM 效率差，且显存需求高于同 FLOPs 的 dense 模型。
3. 团队缺乏分布式系统能力：MoE 的训练需要 EP 优化、通信调度；推理需要 EPLB、disaggregated serving。如果团队做不了这些，MoE 的理论收益会被系统代价吃掉。
4. 需要频繁微调：MoE 微调比 dense 更容易过拟合（expert 的高参数量 + 小数据集 = 过拟合），也更难保持路由稳定。
5. 瓶颈在数据而不是模型容量：MoE 提供的是"更大的参数容量"。如果你的数据不足以填满这些参数，MoE 可能反而因为过参数化更快过拟合。

什么时候 MoE 有意义

1. 需要 > 100B 级别的总参数容量但训练预算有限：这是 MoE 最核心的使用场景。你想要一个有数百 B 参数知识容量的模型，但不想付数百 B 参数 dense 模型的训练和推理成本。
2. 推理场景以高并发/高吞吐为主：大 batch 下稀疏激活的 FLOPs 节省可以兑现为实际的吞吐提升。多用户在线服务、API 服务是典型场景。
3. 多语言/多模态/多任务场景：MoE 天然适合需要不同"处理模块"的场景。不同语言、不同模态的 token 可以被路由到不同的 expert，这比 dense 模型的"所有 token 共享所有参数"更高效。
4. 团队有分布式系统和 GPU kernel 优化能力：能做 EP 优化、通信调度、custom kernel。这不是加分项，而是准入门槛。

瓶颈在哪——判断方法

你的瓶颈是什么	MoE 帮不帮得上	原因
训练 FLOPs 太高	✅ 帮得上	MoE 核心优势：更多参数，更少 FLOPs
推理吞吐太低（高并发）	✅ 帮得上	大 batch 下 FLOPs 节省可以兑现
显存不够	❌ 帮不上	MoE 总参数更多，显存需求更大
通信带宽不够	❌ 反而更差	MoE 额外引入 all-to-all
数据不够	❌ 帮不上	更多参数 + 不够的数据 = 更快过拟合
推理延迟太高（低并发）	⚠️ 视情况	小 batch 下可能更差；大 batch 下可能更好

如何判断 MoE 的瓶颈在模型、路由还是系统

• 监控 expert 利用率分布：如果少数 expert 处理了大部分 token，问题在路由（routing collapse 或 auxiliary loss 系数不当）。
• 监控通信占比：如果 all-to-all 通信占总 runtime > 30%，问题在系统（需要通信优化或调整并行策略）。
• 对比 dense baseline：如果同 FLOPs 的 dense 模型在你的 benchmark 上表现相当或更好，问题可能在 MoE 的模型设计（expert 数量、K 值、shared expert 配置不当）。

九、真实踩坑清单

下面列出在 MoE 训练和推理中常见的工程坑。每个坑给出"为什么会踩、表面症状、深层原因、缓解方向"。

坑 1：Routing collapse 不报错但模型静默退化

为什么会踩： 默认训练 pipeline 不监控 expert 利用率。症状： Loss 正常下降，但下游 benchmark 结果差于预期。根因： 只有少数 expert 在工作，等效模型容量远小于设计。缓解： 每隔 N 步 log 每个 expert 的 token 处理数、routing entropy。发现不均衡后调整 auxiliary loss 系数或切换 auxiliary-loss-free 方案。

坑 2：Auxiliary loss 系数过大压制专业化

为什么会踩： 为了防止 routing collapse 而把 α 调高。症状： Expert 利用率很均匀，但模型性能不如预期——每个 expert 做的事差不多。根因： 过强的均衡约束让 router 失去了基于语义做选择的自由度。缓解： 降低 α，或尝试 auxiliary-loss-free 方案；引入 orthogonality loss 辅助。

坑 3：Capacity factor 设太小导致大量 token drop

为什么会踩： 为了节省计算/显存而压低 capacity factor。症状： 训练 loss 波动增大或 plateau 过早；部分 token 的梯度信号缺失。根因： 路由不够均匀时，热门 expert overflow，token 被 drop。缓解： 增大 capacity factor（1.25 是常见起点），或使用动态 token 重分配策略。

坑 4：Expert 权重初始化不够多样

为什么会踩： 使用默认初始化，所有 expert 起点太相似。症状： 训练前期 expert 权重相似度高，routing entropy 低。根因： Expert 从相似的起点开始，router 没有足够的信号来区分它们。缓解： 用不同 random seed 或刻意分散的初始化策略；考虑 ReMoE 式的"先 dense 再逐步稀疏"训练方案。

坑 5：BF16 路由计算不稳定

为什么会踩： 全用 BF16 训练。症状： 训练早期出现 loss spike 或 NaN。根因： Router softmax 在低精度下对大 logit 值敏感，容易溢出。缓解： Router 内部计算用 float32，dispatch/combine tensor 保持 BF16（Switch Transformer 的 selective precision 方案）；引入 router z-loss 限制 logit 幅度。

坑 6：All-to-all 通信吃掉 FLOPs 节省

为什么会踩： 不做通信优化直接上 EP。症状： 训练 wall-clock time 比同 FLOPs 的 dense 模型还长。MFU 远低于预期。根因： 每层 MoE 的 all-to-all 通信成为瓶颈，尤其跨节点时。缓解： 限制 EP 在节点内（利用 NVLink）；使用 Hybrid-EP；确保 computation-communication overlap。

坑 7：推理小 batch 下 expert GEMM 效率极低

为什么会踩： 部署 MoE 模型服务低并发场景。症状： 推理延迟比同激活参数的 dense 模型高很多。根因： 每个 expert 只处理极少 token，矩阵乘法太小，GPU 利用率低。缓解： 提高并发度（batch 更多请求）；考虑 expert merging/pruning 减少 expert 数量；或在低并发场景用 dense 模型。

坑 8：EP 部署时低并发 GPU 空转

为什么会踩： 部署 MoE 时用了 DP Attention + EP。症状： 低并发时部分 GPU 几乎没有请求但无法释放，因为 expert 层需要全局同步。根因： MoE 的 EP 要求所有 rank 的 forward pass 对齐。缓解： 调整 DP size 适配实际并发量；使用 disaggregated serving 分离 prefill/decode；考虑非 EP 模式（TP for MoE layers）。

坑 9：微调 MoE 过拟合严重

为什么会踩： 在小数据集上微调大 MoE 模型。症状： 训练 loss 快速下降但验证 loss 发散。根因： MoE 的总参数量远大于 dense 同 FLOPs 模型，在小数据上过参数化。缓解： 增大 expert dropout；冻结部分 expert 参数；使用 LoRA-MoE 只微调 router 和少量 expert；或只微调 shared expert。

坑 10：Expert 梯度方差大导致训练不稳

为什么会踩： 路由不够均匀，不同 expert 收到的 token 数差异大。症状： 训练 loss 波动大或出现间歇性 spike。根因： 热门 expert 梯度频繁更新，冷门 expert 长期不更新，整体梯度方差高。缓解： 加强负载均衡；对 router 参数做 gradient clipping；使用更稳定的优化器配置。

坑 11：KV cache 和 expert 参数抢显存

为什么会踩： 部署时为 MoE 模型分配了所有 expert 参数后，KV cache 空间不足。症状： 最大可服务 context length 远低于模型设计的支持长度；频繁 preemption。根因： MoE 总参数量大，留给 KV cache 的空间紧张。缓解： 使用 KV cache 量化（DeepSeek-V2 做到平均 6 bit）；增加 GPU 数量分摊参数；使用 MLA 等 KV 压缩技术。

坑 12：通信与计算 overlap 做不好

为什么会踩： 使用默认的 all-to-all 实现，没有做 kernel 级别的调度。症状： GPU 在通信时计算单元空闲，utilization 出现周期性掉坑。根因： All-to-all 和 expert 计算默认串行执行。缓解： 使用 Megatron Core / DeepSpeed 的 overlap 策略；开发 custom CUDA kernel 实现 communication-computation pipelining。

十、当前前沿与未解问题

MoE 领域当前最活跃的研究方向不是"怎么让 MoE 更大"，而是"怎么让 MoE 更可靠、更经济、更可解释"。

Auxiliary-loss-free 负载均衡

DeepSeek-V3 开了先河，后续工作正在将这个方向理论化。MaxScore routing 把路由形式化为一个带约束的优化问题（最小费用最大流），试图在 expert capacity、token 分配和通信成本之间找到最优平衡。这比 auxiliary loss 的 heuristic 方式更有理论保证。

Expert pruning 和 merging

一个务实的方向：在推理时把 MoE 压缩回类 dense 结构。CD-MoE 等工作尝试把多个 expert 的权重合并为更少的 always-on expert，消除路由开销。Switch Transformer 早期的蒸馏实验保留了约 30% 的稀疏收益——这意味着即使最后用 dense 模型部署，MoE 作为"训练方法"仍然有价值。

Multimodal MoE

Qwen3-VL 的 MoE 变体（30B-A3B 和 235B-A22B）表明 MoE 正在被用作跨模态计算分配的工具。不同模态（文本、图像、视频）的 token 可以被路由到不同的 expert，实现"给不同模态分配不同的计算资源"。这把 MoE 从纯粹的"参数效率"工具扩展成了"计算分配"工具。

Attention MoE

把 MoE 从 FFN 层扩展到 attention 层。Multi-Head MoE 将 token 的 hidden state 分成多个子空间，每个子空间独立路由到不同 expert。这增加了模型的表达能力但也增加了工程复杂度。目前还处于研究阶段，没有大规模生产验证。

Expert 可解释性和可控性

MoTE（Mixture of Tunable Experts）的研究表明，在有大量 expert 的 MoE 模型中，有针对性地在推理时操控少量 expert 的激活，可以改变模型行为（比如降低 refusal rate、控制语言选择），而不需要重新训练。这为 MoE 提供了一种独特的"模块化可控性"——dense 模型做不到这一点。

开放问题

几个当前没有定论的重要问题：

1. 路由到底应不应该是 learned 的？ Hash routing 完全不学习但负载完美均衡，learned routing 有更好的专业化但会 collapse。有没有介于两者之间的最优方案？
2. Expert 数量的最优 scaling law 是什么？ 当前研究给出了一些经验规律（超过 256-512 后收益递减），但缺乏像 Chinchilla 那样的系统性 scaling law。
3. MoE 在 post-training（RLHF、DPO）阶段的行为怎么理解？ 预训练阶段确立的路由模式在 post-training 时是否需要、以及如何调整？
4. MoE + 长上下文的交互效应？ 长序列意味着更多 token 需要路由，负载均衡的挑战更大。路由决策是否需要感知序列长度？
5. 推理时的 expert locality 最佳实践是什么？ EPLB 做了运行时调整，但最优的 expert placement 策略仍然是开放问题。

结论：MoE 不是免费午餐，但可能是大模型时代性价比最高的一张入场券

未来 2-3 年 MoE 最可能持续成功的场景

1. 超大规模预训练：当你需要数百 B 乃至万亿参数的模型容量时，MoE 是唯一经济可行的路线。Dense 路线在这个规模上的训练和推理成本都不可接受。
2. 高并发在线推理服务：API provider、云端 AI 服务等高 QPS 场景。大 batch 下 MoE 的 FLOPs 节省可以转化为实际的吞吐优势和成本节省。
3. 多语言和多模态模型：MoE 的 expert 可以自然地为不同语言和模态分配计算资源，这比 dense 模型的"所有能力共享所有参数"更高效。

适合投入 MoE 的团队

• 有强分布式系统和 GPU kernel 优化能力的团队——这是硬门槛，不是可选项
• 有足够算力做 MoE 级别预训练的团队（至少数百张 GPU）
• 明确需要"大参数容量 + 低训练成本"或"高吞吐推理"的团队
• 能持续投入系统优化的团队——MoE 的系统生态在快速演进，用去年的方案训今年的模型会很吃亏

不要被误导

• "总参数更大"不等于"模型更强"。 MoE 的有效容量取决于路由质量和 expert 利用率。一个 routing collapse 了的 600B MoE 可能不如一个训得好的 70B dense。
• 专家"专业化"远没有你想象的那么强。 大多数 MoE 的路由行为更像 token 分片而非知识领域分工。不要因为"专家"这个词就期待每个 expert 是某个领域的专家。
• MoE 的系统代价是真实的、显著的、不可忽略的。 All-to-all 通信占训练 30-43% runtime 不是极端情况，而是常态。没有通信优化的 MoE 训练可能比 dense 还慢。
• 推理侧的挑战往往比训练侧更难解决。 训练可以用更多 GPU、更长时间来解决，但推理需要在固定硬件上持续满足延迟和吞吐 SLA。MoE 推理的显存需求、小 batch 效率、EP 同步开销都是实际的工程约束。

最后一句

MoE 的本质是一种 复杂性的重新分配：它把"每个 token 都要做的 dense 计算"重新分配为"路由决策 + 稀疏计算 + 系统调度"。如果你的系统能力能够高效地承载后者，MoE 就是一条更经济的 scaling 路线。如果不能，它只是把你不擅长解决的问题换了一个你更不擅长解决的形式。

这不是唱衰。事实上，截至 2025 年底，超过 60% 的开源模型发布采用了 MoE 架构，所有主流性能排行榜的头部模型都是 MoE。这个趋势在未来几年只会加强。但理解 MoE 的"入场门票"到底包含什么，比盲目追随趋势重要得多。

参考资料

以下按在正文中出现的逻辑顺序组织：

核心论文

• Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer," ICLR 2017
• Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding," ICLR 2021
• Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity," JMLR 2022
• Zoph et al., "ST-MoE: Designing Stable and Transferable Sparse Expert Models," 2022
• Jiang et al., "Mixtral of Experts," 2024
• Dai et al., "DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models," 2024
• DeepSeek-AI, "DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model," 2024
• DeepSeek-AI, "DeepSeek-V3 Technical Report," 2024

系统论文

• Jin et al., "MegaScale-MoE: Large-Scale Communication-Efficient Training of Mixture-of-Experts Models in Production," EuroSys 2026
• "Occult: Optimizing Collaborative Communications across Experts for Accelerated Parallel MoE Training and Inference," 2025
• "LAER-MoE: Load-Adaptive Expert Re-layout for Efficient MoE Training," 2026
• "X-MoE: Enabling Scalable Training for Emerging Mixture-of-Experts Architectures on HPC Platforms," SC 2025
• Zhang et al., "A Survey on Accelerated Technologies for Mixture-of-Experts Model Training Systems," Tsinghua Science and Technology 2026
• ACM Computing Surveys, "A Survey on Inference Optimization Techniques for Mixture of Experts Models," 2026

工程资料

• NVIDIA Technical Blog, "Optimizing Communication for Mixture-of-Experts Training with Hybrid Expert Parallel," 2026
• NVIDIA Technical Blog, "Scaling Large MoE Models with Wide Expert Parallelism on NVL72 Rack Scale Systems," 2026
• vLLM Documentation: Expert Parallel Deployment, Data Parallel Deployment
• Red Hat Developer, "Scaling DeepSeek-style MoEs with vLLM and llm-d Using Wide EP," 2025

路由与专业化分析

• Cerebras Blog, "Router Wars: Which MoE Routing Strategy Actually Works," 2025
• OpenMoE analysis on context-independent specialization
• "Advancing Expert Specialization for Better MoE," 2026
• ReMoE, "ReMoE: Fully Differentiable Mixture-of-Experts with ReLU Routing," ICLR 2025
• Hugging Face Blog, "A Review on the Evolvement of Load Balancing Strategy in MoE LLMs," 2025

综述

• "Mixture of Experts in Large Language Models," arXiv 2507.11181, 2025
• Gan et al., "Mixture of experts (MoE): A big data perspective," Information Fusion 2026