2023年年底 Mixtral 8x7B 发布之后“MoE”这个词几乎成了大模型群里讨论最多的话题。很多人第一次意识到大模型不一定只能靠“往参数堆里砸算力”还有一条叫“混合专家模型”的路——总参数看着很大但每次跑数据只激活其中一小部分专家。这里说的就是 MoE全称 Mixture of Experts混合专家模型。大模型原理里它是我觉得最绕也最容易被误读的架构之一你以为它是“多模型配合”其实是“门控路由的稀疏激活”你以为它能省钱省显存实际它省的是计算量显存反而不设免。这篇内容我会从路由机制、专家容量、负载均衡讲起再落到训练配置和推理踩坑给正在做大模型训推、或者想真正搞懂 MoE 架构的读者一条完整的实操路径。1. MoE 是什么先搞清楚它解决了什么问题1.1 从“全员参战”到“精英小组”先看普通 Dense 模型也就是传统密集模型。一个 token 进来了从第一层 Transformer 到最后输出层所有参数都得过一遍。参数翻倍计算量基本就跟着翻倍175B 的模型每次跑一个 token 都等于做一次 175B 参数的完整乘加。这个模式的好处是结构简单、显存好预估、并行起来不费心思但坏处也明显当你想要模型“更聪明”时单纯把参数堆上去训练和推理成本都会飞速上涨。MoE 的思路则是反着来的不搞全员参战而是把模型切成一组“专家”每个专家负责处理某一类特征或模式。每次来一个 token先由一个路由网络判断该让哪些专家来处理再把 token 分过去最后把专家输出加权合到一起。换句话说总参数量可以很大但每次真正参与计算的可能只有其中一小部分。我习惯拿医院分诊来打比方。Dense 模型相当于每个患者来了全医院的科室医生都围上去看一遍虽然也会把病看好但大量医生是在陪跑。MoE 则是一个经验丰富的分诊台根据病症直接把患者分给心内科、骨科或皮肤科只需要少数几个科室参与。医院的医生总数很多每个患者实际只需要极少数的医生服务这就是参数量和计算量解耦的感觉。不过这个类比只能停在宏观层面。真正容易误解的点是MoE 不是“训练了几个大模型然后让它们投票”而是在模型内部的 FFN 层上的“异步专家分工”。你在模型结构里看到的不是一整块前馈网络而是 N 个平行的同构专家模块谁被激活取决于路由器怎么分配。这也是为什么它被称为“稀疏专家模型”每次计算的路径是稀疏的只有少数专家参与。1.2 核心三件套路由、专家、负载均衡一个典型的 MoE 层有三个关键部分。第一部分是路由器也叫门控网络或 Gate通常是一个线性层加 Softmax负责给每个专家打分并决定 token 去哪个专家。第二部分是一组专家网络Expert通常是多个结构相同的 FFN但在个别实现中专家之间也可能存在差异化的结构设计。第三部分是负载均衡机制最常用的是辅助损失aux loss也有通过容量限制、专家 Token 上限等方式实现目的是避免所有 token 都挤向同一个专家。MoE 并不是什么新概念。2017 年 Shazeer 等人的 Sparsely-Gated Mixture-of-Experts 那篇论文就把稀疏门控机制引入了语言模型2020 年 GShard 把它推向大规模机器翻译2022 年 Switch Transformer 提出 Top-1 路由把路由成本降到最低也把 MoE 的规模做到了万亿级参数再到 2023 年 Mixtral 8x7B 开源大家才发现 MoE 不仅能训、能推而且普通开发者在本地也能跑起来热度一下就上来了。为什么前几年 MoE 一直没成为主流我的看法是它不缺数学原理缺的是工程配套。MoE 计算时的通信模式是 all-to-all 的token 要根据路由结果在不同专家之间传输这让并行训练变得复杂。2017 年大家还在用单卡训小模型MoE 的优势发挥不出来直到多卡数据并行、专家并行这些框架成熟之后MoE 才真正成为能落地的方案。这也是为什么理解 MoE 不能只盯着数学公式还要理解它的工程成本。2. 核心机制拆解路由器、专家与容量限制2.1 路由网络的 top-k 选择流程路由这件事听起来像最上层的一个“调度器”实际它在每一个 MoE 层里都会做一次。对于输入的每个 token假设它的 hidden state 是 x先通过一个可学习的权重矩阵 W_g 计算出它和每个专家的匹配分数然后对这些分数做 Softmax 得到概率分布最后只保留概率最高的 top-k 个专家把 token 分发过去。我在给团队讲这个问题时习惯用一个很简化的伪代码。假设我们只需要路由逻辑不考虑训练时的噪声门控import torch import torch.nn.functional as F def moe_route(x, router_weight, num_experts8, top_k2): # x: [batch, hidden_dim] logits x router_weight.t() # [batch, num_experts] probs F.softmax(logits, dim-1) # 取 top-k 个专家 top_probs, top_idx probs.topk(top_k, dim-1) # 重新归一化保证选中的专家权重和为 1 top_probs top_probs / top_probs.sum(dim-1, keepdimTrue) return top_idx, top_probs最后的重新归一化很多人会漏。如果不做这步选中两个专家时每个专家都带着原始概率合并输出时权重和不是 1输出向量的尺度会漂移模型很难稳定。选 top-2 而不是 top-1也不是为了“多个专家一起算更准”更关键的是梯度路径更平滑、路由决策更不容易断层。Switch Transformer 用 top-1 是为了极致的计算效率但 Mixtral 用的 top-2 在不少下游任务上效果更好代价是多算一个专家理论上推理成本也接近翻倍。另一个必须知道的细节是路由决策是 token 粒度的不是句子粒度的。同一个句子里的不同 token完全可能被路由到不同的专家。你可以观察一下训练日志里的路由分布有些 token 会连续几层都去同一个专家有些 token 每层都在变。这也是 MoE 模型“多样性”的一个重要来源。训练时还有一个经验性技巧在路由分数上加噪声。这个做法来自 2017 年的 Noisy Top-k Gating训练阶段给每个专家分数加一点高斯噪声让路由策略在早期多探索、少扎堆防止一上来就收敛到某个专家。推理阶段要去掉噪声否则路由结果不稳定Token 容易被分到错误专家。2.2 专家容量与 Token 丢弃稀疏是有代价的理论上路由网络想怎么分就怎么分但物理硬件不是这么想的。如果连续来了一批 token全都涌向同一个专家那么这一个专家会瞬间算到爆其他专家在旁边空看计算负载极不均匀。GPU 是并行设备最怕这种“热点”效应一出现热点整体吞吐马上被最繁忙的专家卡住。所以 MoE 层会规定每个专家的容量上限。常见的公式很粗暴capacity capacity_factor × (batch 内总 token 数 / 专家数量)如果 capacity_factor 设为 1.0对应的就是“所有 token 被完全均匀分配到专家”时的理想状态。但实际路由不可能这么均衡所以一般会留一点余量设成 1.25 或 1.5。这也解释了为什么 Switch Transformer 会在切分 token 时触发“丢弃”当一个专家已经达到容量上限时超出的 token 就不再进入这个专家而是直接跳过该层把输入通过残差连接送到下一层。这里的水很深。token 丢弃在训练时会造成信息损失如果丢弃率常年保持在 5% 以上你会看到 loss 明显偏高模型能力也会打折扣。想压缩计算成本把 capacity_factor 强行压到 1.0看起来每次计算量小了但丢包率飙升最后模型质量可能还不如一个稍小的 Dense 模型。实际操作中我会先观察训练集的 token 丢弃率把这个指标当成 MoE 训练健康度的晴雨表如果超过 3%5%优先提升 capacity_factor而不是硬调路由损失。还有一种思路是“专家选择”Expert ChoiceEC。普通 MoE 是 token 去找专家EC 反过来每个专家在所有 token 里挑选自己最擅长的 top-k 个。这样做的好处是彻底消灭 token 丢弃因为每个专家总能选到足够数量的 token坏处是一个 token 可能被多个专家同时选中需要额外的 all-to-all 通信实现也更复杂。目前在长文本、多模态等领域EC 思路被不少模型采用但它也谈不上是银弹通信开销和路由可解释性都需要权衡。2.3 负载均衡为什么非加 aux loss 不可如果不做额外约束MoE 训练过程中最典型的问题就是“专家坍缩”模型越学路由网络越倾向于把大部分 token 交给同一个专家其他专家几乎拿不到梯度形同虚设。我见过最极端的情况是某个 8 专家模型里一个专家吃掉了 80% 的 token剩下 7 个专家像摆设。解决办法很直接在损失函数里加一项辅助负载均衡损失也就是 aux loss。Switch Transformer 给出的经典形式大致是aux_loss α × N × Σ (f_i × P_i)其中 f_i 是第 i 个专家实际接收的 token 占比P_i 是路由网络给第 i 个专家的平均概率。如果某个专家又经常被选中f_i 大、门控给它的概率又高P_i 大乘积就会被拉高loss 就会惩罚这种扎堆现象。均匀分布时 f_i 和 P_i 都接近 1/N乘积的累加值很小对整个损失影响不大。α 通常取 1e-3 到 1e-2 之间太大容易干扰主任务学习太小起不到均衡作用。后来 DeepSeek-V3 这类模型又在负载均衡上做了迭代除了 aux loss还引入了一个 Router Z-Loss。这个损失是对路由 logits 做 logsumexp 的平方惩罚主要作用是抑制路由分数过大、Softmax 概率过于尖锐的问题。路由分数一旦爆炸模型对“选哪个专家”特别自信后续微调时很容易震荡加了这个约束后训练更稳。我的建议是如果你在训练 MoE 时发现 warmup 阶段 loss 波动特别大先把 Router Z-Loss 加上很多诡异的不收敛问题会好很多。另一个值得记下来的趋势是“细粒度专家 共享专家”。这个设计和传统 MoE 不太一样传统 MoE 所有专家都是路由选择的而新一代模型会在 MoE 层里单独放一个共享专家无论什么 token 来都会激活公共知识全由它承接同时把剩余专家切得更细专门处理token 之间的差异化信息。共享专家存在的逻辑是所有 token 都有一部分“共性知识”让它们每次都去争抢路由专家既浪费容量又增加负载均衡难度。把这些公共部分抽出来单独放路由专家的分工反而更清晰。3. 实操怎么训一个能用的 MoE 模型3.1 关键超参数先抄一套能跑的配置我在刚开始做 MoE 实验时最大的问题不是不理解原理而是不知道超参数从哪下手。后来反复试下来一个适合“小规模验证”的配置大概是这样的模型总参数量控制在 1B 以内设置 8 个专家每个 token 激活 top-2 专家容量因子设 1.25辅助损失系数设 0.01配合 3% 左右的共享专家参数量。这个组合在中等规模的公开数据集上能比较稳定地训练适合用来摸清行为。举个例子假设一个 batch 里面有 1024 条样本每条样本长度是 512那总的 token 数就是 524288。8 个专家均匀分的话每个专家理论上接收 65536 个 token容量因子设成 1.25实际容量就是 81920。这样即使某些专家稍稍“热门”也不会马上触发大范围 token 丢弃。关于 top-k 的选择我有两个判断维度。如果目标是评估“稀疏激活是否有效”top-2 是最好的起点如果目标是把推理成本压到极致再考虑 top-1。从训练稳定性看top-2 比 top-1 好太多因为梯度至少有两条路径回流不至于出现某层“一条路走到底”的情况。容量因子则不要一开始就追求极致我会先设 1.5 跑通一轮看丢包率正常之后再逐步下调到 1.25 甚至 1.125。省那点计算量不值得用收敛性来赌。分布式并行也要在配置阶段想好。如果是单机多卡最常用的是数据并行 专家并行组合encoder/attention 部分和数据并行MoE 层的专家被分布到不同卡上。这样能解决单卡放不下全部专家的问题但每次 token 路由都会产生跨卡通信。所以配置时比较重要的一个动作是把专家数量和控制通信次数的组数配置好别让通信变成瓶颈。超参数推荐范围备注num_experts8 ~ 128先小后大路由难度随专家数上升top_k1 / 2top-2 更稳top-1 更省算力capacity_factor1.0 ~ 2.0从 1.25 起步观察丢弃率aux_loss_coef1e-3 ~ 1e-2太小坍缩太大会干扰主任务路由温度1.0 ~ 2.0训练初期可稍大帮助探索共享专家比例0% ~ 5%较大模型更适合加共享专家3.2 训练中常见的翻车点第一个坑是“死专家”。你训练到一半发现某些专家几乎没有被路由到这类专家长期拿不到梯度参数就不会再更新。排查时我习惯把每个专家被选中的次数画成直方图看到有专家长期挂零就需要干预。简单粗暴的做法是在路由打分上给这些死专家加一个正的偏置让它们短暂“复活”更温和的做法是在训练早期加入更大强度的路由噪声让初始探索更充分。死专家一旦出现后续如果要删除它模型能力通常会有明显波动所以尽量在训练早期就盯住分布。第二个坑是 loss 震荡。MoE 的训练有两个互相影响的系统路由网络在学“怎么分配 token”专家网络在学“怎么处理好被分配到的 token”。两者相互依赖有时会出现来回震荡。我的一个经验是不要同时大幅调整负载均衡系数和容量因子这两个东西强相关。比如你把 capacity_factor 从 1.5 降到 1.25会让一批 token 被丢弃损失上升是正常的这时候如果又去调 aux_loss 系数loss 曲线很容易失控。第三个坑和并行有关。训练 MoE 时专家并行会带来通信开销这个问题在数学上不体现但会在实测时间上体现。我试过一次把 32 个专家分布到 16 张卡上每个专家本来应该很轻松但因为跨卡通信频繁单次 step 的时间反而比数据并行还长。所以并行策略不是“专家越多越好”要结合模型尺寸、带宽和 batch 大小一起看。如果不想上来就碰专家并行可以先在单卡或两台机上用小规模模型跑把路由行为摸清楚再说。3.3 推理端降本显存、调度与量化很多刚接触 MoE 的人会有一个错觉“既然只激活 2 个专家那显存是不是也只要原来的 2/8”这个误解很危险。MoE 的稀疏性节省的是计算量不是存储量。部署时所有专家的权重都必须常驻显存因为不知道下一秒哪个 token 会路由到哪个专家。Mixtral 8x7B 总参数接近 47B即使单次激活只有约 13B部署显存依然按 47B 算。但在批量推理场景下MoE 的优势非常实在。由于每个 token 分给不同专家batch 越大每个专家都能被填得越满算力利用率越高。换句话说MoE 特别适合高并发、大吞吐场景如果是单条请求低延迟交互调度和权重驻留的代价会更明显。框架选择上现在已经有很多推理框架支持 MoE 优化vLLM、SGLang、TensorRT-LLM 都陆续推进了相关能力。我的建议是不要裸写 PyTorch 推理否则很可能变成“逐个专家串行计算”稀疏优势全部丢失。量化是省显存的主要手段。把路由专家压到 INT8 或 INT4 很常见但路由器参数我建议保留较高精度或者单独做混合精度。原因很简单路由是入口如果路由判断出错token 去了错误的专家后面模型能力会有雪崩式下降比单纯降低专家权重精度伤害大得多。每次量化完都要用一份固定的校准数据跑一遍指标对比不要只看显存量降了就觉得成功。还有一个实战技巧是 MoE Upcycling。如果你已经有一个训练成熟的 Dense 模型可以把它当成初始化基础把 FFN 复制成多个专家再用 MoE 继续训练。这个过程比从随机初始化训练 MoE 快非常多适合在算力有限的时候快速验证 MoE 能带来多少收益。我自己做实验时先用一个 5B 的 Dense 模型 upcycling 成 8 专家的 MoE只用了原来 1/3 的预算就看到了明显的效果提升。4. 选型与避坑什么时候该上 MoE4.1 算算收益账数据量和场景是否撑得起稀疏MoE 不是模型越大越好它有一个重要前提数据量要足够。专家变多意味着每个专家的参数被“稀释”了如果训练 token 很少每个专家学到的东西反而不如一个同等规模的 Dense 模型扎实。我在固定 token 预算下对比过 Dense 和 MoE当训练数据只有几十亿 token 时MoE 往往打不过 Dense当数据量涨到几百亿甚至更多MoE 的潜力才逐渐拉开。所以如果你的预算有限不要因为“MoE 很火”就硬上。另一个判断维度是任务分布。如果业务数据本质上差异很大比如多语种混合、多行业混合MoE 的特化能力会很值钱——不同专家天然可以学习不同子分布的模式如果任务分布非常单一所有 token 都长得差不多路由网络找不到好的分工最终可能只是在反复利用少数几个专家。还要看服务方式。在线高并发场景MoE 的吞吐优势能直接兑换成成本优势但离线批量跑一条长文档路由调度和通信开销占比会上升。建议先用一个 1B 量级的小 MoE 在你的真实数据上做三天实验看训练 loss 和下游指标的趋势再决定要不要在大模型上铺开。4.2 快速决策速查表场景更推荐原因千亿参数级训练 高并发推理MoE同样的总参数下计算量低吞吐优势明显移动端 / 边缘设备部署DenseMoE 权重驻留多框架支持不如 Dense 成熟单路低延迟交互不一定需要实测router 和权重驻留可能拖慢训练 token 极少50BDense专家数据不足稀疏收益不明显多语种、多领域混合数据MoE专家可分而治之摆脱互相干扰团队没有多卡/高速通信环境谨慎 MoE专家并行会引入严重通信瓶颈4.3 我踩过的坑和一条可复现的验证路径我早期做 MoE 时第一个模型训练到一半就“坍缩”了aux loss 和容量都调过还是没有恢复。后来复盘发现问题出在训练初期路由噪声太小模型一开始就扎堆选专家后面想掰回来已经太难。第二次实验把噪声强度调大训练稳定了很多。所以“早期探索”比“后期纠偏”重要得多。还有一个错觉是“专家越多能力越强”。我试过同样总参数量下从 4 个专家增加到 16 个专家模型效果并不是线性提升反而因为路由难学和通信开销导致收敛变慢。专家的理想数量取决于你有多少数据、任务分布是否多样而不取决于一个拍脑袋的数字。如果你不确定先从 8 个专家开始把训练稳定之后再翻倍对比。如果要我给出一条可复现的验证路径那就是准备一份中等规模的任务集把 Dense 模型跑到底线再用 MoE 在相同 token 预算下从零训练第三步用 Dense checkpoint 做 MoE upcycling。三条路径出来的模型放同一套评测集上比较基本能算出 MoE 在你自己业务数据上的真实收益。这个流程看起来笨但比我见过的任何“这个模型效果好”的传言都靠谱。