什么是MoE稀疏专家模型：以35B总参数量与3B激活参数为例解析其设计逻辑

作者：carzy2026.11.03 15:06浏览量：0

简介：本文以一类总参数量为35B、单次推理仅激活3B参数的混合专家模型为对象，系统解释MoE架构的定义、核心组成、工作原理与适用场景。文章会说明“总参数”与“激活参数”的区别，分析这类模型为何能在控制推理成本的同时提升代码智能体与语言能力，并给出选型、部署和运维层面的注意事项。

一、概念定义：它是什么

在深度学习模型设计中，有一类模型被称为混合专家模型，英文常写为 Mixture of Experts，简称 MoE。它的核心特点是：模型内部包含多个并行的“专家”子网络，但一次推理并不会调用全部专家，而是由一个小型路由机制根据输入内容动态选择其中一部分专家参与计算。

因此，当人们提到“总参数规模为 35B、每个 token 仅激活约 3B 参数”时，指的就是这类模型的一种典型配置。这里的 35B 表示模型中所有专家以及其他组件加在一起的参数总量，约为 350 亿；而 3B 表示处理单个 token 时实际参与前向计算的参数量，约为 30 亿。

可以从三个角度理解这个概念：

  • 从技术视角看，MoE 是对传统稠密模型的一种结构扩展。稠密模型中，每个输入都会经过全部参数计算；而在 MoE 中，输入会根据自身特征被路由到不同专家，从而减少单次计算量。
  • 从业务视角看，它是一种用参数规模换取能力、用稀疏激活换取推理效率的折中方案。它希望在不显著增加每次推理成本的前提下，获得更大模型才能具备的知识容量与表达能力。
  • 从使用视角看，开发者拿到的是一个可部署的模型权重，它看起来像一个普通模型，但内部计算路径会根据输入动态变化。

因此，所谓的“35B-A3B”并不是指两个独立模型，而是对同一个 MoE 模型的两个关键指标进行描述：总参数规模与单 token 激活参数规模。

二、背景与价值：为什么需要这种设计

在模型能力提升的过程中，直接扩大稠密模型参数规模是最直观的方法。然而，参数规模越大，推理时所需的计算资源、显存占用和响应时间也越高。对于需要高频调用、低延迟响应的场景，这种成本增长往往难以接受。

MoE 架构的出现，正是为了在“能力提升”和“推理成本”之间寻找新的平衡点。

以总参数 35B、激活参数 3B 的配置为例，它意味着模型在存储层面拥有较大规模的知识容量，但在实际执行一次 token 推理时，只需要承担接近 3B 参数规模的计算负载。这让模型有可能在以下方面获得收益：

  1. 提高知识密度：总参数量大，意味着模型可以容纳更多语言知识、代码模式和推理经验。
  2. 控制单次推理成本：激活参数小，意味着计算量、延迟和能耗不会随总参数同步增长。
  3. 增强任务适配能力：不同专家可以学习不同领域或不同类型任务的特征，路由机制根据输入内容进行选择，使模型在面对代码、自然语言或视觉语言任务时更加灵活。

不过，这种设计并非没有代价。与同等总参数规模的稠密模型相比，MoE 模型在部分任务上的综合能力可能偏弱，因为单个输入只能利用其中一部分参数。这是 MoE 设计中的固有取舍。

三、核心组成：MoE 模型的关键模块

一个典型的 MoE 模型通常由以下几个部分构成：

1. 专家网络

专家网络是模型的主体部分。每个专家可以是一个前馈网络，也可以是更复杂的子结构。不同专家在训练过程中会逐渐分化，形成对不同特征的偏好。例如，有的专家更擅长处理数学推理，有的更擅长代码语法，有的则更关注自然语言语义。

在总参数 35B 的模型中，专家网络通常占据了大部分参数。假设模型包含若干层，每一层都配置了多个专家，那么总参数规模会随专家数量增加而快速上升。

2. 路由机制

路由机制是 MoE 的关键组件。它负责为每个输入 token 选择最合适的专家。通常，路由会输出一组权重，表示各个专家对当前输入的重要性，然后选择权重最高的若干专家参与计算。

例如，一个 token 可能被分配给专家 2 和专家 7，而下一个 token 则被分配给专家 1 和专家 5。这种动态分配使得不同 token 的计算路径不同。

3. 稀疏激活策略

稀疏激活是指每次只激活少量专家，而不是全部。例如，一个模型可能配置了 128 个专家，但每个 token 只选择其中 2 个进行激活。这种策略可以显著降低计算量。

需要注意的是，稀疏激活并不意味着模型只存储了少量参数。所有专家参数仍然需要被保存在显存或内存中，只是在计算时不会全部参与。

4. 共享组件

除了专家网络，MoE 模型通常还包含一些共享组件，例如注意力层、嵌入层和输出层。这些组件不参与专家路由，而是对所有 token 共享。因此，激活参数通常只统计专家部分，而不包括共享组件。

四、工作原理：路由、专家计算与结果融合

MoE 模型的前向计算过程可以概括为以下几步：

  1. 输入编码：token 进入模型后，先经过嵌入层和注意力层，得到中间表示。
  2. 路由评分：路由机制读取中间表示，为每个专家计算一个相关性分数。
  3. 专家选择：根据分数选择 top-k 个专家。k 通常是 1、2 或 4，具体取决于模型设计。
  4. 专家计算：被选中的专家对输入进行计算，输出各自的处理结果。
  5. 加权融合：将专家输出按照路由权重进行加权求和，得到该层的最终输出。
  6. 逐层重复：在多层结构中，每个 token 会逐层经过上述过程，最终得到模型输出。

上述过程可以用以下伪代码表示：

  1. for each token:
  2.     hidden_state = attention(token)
  3.     router_scores = router(hidden_state)
  4.     selected_experts = top_k(router_scores, k=2)
  5.     expert_outputs = []
  6.     for expert in selected_experts:
  7.         output = expert(hidden_state)
  8.         expert_outputs.append(output)
  9.     layer_output = weighted_sum(expert_outputs, router_scores)

可以看到，虽然模型总参数很大，但每个 token 只经过少量专家计算。这就是“总参数 35B、激活参数 3B”这类表述的由来。

五、典型应用场景

MoE 模型因其参数规模与推理效率之间的平衡，适用于多种场景。

1. 代码智能体与终端任务执行

在代码智能体场景中，模型需要根据用户指令生成代码、理解终端输出、规划后续操作。这类任务通常链条较长，需要模型具备较强的代码理解与规划能力。由于激活参数较少，模型可以在不显著增加延迟的情况下处理较长的上下文。

从公开评测结果来看，这一类模型在终端任务基准测试中的表现有明显提升，说明其在多步骤工具调用和代码生成方面具备实用价值。

2. 自然语言推理与知识问答

MoE 模型适合作为通用语言模型底座，用于开放域问答、文本摘要、内容分类等任务。较大的总参数量使其能够吸收更广泛的知识，而稀疏激活则控制了推理时的资源消耗。

3. 视觉语言任务

部分 MoE 模型还支持视觉语言能力，例如图像描述、视觉问答等。在这类任务中，路由机制可能需要对图像特征和文本特征同时进行专家分配，使模型能够处理跨模态信息。

4. 云端 API 与本地部署

由于激活参数较低，这类模型在推理速度上具有一定优势，适合以 API 形式提供对外服务，也适合在资源相对受限的环境中部署。开发者可以根据自身需求选择使用托管接口或自行部署权重。

六、相关概念区别：MoE 与稠密模型、模型量化

在理解 MoE 模型时，容易与以下几个概念混淆。

1. MoE 与稠密模型

稠密模型在每次推理时都会激活全部参数。例如，一个 27B 的稠密模型，每个 token 都会经过 27B 参数计算。而 MoE 模型可能总参数达到 35B，但单 token 只激活 3B 参数。

两者的区别不在于总参数量，而在于“单次推理的计算量”。MoE 可以用更大的总参数规模获得更好的表达能力，同时保持较低的单次计算成本。

2. MoE 与模型量化

模型量化是通过降低参数精度来减少显存占用和计算量，例如从 FP16 转为 INT8。它不改变模型结构，而是改变数值表示方式。

MoE 则是一种结构性稀疏，通过动态选择专家来减少计算。两者可以结合使用，但解决的问题不同。量化主要降低单次计算的硬件开销，而 MoE 主要减少实际参与计算的参数量。

3. MoE 与模型蒸馏

模型蒸馏是使用大模型作为教师模型训练小模型，缩小模型整体体积。蒸馏后的小模型通常是稠密模型，参数量更小，但能力可能接近大模型。

MoE 不会直接生成一个小模型，而是保留大量专家参数，通过路由实现条件计算。它更适合希望在保持较大模型容量的同时控制推理成本的场景。

七、使用注意事项

在实际选型和部署 MoE 模型时，需要关注以下几个问题。

1. 显存占用

虽然激活参数较少，但模型总参数仍然需要加载到显存或内存中。对于总参数 35B 的模型，即使使用半精度或量化存储，也需要较大的存储空间。因此，在本地部署前应评估硬件条件。

2. 推理延迟

MoE 模型的延迟不仅取决于激活参数，还取决于路由计算、专家切换以及硬件调度效率。在批量推理场景中，不同 token 可能被分配到不同专家，这会增加并行计算的复杂度。因此，实际延迟不一定与激活参数成线性关系。

3. 训练稳定性

MoE 模型在训练过程中容易出现负载不均衡的问题，即某些专家被频繁选择，而另一些专家很少被激活。这会导致部分专家训练不充分，影响整体效果。因此，训练时通常需要引入负载均衡损失或其他约束。

4. 微调与适配

如果需要针对特定业务场景进行微调，应关注路由机制的稳定性。由于专家选择是动态的，微调时可能出现专家利用不均的情况。建议在小规模数据上先进行验证，观察不同专家的激活分布是否合理。

5. 安全与合规

对于涉及敏感数据或对外提供服务的场景，应关注模型输出内容的合规性。无论采用托管 API 还是自建部署，都需要配合内容审核、访问控制和日志审计等机制。

八、总结

总参数 35B、激活参数 3B 的模型，是一类典型的混合专家模型配置。它通过多个专家网络与动态路由机制，实现了“大参数容量”与“低单次计算成本”之间的平衡。

从定义上看，它的关键特征不是总参数有多大，而是每次推理只激活其中一部分参数。这种设计让模型能够在代码智能体、自然语言推理和视觉语言等场景中提供较强的能力，同时为云端服务和本地部署保留了效率空间。

但 MoE 并非银弹。它与稠密模型相比存在一定能力折中，在显存占用、训练稳定性、微调适配和推理调度方面也有需要特别关注的问题。理解“总参数”与“激活参数”的区别，是正确评估这类模型适用性的第一步。只有在明确业务需求、资源限制和性能目标之后，才能判断它是否比传统稠密模型更适合当前场景。

最热文章