大模型参数量的膨胀速度，这两年大家有目共睹。从早期几亿参数的小模型，到现在动辄千亿甚至万亿参数的庞然大物，单卡显存早就装不下了，多卡并行训练也变得越来越吃力。但有意思的是，真正跑推理的时候，模型并不是每个参数都会参与计算——这就是稀疏化的核心思路。而把这套思路真正做成工业级架构的，就是MoE（Mixture of Experts，混合专家）。

我第一次认真拆 MoE 是在一个推理成本压不下去的项目里。当时模型效果不错，但每次请求都要激活全部参数，GPU 利用率上不去，延迟也下不来。后来换成 MoE 结构，同样的效果，激活参数量直接砍到原来的几分之一，推理吞吐量翻了好几倍。从那以后我就意识到，MoE 不是学术圈的概念玩具，而是大模型落地绕不开的一环。

这篇文章我会从 MoE 的基本原理讲起，拆解它的路由机制、负载均衡、显存占用、训练策略，再结合几个主流开源模型的实现细节，把"为什么这样设计"讲清楚。不管你是刚接触大模型架构的新手，还是正在做推理优化的工程师，都能从中找到可以直接参考的东西。

1. MoE 到底解决了什么问题

1.1 稠密模型的参数困境

先说说传统稠密（Dense）模型的问题。一个标准的 Transformer 模型，每一层的前馈网络（FFN）都是全量激活的——输入一个 token，整个 FFN 的所有参数都要参与计算。这意味着什么？模型参数量越大，单次推理的计算量就越大，显存占用也越高。

以 175B 参数的稠密模型为例，光是权重加载就需要 350GB 的显存（FP16 精度下），推理时还要加上激活值、KV Cache 等开销。这还没算上训练时的梯度、优化器状态，实际需求轻松突破 1TB。对于大多数团队来说，这个门槛太高了。

更关键的是，稠密模型的"参数效率"其实很低。研究表明，对于不同的输入 token，模型真正需要的知识是高度特化的——处理代码的 token 和处理诗歌的 token，需要的参数子集完全不同。但稠密模型不管这些，每次都用全部参数算一遍，浪费了大量算力。

1.2 稀疏激活的核心逻辑

MoE 的思路很直接：既然不是每个 token 都需要全部参数，那就把 FFN 拆成多个"专家"（Expert），每个 token 只激活其中一小部分。这样一来，模型的总参数量可以做得很大，但单次推理的计算量只和激活的专家数量相关。

举个具体的例子。假设一个 MoE 层有 8 个专家，每个专家是一个独立的 FFN，路由网络（Router）会根据 token 的特征选择 Top-2 专家参与计算。那么总参数量是 8 个 FFN 之和，但实际计算量只有 2 个 FFN。这就是"参数规模大、计算量小"的稀疏化优势。

注意：MoE 的稀疏性是"条件计算"（Conditional Computation）的一种实现，和模型剪枝、量化那种"静态稀疏"不是一回事。MoE 的稀疏性是动态的，每个 token 激活的专家可能都不一样。

1.3 参数量与计算量的解耦

MoE 最吸引人的地方，是它把模型容量和计算成本解耦了。稠密模型里，参数量增加必然带来计算量增加；MoE 里，你可以通过增加专家数量来扩大模型容量，而单 token 的计算量基本不变（只要保持 Top-K 不变）。

这个特性对实际部署意义重大。比如一个 8x7B 的 MoE 模型，总参数量约 47B，但每个 token 只激活约 13B 的参数。推理时的显存占用和计算量接近一个 13B 的稠密模型，但效果却接近甚至超过一个 30B+ 的稠密模型。这种"性价比"是稠密模型很难做到的。

不过这里有个常见的误解需要澄清：MoE 并不会减少显存占用。虽然计算时只激活部分专家，但所有专家的参数都需要加载到显存里（或者至少需要能被快速访问）。所以"MoE 架构要全部参数进显存吗"这个问题的答案是：在标准实现下，是的，全部专家参数都需要驻留在显存或可快速换入的存储中。这也是 MoE 部署时最头疼的问题之一，后面我会专门讲怎么优化。

2. 路由机制：MoE 的大脑是怎么工作的

2.1 Top-K 路由的基本流程

MoE 的核心是路由网络，它决定了每个 token 该送给哪些专家处理。最常见的做法是 Top-K 路由，流程大致如下：

1. 对每个 token 的隐藏状态，通过一个线性层计算它在所有专家上的得分（logits）。
2. 对得分做 Softmax，得到每个专家的权重。
3. 选择得分最高的 K 个专家，用它们的权重对输出做加权求和。

用伪代码表示大概是这样：

# 假设 hidden_states 形状为 [batch, seq_len, hidden_dim] # gate 是一个线性层，输出维度为 num_experts router_logits = gate(hidden_states) # [batch, seq_len, num_experts] routing_weights = softmax(router_logits, dim=-1) # 选择 Top-K 专家 top_k_weights, top_k_indices = topk(routing_weights, k=K, dim=-1) # 归一化权重 top_k_weights = top_k_weights / top_k_weights.sum(dim=-1, keepdim=True) # 对每个专家计算输出并加权求和 output = zeros_like(hidden_states) for i in range(K): expert_idx = top_k_indices[..., i] weight = top_k_weights[..., i] output += weight * experts[expert_idx](hidden_states)

这个流程看起来简单，但实际实现时有大量细节需要处理。比如 Top-K 的选择是每个 token 独立做的，不同 token 可能选择完全不同的专家组合；再比如权重的归一化方式会影响训练的稳定性。

2.2 路由算法的几种变体

Top-K 路由是最基础的方案，但实际研究中衍生出了不少变体，各有取舍。

Top-1 路由：每个 token 只选一个专家。计算量最小，但训练时容易不稳定，因为路由决策是离散的，梯度回传困难。Switch Transformer 用的就是这种方案，通过辅助损失来缓解负载不均的问题。

Top-2 路由：每个 token 选两个专家。这是目前最主流的方案，GShard、GLaM 等模型都采用这种配置。计算量比 Top-1 大，但训练更稳定，效果也更好。

专家容量限制：为了防止某个专家被过度使用，很多实现会设置一个容量上限（Capacity Factor）。如果某个专家收到的 token 超过容量，多余的 token 会被丢弃或者走残差连接。这个机制对负载均衡很关键，但也会影响效果——被丢弃的 token 相当于没经过 FFN 处理。

软路由 vs 硬路由：硬路由就是上面说的 Top-K 选择，每个 token 只走部分专家。软路由则是所有专家都参与，但用权重加权。软路由计算量大，实际中很少用，更多是作为理论分析的工具。

2.3 路由网络的训练难点

路由网络最难的地方在于它的离散性。Top-K 选择是一个不可微的操作，梯度没法直接回传。常见的解决方案有几种：

Gumbel-Softmax：用 Gumbel 噪声加 Softmax 来近似离散选择，训练时用软权重，推理时用硬选择。这种方法理论优雅，但实际中调参比较麻烦。

辅助损失：不直接对路由决策求导，而是加一个辅助损失来引导路由网络。比如负载均衡损失，鼓励 token 均匀分配到各个专家。这是目前最常用的方案，实现简单，效果也稳定。

强化学习：把路由决策看作一个策略，用 REINFORCE 等算法来优化。理论上可行，但实际中很少用，因为方差太大，训练不稳定。

我在实际项目里的体会是，辅助损失的设计比路由算法本身更重要。一个好的负载均衡损失，能让训练稳定性和最终效果都提升一个档次。后面讲负载均衡时会详细展开。

3. 负载均衡：MoE 训练中最容易翻车的地方

3.1 负载不均的根源

MoE 训练中最常见的问题就是负载不均——少数几个专家被大量 token 选中，其他专家几乎没人用。这种情况一旦出现，会引发一系列连锁反应：

• 热门专家的参数学得更充分，冷门专家基本没更新，专家之间的能力差距越来越大。
• 计算资源浪费，热门专家所在的 GPU 成为瓶颈，其他 GPU 闲着。
• 训练不稳定，梯度集中在少数专家上，容易导致 loss 震荡。

负载不均的根源在于路由网络的"马太效应"：训练初期，某些专家因为随机初始化恰好表现好一点，就会被更多 token 选中，然后学得更好，进一步被更多 token 选中。这个正反馈循环一旦形成，就很难打破。

3.2 辅助损失的设计

解决负载不均最常用的手段是加辅助损失。核心思想是：除了主任务损失，再加一个损失项来惩罚负载不均。

最经典的负载均衡损失来自 Switch Transformer，形式如下：

# f_i: 分配给专家 i 的 token 比例 # P_i: 专家 i 的平均路由概率 # N: 专家数量 aux_loss = N * sum(f_i * P_i for i in range(N))

这个损失的含义是：如果 token 分配比例和路由概率分布不一致，损失就会变大。理想情况下，每个专家收到的 token 比例应该等于它的平均路由概率，这样损失最小。

实际实现时，通常会加一个系数来控制辅助损失的权重。这个系数很关键：太小了起不到均衡作用，太大了会影响主任务效果。我试过的经验值是 0.01 到 0.1 之间，具体要看模型规模和任务类型。

3.3 专家容量与 Token 丢弃

除了辅助损失，另一个常用手段是设置专家容量。每个专家能处理的 token 数量有上限，超过的 token 会被丢弃或走残差连接。

容量计算公式一般是：

capacity = (tokens_per_batch / num_experts) * capacity_factor

capacity_factor 通常取 1.0 到 2.0 之间。取 1.0 意味着每个专家平均处理这么多 token，取 2.0 则留了一倍余量。

Token 丢弃是个双刃剑。好处是强制负载均衡，坏处是丢弃的 token 相当于没经过 FFN，可能影响效果。实践中，如果辅助损失调得好，Token 丢弃率可以控制在很低的水平（比如 1% 以下），这时候容量的主要作用是防止极端情况。

提示：监控 Token 丢弃率是 MoE 训练中必做的功课。如果丢弃率持续偏高，说明负载均衡没做好，需要调整辅助损失系数或容量因子。

3.4 实际训练中的调参经验

负载均衡这块，我踩过的坑不少，分享几个实用的经验：

辅助损失系数不要一开始就设太大。训练初期路由还没稳定，太大的辅助损失会干扰主任务学习。可以先设小一点（比如 0.01），观察负载情况再逐步调整。

监控每个专家的 token 分配比例。理想情况下应该接近均匀分布，如果发现某些专家长期低于平均值，说明均衡没做好。这个指标比总 loss 更能反映 MoE 的健康状况。

容量因子可以动态调整。训练初期可以设大一点（比如 2.0），给路由网络更多探索空间；训练后期再收紧（比如 1.25），提高计算效率。

不要忽视专家初始化的影响。如果所有专家用相同的初始化，路由网络很难区分它们，容易导致负载不均。实践中可以用不同的随机种子初始化各个专家，增加多样性。

4. 显存与计算优化：MoE 部署的硬骨头

4.1 全部参数进显存的问题

回到那个热搜问题："MoE 架构要全部参数进显存吗？"标准答案是：在朴素实现下，是的。因为路由网络是动态的，你没法提前知道哪个 token 会走哪个专家，所以所有专家的参数都得随时可用。

这就带来一个尴尬的局面：一个 8x7B 的 MoE 模型，总参数量 47B，推理时虽然只激活 13B，但显存占用却接近 47B 的稠密模型。稀疏化带来的计算优势，在显存上完全体现不出来。

这个问题在单卡部署时尤其致命。一张 80GB 的 A100，加载 47B 参数的 FP16 模型需要 94GB，根本装不下。所以 MoE 部署时，显存优化是绕不开的课题。

4.2 专家并行的切分策略

最直接的解决方案是专家并行（Expert Parallelism）。把不同的专家放到不同的 GPU 上，每个 GPU 只加载一部分专家。这样单卡显存需求就降下来了。

但专家并行有个问题：token 需要在 GPU 之间传输。如果某个 token 被路由到另一张卡上的专家，就需要跨卡通信。这个通信开销可能成为瓶颈，尤其是在专家数量多、路由分散的情况下。

实践中，专家并行通常和其他的并行策略结合使用。比如：

选择哪种组合，取决于模型规模、硬件配置和通信带宽。一般来说，专家并行是 MoE 特有的，其他几种和稠密模型类似。

4.3 专家卸载与按需加载

如果显存实在不够，还有一种方案是专家卸载（Expert Offloading）：把不常用的专家放在 CPU 内存或 SSD 上，需要时再加载到 GPU。这类似于操作系统的虚拟内存机制。

这种方案的好处是显存需求大幅降低，坏处是加载延迟。如果路由比较集中，大部分 token 都走少数几个专家，那么卸载的效果会很好；如果路由很分散，频繁的加载会成为瓶颈。

实际实现时，通常会结合缓存策略：把最近使用的专家留在 GPU 上，冷门的专家卸载出去。缓存命中率是关键指标，命中率高的话，卸载带来的延迟可以控制在可接受范围内。

4.4 推理时的批处理优化

MoE 推理还有一个特殊之处：不同 token 走的专家不同，导致计算图是动态的。这对批处理优化提出了挑战。

一个常用的技巧是"按专家分组"：先把所有 token 按路由结果分组，同一组的 token 一起送给对应的专家处理，处理完再合并。这样每个专家的计算都是稠密的，能充分利用 GPU 的并行能力。

但这个分组-计算-合并的过程有额外开销，尤其是 token 数量少的时候。所以 MoE 推理在 batch size 较大时效率更高，小 batch 时反而不如稠密模型。

5. 主流 MoE 模型的架构对比

5.1 Mixtral 8x7B 的设计取舍

Mixtral 8x7B 是 Mistral AI 发布的开源 MoE 模型，也是目前最流行的 MoE 模型之一。它的设计有几个值得注意的点：

• 每个 MoE 层有 8 个专家，Top-2 路由。
• 专家是 FFN 层，注意力层是共享的。
• 总参数量约 47B，激活参数量约 13B。

这种设计的巧妙之处在于，它只把 FFN 层做成 MoE，注意力层保持稠密。原因是 FFN 层的参数量通常占模型的大部分（约 2/3），把它稀疏化收益最大；而注意力层的参数量相对小，做成 MoE 收益有限，还会增加复杂度。

Mixtral 的效果也验证了这个设计：它在多个基准上接近甚至超过了一些更大的稠密模型，而推理成本只有 13B 模型的水平。

5.2 DeepSeek-MoE 的细粒度专家

DeepSeek-MoE 走了一条不同的路线：细粒度专家（Fine-Grained Expert）。传统 MoE 每个专家是一个完整的 FFN，DeepSeek-MoE 把 FFN 拆得更细，每个专家只负责 FFN 的一部分。

具体来说，DeepSeek-MoE 有 64 个路由专家和 2 个共享专家，每个 token 激活 6 个路由专家。这种设计的好处是专家组合更灵活，能更精细地匹配 token 的需求。

共享专家的设计也很有意思：不管什么 token，都会经过共享专家处理。这相当于给模型一个"基础能力"的保障，避免所有能力都依赖路由选择。

5.3 Qwen-MoE 的专家特化

Qwen-MoE 在专家特化方面做了一些探索。它的思路是让不同的专家专注于不同类型的知识或任务，比如有的专家擅长代码，有的擅长数学，有的擅长自然语言。

这种特化不是显式指定的，而是通过训练自然形成的。但可以通过一些技巧来引导，比如在训练数据中混合不同领域的数据，让路由网络学会区分。

实际观察下来，Qwen-MoE 的专家确实表现出一定的特化倾向，但不像想象中那么泾渭分明。大部分专家还是"通才"，只有少数专家有明显的领域偏好。

5.4 架构对比与选型建议

把几个主流 MoE 模型放在一起对比：

选型时主要看几个因素：显存预算、推理延迟要求、任务类型。如果显存充足、追求效果，可以选专家数多的；如果显存紧张、追求低延迟，可以选激活参数少的。

6. MoE 训练的实操要点

6.1 从稠密模型初始化

从头训练一个 MoE 模型成本很高，一个实用的技巧是从稠密模型初始化。具体做法是：把稠密模型的 FFN 复制多份作为初始专家，然后加一个随机初始化的路由网络。

这样做的好处是，专家一开始就有不错的能力，路由网络只需要学习如何分配 token。相比从头训练，收敛速度快很多，效果也更稳定。

不过要注意，复制出来的专家是完全相同的，路由网络很难区分它们。所以通常会在复制时加一点噪声，或者用不同的随机种子重新初始化部分参数，增加专家之间的差异性。

6.2 学习率与优化器设置

MoE 的学习率设置和稠密模型有些不同。路由网络通常需要更大的学习率，因为它要从零开始学习；专家网络可以用较小的学习率，尤其是从稠密模型初始化时。

实践中，常见的做法是给路由网络和专家网络设置不同的学习率倍数。比如专家网络用基础学习率，路由网络用 2-5 倍的学习率。具体倍数要看训练情况调整。

优化器方面，AdamW 是最常用的选择。但要注意，MoE 的梯度分布可能比稠密模型更不均匀，梯度裁剪（Gradient Clipping）很重要。通常会把梯度范数裁剪到 1.0 左右。

6.3 训练稳定性监控

MoE 训练比稠密模型更容易出现不稳定，需要重点监控几个指标：

• 路由熵：衡量路由分布的集中程度。熵太低说明路由太集中，负载不均；熵太高说明路由太随机，专家没学到东西。
• 专家利用率：每个专家处理的 token 比例。理想情况是接近均匀。
• Token 丢弃率：被容量限制丢弃的 token 比例。应该控制在较低水平。
• 辅助损失：负载均衡损失的变化趋势。应该逐渐下降并稳定。

这些指标最好做成实时监控面板，训练时随时观察。一旦发现异常，及时调整超参数。

6.4 微调时的注意事项

MoE 模型的微调和稠密模型有些不同。最大的区别是，微调时路由网络的行为可能发生变化，导致负载分布偏移。

一个常见的问题是"专家坍缩"：微调后，大部分 token 都走少数几个专家，其他专家被"遗忘"。这会降低模型的有效容量，影响效果。

避免这个问题的方法有几种：一是微调时也加负载均衡损失，保持路由的均衡性；二是冻结路由网络，只微调专家参数；三是用较小的学习率，避免路由网络变化太大。

我个人的经验是，如果微调数据量不大，冻结路由网络是最稳妥的选择。如果数据量较大、任务和预训练差异明显，可以解冻路由网络，但要加辅助损失。

7. MoE 的局限与未来方向

7.1 通信开销与工程复杂度

MoE 最大的代价是工程复杂度。专家并行带来的跨卡通信、动态路由带来的负载不均、显存管理的复杂性，都让 MoE 的部署比稠密模型难得多。

通信开销尤其是个问题。在专家并行场景下，token 需要在 GPU 之间来回传输，如果通信带宽不够，计算省下来的时间可能还不够通信消耗的。这也是为什么 MoE 在单机多卡场景下表现好，跨机场景下优势不明显。

7.2 效果与效率的平衡

MoE 不是万能的。它的优势在于"用更少的计算达到相近的效果"，但这个"相近"是有条件的。在某些任务上，MoE 的效果可能不如同等参数量的稠密模型，因为稀疏激活限制了模型的表达能力。

另外，MoE 的推理延迟不一定比稠密模型低。虽然计算量小了，但动态路由和专家调度有额外开销。在低延迟场景下，这个开销可能抵消计算量的优势。

7.3 值得关注的新方向

MoE 领域还在快速发展，几个值得关注的方向：

软 MoE：不用硬性的 Top-K 选择，而是用软权重让所有专家都参与。这样训练更稳定，但计算量降不下来。最近有一些工作在用低秩近似来降低软 MoE 的计算成本。

动态专家数量：根据 token 的难度动态调整激活的专家数量。简单 token 走一个专家，复杂 token 走多个专家。这样能更精细地分配计算资源。

跨层共享专家：不同层共享一部分专家，减少总参数量。这对显存优化有帮助，但可能影响效果。

MoE + 量化：把专家参数量化到低精度，进一步降低显存需求。这个方向工程价值很大，已经有一些实践案例。

我在实际项目里最深的体会是，MoE 不是一个"即插即用"的优化，而是一套需要整体设计的架构方案。从训练到推理，从显存管理到负载均衡，每个环节都要仔细考虑。如果只是简单地把 FFN 换成 MoE，很可能效果不如预期，还引入一堆工程问题。

但如果你愿意投入精力去调优，MoE 带来的收益是实实在在的。尤其是在推理成本敏感的场景下，MoE 能让你用更少的 GPU 跑更大的模型，这个性价比是稠密模型很难达到的。