混合专家模型（MoE）核心解析：稀疏激活、路由机制与工程实践

最近好几拨做模型训练的朋友都在问同一个问题：开源模型技术报告里“总参数”越报越大，显卡上却还跑得动，参数表和显存需求对不上。答案十有八九是 MoE。混合专家模型（Mixture of Experts）这名字听起来很唬人，实际拆开就是一句大白话：模型总参数可以很大，但每个输入 token 只激活其中一小部分“专家”参数来计算。这个思路不是这两年才冒出来的，只是大模型算力紧张以后，它成了扩大模型容量最实用的手段。这篇文章不准备堆一堆劝退公式，主要按我自己的理解，把 MoE 为什么能省计算、路由怎么给 token 分派专家、训练和推理要注意什么，以及什么情况下不如老老实实堆 Dense 模型，统一过一遍。适合的人：正在做模型选型、准备做 MoE 微调、或者想从零搭一个小规模 MoE 实验的工程师同学。还没接触过 Transformer 的读者建议先补一下基础再来读。

1. MoE 到底是什么：从“全栈员工”到“专家团队”

1.1 稀疏激活：模型变“胖”，计算量没有跟着“胖”

普通 Transformer 的 FFN 层，对所有 token 用同一套参数，这就是 Dense 模型。假设模型有 700 亿参数，中间那些 FFN 权重对每个 token 都得完整算一遍，所以训练和推理成本基本跟着参数线性走。MoE 的做法则是：把某些 FFN 层改造成“一组专家”，每个专家是一套独立 FFN，旁边再配一个路由模块。输入 token 到达这一层时，先看它的 hidden state，挑出少数几个专家，只算这几个专家的 FFN，其他专家在这次前向计算里直接当作不存在。

稀疏激活是 MoE 的核心性质。模型“总参数量”可以做到几百 B，但单次前向真正参与计算的“激活参数”可能只有十几 B 甚至几 B。这就好比一间公司注册了 800 名员工，但一张工单真正被调来干活的可能只有几个人，剩下的人照常坐工位、领工资（占显存），但在你这张工单上不产出。这也是为什么很多模型参数表写的是“总参数 XXXB，激活参数 XXB”，而不是一个数。

为什么这种设计能装下更多知识？Dense 模型每加一批参数，就要让所有 token 把新参数都过一遍，训练成本直接爆炸；MoE 加一批专家，只影响被路由选中的那一部分 token，训练成本增长远比参数增长慢。知识容量跟着总参数量走，计算成本跟着激活参数走，两者解耦之后，才可能在单卡算力有限的情况下把模型塞进更大的容量。我在训练中反复体会到的就是这一条：MoE 省的是算力，不是内存，这一点后面部署部分还会重点讲。

1.2 路由决策与加权输出：一次前向计算到底发生了什么

一个 MoE 层的前向流程并不复杂。输入向量 x 先经过门控网络，门控通常是一个线性层加 softmax，输出每个专家的概率分布。接着取概率最高的前 K 个专家（常见 K=2），把 x 分别送进这些专家各自的 FFN 里做变换，得到多个专家输出。最后用路由概率作为权重，对这些专家输出做加权求和，得到这一层的最终输出。专家之间的计算完全独立，所以天然可以并行；所谓 dispatch 和 combine，就是把 token 按照路由决定分发到对应专家所在的设备，算完再把结果收回来拼回去。

训练阶段还有个容易忽略的细节：gate 在计算 logits 时会加一点噪声。这个噪声的目的是探索，避免 router 在非常早的 step 就锁死在某几个专家上，导致其他专家永远没机会学。等 warmup 阶段结束，再逐步把噪声撤掉，路由才开始真正进入“精细化分工”的状态。很多从零实现 MoE 的人漏了这一步，结果 router 提前固化，模型后期的表现上限直接被锁死。

1.3 MoE 真正解决的痛点：参数容量、训练成本与推理的三角

Dense 模型的痛苦在于一个三角矛盾：想提升效果就加参数，加参数就要更多算力、更多显存、更大 batch。MoE 把容量和计算解耦之后，总参数涨了，单位 token 的计算量只涨一点；但显存需求仍然跟总参数量走，所以它解决的是“更多知识”和“有限算力”这一对矛盾，而不是“更小显存”这个矛盾。对训练集群来说，稀疏激活能大幅减少每 token 的 FLOPs，让更大 batch 成为可能，这又是训练稳定性的额外红利。

代价也藏在三个方面。第一，路由机制要学会“正确分配专家”，这本身需要训练时间；第二，专家被切到多卡之后，通信开销不可忽略；第三，负载不均衡会导致部分专家“饿死”，整体模型白训练。后面几节基本就是围绕这三个代价展开的。

2. 路由机制与专家选择：MoE 的调度中心是怎么干活的

2.1 Gating Network：给每个 token 打分

路由模块本质上就是一层线性层，输入是 token 的 hidden state，输出是每个专家的 logits。维度一般是 hidden_size × num_experts。得到 logits 后做 softmax，变成每个专家被选中的概率。实际选择时，并不一定非要用 softmax 之后的概率来排序，直接用 logits 排序结果也一样，因为顺序一致；但最终输出加权时要用 softmax 后的归一化权重，这样才能保证总权重为 1，输出尺度稳定。

训练时加在 logits 上的噪声，常见做法是加一个标准正态分布噪声乘以一个很小的 scale，scale 可以取 0.01 到 0.1。scale 越大，探索越强，router 初期越“乱跳”；后期逐步关掉或调小，让选择稳定下来。我见过一个开源实现里把噪声 scale 做成 schedule，warmup 阶段 0.1，后续线性降到 0，实测比固定噪声更稳。比较省事的做法是先固定 0.01，等模型训练几千步后再手动关掉，也能跑出正常效果。

2.2 Top-K 选择：为什么是 K=2 而不是 K=全部

Top-1 最简单，计算量最小，但训练稳定性差。因为选出的单个专家会承担非常强的梯度更新，一旦选错，优化方向就剧烈抖动。K 如果太大，比如 K=8，等于所有专家都参与计算，稀疏激活名存实亡，计算量回归 Dense 水平，还多出路由和通信开销。Top-K 还直接影响通信量，选中的专家越多，每个 token 需要 dispatch 和 combine 的数据就越多，跨卡传输的次数也成倍增加。

为什么 K=2 成为普遍折中？两个专家的输出可以做一个简单的软组合，比单独一个专家容忍更多噪声，梯度平滑一些；同时两路并行只比一路多一份专家计算，卡在可控范围内。多个实验和工程实践都指向同一个结论：从 K=2 再往上加，质量提升很有限，计算成本却明显上涨。所以“2”更多是工程与稳定性的妥协，而不是理论最优解。如果你在代码里看到有人设 K=4，先别急着批判，得看他专家的粒度是不是已经拆得非常细，此时多一两个被选专家可能是在弥补单专家容量太小的问题。

2.3 辅助平衡损失：防止专家“饿死”和“撑死”

完全没有约束时，路由大概率会把大部分 token 送进少数几个专家，其他专家形同虚设。这是无监督优化里典型的“富者愈富”：被选中越多的专家，梯度越充分，能力越好，于是又被选得更多；没被选中的专家一直拿不到有效梯度，停在随机初始化附近。最后整个模型的容量被浪费了大半。

为了解决这个问题，业界几乎统一加一个辅助平衡损失。常见设计：统计一个 batch 内每个专家被选中的概率均值 f_i，再乘上路由分配给它的平均概率 P_i，求乘积和。这个值越小，说明“谁被选得多谁就被分配高概率”这样互相强化的关系越弱，均衡性越好。实际代码里会给它乘一个很小的系数，典型值 0.01 左右，叠加到主损失上。

这个系数非常需要手工调。我一开始图省事设过 0.1，结果专家之间确实均衡了，但整体 loss 明显变差，因为强约束牺牲了路由的分配性能。后来降到 0.01 附近才找到平衡点。原则很简单：路由明显塌缩就调大，模型精度下降就调小。

2.4 专家容量与 Token 丢弃：容易被忽略的隐性开关

每个专家的处理能力是有上限的。代码里通常用 capacity 来表示：

capacity = ceil(batch_tokens / num_experts) × capacity_factor

如果某个专家被分到的 token 数超过 capacity，超出的 token 要么被丢弃，要么就地排队等待。被丢弃的 token 通常会直接走残差旁路，也就是把这一层当成没有专家 FFN，只保留 attention 之后输入本身。capacity_factor=1.0 意味着每个专家最多只能承接平均接单量，这几乎必然导致丢弃，因为路由分布不可能完美均衡；调到 1.25 到 1.5 能显著减少丢弃，但会占用更多显存和计算资源。

这个参数藏得很深。很多人调 MoE 调了半天 loss 不对劲，最后发现是 capacity 设置的问题。尤其是把专家数从 8 改成 64 时，batch 内每个专家平均分配到的 token 变少了很多，capacity_factor 如果不调整，丢弃行为会完全改变模型表现。我自己训练时会在日志里单独打印一个 token 丢弃率指标，要求它稳定在 1% 以内；一旦发现连续出现大批量 token 被丢弃，优先提高 capacity_factor 或者增强辅助平衡损失的权重。

3. 进阶设计：细粒度专家、共享专家与路由改进

3.1 细粒度专家：把专家拆小，组合更灵活

经典 MoE 把整个 FFN 当一个专家。这种设计下，单个专家内部参数很多，但一次只能选两个，等于把“全科医生”派去处理所有类型的 token，粒度太粗。细粒度专家则是把专家拆小：比如原先专家 FFN 的中间层维度是 4096，拆成 8 个小专家、每个中间层维度 512。总参数量基本不变，但路由每次能在更多候选者里挑两个。这样不同专家可以专精更具体的模式，组合起来也更灵活。

细粒度带来的收益本质上是“组合爆炸”。假设你有 N 个小专家，每次选 2 个，可能的组合数是 O(N²) 量级，远大于原来 4 个大专家选 2 个的组合数。语义空间被切得更细，token 的分派颗粒度也更高。代价是路由计算量增加、专家之间的通信量增加。所以不是拆得越细越好，一般要在实验里观察效果变化，通常在收益曲线变平时停止继续增大专家数量。

3.2 共享专家：常设的“公共知识库”

Top-2 路由的特点就是每个 token 只走极少专家，这会带来一个问题：语言模型里有大量非常通用的知识，比如基础句法、因果常识、通用推理模式，如果这些也要靠路由专家去处理，那所有 token 都在为这些共性反复选择专家，路由容量被白白消耗。共享专家的思路是：设置一个不参与路由的专家，每个 token 进来都固定经过它，它就像公司的公共行政部，所有人都能调用。然后再额外路由几个专家，负责领域和语义差异。

实现上，共享专家可以直接放在 MoE 层里作为固定路径，也可以把它的输出叠加在路由专家的加权和后面。效果上，共享专家让模型更稳定，因为它保证了每个 token 至少有一条基础计算路径，不依赖路由质量；同时把路由专家解放出来，让它们更专注做差异化分工。现在很多开源模型里的“共享专家”变体已经快成为标配，不是偶然，它确实解决了 Top-2 稀疏路由在强通用任务上的短板。

3.3 部分层 MoE：不是每一层都需要专家化

有些实现不会把每个 FFN 都替换成 MoE，而是挑一部分层放路由专家。浅层主要负责通用特征抽取，语义标签差异不明显，专家化收益低，反而增加成本和通信压力；深层特征更抽象、更接近最终任务语义，路由器更容易学到有意义的分工。具体放多少层、从第几层开始，取决于任务和模型规模。我做过一个实验：12 层 Transformer 只把最后 6 层改成 MoE，和全部层改成 MoE 相比，效果非常接近，训练成本却省下不少。这属于典型的“用稀疏换通信”思路，对中等规模模型很实用。

3.4 从 Dense 权重升级到 MoE：一种省钱的探索路径

如果手里已经有一个训练好的 Dense 模型，想尝试 MoE 但不想从头预训练，可以考虑“复制扩展”：把 Dense 的 FFN 权重复制成好几份，作为多个专家的初始权重，再给每份权重加微小噪声打破对称性；路由器模块随机初始化。这样模型在训练初期基本等价于原来的 Dense 模型，之后再通过继续训练让专家逐渐分化。这个办法省掉了从零预训练的大部分成本，路由一开始也不至于因为完全没有先验知识而乱选。

不过要注意：初始相同的专家在早期梯度完全一样，如果噪声太小，专家分化会很慢；噪声太大，模型又容易被带偏。我实测下来，初始噪声 scale 在 0.01 到 0.05 之间比较安全，同时要让 router 在前几百步保持较高探索强度，否则复制出来的专家很可能长期处在“同质化”状态。

4. 工程落地：我实测下来的 MoE 训练与部署注意点

4.1 训练阶段：显存与通信为什么会猛增

Dense 模型训练时，每个参数和它的优化器状态都留在本地，梯度是局部的；MoE 不同，因为专家会被切到不同 GPU 上，一个 token 的 hidden state 要 dispatch 到专家所在设备计算，再把结果 combine 回来。这种通信在代码里通常表现为 all-to-all 通信，也就是说每个设备都要给其他设备发数据，也都要收数据。GPU 数量越多，通信图的规模越大，小 batch 时通信占比甚至能到三到四成。

显存开销也比直观预期高：专家参数本身、优化器状态、梯度，这些都要跟着专家分布存储，跨节点同步更麻烦。我遇到最典型的认知偏差是，以为 MoE 稀疏激活能省显存，实际单卡显存需求几乎等于总参数量。省的是算力，不是内存。所以训练 MoE 时，通信框架和显存规划往往比模型结构本身更影响效率。

4.2 推理部署：计算省了，内存没省

推理阶段也一样，模型总参数量决定了最低显存门槛。一张 80GB 的卡，FP16 精度下能加载的模型总参数量上限大约 40B，跟它是不是 MoE 没什么关系。每个 token 虽然只算两个专家，但加载模型时，所有专家权重都已经驻留在显存里。换句话说，计算瓶颈降了，内存和带宽瓶颈原样保留。

工程结论就是：MoE 适合能够攒大批量再统一跑的场景，比如离线批量推理、服务端高并发；不适合单条短请求要求极低延迟或单卡小显存部署的场景。KV Cache 方面，因为 attention 部分通常还是共享的，序列越长，attention 的 KV 占比越高，这一点和 Dense 模型差不多；FFN 计算占比下降之后，attention 计算反而可能变成相对瓶颈。所以不能说“MoE 一定更快”，关键看具体业务请求形态。我踩过的一个坑是，在短请求高并发场景硬上 MoE，结果因为每次都要跨卡通信，延迟反而比 Dense 高了一截。

4.3 实验期最值得盯的三个指标

训练 MoE 不要只看 loss 曲线。我建议至少在日志里记录三样东西：

• 专家利用率：每个专家最近一个 batch 里被选中的 token 数，按专家画柱状图。理想情况是分布相对均匀，不要出现某个专家是 0 或者独占 80% 的情况。
• 路由熵：对每个 batch 的专家概率分布求熵。熵掉得太快说明路由早早固化，后期很难再分化；熵一直很高则说明路由没有学到有效分工，专家都在“摸鱼”。
• 丢弃率：每个 batch 里因为 capacity 限制被丢掉的 token 比例。这个数字比 loss 更能直接反映 capacity_factor 设置是否合理。

这三个指标最好同步记录。我有一次就是只看 loss，觉得曲线很正常，后来看了眼专家利用率才发现四个专家里有三个已经长时间“失业”，只是剩下那一个专家勉勉强强把 loss 扛住了。如果不看利用率，这种模型训练到一半时，等于是花着 MoE 的钱在跑一个比 Dense 还差的效果。

5. 常见问题与排查技巧实录

实际训练 MoE 的过程中，下面这几个问题出现频率非常高，我把症状和排查思路整理成了一张速查表。

路由坍缩是最常见也是最隐蔽的问题。修它的第一步不是调模型，而是先确认数据有没有偏差，比如某类 token 占比过高。第二步是看 aux loss 是不是被主 loss 淹没了，打开日志确认它是否在正常下降。第三步再调大系数。我自己的经验是：先小幅调大到 0.02 观察 200 步，如果专家利用率还是极端，再继续调；一次跳太多容易把模型精度打崩。

微调 MoE 导致“变笨”这件事也值得单独讲。MoE 的预训练知识分布在专家权重里，Router 的分配模式其实是这些知识的重要索引。如果全量微调时所有参数都放开，路由分布很容易被新任务带偏，导致新数据进来时模型调用了一组错误专家。比较好的做法是在微调阶段冻结非专家层，只让 router、共享专家和小部分低秩适配参数可学习。这样新任务能调整路由偏好，但不会把底层语言能力破坏掉。

6. 选型思考与经验总结：什么时候才该上 MoE

6.1 适合与不适合 MoE 的场景

这里多说一句：MoE 并不适合所有任务。如果领域数据量小、任务非常单一，那路由能学到的分工空间很有限，加一堆专家只会增加训练成本和过拟合风险。更直白地说，MoE 的价值前提是“数据的多样性足够高”。数据不够多样时，MoE 和 Dense 效果差距不大，但工程复杂度明显更高。

6.2 从零开始做 MoE 实验的建议路径

如果你没有跑过 MoE，我建议按这条路径走，而不是直接拿一个超大模型开练：

1. 先有一个小规模 Transformer 基座，能正常跑通语言建模任务。
2. 挑其中几层 FFN 替换成 MoE 层。
3. 初始配置用 num_experts=8，top_k=2，capacity_factor=1.25，aux_loss_coef=0.01。
4. 训练过程中持续记录专家利用率、丢弃率和路由熵。
5. 拿同一份数据和同样的训练步数，跟 Dense 基线做对比。你可能看到 MoE 前几百步 loss 稍差，这是路由器在探索，正常；如果 loss 始终追不平，去查负载均衡配置。
6. 路由健康之后再逐步加专家数量、加细粒度拆分、再加共享专家。

一个比较省心的初始配置可以长这样：

num_experts: 8 top_k: 2 expert_intermediate_size: 1024 capacity_factor: 1.25 aux_loss_coef: 0.01 router_noise_scale: 0.01

这套配置在中小规模模型上一般不会出大问题，之后再根据监控指标微调。

6.3 一点真实体会

我一开始做 MoE 实验时有一个误区，以为 MoE 是一种“更聪明的神经网络层”，只要把 FFN 换成专家池，效果就会自动变好。实际跑了几轮才发现，MoE 更像一个分布式系统问题——你把模型切成很多专家，真正要管理的是如何让每个专家都有活干，如何让通信不拖后腿，如何让梯度不因稀疏而剧烈抖动。路由、容量、负载均衡这三件事，每调一个都会牵动另外两个。如果你准备接触 MoE，我的建议是别急着堆参数，先用小模型把这三个指标调明白，再迁移到大模型上会顺畅很多。