从Transformer诞生起，前馈网络（FFN）就是"又笨重又绕不开"的角色：它占了模型近三分之二的参数量，但每个token都得老老实实把所有参数过一遍。你扩大模型容量，推理成本就跟着线性往上涨，这让很多想做大规模模型的人非常头疼。MoE混合专家模型，或者说稀疏前馈网络，正是冲着这个矛盾来的——它把单个FFN拆成一组并行专家，再加一道轻量门控路由，让每个token只激活其中一小部分专家。参数总量可以扩展数倍到数十倍，但单token的计算量基本维持原样，容量和成本终于被解耦了。这篇文章我会从设计动机一路讲到训练和推理阶段的工程坑，包括门控网络怎么工作、负载均衡为什么难搞、专家并行怎么通信，以及一批可以直接上手的调参经验。不管你是想改造自己的Transformer，还是想理解最近一系列MoE大模型的结构，这篇都值得认真看完。

1. 从 FFN 到 MoE：改写前馈网络的真实动机

1.1 一个容易被忽视的事实：Transformer 的容量主要藏在 FFN 里

很多人一提到Transformer，下意识关注的是自注意力（Self-Attention）——tokens之间的交互全靠它。这话没错，但你要是统计一下参数量，注意力层其实只占很小一部分。一个标准Transformer Block里，FFN通常包含两个线性变换：先把隐藏维度（比如4096）升到中间维度（比如11008），再降回来。这两个矩阵相加，参数量轻轻松松占总模型的2/3甚至更多。

为什么设计成这个样子？因为FFN负责的是"逐位置的记忆与抽象"：每个token独立经过同样的非线性变换，把注意力层已经汇集的上下文信息进一步加工成更高层的特征。可以这样理解：注意力层负责"商量"，FFN负责"各自做事"。商量只需要一个桌子，做事却需要大量工具，工具多了，参数量自然就上去了。

问题在于，推理时即使工具再多，每个token也得把这些工具全部用一遍。参数量翻倍，单个前向的计算量就翻倍，延迟也跟着上来。于是你面临一个非此即彼的选择：要么保持计算量不变，放弃扩展容量；要么接受昂贵的推理成本。这个矛盾在模型规模做大之后尤其尖锐，我当时在一个文本模型项目里试着把FFN中间维度从4倍扩到8倍，效果确实有提升，但显存和推理延迟的代价直接让我放弃了。

1.2 稀疏激活的直觉：让"参数多、计算少"变成现实

MoE的思路一句话就能讲清楚：既然每个token用不上所有工具，那就把FFN拆成若干个可以独立工作的"专家"，然后装一个分诊台（门控网络），让每个token只去它需要的几个专家那里，其余专家本轮直接跳过。

这就是"稀疏激活"的含义。传统FFN是稠密计算——所有参数对所有输入都参与计算；MoE则是稀疏的——参数总量很大，但单个token实际触发的参数很少。用专业一点的术语描述：假设总共有E个专家，每个token从路由分布里挑出K个专家（K远小于E，通常K取1或2），那么这token的FFN计算量大约是原来单个FFN的K/E，而不是E倍。

直觉上可以类比全科医生和专科门诊的区别。普通FFN像一个能力全面的全科医生，每个病人都由他一个人看，诊所请不动更多医生，病人再多也是他一个人忙。MoE则是一个开了很多专科诊室的医院，每个专家只擅长某一类病，分诊台根据病人症状快速分配科室，每个病人只看一两个专家，其他科室完全不打扰。医院规模可以很大，但单个病人的看病时间并没有增加多少。模型容量来自"有很多专科医生"，计算效率来自"每个病人只看很少的医生"。

1.3 为什么改造的是 FFN，而不是注意力层

这里有个值得深思的问题：为什么大家做MoE都动FFN，而不直接把注意力层也拆成混合专家？原因在于两种结构的Nature完全不同。注意力层在每层同时处理所有token，通过Q、K、V矩阵建立跨token的交互，每个token的结果都与其他token相关；FFN则对每个token独立操作，token之间没有任何信息交换。

正因为FFN的逐token独立性，我们才可以放心地把不同token送到不同专家，专家之间不通信，各自处理完再把结果放回原来的位置。如果对注意力层做路由，比如让每个token只和一部分token交互，那"被谁注意到"会因为不同token选了不同专家而变得极度碎片化，上下文信息容易出现断裂，训练难度也会直线上升。这不是说注意力MoE完全不可行，而是在标准Transformer架构里，FFN是成本收益最划算的改造点：改动局部、逻辑清晰、收益最大。

还有一点很实际：FFN的权重是逐token独立存储的，天然适合做"参数并行"——把不同专家放到不同GPU上，互不干扰。注意力层则必须做完整的矩阵乘法和跨卡同步，通信开销大得多。所以从工程角度，FFN也远比注意力层更适合做稀疏化改造。

2. 稀疏路由的完整工作链路：门控网络、Top-K 选择与专家容量

2.1 门控网络：token 怎么决定自己去哪个专家

门控网络（Router，也叫Gating Network）是整个MoE最核心的组件。别看它决定着一大群专家的调用方式，它本身的结构却非常简单：通常就是一个线性层，输入是token的隐藏表示h，输出维度等于专家总数E。然后过一个Softmax，得到该token对各专家的选择概率分布。

用公式表示就是：

• router_logits = W_r @ h
• router_probs = softmax(router_logits)

这里的W_r是一个非常小的矩阵，假设隐藏维度是4096，专家数是8，那W_r的参数量只有4096 × 8，占整个模型的比重可以忽略不计。所以门控网络被称为"轻量"——它算得快、参数少，却直接影响模型的容量利用率。

一个关键的设计细节是：Router的输入到底用哪一层表示。如果是用当前层的FFN输入，那路由决策反映的是"这一层之前"的特征；如果是用上一层的输出或者与attention输出拼接后的向量，则可能包含更多上下文。不同实现各有取舍，我个人的粗浅经验是：在层数较深的地方，用本层的输入就够；如果训练不稳定，可以尝试把上一层Router的logits也拼接喂进来，给当前层更多先验。

2.2 Top-K 选择与专家容量：从"分诊"到"预约挂号"

拿到全量专家概率后，不能真的所有专家都参与计算，那样又退回稠密了。做法是取概率最高的K个专家，K通常取1或2。取到具体哪K个专家后，对应专家计算得到输出，再按路由概率（或归一化后的权重）加权求和，得到当前token的FFN输出。

当K=1时，每个token只走一个专家，计算效率最高，但每个token的感受域非常受限，专家之间也完全没有冗余协作。K=2是当前很多工作的经验默认值：既保证了稀疏性，又给了token一点选择的余地。我感觉K=2相当于让分诊台不仅选"最合适"的科室，还允许"备选"科室兜底，对训练初期路由还不成熟时特别友好。

接下来是专家容量（Expert Capacity）的问题。一个专家在某一层最多能处理多少个token？如果不设上限，某几个热门专家可能被分配大量token，其他专家空转，计算负载严重不均。于是实现时会为每个专家设置一个容量上限：capacity = capacity_factor * (T / E)。这个公式的含义是：理论平均分配下，每个专家应该处理T/E个token，capacity_factor则允许一定的弹性冗余。举个例子，假设T=256个token，E=8个专家，理论平均是每个专家32个token，capacity_factor取1.25，则容量为40。

一旦某个专家被分配的token数超过了容量，超出的token就只能被丢弃，或者走一条"残差连接直接跳过FFN"的通路。很多人第一次看到"丢弃token"会吓一跳：训练时丢信息，模型还能学好吗？实际上这是工程上的妥协——如果强行保留所有token，计算图和同步逻辑会变得非常复杂，还会导致不同专家之间的执行时间出现长尾。后续有人提出无丢弃（drop-free）的负载均衡方法，核心是调整路由分配而不是限制容量，效果也确实更好。但从工程复杂度考虑，带容量的实现依然是目前最稳妥的基线方案。

2.3 一个完整的 token 走向示例

为了把上面这些概念串起来，我走一遍一个token在MoE层的完整流程：

1. token输入为形状[B, H]的向量，先复制一份作为残差，为后续相加做准备。
2. 门控网络根据当前token的表示算出每个专家的概率，得到形状[E]的分布。
3. 挑选概率最高的K=2个专家，记为专家3和专家7。
4. token被送往专家3和专家7所在的设备（如果是单卡，就是同一设备上的不同矩阵）。
5. 专家3和专家7分别对token做自己的FFN前向计算，得到两个输出。
6. 两个输出按路由权重加权求和。
7. 加权结果与第一步的残差相加，得到当前层的输出。

这个流程里，其他6个专家完全没有参与计算，对应的参数也处于空闲状态。这就是"稀疏"两个字的真正含义——不是少设计了参数，是每次只用到其中一小撮。

3. 负载均衡与路由离散性：训练阶段最头疼的两个工程问题

3.1 离散路由不可微：梯度怎么回到 Router

MoE听着完美，但训练时第一个坑就摆在面前：Top-K取的是索引，是一个离散操作，不可导。你没法把"我选了专家3"这个行为直接变成梯度信号来更新门控网络。怎么办？

经典解法是：虽然选择是离散的，但最终输出是对"所选专家的输出"按概率加权求和，而概率本身是router logits经softmax得到的，是连续可导的。于是梯度可以沿着"概率权重"这条路回传到路由网络。换句话说，真正参与加权求和的权重是router_probs里选中那个位置的值，而不是一个one-hot向量；即使如此，这仍然会产生一个什么问题呢？

问题在于，概率权重在反向传播时数值通常比较小，门控网络拿到的梯度信号偏弱。你可以理解为：后端专家们学得很快，但分诊台学得有点滞后。这带来一系列连锁问题，后面会详细讲。

还有一个细节容易被忽略：训练时如果想用hard gradient估计算法（类似Gumbel-Softmax的Straight-Through），情况会稍有不同——forward时用one-hot，backward时用连续概率的近似梯度。但标准实现里，大多数框架仍然采用"加权求和式"的软路由，简单且稳定。我之前在某次实验里试过hard路由，收敛速度明显变慢，后来果断退回soft加权。

3.2 负载坍缩：少数专家过热、多数专家空转

MoE最著名的训练困境就是负载坍缩（load collapse）。开始训练时，Router的参数几乎随机，各专家的分配还算均匀。但很快，某些专家因为初始化稍好、梯度更新方向略微有利，就会被分配更多的token，形成正反馈：热门专家学得更快、表现更好，Router越来越倾向于选它，其他专家则长期闲置，梯度信号近乎为零，逐渐变成"死专家"。最终整个模型退化成其实只用了两三个专家，参数总量虚增，容量优势形同虚设。

解决负载坍缩的主要手段是加辅助负载均衡损失（Auxiliary Load Balancing Loss），让Router在每个batch里尽量把token均匀分配给专家。经典的实现大概长这样：

aux_loss = E * sum(prob_per_expert * fraction_of_tokens_per_expert)

其中prob_per_expert是所有token对本专家的平均选择概率，fraction_of_tokens_per_expert是实际被分配到本专家的token占比。二者相乘再求和，如果分配完全均匀，这个值会趋近于1；越不均匀，值越大，相当于对Router施加一个均匀化的惩罚。E作为缩放因子，使得损失数值与专家数无关，方便统一调系数。

但这又引入新矛盾：辅助损失权重设太大，模型会倾向于"为了均匀而均匀"，牺牲真正的专业分化，整体表现下降；设太小，负载坍缩压不住。我在实际调参时观察到的情况是：由于每个batch的分布都在变，固定权重很难同时照顾训练前期和后期的需求。比较务实的方法是训练前几百步用小权重，等专家分化初步形成后再逐渐加大；或者观察负载的variance指标——如果某专家占比长期超过2倍平均值，就临时加大权重拉一把。

3.3 初始化与 Router 输入尺度的稳定性

除了负载均衡，Router训练的另一个隐性障碍是logits的数值波动。如果Router的输出一直非常大，softmax出来的分布就会非常尖锐，几乎等于固定选Top-1专家，别的专家几乎没有机会。反过来，如果logits太小，分布太平滑，Top-K的选中结果和未选中结果差异不大，路由失去了区分能力。

一个常用技巧是给Router加一个可学习的temperature项，初始值设小一点，让logits先温和一些。入口处做LayerNorm也是常见做法，把不同token的表示尺度拉到同一水平，避免某些高范数token支配Router的决策。

我还用过一种更朴素的方法：直接从已有Dense模型做热启动（warm start）。比如把稠密FFN拆成E个专家时，克隆同一份参数作为每个专家的初始化，这样所有专家在训练初期能力一致，Router没有"偏心"的理由。这在多任务迁移场景下特别有效，毕竟从零训练一个大规模MoE，冷启动稳定性的难度是很多人低估的。

4. 训练态与推理态的差异：显存预分配、专家并行与通信开销

4.1 训练时怎么摆放专家：专家并行与 All-to-All 通信

讨论完训练稳定性，还得解决一个现实问题：MoE参数总量大，一张卡根本放不下。传统模型并行是切分每一层的矩阵，MoE则有天然更优的方案——专家并行（Expert Parallelism）：把不同专家分布在不同GPU上，每张卡只保存一部分专家的权重，Router所在位置则根据token的分布动态将token散播到对应专家所在的卡。

这里有两个关键通信阶段。第一个阶段叫Dispatch：某个token被路由到专家3，而专家3在另一张卡上，就必须把token的隐藏向量通过通信送到那张卡。第二个阶段叫Combine：专家3算完输出后，结果还要送回原来的卡，供后续的残差相加和下一层使用。如果K=2，token实际上要做两次dispatch/combine，通信量也随之倍增。

这两个通信阶段使用的通常是All-to-All模式，也就是每个节点都要向其他所有节点发送数据。这和传统All-Reduce（所有节点只汇总一个结果）完全不同。通信量大约正比于被路由的token数、隐藏维度和专家跨卡跳数。所以一个非常重要的工程教训是：MoE的稀疏收益到一定规模后可能被通信开销吃掉。如果网络带宽不够，你会发现训练速度不升反降，加专家还不如加计算密度来得划算。

我实际测试过一个典型配置：8卡环境、每层8个专家、K=2。在单机NVLink互联下通信损耗还能接受，但一旦跨机走以太网，训练step时间立刻涨了30%，收益大打折扣。所以设计MoE规模时，一定要先盘清楚自己的通信拓扑。

4.2 推理态显存的真正瓶颈：参数常驻，而不是计算量

很多人第一次接触MoE推理时都会有个错觉：既然每个token只激活一小部分专家，那显存占用是不是也按比例减小？不是。稀疏只减少了计算量（FLOPs），参数依然全部常驻显存。无非是一个token实际只用到了门控网络和少数专家的权重，但所有专家的参数都必须在内存里待命，因为你不知道下一个token会访问哪个专家。

这在推理侧会造成一个非常有趣的局面：MoE模型的推理延迟可以接近同计算量的Dense模型，但显存占用接近同参数量的Dense模型。换句话说，你省的是算力，省不了容量。正因如此，大规模MoE推理基本都是多卡分布式方案，每张卡放一部分专家。当请求到来时，token先经过路由，再通过通信调用其他卡的专家。这实际上把训练时的专家并行复用了，只是batch更小、通信更多在卡间进行。

显存优化通常还有两个方向：一是对专家权重做更激进的低比特量化，因为专家本身是逐token独立使用的，量化误差不容易像attention参数那样跨token扩散；二是预先把所有专家的参数做统一内存池管理，配合显存碎片整理。后一种技巧偏工程化，但收益很直观，尤其在长期多请求服务的场景里。

4.3 padding token 带来的路由损耗：一个容易踩的隐藏成本

训练时为了batch对齐，我们会给短句做padding。在普通Transformer里，padding位置虽然参与计算，但因为注意力mask的存在，它们对有效位置的影响基本可以被忽略，于是人们很少专门去处理padding token的成本。但在MoE里情况变了：每个padding token也要走Router、也要被dispatch到某个专家、也要占用专家容量。

这带来两个直接后果。第一，padding token占用专家容量，可能导致有效token被挤掉（超过capacity被丢弃）。第二，即使padding token没有实际信息，它们依然占据通信通道，白白消耗All-to-All带宽。好在我们找到的解决办法并不复杂：在padding位置的路由概率上直接加一个非常大的负偏置，让Router几乎不可能选中任何专家；或者把padding token在进入MoE层之前直接从batch里摘除，等所有专家计算完再放回原位。前者改动小，后者更彻底，但需要处理动态batch，工程复杂度会增加一些。

类似的浪费也出现在推理场景：现在主流的推理框架普遍采用连续批处理（continuous batching），不同请求的长度不对齐时，也会出现大量"虚位"token。所以做MoE推理服务时，请求调度策略对性能的影响往往比模型结构本身还大。

5. 实测调参清单与扩展思路：从复现一个简单 MoE 层开始

5.1 一个可直接改写的 MoE 层伪代码结构

看完前面的原理，你已经可以把一个标准的MoE层搭出来了。下面用离实现很接近的伪代码展示核心逻辑，框架无关，方便你对照着改写自己的代码。

def moe_ffn(x, experts, router, K=2, capacity_factor=1.25): # x: [batch, hidden] B = x.shape[0] E = len(experts) T = B # 这里假设每个token独立路由，实际实现会考虑padding mask # 1. 计算路由概率 logits = router(x) # [B, E] probs = softmax(logits, dim=-1) # [B, E] # 2. 取Top-K专家 top_probs, top_idx = probs.topk(K, dim=-1) # 各[B, K] top_probs = top_probs / top_probs.sum(dim=-1, keepdim=True) # 归一化 # 3. 按专家容量筛选 capacity = int(capacity_factor * B / E) dispatch_mask = build_dispatch_mask(top_idx, E, capacity) # [B, E, K] 或管理token分配 # 4. 对每个选中的专家执行 FFN，并按权重聚合 output = zeros_like(x) for e in range(E): selected = dispatch_mask[:, e] # 哪些token被分到专家e if selected.any(): expert_out = experts[e](x[selected]) # [num_selected, hidden] output[selected] += (top_probs[selected, e] * expert_out) # 5. 残差连接 return output + residual_x

当然真实工程里不会用for循环逐专家算，而是通过矩阵乘法一次性完成所有专家的前向；但核心逻辑就是上面的流程。为了效率，专家计算通常会合并成一个大的张量运算：把专家参数沿着一个轴堆叠起来，然后用grouped GEMM一次算出所有选中专家的输出。这也是很多训练框架在MoE部分做的主要优化。

5.2 调参顺序：先稳定路由，再追容量

调MoE和调普通模型一个很大的区别是，超参数之间存在明显的先后依赖关系。一上来就乱试专家数、路由权重，很容易出现"忘记调了什么"的局面，因为每个超参数都会间接影响Router的负载分布。我建议按下面的顺序做：

具体来说，先固定E和K，把capacity_factor从1.25开始试，观察训练时被丢弃token的比例。如果丢弃太多，说明Router的选择太集中或容量太小，可以适当调大capacity_factor；如果几乎为零，则逐步减小，压出更多计算密度。然后才去调整aux loss系数：从0.01起步，每几百步看一眼各专家的token占比分布。占比的方差如果持续缩小到接近均匀，说明权重偏大，可以降；如果某个专家占比持续超过2倍平均，则要加大权重。

一个反直觉的经验是，对于中小规模的模型（参数量在亿级以下），MoE的优势并不明显。Router自身也需要数据爬坡，假设总数据量没法让每个专家都充分训练，那稀疏结构的收益就会打折扣。所以不要只盯着"MoE=大模型专利"这个说法，也要理解它依赖的"规模前提"。

5.3 什么时候不应该用 MoE，以及几个值得关注的扩展方向

MoE不是银弹。如果你的使用场景是单机单卡、推理延迟极敏感、或者模型规模本来就很小，那么MoE带来的通信开销和显存负担通常不值得。尤其是边缘端或者移动端场景，参数量常驻和动态路由的不确定性，会让部署变得非常不友好。宁可把精力花在蒸馏、量化或者知识蒸馏这类压缩手段上。

反过来，MoE真正发光的地方是：训练语料极其丰富而单卡显存成为瓶颈、需要在不显著增加推理计算量的前提下扩展容量、以及多种异构任务希望共用一套底座但各任务又有自己的特性。多模态方向也可以大胆尝试——不同模态的信息处理模式差异大，正好适合交由不同专家专人负责，门控网络学到的"模态路由"有时会带来意想不到的可解释性。

我在一次改造中把MoE从语言模型搬到了推荐系统的打分模型里：不同用户群体走不同专家，冷启动阶段用户走Generalist专家，活跃用户则能访问专属专家后的组合结果，效果提升比纯粹加深网络更明显。这说明MoE的"分诊思想"完全值得跨场景复用，关键还是找到那些"不同样本需要不同能力"的问题。

最后分享两个小技巧。如果你已经用上了MoE，建议把Router的决策分布做成可视化日志，每训练几千步看一眼，比任何损失曲线都能更快发现问题；另一个是在测试阶段记录"专家热力分布"，如果模型收敛后大部分token的Top-1专家高度集中，往往说明模型只学到了表面规律，需要回头检查训练数据本身的多样性。

MoE这条路，技术在往前走，但工程的坑说到底还是那几类：通信、负载、稳定性。理解了底层逻辑，剩下的就是耐心调参和踩坑。希望这些经验能帮你少走几步弯路。