万亿参数时代的稀疏之道MoE混合专家架构的工程原理与2026年工业实践

摘要

混合专家（Mixture-of-Experts, MoE）已在2025-2026年成为开放权重大模型的默认架构范式。从DeepSeek V4-Pro的385专家、1.6T总参/49B激活，到Llama 4 Maverick、GLM-5.2、Qwen3-235B、Nemotron 3 Super，几乎所有旗舰模型都站在MoE这一侧。本文认为，MoE的核心价值不在于"让模型更大"，而在于通过条件计算将训练规模与推理成本彻底解耦——一个671B参数的模型推理时仅激活37B参数，单token成本与70B稠密模型持平。本文从路由机制、负载均衡、训练工程、推理优化、混合架构、量化压缩、前沿趋势七个维度，系统拆解MoE在2026年的工程原理与工业实践，尤其聚焦DeepSeek、Google、Meta三家的差异化路线选择。

1. 引言：从"越大越好"到"聪明的稀疏"

2024年12月，DeepSeek V3发布时引发了一场不大不小的认知地震：一个671B总参数的模型，推理时仅激活37B参数，在多项评测上追平甚至超越了GPT-4。围绕这个结果有两种解读：一种是"中国模型追上来了"，另一种是"MoE终于从玩具变成生产力工具了"。本文持后一种视角。

把时间往回拨到2022年。当时MoE在NLP圈并非新鲜事物——Google早在2017年就在《Outrageously Large Neural Networks》中系统阐述了MoE的稀疏门控架构，Switch Transformer（2021）更是用Top-1路由把模型规模推到了1.6T参数。但这些早期工作都停留在学术论文与Google内部部署层面，开源社区真正大规模采用MoE，始于2023年底Mixtral 8x7B的发布。到了2025-2026年，局势完全逆转：DeepSeek V4-Pro、GLM-5.2、Kimi K2.6、Qwen3-235B-A22B、Llama 4 Maverick、Nemotron 3 Super、Arcee Trinity——几乎所有值得关注的开放权重模型都采用了MoE架构。

这种集体转向背后有一条清晰的逻辑链。稠密模型的Scaling Law呈现一个令人无奈的约束：参数翻倍，计算量翻倍，推理成本也翻倍。这意味着每当你想让模型"知道更多"（增加知识容量），就得同时为每次推理支付更高的算力账单。MoE打破了这种捆绑——通过将知识分布在多个"专家网络"中，每次推理只激活少数专家，模型的知识容量与推理计算量之间不再是线性关系。671B和1.6T参数的模型分别以37B和49B成本运行，这就是解耦的力量。

MoE本质上是一场工程架构革命，不是算法革命。它没有发明新的自注意力机制，没有提出新的优化器，也没有颠覆Transformer的宏观结构。它只做了一件事：把前馈网络（FFN）这一层从"一个超级大的全连接"拆成"一组小型专家 + 一个路由器"，然后让路由器为每个token选一个或几个专家来处理。这种"条件计算"的思路，其实在软件工程中随处可见——从微服务架构到内容分发网络（CDN），都是通过动态路由实现资源的按需分配。MoE不过是把这个逻辑搬进了神经网络的每一层。

2. MoE的底层架构：用条件计算替换前馈网络

2.1 标准Transformer中的稠密FFN

要理解MoE，先要理解它替换了什么。在标准Transformer解码器层中，自注意力（Self-Attention）之后紧跟着一个两层前馈网络：

FFN(x) = W_up · GELU(W_gate · x)

其中 W_gate 将隐藏维度 d 映射到中间维度 d_ff（通常 d_ff = 4d），GELU激活函数引入非线性，W_up 将中间维度映射回 d。这个FFN占了Transformer约三分之二的参数量和计算量，是模型中最"重"的组件。

稠密FFN的问题是：每个token不论语义复杂度高低，都经过同一个参数的完整计算路径。一个简单的句号token和一段复杂的推理链token，消耗的计算资源完全相同。而MoE的核心直觉恰好相反：不同token可能需要不同的"知识处理通道"。

2.2 MoE层的基本结构

MoE层不改变Transformer的宏观结构，只替换其中的FFN。一个MoE层包含三个组件：

1. N个专家网络（Expert FFNs）：每个专家是一个独立的FFN（结构与传统FFN相同，但参数量更小）
2. 一个门控网络（Gating Network / Router）：一个线性层 + Softmax，输出token分配给各专家的概率分布
3. Top-K选择与加权求和：仅保留概率最高的K个专家，将其输出按门控权重加权求和

数学表述如下：

G(x) = Softmax(TopK(W_g · x, K))
y = Σ_{i=1}^{N} G(x)_i · E_i(x)

其中 W_g 是门控网络的权重矩阵，TopK(·, K) 将非Top-K位置的logit设为 -∞（归一化后对应位置变为0），E_i(x) 是第 i 个专家的FFN前向输出。

flowchart LR
    subgraph Dense["稠密 FFN 层"]
        A1["x (输入)"] --> B1["W_gate (升维)"] --> C1["GELU 激活"] --> D1["W_up (降维)"] --> E1["FFN(x)"]
    end

    subgraph MoE["MoE 层"]
        A2["x (输入)"] --> B2["门控网络 W_g"]
        B2 --> C2["Softmax + Top-K"]
        C2 --> D2_1["Expert 1"]
        C2 --> D2_2["Expert 2"]
        C2 --> D2_3["Expert ..."]
        C2 --> D2_k["Expert K"]
        D2_1 --> E2["加权求和"]
        D2_2 --> E2
        D2_3 --> E2
        D2_k --> E2
        E2 --> F2["MoE(x)"]
    end

这张图直观呈现了稠密FFN与MoE层的结构差异。左侧的稠密FFN是一条单线程的流水线，所有输入经由同一组权重处理。右侧的MoE层则增加了一个"路由决策"环节：门控网络先对输入token做一个快速分类，决定把它分发给哪几个专家，然后把分散的结果聚合起来。路有多条，但每个token只走其中少数几条。

2.3 路由策略的演化：从Switch到DeepSeek

Top-K中K的取值差异，直接决定了模型行为的稀疏程度，也是不同模型路线分歧的起点。

Switch Transformer（2021）采用Top-1路由，每个token只激活一个专家。这种设计的优势在于计算量最小、通信开销最低——每个token只需向一个专家发送数据。但代价是单专家无法覆盖足够的知识维度，且专家间的负载极度不均匀。Switch Transformer虽然将模型规模推到了1.6T参数，但在MMLU等下游基准上的表现远不如同参数量的稠密模型。

Mixtral 8x7B（2023）采用Top-2路由，每个token激活2个专家。这是开源社区首次验证了"略多一些的专家激活数量比死磕Top-1更优"这一经验法则。2个专家的加权组合提供了比单个专家更丰富的表达能力，且计算量只增加了一倍（相对Top-1），仍然远低于全部专家的8倍开销。

DeepSeek V3/V4-Pro（2024-2026）的路线是Top-6~8 + 共享专家 + 路由专家分离。DeepSeek设计了两种专家类型：共享专家（Shared Expert） 对所有token都激活，承担基础通用知识的处理任务；路由专家（Routed Expert） 才参与稀疏路由，每个token从数百个路由专家中选6-8个。这种设计的直觉是：有些知识（如语法规则、位置编码）几乎是所有token都需要的，没必要每次在路由上做决策；只有领域性、特异性强的知识才需要稀疏分发。DeepSeek V4-Pro总计385个专家（1个共享+384个路由），每次激活1个共享 + 6-8个路由，维持了37B激活参数，做到了671B总参数量的5.5%激活率。

3. 路由机制：负载均衡是MoE的第一性工程难题

如果把MoE比作一家医院，门控网络就是分诊台。理想的分诊台应该根据病情的复杂程度，把病人均匀地分配到各科室——不能让一个科室挤满90%的病人而其他科室空闲。但实际情况是，分诊台天然偏爱"热门科室"，因为病人在表征空间中呈现簇状分布，大量token在语义上接近，会被路由到同一组专家。这就是MoE训练中最棘手的工程问题：专家坍塌。

3.1 专家坍塌的形成机理

专家坍塌是一个自增强的负反馈循环：

1. 门控网络的学习信号来自梯度下降，训练初期某个专家在特定类型的token上表现稍好
2. 门控网络倾向于此专家，更频繁地将类似token路由给它
3. 该专家收到更多训练信号，在该方向上表现更好
4. 门控网络进一步强化对该专家的偏好
5. 其他专家因训练不足而退化，门控网络更不愿路由给它们

最终结果是：名义上有N个专家，实际只有2-3个专家在"工作"，模型退化为一个参数量缩小N倍的稠密模型，且其他专家的存储开销白白浪费。

flowchart TD
    T["输入 Token"] --> G["门控网络 (Softmax)"]
    G --> P["Top-K 概率分布"]
    P --> LB{"负载均衡约束"}
    
    LB -- "通过 ✅" --> R["路由到目标专家"]
    LB -- "不通过 ❌" --> ADJ["调整路由概率"]
    ADJ --> LB
    
    R --> E1["Expert A<br>(激活)"]
    R --> E2["Expert B<br>(激活)"]
    R --> EN["Expert ...<br>(激活)"]
    
    E1 --> AG["加权聚合"]
    E2 --> AG
    EN --> AG
    AG --> OUT["输出 y"]
    
    style LB fill:#f96,stroke:#333,stroke-width:2px

这个过程说明，负载均衡不是MoE训练中的"可选优化"，而是必要条件。没有负载均衡的MoE会在几十步训练内崩溃为少数专家垄断的状态。下图展示了Token从门控到路由再到聚合的完整决策链路，其中"负载均衡约束"这个菱形节点是整个流程的天然瓶颈。

3.2 解决方案一：辅助损失

最经典的负载均衡方案是为训练目标增加一个额外的辅助损失项。Google在《Outrageously Large Neural Networks》中提出的形式如下：

L_aux = α · N · Σ_{i=1}^{N} f_i · P_i

其中：

• f_i 是第i个专家被路由到的tokens占比
• P_i 是门控网络分配给第i个专家的平均概率
• N 是专家总数
• α 是辅助损失的权重系数，通常设为0.01左右

直观理解：当所有专家被均匀路由（f_i ≈ 1/N）、门控概率均匀分布（P_i ≈ 1/N）时，该损失取最小值。任何偏移都会增大损失。

Switch Transformer将α设为0.01并配合了另一种技巧：专家容量（Expert Capacity）——限制每个专家每批次能处理的token上限，超出上限的token会被"溢出"丢弃或重新路由。这种做法虽然降低了模型容量（丢弃训练信号），但保证了负载均衡的刚性约束。

3.3 解决方案二：Expert Choice路由

Google在2022年发表了Expert Choice（EC）路由，从根本上翻转了路由方向。传统路由是"每个token选Top-K个专家"，EC路由是"每个专家选Top-K个token"。

EC路由的工作方式是：对于每一层，门控网络输出一个 token × expert 的亲和度矩阵。每个专家从所有token中选择亲和度最高的top-k个token进行处理——专家选择token，而非token选择专家。这天然保证了每个专家处理相同数量的token，负载零偏差。

EC路由的代价是：每个专家处理的token集合是全局最优的，但失去了token视角的灵活性——不同token可能被不同数量的专家处理（取决于它在所有专家那里的排名）。Google的实验表明，EC路由在收敛速度和最终性能上都优于传统的token-choice路由，但它与流式推理、decoder-only自回归生成框架的兼容性略差——因为自回归生成中每个token是一步一步生成的，无法提前预知整批token的分布来做全局排序。

3.4 解决方案三：DeepSeek的细粒度约束

DeepSeek V2/V3提出了另一种路线：无辅助损失的负载均衡。其核心思路分为两个层次。

第一层是动态偏置调整：门控网络的最终路由决策不是直接使用Softmax输出的概率，而是在这些概率上添加一个可学习的偏置项（bias term），偏置的调整方向取决于专家当前的负载与期望负载的偏差。如果专家i当前负载低于平均值，正偏置（提高分派概率）；如果过高，负偏置（降低分派概率）。这个偏置不参与梯度下降的反向传播，而是通过一个独立的EMA更新。

第二层是设备限制路由：在分布并行场景下，每个token的路由决策还需要考虑专家所在的物理设备。DeepSeek限制了每个token只能路由到本设备及相邻设备上的专家，减少了跨设备通信开销。这相当于在路由层面同时考虑了计算负载和通信负载。

DeepSeek方案优势在于：辅助损失的系数调参在训练中非常敏感，α设为0.01还是0.001可能导致完全不同的负载分布。偏置调整方案避免了这种超参数调优，让负载均衡成为"运行时自动调节"的机制，而非"训练的额外约束"。

三种方案各有利弊：辅助损失实现简单但调参成本高，EC路由负载均衡效果最优但与推理流程有结构性不匹配，DeepSeek方案工程优雅但实现复杂。2026年的趋势是辅助损失 + 专家容量作为"兜底方案"被广泛保留，而顶级的训练（如DeepSeek、Qwen）均采用了偏置调整或EC路由。

4. 训练MoE：通信、稳定性与超参数的艺术

MoE训练与稠密模型训练之间的工程差异，远比"多一个门控网络"这几个字看上去要复杂。核心挑战来自三个方面：通信模式、数值稳定性和超参数敏感性。

4.1 专家并行与All-to-All通信

稠密模型分布式训练的主流方案是张量并行（TP）和流水线并行（PP）。但对MoE来说，最自然的并行维度是专家并行——把N个专家分布到M个GPU上，每个GPU负责N/M个专家的计算。

专家并行的前向传播流程如下：

1. Token分派：每个GPU对自己分批的token计算路由决策，确定每个token要去哪个专家
2. All-to-All通信：GPU将token数据发送给对应的专家所在设备。这是一个典型的全交换模式——每个GPU都向所有其他GPU发送数据，也从所有其他GPU接收数据
3. 专家计算：每个GPU在自己负责的专家上执行FFN前向
4. 反向All-to-All：将计算结果返回给token来源的GPU
5. 加权聚合：每个GPU在本地完成MoE输出的加权求和

通信量与batch size（B）、隐藏维度（d）和Top-K数量（K）成正比：

通信量 = B × d × K × (N-1) / N

当专家数量N很大（如DeepSeek V4-Pro的384个路由专家）、总共部署在数十个GPU上时，每轮前向传播的All-to-All通信量可以达到百MB级别。如果带宽不足（如使用NVLink而非InfiniBand），通信延迟会超过计算延迟，使训练的MFU（模型FLOPs利用率）大幅下降。

4.2 Megablocks和DeepSeek-Alpha的优化

2024年以来的核心工程突破来自两个方向。

Megablocks（Stanford/MosaicML） 解决了MoE中一个微妙的CUDA效率问题。在标准MoE实现中，同一批次的不同token被路由到不同专家，导致专家接收的数据量是非规则的——专家A可能处理15个token，专家B处理8个，专家C处理22个。传统做法是每个专家都padding到最大容量然后做矩阵乘法，浪费了大量FLOPs。Megablocks提出了一种"分块调度"的策略：将不规则的小矩阵乘法合并为更大规模的分块矩阵乘法，通过动态规划方法优化分块大小，显著提升了GPU计算效率。

DeepSeek-Alpha 提出了另一种路线——分组专家并行（Grouped Expert Parallelism, GEP）。将专家分组，组内专家放在同一台机器上（通过NVLink高速通信），组间专家跨机器分布（通过InfiniBand通信）。这样可以减少跨机通信的次数：一个token的路由目标通常在同一个组内（由于设备限制路由的设计），大部分通信落在高速的组内链路，组间通信仅发生在极端情况下。

4.3 训练稳定性与梯度管理

MoE训练的另一个隐性陷阱是梯度行为。稠密模型中，所有参数对每个batch都有相同的梯度更新机会。但在MoE中，一个批次中专家A可能只能处理15个token（因此只有这15个token产生针对专家A的梯度），而专家B可能处理30个token。这就导致专家间的梯度尺度天然不一致。

这个问题的后果有两方面。一是弱势专家（处理token少）的更新步长小，进一步导致其竞争力下降，加速专家坍塌。二是在优化器层面，使用统一学习率可能导致"热门专家"过拟合，"冷门专家"欠拟合。实践中，DeepSeek架构的调参经验包括：对路由专家的梯度做层归一化（Layer-wise Gradient Scaling），将专家间的梯度范数对齐到相似水平；学习率调度上不使用预热后的cosine衰减，而采用更保守的常数学习率 + 阶段性阶梯衰减，给弱势专家更多的适应时间。

4.4 MoE超参数的艺术

MoE的训练超参数暴增于稠密模型。关键超参数包括：

• 专家数量N：从Qwen3-235B的每个MoE层64专家的中等规模，到DeepSeek V4-Pro的385专家
• 激活专家数K：从Switch的1个到DeepSeek的6-8个
• 路由策略：Token-choice vs Expert-choice
• 辅助损失权重α：0.001到0.1不等
• 专家容量：通常设置为预期负载的1.2-1.5倍
• 专家初始化：正交初始化 vs 复用预训练稠密权重

这些超参数之间还存在耦合关系——N越大，K需要适度增大以保持建模容量；专家容量越小，辅助损失权重α需要相应提高；路由策略不同会导致最优学习率的差异。2026年的实践共识是，MoE训练的超参数调优成本大约是同等规模稠密模型的2-3倍，这也是部分团队仍然坚持稠密模型路线的现实原因之一。

5. 2026年MoE旗舰模型横向对比：差异化的工程选择

2026年的MoE生态已经不是"用还是不用"的问题，而是"怎么用、用谁的方案"的问题。不同团队在MoE架构上做出的差异化选择，本质上反映了它们对"稀疏性-容量-效率"三维平衡的不同判断。

DeepSeek V4-Pro：极致稀疏的路线

DeepSeek的路线是"用最大数量的专家实现最高程度的稀疏"。385个专家分布在64层的每个MoE层上（每层6个路由专家+1个共享专家），每层路由专家激活率约为1.6%（6/384）。这种极致稀疏的设计要求极强的负载均衡约束，DeepSeek的偏置调整机制正是在这个背景下设计的。

技术启示：DeepSeek证明了专家数量可以做到300+级别而不显著降低路由质量。但代价是训练基础设施的高度定制化——DeepSeek的通信拓扑和流水线调度是为其385专家架构专门优化的，不经过大规模改造无法直接复用。

GLM-5.2：分层MoE的Agent优先路线

GLM-5.2（智谱）选择了不同的方向。它的MoE架构是分层的：一部分关键层（靠近输入的嵌入层和靠近输出的顶层）采用全激活的稠密FFN，保证底层语义提取和顶层推理整合的质量；中间层采用稀疏MoE，节省计算量。这种设计的直觉是，底层和顶层对模型性能的"边际回报"更大，不适合稀疏化；中间层更多是知识容量储备，在保证足够专家数量的前提下可以用稀疏性来换取效率。

GLM-5.2还特别强化了路由网络与Agent能力的关联：在训练中引入了一个"意图识别"辅助任务，帮助门控网络学会根据用户意图（代码、数学、问答、工具调用等）做路由选择，使得后续的Agent工具调用场景中，路由网络天然偏好的专家与任务类型更加匹配。

Llama 4 Maverick：通用旗舰的多语言多模态适配

Meta的Llama 4 Maverick选择了"K值较大但N值适中"的保守路线。128个专家、8个激活，激活率达6.25%，远低于DeepSeek的稀疏度。这反映了Meta对模型通用性的保守判断：多语言任务和多模态任务（文本+图像+视频联合理解）要求每个token能调用的知识覆盖面更广，K值太小可能导致某些语言或模态的token找不到合适的专家。Llama 4的路由策略沿用了辅助损失+专家容量的经典方案，主打稳健。

Qwen3-235B-A22B：Thinking vs Instruct的路由差异化

Qwen3-235B-A22B最引人注目的设计是路由网络的双模式设计。在"思考模式"（Thinking Mode）下，路由网络偏向选择代码推理类和数学类的专家，因为思考模式的典型场景是分步推理。在"对话模式"（Instruct Mode）下，路由网络的选择分布更加均匀，涵盖知识问答、创意生成等多样化需求。这种模式感知的路由策略实现方式是在训练阶段提供两种标签：Thinking token和Instruct token，门控网络的学习目标是在这两种分布下都达到高路由质量。这相当于门控网络在"专业化路由"和"通用化路由"之间达到了一个动态平衡。

6. MoE推理优化：专家并行与动态调度系统

训练完成之后，MoE模型的推理优化是另一个独立的战场。稠密模型推理中最棘手的KV Cache问题，在MoE这里变成了"KV Cache + 专家调度"的双层优化问题。

6.1 专家并行推理部署

在推理场景下，专家并行（Expert Parallelism, EP）仍然是最核心的部署策略。一个671B参数的MoE模型（如DeepSeek V4-Pro）如果全部放在单张GPU上，即使经过INT4量化也无法满足显存需求。EP将这些专家均匀分布到多张GPU上：

• 32张GPU时，每张GPU负责约12个路由专家 + 所有的共享专家（共享专家通常复制到所有GPU上）
• 每张GPU需要存储约21B参数（671B / 32），以FP8精度约为21GB，加上其他层参数和KV Cache，8卡H100（80GB）集群可以容纳

与训练EP不同，推理EP面临一个额外的挑战：推理阶段的请求到达是异步的，无法像训练那样通过预先划分批次来优化通信模式。为此，推理框架在EP基础上增加了两级缓存策略。

6.2 预取与分级缓存

推理集群中，热门专家和冷门专家的访问频率可以相差100倍以上。优化策略是针对不同热度的专家采用不同的存储策略：

• Hot Expert（Top 20%最常被路由的专家）→ 常驻显存，任何时候都可近零延迟访问
• Warm Expert（中间60%专家）→ 常驻显存，但在显存紧张时可能被优先驱逐
• Cold Expert（底部20%最少访问的专家）→ 存储在CPU内存或NVMe SSD上，被路由到时动态加载到显存

动态加载策略需要与推理调度器紧密集成：调度器在预填充阶段（Prefill Phase）分析请求的路由分布，提前将可能命中的冷门专家从CPU加载到GPU显存，避免解码阶段（Decode Phase）的等待。

6.3 连续批处理在MoE场景下的挑战

连续批处理（Continuous Batching）是vLLM/SGLang等推理框架的核心创新，它允许在某个请求完成解码后立即插入新请求，而不是等整个batch完成。但在MoE场景中，连续批处理带来了一个棘手的效率问题：专家激活矩阵的稀疏性不规律。

具体来说，一个batch中不同请求的不同token可能命中完全不同的专家子集。假设batch中有8个请求，每个token激活6个专家，经过连续批处理的追加和移除，每个解码步的专家激活模式都在变化。这种变化导致每轮计算的专家FFN矩阵形状不规则——专家A可能处理3个token，专家B处理7个，专家C处理2个。对小矩阵做GEMM运算在CUDA上效率极低，无法充分利用Tensor Core的算力。

flowchart LR
    REQ["请求流"] --> CB["连续批处理调度器"]
    CB --> TOKENS["Batch Token 序列"]
    TOKENS --> ROUTE["Token 路由决策"]
    ROUTE --> SPARSE["专家激活矩阵<br>(稀疏不规则)"]
    SPARSE --> MERGE["分块合并 Megablocks"]
    MERGE --> EP["专家并行计算"]
    EP --> AGGR["加权聚合"]
    AGGR --> DECODE["解码输出"]
    
    style SPARSE fill:#f9f,stroke:#333,stroke-width:2px
    style MERGE fill:#6f9,stroke:#333,stroke-width:2px

上图展示了MoE推理的完整链路。关键瓶颈在"专家激活矩阵"（稀疏不规则）到"分块合并"这个环节——这也是Megablocks等优化库在推理侧的用武之地。通过将同一个batch内的token按路由结果重新编排，使得专家计算的矩阵乘法形状更加规整，CUDA的Tensor Core利用率可以从不足30%提升到60-70%。

6.4 DeepSeek的推理部署成本奇迹

DeepSeek最大的落地成果不在于模型精度，而在于推理成本。以每token 37B参数激活、671B总参数、H800集群部署的方案，DeepSeek V3/V4的推理成本约为GPT-4的1/10——在2024年底这个比例是1/20，随着其他模型优化也有所收敛，但整体成本优势仍然在一个数量级水平。

这个成本优势的来源是多层次的：385专家的极端稀疏架构使单token计算量低于70B稠密模型；EP + 分组通信优化使多GPU的通信开销被控制在可接受范围；分块矩阵合并（Megablocks风格）使GPU利用率最大化；FP8量化的差异化精度使大部分计算受益于低精度Tensor Core。最终实现的不是某一方面的优化，而是架构-通信-计算-精度四层面的系统性降本。

7. 混合架构浪潮：MoE × SSM × 线性注意力

2026年MoE架构的一个重要趋势是"不再是孤立的MoE"。MoE正在与状态空间模型（SSM）、稀疏注意力、线性注意力等架构组件深度融合，形成混合架构（Hybrid Architecture）。这背后的驱动力很直接：既然FFN层可以稀疏化（MoE），那注意力层也可以稀疏化或替代化。两条稀疏路径汇合，推理成本的下降空间是叠加的。

7.1 MoE + SSM：Nemotron 3 Super的路线

Nemotron 3 Super（NVIDIA）是2026年最激进的混合架构尝试之一。它的设计思路是将Transformer解码器层的两个核心组件分别替换为更高效的变体：

• 注意力层 → Mamba-3（SSM层）：用状态空间模型替代传统的自注意力，将二次复杂度O(L²)降为线性O(L)
• FFN层 → MoE层：对前馈网络做稀疏化

这种"SSM处理序列依赖 + MoE处理语义知识"的拆分具有工程上的合理性。SSM的优势在于长上下文处理——256K token序列中，Mamba-3的计算量与128K token序列几乎持平（线性增长），而自注意力的计算量会翻四倍（二次增长）。MoE的优势在于知识容量——64个专家中的4个激活提供了稀疏知识覆盖。两者结合后，模型在128K+长上下文任务上展现了显著的优势。

但混合架构也有代价。Nemotron 3 Super在4K以下的短上下文任务上，精度略低于同等参数量的稠密Transformer。这符合SSM的已知特性——在短序列上，其表达能力不如完全的自注意力机制。NVIDIA的权衡是：牺牲1-2%的短上下文精度，换取长上下文能力和推理成本的50%以上降低。

7.2 注意力层简化 + FFN层稀疏化的双轮驱动

2026年有更多模型在注意力层面做文章。MiniMax-01采用了线性注意力（Linear Attention） + MoE的组合，用核技巧近似后的注意力替代标准Softmax注意力，使注意力计算的复杂度从O(L²d)降为O(Ld²)。Arcee Trinity则在稀疏注意力（只在少数选定的token对上做注意力计算）基础上叠加MoE。

GLM-5.2的"分层MoE"也属于混合架构的一个子类——它不是用不同的架构组件替换注意力层，而是在不同的层采用不同的稀疏策略。靠近输出的最后几层使用全注意力 + 全激活FFN，保证"输出质量"；中间层使用全注意力 + 稀疏MoE FFN，兼顾效率与知识覆盖。这种"同一种架构内按层差异化"的设计降低了工程复杂度，但也牺牲了部分效率提升。

7.3 "注意力层简化+FFN层稀疏化"为什么是趋势

直觉上，这条路径可行是因为模型计算瓶颈的两头——注意力（序列建模）和FFN（知识存储）——本质上是独立的资源消耗。注意力层的计算量与序列长度相关，对知识容量几乎没有贡献；FFN层的计算量与参数规模相关，对序列建模几乎没有贡献。因此，对两者分别做优化（注意力层简化节省了序列维度的计算，FFN层稀疏化节省了参数维度的计算）时，优化效果是正交叠加的，而非互相冲突。

2026年的共识是，对于追求极致的推理效率的模型（尤其是需要处理长上下文和超大知识库的模型），"注意力层简化 + FFN层稀疏化"将是2027-2028年的默认配置。MoE在其中的角色也从"技术亮点"变为"基础设施组件"。

8. 量化、压缩与MoE蒸馏：让稀疏模型更轻

MoE模型部署的最后一个环节是压缩。一个671B参数的模型，即使激活量只有37B，总向的显存占用仍然是部署中的硬约束。量化、压缩和蒸馏在MoE模型上呈现了一些与稠密模型不同的特性。

8.1 差异化精度量化

MoE模型中不同组件的敏感性不同。经验表明，门控网络对量化的耐受度远高于专家网络——门控网络只做token分类（softmax输出分布），精度要求相对较低，FP8甚至INT4都能保持路由质量在可接受范围。而专家网络执行FFN计算，它的计算精度直接影响模型输出的质量。

基于这个观察，SF-vLLM和SGLang的FP8量化采用了差异化精度策略：

• 门控网络：INT4量化（路由质量几乎不受影响）
• 共享专家：FP8量化（精度敏感度中等）
• 路由专家：FP8量化，对部分关键维度（如第一个FFN层的输入投影）保留FP16

这种差异化策略可以在总参数量不变的前提下，将GPU显存占用再压缩约25-30%。以DeepSeek V4-Pro为例，FP8 + 差异化精度后，671B模型的总显存占用约670GB（原始FP16的1372GB减少了约51%），使得在8卡H100集群（8×80GB = 640GB，加上激活内存）上部署成为可能。

8.2 KV Cache压缩在MoE中的特殊性

MoE模型的KV Cache占用与稠密模型在总量上没有本质差异——因为KV Cache来自注意力层，与FFN层是否稀疏化无关。但在压缩策略上，MoE提供了一个额外的自由度：专家路由信息可以用于压缩KV Cache。

具体做法是：在压缩KV Cache时，同时对专家路由的分布信息进行编码。当模型从KV Cache恢复上下文时，路由信息也一并恢复，使后续解码步骤中的路由决策可以快速重建。这种方法在DeepSeek的KV2项目中得到了实证，将KV Cache压缩比从稠密模型的4-6倍提升到了MoE场景下的8-10倍。

8.3 MoE蒸馏

MoE蒸馏是一个介于"压缩"和"重新训练"之间的领域，2026年出现了两条截然不同的路线。

MoE-to-Dense蒸馏是从教师MoE模型中蒸馏出一个更小的稠密学生模型。Mixtral 8x7B的各种蒸馏版（如Mistral-Nemo）就是这条路线的例子。核心做法是将MoE门控网络的路由知识作为额外的蒸馏信号传递给学生模型——不仅让学生模仿教师模型的输出logits，还让学生学习教师模型对"哪些专家对这个token最有用"的内部表征。实验表明，加入路由蒸馏信号后，学生模型的收敛速度提升了约30%，同参数规模下的精度提升了2-3%。

Dense-to-MoE Up-cycling是反方向——将一个预训练的稠密模型"扩展"成一个MoE模型。Arcee Trinity走的就是这条路。Up-cycling的做法是：将稠密模型FFN层的权重复制N份，作为N个专家的初始化权重，然后新增一个随机初始化的门控网络，在新数据上进行少量微调。这种方法的优势在于跳过了从零训练MoE的高昂成本——稠密模型是现成的，只需要扩展和微调。代价是Up-cycling得到的MoE模型通常不如从头训练的MoE模型那么"稀疏"（专家间的专业化程度低），但以极低的成本获得了模型规模的提升。

8.4 专家剪枝

专家剪枝是终端部署场景下最令人关注的压缩技术。核心思路很简单：既然不是所有专家都在模型部署后的实际负载中被访问，那为什么不在部署之前把那些几乎从未被路由到的专家剪掉？

2026年的动态专家剪枝方法不再是"一刀切"的静态剪枝，而是路由感知的剪枝。具体做法是分析一段有代表性的deployment workload（比如应用场景中的真实用户请求）下的路由分布，将那些在deployment数据上路由概率之和低于某个阈值（如0.01）的专家标记为"可剪枝"。剪枝后对门控网络做少量微调，让路由分布重新适应。这种方法可以将模型参数量减少10-20%，而在特定场景下的精度几乎没有下降。

9. 前沿趋势：自适应路由、超专家与领域MoE

站在2026年中期回望，MoE架构在过去三年的演进步伐令人印象深刻。但更值得关注的是2026年前沿实验室中正在酝酿的下一代方向——它们可能定义2027-2028年的MoE形态。

9.1 从固定K到动态专家数

当前所有主流MoE模型都采用固定K路由——不管token是简单标点还是复杂推理链，都激活相同数量的专家。但直觉告诉我们，简单token不需要这么多专家，复杂token可能需要更多。

2026年的前沿工作是Token-level动态专家数：让门控网络输出一个"复杂度得分"，根据这个得分动态决定激活多少个专家。Google DeepMind正在探索的方案是：门控网络输出一个连续向量，然后通过可微分的top-k采样（类似Gumbel-Softmax的变种）让模型自主学习每个token的最佳专家数。初步实验表明，动态K相比固定K可以在保持精度的同时降低约15%的平均计算量——因为大部分token确实只需要较少的专家，只有少数困难token需要更多。这个方向还在研究阶段，但逻辑自洽，预计2027年左右会有工业级实现。

9.2 超专家（Super-Expert）架构

超专家（也叫Mega-Expert）的设想与大模型的"知识层次"结构有关。研究者发现，MoE模型的专家在语义专业化上呈现一种"长尾分布"：少数专家覆盖了大量基础语义（如语法、句法、基础世界知识），大量专家覆盖了长尾的专业知识（如医疗、法律、特定编程语言）。

超专家架构建议：设置一个规模显著大于其他专家的"顶层专家"，它负责处理所有token的基础通用能力；其余是数量众多但规模较小的领域专家。这个设计与DeepSeek的"共享专家"理念一脉相承，只不过共享专家的规模不再是"与单个路由专家相同"，而是"显著更大"，使其有能力承担更通用的表征学习任务。

9.3 领域MoE：预训练后新增专家的Xtuning

领域MoE（Domain-Specialized MoE）是最接近产业落地的方向，也是2026年最具商业价值的MoE创新之一。它的核心操作很简单：在预训练好的MoE模型上，不修改任何已有参数，仅新增一组领域专用的路由专家，然后在特定领域数据上做增量微调。

这个思路的吸引力在于经济性。微调一个稠密大模型来获得领域能力，通常需要全参数微调（Full Fine-tuning）或LoRA，前者成本极高，后者可能改变模型在其他领域的表现。而领域MoE的Xtuning只训练新添加的专家参数和门控网络的路由偏置，模型的其他参数全部冻结。例如，一个医疗领域的MoE扩展可能只添加4个医疗专家（约3B参数），用一个A100节点训练几天即可完成，且在保持通用能力不变的同时，医疗领域精度提升10-15%。

2026年已经有开源工具链支持领域MoE扩展——SGLang的MoE Xtuning模块和Hugging Face的PEFT库都对这种模式提供了原生支持。可以预见，2027年这一模式将成为企业私有化部署MoE模型的标准操作。

9.4 视觉与多模态MoE

MoE在多模态领域的进展同样不容忽视。视觉backbone（如ViT）中的MoE进化路径是：将ViT的Transformer块中的FFN替换为MoE层，使视觉模型也能获得稀疏计算的好处。2026年发布的ViT-5采用了"混合路由"的设计——部分层采用语义路由（token根据语义特征路由），部分层采用空间路由（token根据空间位置路由）。这种混合路由策略使视觉模型在大规模图像识别上将推理速度提升了3-4倍，精度几乎不变。

在多模态统一模型（如Gemini系列、GLM-5V）中，MoE的挑战在于不同模态的embedding分布差异巨大——文本token的embedding在一个子空间，图像的在一个子空间，音频的又在一个子空间。如果门控网络在训练初期没有做好模态感知的初始化，可能出现某个模态的token集体路由到一个专家的情况。解决方法是模态感知的路由初始化——为每个模态设置独立的初始路由概率分布，并在训练初期做模态间的负载均衡调节。

10. 结论：稀疏是一场组织架构革命

如果把MoE的发展历程放在一个更宏观的视角下来看，它会让人联想到软件工程架构的演变：从"单块巨石"到"微服务"。稠密模型就是一个单块巨石——一个巨大的FFN，承担所有知识的存储和所有token的处理。MoE把一个单块巨石拆成了一组小而专注的服务（专家），加一个路由层（API网关）。

这种类比不只是比喻上的相似，它在工程特征层面也是成立的。单块架构下，"维修"（模型更新）需要整个系统的停机和全面回归测试（全参数微调）。微服务架构下，可以只更新或替换少数几个服务（Xtuning新增或替换特定专家），不影响其他服务的运行（模型在其他领域的能力不受影响）。单块架构的扩展方式是"换更大的机器"（更大的稠密模型），微服务的扩展方式是"增加更多实例"（增加更多专家）。MoE就是机器学习的微服务架构。

对工程师的实操建议：如果你的场景要求极致性能且有足够预算进行大规模训练，MoE是目前为止最优的选择。如果你需要快速迭代、从小规模起步，或者目标部署环境对显存有强约束（如单卡消费级GPU运行），稠密模型（如Qwen2.5-32B、Llama 3.3-70B）仍然是更稳妥的起点——训练成本更低、部署更简单、生态支持更成熟。MoE是"规模起飞"之后的架构，不是"原型验证"阶段的架构。

MoE的训练工具链现状：Megablocks和Tutel（NVIDIA）提供了高效MoE内核实现，SGLang和vLLM提供了MoE推理引擎的完整支持，DeepSeek-Infrastructure的MoE训练组件虽然未完全开源但影响力巨大，Hugging Face Transformers的MoE支持也已从实验状态升级为一级特性。2026年，构建一个MoE模型的技术壁垒已经从"能不能做"降低到了"愿不愿意投入资源去做"——但这仍然是一个需要工程团队从全栈考虑的决策，而非一个简单的pip install。

展望2027年，MoE将走向"智能稀疏"——不是把专家做多、做小、做得更稀疏，而是让稀疏性本身更具智能：根据任务复杂度动态调整计算量，根据领域需求动态增减专家，根据部署负载动态调节路由策略。稀疏不再是目的，高效地分配智能才是。MoE用条件计算打破了Scaling Law的硬约束——它没有改变模型的极限能力，但它让万亿参数模型以可承受的成本服务于真实应用。这本身就是一场伟大的工程胜利。