★ FEATURED ARTICLE 最近好几拨做模型训练的朋友都在问同一个问题开源模型技术报告里“总参数”越报越大显卡上却还跑得动参数表和显存需求对不上。答案十有八九是 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 个专家常见 K2把 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 上的噪声常见做法是加一个标准正态分布噪声乘以一个很小的 scalescale 可以取 0.01 到 0.1。scale 越大探索越强router 初期越“乱跳”后期逐步关掉或调小让选择稳定下来。我见过一个开源实现里把噪声 scale 做成 schedulewarmup 阶段 0.1后续线性降到 0实测比固定噪声更稳。比较省事的做法是先固定 0.01等模型训练几千步后再手动关掉也能跑出正常效果。2.2 Top-K 选择为什么是 K2 而不是 K全部Top-1 最简单计算量最小但训练稳定性差。因为选出的单个专家会承担非常强的梯度更新一旦选错优化方向就剧烈抖动。K 如果太大比如 K8等于所有专家都参与计算稀疏激活名存实亡计算量回归 Dense 水平还多出路由和通信开销。Top-K 还直接影响通信量选中的专家越多每个 token 需要 dispatch 和 combine 的数据就越多跨卡传输的次数也成倍增加。为什么 K2 成为普遍折中两个专家的输出可以做一个简单的软组合比单独一个专家容忍更多噪声梯度平滑一些同时两路并行只比一路多一份专家计算卡在可控范围内。多个实验和工程实践都指向同一个结论从 K2 再往上加质量提升很有限计算成本却明显上涨。所以“2”更多是工程与稳定性的妥协而不是理论最优解。如果你在代码里看到有人设 K4先别急着批判得看他专家的粒度是不是已经拆得非常细此时多一两个被选专家可能是在弥补单专家容量太小的问题。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_factor1.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 的过程中下面这几个问题出现频率非常高我把症状和排查思路整理成了一张速查表。症状可能原因排查与解法loss 不降或波动大专家利用率极度集中路由坍缩负载均衡失效调大 aux loss 系数给 router 加噪声或 dropout检查初始化权重是否同质某个专家利用率长期为 0capacity_factor 过小导致 token 全被丢弃或路由初始偏向其他专家先确认丢弃率再调大噪声与 aux loss检查专家 id 是否正确loss 出现周期性尖峰特定 batch 中大量 token 涌进同一专家造成单卡计算和通信尖峰减小 batch 或提高 capacity_factor打开梯度裁剪推理吞吐比 Dense 还慢batch 太小通信占比高或 attention 成了瓶颈增大 batch尝试部分层 MoE减少专家数量微调后模型能力明显下降全量微调导致路由分布突变破坏预训练知识冻结非专家层只调 router、共享专家或少量低秩参数显存 OOM把稀疏激活误解为显存节省优化器状态分片、开启激活重计算必要时量化专家权重或减少专家数路由坍缩是最常见也是最隐蔽的问题。修它的第一步不是调模型而是先确认数据有没有偏差比如某类 token 占比过高。第二步是看 aux loss 是不是被主 loss 淹没了打开日志确认它是否在正常下降。第三步再调大系数。我自己的经验是先小幅调大到 0.02 观察 200 步如果专家利用率还是极端再继续调一次跳太多容易把模型精度打崩。微调 MoE 导致“变笨”这件事也值得单独讲。MoE 的预训练知识分布在专家权重里Router 的分配模式其实是这些知识的重要索引。如果全量微调时所有参数都放开路由分布很容易被新任务带偏导致新数据进来时模型调用了一组错误专家。比较好的做法是在微调阶段冻结非专家层只让 router、共享专家和小部分低秩适配参数可学习。这样新任务能调整路由偏好但不会把底层语言能力破坏掉。6. 选型思考与经验总结什么时候才该上 MoE6.1 适合与不适合 MoE 的场景场景是否推荐原因通用多语言大模型推荐覆盖面广、知识容量需求大专家领域分工收益明显代码、数学等分科知识推荐不同语言、不同题型天然形成子任务路由容易学到有意义分工低延迟单请求在线服务不推荐通信和全量加载内存会吃掉稀疏计算的收益单卡边缘设备部署不推荐无法容纳总参稀疏激活不能减内存预算有限但想扩大参数容量推荐激活参数可控训练成本比同等 Dense 低已训练 Dense 模型做特定任务微调谨慎建议冻结大部分参数只微调路由和共享专家这里多说一句MoE 并不适合所有任务。如果领域数据量小、任务非常单一那路由能学到的分工空间很有限加一堆专家只会增加训练成本和过拟合风险。更直白地说MoE 的价值前提是“数据的多样性足够高”。数据不够多样时MoE 和 Dense 效果差距不大但工程复杂度明显更高。6.2 从零开始做 MoE 实验的建议路径如果你没有跑过 MoE我建议按这条路径走而不是直接拿一个超大模型开练先有一个小规模 Transformer 基座能正常跑通语言建模任务。挑其中几层 FFN 替换成 MoE 层。初始配置用 num_experts8top_k2capacity_factor1.25aux_loss_coef0.01。训练过程中持续记录专家利用率、丢弃率和路由熵。拿同一份数据和同样的训练步数跟 Dense 基线做对比。你可能看到 MoE 前几百步 loss 稍差这是路由器在探索正常如果 loss 始终追不平去查负载均衡配置。路由健康之后再逐步加专家数量、加细粒度拆分、再加共享专家。一个比较省心的初始配置可以长这样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我的建议是别急着堆参数先用小模型把这三个指标调明白再迁移到大模型上会顺畅很多。
阅读完成 · 觉得有帮助？
