一个300亿参数的模型如何仅激活30亿参数处理每个Token，却依然能发挥大模型的能力？Nemotron 3.5 Lightning给出了答案：它采用混合专家（Mixture-of-Experts，MoE）架构，为每个Token只选择一部分参数参与计算。
目前主流的模型架构有两种：稠密模型（Dense model）和MoE模型。一个模型如何组织其参数，与它拥有多少参数同样重要。相比原始参数数量，正确的架构选择对吞吐量、内存成本和服务复杂度的影响更大。因此，在两者之间做出选择，最终取决于你的部署约束条件。
可以把这种差异想象成两台排量相同的发动机。一台在每个循环中点燃所有气缸；另一台则只激活它所需要的气缸。
本文将解释：
稠密架构与MoE架构的工作原理
它们如何影响性能
何时该选择哪一种
稠密模型与MoE模型
简单来说，稠密模型与MoE模型的区别在于它们如何使用参数。稠密模型在处理每个Token时会激活所有参数。MoE模型则存储多个专家网络，但每个Token只会被路由到其中被选中的一小部分。
稠密模型通常更适合追求部署简单、性能可预测的场景，而MoE模型在内存和服务复杂度可控的前提下，能够提供更大的容量和更高的吞吐量。
参数运作方式的差异
在稠密模型中，每一次前向传播都会用到全部参数。一个270亿参数的模型，其全部270亿参数都会在处理每个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仍会照常经过完整的注意力机制。当模型卡片上标注“30亿激活参数”时，它既包含了每个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的浮点运算数）解耦开来。
在稠密模型中，托管成本和推理成本是同步扩展的，而MoE打破了这种关联。使用MoE时，显存成本是预先支付的。当所有专家都加载到内存中后，计算成本按Token计费，且仅随被激活的专家数量而扩展。闲置的专家运行时不产生任何计算成本，但仍需占用相应的内存空间来存储，这种从“按Token可变计算”到“固定内存占用”的转变，正是其中的核心权衡所在。
在批处理大小为1时，解码过程受限于可用内存而非计算能力，这正是MoE表现出色的场景，因为它每个Token只需读取更少的权重字节。随着批处理大小的增加，各个Token累计会用到网络中的大部分专家，这一优势会随之缩小，但每个Token所需工作量的减少这一优势依然存在。在不同批处理大小下，MoE始终保持吞吐量优势，但与一个经过良好优化的稠密模型相比，其在高并发场景下的延迟优势会有所收窄。
现代推理框架通常能够在不丢弃Token的情况下处理路由，不过所有专家都必须同时驻留在GPU内存中。这样留给KV缓存的空间，就会比同等规模的稠密模型通常所拥有的空间要少。
实例对比
下表1展示了一个直接的对比。在总参数规模相等的情况下，稀疏性对服务吞吐量的影响十分明显：Gemma 4 31B和Nemotron 3.5 Lightning的总参数量都约为300亿，但在不同的NVIDIA GPU服务商环境下，两者的输出速度区间完全没有重叠。每个Token仅激活30亿参数是造成这一差异的主要原因，但并非唯一原因。Lightning的Mamba-2层及其推测解码机制也独立地为此做出了贡献。
从中可以看出两者各自的取舍：例如，Lightning的输出速度是Qwen3.8-27B的四到五倍，价格却只有其十四分之一，但在综合能力评测上得分不到后者的一半。这种特性非常适合大批量执行明确步骤的智能体执行层场景，但不适合那种由单次高难度推理过程决定最终结果的场景。
何时该使用稠密模型或MoE模型？
至于该选择哪种模型，取决于哪一种更适合你的部署场景。
以下几个因素值得考虑：
内存预算：内存占用取决于总参数量而非激活参数量，因此一个300亿参数的MoE模型和一个300亿参数的稠密模型大致都需要约60GB内存。真正的问题在于，这些内存空间能为你换来什么：稠密模型将其转化为能力，而MoE将其转化为吞吐量。
并发处理：对于单个请求而言，MoE明显更有优势。随着并发数的增加，其吞吐量优势会持续保持，但延迟差距会逐渐缩小。如果你的场景对高并发下的延迟较为敏感，建议在做决定前分别对两种架构进行基准测试。
微调计划：稠密模型的微调更为简单；所有参数都会被激活，梯度也能均匀流动。而对MoE模型进行完整微调，可能会打破路由的平衡，使得某些专家变得比其他专家更“受欢迎”，甚至导致某些专家被彻底淘汰。LoRA/PEFT等方法，连同直接冻结路由网络的做法，有助于避免这一问题。NeMo针对Lightning的监督微调方案，就专门为该模型正确处理了这一问题。
量化处理：架构差异体现在压缩比上的影响并不明显，实践中有两个因素更为重要。首先，需要确认模型检查点本身已经采用的精度：例如Mistral Small 4原生就是FP8精度，因此4-bit量化带来的实际提升约为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和腾讯的Hy-Embodied-VLM-1.0是该生态系统中颇受欢迎的选择。
Q&A
Q1：稠密模型和MoE模型有什么区别？
A：稠密模型在处理每个Token时会激活全部参数，而MoE模型则为每个Token只激活一部分“专家”参数。这种差异使得MoE模型在内存占用相同的情况下，通常能实现更高的吞吐量，而稠密模型则更易于部署和微调。
Q2：MoE模型一定比稠密模型运行速度更快吗？
A：并非绝对。在低并发或单个请求场景下，MoE模型的吞吐量优势明显；但随着并发数增加，各Token会累计用到大部分专家，这一优势会逐渐缩小，实际表现还取决于硬件、精度和推理框架等因素。
Q3：Nemotron 3.5 Lightning有什么特点？
A：它是一款采用Mamba-2 + MoE + 注意力混合架构的模型，总参数约300亿，但每个Token仅激活约30亿参数，配合推测解码技术，在保持较低成本的同时实现了较高的输出速度，其权重、数据和训练方案均已完全开放。
