MoE模型：稀疏化革命如何突破大语言模型扩展瓶颈？

引言

过去几年，大规模稠密语言模型的扩展是推动大语言模型 (LLMs) 发展的主要动力。从早期如ULMFiT（约3000万参数）或GPT-2（15亿参数）等模型，到如今拥有数千亿参数的系统，其核心扩展思路始终遵循一个简单的范式：

数据越多 + 参数越多 = 性能越好

缩放定律进一步强化了这一趋势。然而，纯粹扩展稠密模型正面临严峻的现实瓶颈：
* 训练成本呈指数级增长
* 推理延迟不断增加
* 部署需要海量的内存和硬件资源

这正是专家混合模型 发挥作用、开启稀疏化革命的关键所在。

如果你已了解MoE基础，想直接查看其在Transformers中的工程实现，可以跳转到相关章节。

从稠密到稀疏：什么是MoE？

MoE模型保留了Transformer的主体架构，但将其中的部分稠密前馈网络层替换为一组专家。这里的“专家”并非指特定领域（如数学或代码）的专家，而是一个可学习的子网络。对于输入的每个token，一个路由器会动态选择少数几个专家来处理。

图1：在4个专家中，路由器为当前token激活了专家1（示意图）

不同的token会根据其隐藏状态激活不同的专家组合。这带来了MoE的核心优势：

模型的总容量取决于所有专家的参数量，而推理速度仅取决于每个token实际激活的参数量。

以gpt-oss-20b模型为例：其总参数量为210亿，但每个token仅激活32个专家中的4个。加上模型中的共享参数，每个token实际仅使用约36亿参数进行计算。在一台内存带宽约为800GB/s的M3 Ultra Mac上，其理论生成速度可粗略估算为：

800 / (3.6 × 2) （bfloat16精度下，每个参数占2字节）

结果约为 111 tokens/s，而实际测得的速度约为 115 tokens/s，与估算高度吻合。这说明模型在推理时的计算开销类似于一个36亿参数的稠密模型，却能发挥出接近210亿参数模型的性能。

(注：若使用模型原生的mxfp4量化内核，速度还会进一步提升。)

MoE的优势主要体现在以下几个方面：

1. 更高的计算效率：在相同的训练计算量预算下，MoE模型通常能获得优于同等规模稠密模型的性能。
   
   图2：稠密模型与MoE模型的训练损失对比曲线

2. 天然适合并行计算：专家网络构成了计算图中清晰的结构边界。由于不同token使用不同的专家，可以在专家维度上进行高效的并行计算。

3. 行业广泛采用：MoE已成为当前大模型架构的重要趋势。近期发布的开源MoE模型包括Qwen 3.5、MiniMax M2、GLM-5、Kimi K2.5等。这一趋势在DeepSeek R1发布后明显加速，其架构可追溯至更早的DeepSeek V2。更早的代表性作品还有2023年12月发布的Mixtral-8x7B。
   
   图3：近两年内Transformers库中MoE模型数量的增长趋势，DeepSeek R1的发布是一个重要拐点

闭源模型同样广泛采用了MoE架构。ChatGPT长期被推测采用了稀疏架构，而开源模型gpt-oss系列则明确采用了MoE设计。

Transformers与MoE

当前生态系统中的大多数工具（如模型加载、设备分配、量化和执行后端）最初都是为稠密模型设计的。MoE的稀疏特性对这些底层假设提出了挑战。

要让MoE在transformers库中成为一等公民，不仅需要添加新的模型类，更需要对模型加载流程、执行机制以及分布式抽象进行系统性重构。接下来，我们将重点介绍transformers库是如何逐步演进以支持稀疏架构的：

• [权重加载重构]
• [专家执行后端]
• [专家并行]
• [使用Transformers训练MoE]

权重加载重构

对于稠密模型，AutoModelForCausalLM.from_pretrained(“model_id”)这一过程相对直接：从检查点下载的每个权重张量，通常都能一一对应到运行时模块的某个参数上。

但对于 MoE 模型，情况则更为复杂。在大多数 MoE 模型的检查点中，每个专家（Expert）的权重都是被单独序列化保存的。例如，查看 DeepSeek-V3 的检查点索引文件，你会看到类似以下的键名：

model.layers.3.mlp.experts.0.gate_proj.weight
...
model.layers.3.mlp.experts.255.gate_proj.weight

每个专家都拥有自己独立的一组权重矩阵。以 DeepSeek-V3 为例，其本质是将 256 个（编号 0 到 255）小型前馈网络（FFN）的权重并排保存。

然而，在模型实际运行时，GPU 执行的是经过高度优化的计算内核。现代 MoE 内核，例如 grouped GEMM 和融合式 MoE 实现，其设计目标是通过单次操作同时处理所有专家，而非对专家进行循环遍历。

为了实现这种高效计算，就需要将所有专家的权重预先打包成一个连续的张量。

这就产生了一个关键的不匹配：
* 检查点格式： 256 个独立的张量。
* 运行时需求： 1 个打包后的连续张量。

权重加载重构的核心作用，就是通过一种系统化的方式来弥合这一差距。其思路从传统的“检查点结构与运行时结构匹配，只需逐键复制”，转变为一种更灵活的理念：检查点只是张量的序列化来源。加载过程本质上是一个转换流水线，它会将这些原始张量转换为运行时所需的布局。

使用 WeightConverter 实现动态加载

此次重构引入的核心抽象是 动态权重加载，它通过 WeightConverter 类来实现。

WeightConverter 允许我们定义从源格式到目标格式的映射规则：
source key patterns → target key(s) + operations

基础操作（如切分、拼接等）可以灵活组合。其中，有两个操作在 MoE 场景中尤为常用：

• MergeModulelist：用于将一组张量合并为一个张量。例如，可以组合使用 MergeModulelist 和 Concatenate 操作，将 MoE 层中多个专家的权重堆叠并打包成一个统一的张量。
  python
WeightConverter(
["block_sparse_moe.experts.*.w1.weight", "block_sparse_moe.experts.*.w3.weight"],
"mlp.experts.gate_up_proj",
operations=[
MergeModulelist(dim=0),
Concatenate(dim=1),
],
)
• SplitModulelist：用于将一个张量拆分回一组张量。例如，可以将已经堆叠打包的专家权重重新拆分为独立的专家权重。
  python
WeightConverter(
"mlp.experts.down_proj",
"block_sparse_moe.experts.*.w2.weight",
operations=[SplitModulelist(dim=0)],
)

张量的延迟实例化

此次重构不仅增强了转换能力，还优化了转换任务的调度执行策略。

加载器会首先扫描检查点的所有键，并与预定义的转换规则进行匹配，然后按转换器对张量进行分组。当一个键被确定需要使用时，它会被注册为一个“未来”任务，并通过线程池进行实际的加载。只有当某个转换操作所需的所有依赖张量都准备就绪后，该操作才会被执行。例如，MergeModulelist 操作必须等待某一层所有专家的权重都加载完成后才会启动合并。

这种延迟实例化的机制，有效减少了重复扫描和内存使用的峰值。

基准测试：权重加载流程的性能提升

为了量化评估新权重加载流程带来的改进，我们对 transformers 库的 v4 和 v5 版本进行了基准测试。测试重点聚焦于大型 MoE 模型的加载速度，因为这在训练和推理中通常是一个性能瓶颈。

测试使用了以下代码分支进行对比：
* v4 分支
* v5 分支

测试示例代码如下：
“`python
from transformers import AutoModelForCausalLM

model_id = “Qwen/Qwen1.5-110B-Chat”
model = AutoModelForCausalLM.from_pretrained(model_id)
“`

测试中涉及两个关键的环境变量：
* HF_ENABLE_PARALLEL_LOADING：用于启用基于线程的分片并行加载功能。

环境变量 HF_DEACTIVATE_ASYNC_LOAD

• HF_DEACTIVATE_ASYNC_LOAD：设置为 True 可关闭 v5 版本中默认启用的异步加载流程，作为回退到旧版同步加载方式的选项。

性能测试结果

测试模型： Qwen/Qwen1.5-110B-Chat
测试硬件： 1× A100 (80GB)

| 版本 | 并行策略 | 加载方式 | 加载时间 |
| :— | :— | :— | :— |
| v4.57.6 | auto | 线程池 | 66.24s |
| v4.57.6 | auto | 顺序 | 67.29s |
| v4.57.6 | TP | — | OOM |
| v5 | auto | 异步 (默认) | 20.71s |
| v5 | auto | 同步 | 45.3s |
| v5 | TP | 异步 | 10.1s |
| v5 | TP | 同步 | 19.28s |

图 4：不同 Transformers 版本下的模型加载性能对比

这种显著的性能提升并非简单地通过增加线程数量实现，而是源于一系列底层优化机制的协同作用：

• 单次扫描路由 (Single-pass routing)
• 异步实例化 (Async materialization)
• 感知转换的调度 (Conversion-aware scheduling)

这些机制共同避免了不必要的中间张量创建和内存峰值，并能在加载阶段同步完成专家权重打包和投影融合等优化操作。

量化流程的集成

此次重构实现了“先构建模型计算图，后填充权重”的流程。这使得量化可以作为权重加载流程中的一个可选步骤被无缝集成。这一点至关重要，因为只有在专家权重以统一且可预测的打包结构存在后，“按专家进行量化” 的策略才具有实际意义。这种端到端的处理流程在之前是无法实现的，现已通过公开 API 提供给开发者使用。

专家执行后端

当专家权重完成打包后，下一个核心问题是：如何高效地执行专家路由计算？

在 MoE 模型中，每个 token 会被路由到不同的专家。这要求在运行时完成一系列操作：将 token 分发至对应的专家权重、高效执行投影计算、应用路由权重，最后对结果进行汇总与重排。

专家后端系统（在 PR #42697 中引入）正是为了解决这些问题而设计。它提供了一种可插拔的执行架构，将专家计算逻辑与具体的模型实现解耦。这意味着无需在每个 MoE 模型中硬编码特定的调度策略，而是可以在运行时为专家层动态选择最合适的后端实现。

该机制通过装饰器模式实现：
python
@use_experts_implementation
此装饰器会封装专家类，并自动将计算分发到所选的后端执行。

目前系统提供了三种后端实现：

1. eager：逐个遍历被激活的专家并分别执行投影计算。主要用于结果验证和调试。
2. batched_mm：基于 torch.bmm 实现。它会为每个 token 复制对应专家的权重，然后通过一次批量矩阵乘法完成计算。适用于批处理规模较小、GPU 计算能力强且显存充足的场景。
3. grouped_mm：基于 torch._grouped_mm 实现。它会先按照专家 ID 对 token 进行排序和分组，然后通过一次分组矩阵乘法完成计算。这种方式在大规模批处理或显存受限的情况下通常表现更优。

图：专家后端执行流程示意图

专家并行

MoE 模型的参数量可达数千亿级别，远超单张 GPU 的承载能力。专家并行 通过将专家分布到多个设备上来解决这一问题。每个设备仅加载并负责计算分配给自己的那部分专家，最后参与全局结果的汇总。

由于每个 token 通常只激活少数几个专家，这种并行方式可以在不显著增加计算开销的前提下，将模型扩展到更大的参数规模。

可以通过设置 enable_expert_parallel=True 来启用专家并行：
“`python
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from transformers.distributed.configuration_utils import DistributedConfig

distributed_config = DistributedConfig(enable_expert_parallel=True)

model = AutoModelForCausalLM.from_pretrained(
“openai/gpt-oss-120b”,
dtype=”auto”,
distributed_config=distributed_config,
)
使用以下命令启动：bash
torchrun –nproc-per-node N script.py
``
其中N` 应能整除专家总数，通常也等于使用的 GPU 数量。

当启用专家并行后，模型会从标准的张量并行策略切换为专家并行策略，并采用专门的权重切分方式。其核心组件包括：

1. GroupedGemmParallel：沿专家维度（dim=0）对权重进行切分，确保每个设备仅加载 专家总数 / 设备数量 的专家权重。
2. RouterParallel：将全局专家索引映射为本地索引，过滤掉不属于当前设备的专家，确保每个设备仅使用本地专家进行计算，并通过 all-reduce 操作在设备间汇总部分计算结果。

使用 Transformers 训练 MoE 模型

MoE 模型在推理扩展方面表现出色，但其训练过程则要复杂得多。

主要挑战包括：参数规模极其庞大、专家间的分布式通信复杂，以及路由过程的不稳定性。针对这些挑战，社区通过引入 Expert Backend 抽象、优化核心算子等方式，实现了更高效的 MoE 训练方案，具体表现在：

• 训练速度：相比传统方法有显著提升。
• 显存占用：得到有效降低。
• 上下文长度：支持更长的序列处理。

在技术实现上，通过统一采用 PyTorch 的 torch._grouped_mm API，并结合自定义的 Triton grouped-GEMM 等优化内核，对 MoE 层的前向与后向传播进行了深度优化。这些改进已集成至 transformers 库中，为用户提供了更高效的训练与推理体验。

有关 MoE 模型性能优化的技术细节，可参阅相关开源项目与官方文档。

总结

随着稀疏化架构的持续演进，transformers 库也将同步更新，以支持最新的模型与技术。我们欢迎正在使用或研究 MoE 模型的开发者提供反馈，例如你希望在该库中看到哪些新的抽象接口、算子优化或工作流程改进。

英文原文: https://huggingface.co/blog/moe-transformers

原文作者: Aritra Roy Gosthipaty, Pedro Cuenca, merve, Ilyas Moutawwakil, Arthur Zucker, Sergio Paniego, Pablo Montalvo

译者: Luke, Hugging Face Fellow

关注“鲸栖”小程序，掌握最新AI资讯