稠密模型 vs. MoE 模型：激活参数、吞吐量与选型指南

一个300亿参数的模型如何能在每个token上只激活30亿参数，却仍然利用更大模型的容量？Nemotron 3.5 Lightning 说明了答案：它使用了混合专家（MoE）架构，为每个token只选择其参数的一个子集。

有两种主流的模型架构：稠密模型和MoE。模型如何组织其参数与它有多少参数同样重要。正确的选择对吞吐量、内存成本和服务复杂性的影响比原始参数数量更大。因此，在两者之间选择取决于你的部署约束。

把这种差异想象成两台总排量相同的发动机。一台在每个循环中点燃所有气缸；另一台只激活它需要的气缸。

这篇文章解释了：

• 稠密架构和MoE架构如何工作
• 它们如何影响性能
• 何时选择哪一种

稠密模型 vs. MoE模型

简单来说，稠密模型和MoE模型的区别在于它们如何使用参数。稠密模型为每个token激活其所有参数。MoE模型存储多个专家网络，但每个token只通过一个选定的子集进行路由。

稠密模型通常倾向于更简单、更可预测的部署，而MoE模型在内存和服务复杂性可控的情况下可以提供更大的容量和吞吐量。

视频1. 稠密 vs MoE：如何选择正确的AI架构

参数有何不同

在稠密模型中，每个参数都参与每次前向传递。一个27B模型的全部27B参数为每个token触发，通过每个解码器层中单个共享的前馈网络（FFN）块。

一个MoE模型用多个FFN块替换那个单个共享FFN，也称为专家。通过内部路由过程，传入的token通过一小部分专家处理，而不是每个参数都参与。在结构上，在稠密模型会有一个FFN的每个解码器层内部，MoE层有多个（例如8、64或128个）。一个学习到的门控网络，通常称为

路由器网络，位于所有这些之前，并将每个传入token分配给得分最高的k个专家。被选中的FFN块是为该token运行的块，而其余块在该特定层被跳过。不过，大多数现代MoE，例如

Mistral Small 4也

运行一个“共享”专家，每个token无论如何都会被路由到它。

MoE路由如何工作

对于MoE模型，路由决策对每一层都是独立的，这意味着一个token不会在被路由到一个专家后就留在那里进行其余计算。在每个解码器层，它会根据该token在网络中该点所表示的内容重新路由。每一层的这些专家并非传统意义上的专家，即专门研究某个主题，而是它们的专长主要在于语法和token类型模式（标点、数字等），尽管这因架构或训练方法而异。

虽然路由机制决定了在每个解码层跳过哪些 FFN 块，但 token 仍会像往常一样通过完整的注意力机制。当模型卡上写着“3B 激活参数”时，它包括了每个 token 的注意力权重和嵌入权重，以及被选中的 FFN 权重。

MoE 变体

MoE 也有多种变体，其中之一是 NVIDIA 的 Nemotron 3.5 Lightning 模型卡，它指定了一种 Mamba-2 + MoE + 注意力混合架构。在大多数层中，Mamba-2 层取代了注意力机制，它携带一个恒定大小的循环状态，而不是不断增长的 KV 缓存。这改变了长上下文下的内存占用情况，而这是仅靠稀疏性无法解释的。

Lightning 并非利用完整模型的广度来做出这些路由决策，而是先将它们压缩到一个更小的空间中，从而使模型的路由决策成本更低。下面的图 1 描述了通用的 transformer-MoE 情况。请注意，MoE 模型是一种稀疏模型。

图 1. 具有不同路由机制的稠密模型和稀疏模型解码器块 (

来源：Medium)## 哪个更快：稠密模型还是 MoE 模型？

MoE 模型通常在 token 吞吐量方面更快，因为它们只为每个 token 激活一部分前馈参数。稠密模型激活整个网络，但可以提供更简单的服务和更可预测的延迟。

在高并发情况下，路由和内存移动可能会缩小 MoE 的优势。结果还取决于硬件、精度、推理框架和模型设计。例如，Nemotron 3.5 Lightning 具有 Mamba-2 层和推测解码。

关键模型性能差异

两者之间的性能差异归结为两个主要方面。其一，在总参数数量相同的情况下，被跳过的 FFN 块使 MoE 更快。两者之间更重要的差异在于，MoE 将内存（总参数 → 显存到主机）与计算（激活参数 → 每 token 的 FLOPs）解耦。

在稠密模型中，托管和推理成本同步增长，而 MoE 打破了这种联系。使用 MoE 时，显存是预先支付的。当每个专家都加载到内存中时，计算是按 token 支付的，并且仅随激活的专家而扩展。空闲专家运行成本为零，但仍需支付存储它们所需的内存，使得从可变的每 token 计算转向固定内存成为主要的权衡。

在批大小为 1 时，解码受可用内存而非计算的限制，这正是 MoE 表现良好的地方，因为它每个 token 读取的权重字节更少。随着批大小的增长，token 总体上最终会使用网络中的大部分专家，这种优势会缩小，而每个 token 工作量的减少仍然存在。MoE 在各种批大小下都保持吞吐量优势，但与优化良好的稠密模型相比，其延迟优势在高并发时会缩小。

现代推理框架通常在不丢弃 token 的情况下处理路由，不过所有专家必须同时驻留在 GPU 内存中。与规模相当的稠密模型相比，这留给 KV 缓存的空间更少。

示例对比

下面的表 1 展示了一个直接对比。在总参数量相同的情况下，稀疏性在服务吞吐量上表现得十分明显：Gemma 4 31B 和 Nemotron 3.5 Lightning 的总参数量都约为 30B，但在 NVIDIA GPU 提供商之间，它们的输出速度区间并不重叠。每个 token 激活 3B 参数是一个主要原因，尽管不是唯一原因。Lightning 的 Mamba-2 层及其推测解码独立于混合 MoE 架构发挥作用。

Nemotron 3.5 LightningMistral Small 4表 1. 来自 Artificial Analysis 的输出速度与成本中位数数据（10K token 输入，检索于 2026 年 8 月 31 日）；基准测试仅覆盖 NVIDIA GPU 提供商

两者的权衡都可以观察到；例如，Lightning 的输出速度是 Qwen3.8-27B 的四到五倍，价格只有其十四分之一，而在通用能力上的得分不到其一半。这对于以规模化方式运行定义明确的步骤的智能体执行层来说是正确的，而对于一次困难的推理过程决定结果的情况则是错误的。

何时应该使用稠密模型或 MoE 模型？

在决定使用哪个模型时，取决于哪一个最能服务于你的部署场景。

有几个因素需要考虑：

内存预算：内存占用跟踪的是总参数量而非激活参数量，因此一个 30B 的 MoE 模型和一个 30B 的稠密模型都需要大约 60 GB。真正的问题在于这些 GB 能换来什么：稠密模型将其转化为能力，MoE 则转化为吞吐量。并发性：对于单个请求，MoE 明显胜出。其吞吐量优势在并发扩展时依然保持，但延迟差距会缩小。如果你在高并发下对延迟敏感，请在做出决定前对两者都进行基准测试。微调方案：稠密模型的微调更简单；所有参数都会激活，梯度均匀流动。对 MoE 模型进行全量微调可能会使路由器失衡，导致某些专家比其他专家更受欢迎，或者某些专家被完全淘汰。LoRA/PEFT 方法有助于避免这一问题，同时也可以直接冻结路由器。NeMo 针对 Lightning 的监督微调配方专门为该模型正确处理了这一点。量化：压缩比并不是架构差异所在之处。在实践中，有两件事更重要。首先，检查检查点本身已经以什么精度发布：Mistral Small 4 原生就是 FP8，因此 4 位量化只能再带来约 1.7 倍的压缩（121GB → 71GB），而不是 4 倍。其次，两种架构都有量化效果很差的模块，而且它们并不相同。在 MoE 中，是路由器，因为微小的扰动就会翻转离散的路由决策。相关配方会将路由器、嵌入层和输出头保持在更高精度，而在混合注意力模型中，翻转路由决策的是循环投影。例如，量化版 Qwen3.8-27B 的构建版本正是出于这个原因将线性注意力块保持在 BF16。

核心权衡

稠密模型和 MoE 是对同一个权衡的两种回答：每参数能力与每 token 计算量之间的权衡。稠密模型让一切保持简单、让所有参数都处于激活状态，这使其更易于微调和部署。MoE 用内存换取吞吐量，并在服务复杂性上付出代价。

Nemotron 3.5 Lightning 完全开放，包括权重、数据和配方，因此你可以将其适配到你的工作流中，并部署到任何地方。要开始使用，可以在 build.nvidia.com 或通过 OpenRouter 试用。从 Hugging Face 和 ModelScope 下载权重。

对于物理 AI 工作负载，AgiBot GO-1 和 Tencent Hy-Embodied-VLM-1.0 是生态系统中流行的选择。