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

一个 30B 参数的模型，怎么能做到每个 token 只激活 3B 参数，却依然用上更大模型的容量？Nemotron 3.5 Lightning 给出了答案：它采用混合专家（Mixture-of-Experts，MoE）架构，每个 token 只选用其中一部分参数。

主流的模型架构有两种：稠密（Dense）模型和 MoE。模型如何组织参数，与它有多少参数同样重要。这个选择对吞吐量、显存成本和部署复杂度的影响，比单纯的参数量更大。因此，在两者之间做选择，取决于你的部署约束。

可以把这种差别想象成两台总排量相同的发动机：一台每个循环都让所有气缸点火，另一台只启用需要的气缸。

本文将介绍：

• 稠密与 MoE 架构的工作原理
• 它们如何影响性能
• 何时该选哪一种

稠密模型 vs. MoE 模型

简单来说，稠密模型和 MoE 模型的区别在于如何使用参数。稠密模型对每个 token 都激活全部参数。MoE 模型存储多个专家网络，但每个 token 只会被路由到其中被选中的一小部分。

稠密模型通常更适合追求更简单、更可预测的部署；而在显存和部署复杂度可控的情况下，MoE 模型能提供更大的容量和更高的吞吐量。

▶ https://www.youtube.com/watch?v=Nc481t18dKw

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

参数的差别

在稠密模型中，每个参数都参与每一次前向传播。一个 27B 模型的全部 27B 参数会在每个 token 上全部激活，每个解码器层只经过一个共享的前馈网络（FFN）块。

MoE 模型把这个单一的共享 FFN 替换成多个 FFN 块，也就是专家。通过内部的路由过程，输入的 token 只由一小部分专家处理，而不是动用每一个参数。从结构上看，在稠密模型每个解码器层只有一个 FFN 的位置，MoE 层有多个（例如 8、64 或 128 个）。一个可学习的门控网络（通常称为路由器网络）位于所有专家之前，把每个输入 token 分配给得分最高的前 k 个专家。被选中的 FFN 块会为该 token 运行，其余的则在这一层被跳过。不过，像 Mistral Small 4 这样的大多数现代 MoE 还会运行一个“共享”专家，无论如何每个 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 模型属于稀疏模型的一种。

稠密模型和 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 架构无关。

表 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 是生态中广受欢迎的选择。