一个30B参数的模型，每个token只激活3B参数，却依然能用上大模型的容量。Nemotron 3.5 Lightning给出的答案，是Mixture-of-Experts（混合专家，MoE）架构——它只为每个token挑选一部分参数参与计算。

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

打开网易新闻 查看精彩图片

两种引擎，同一排量

打个比方：两台总排量相同的发动机。一台每个循环都点燃所有气缸，另一台只点燃当下需要的那几个。

显存和算力，被拆开了

MoE模型把所有专家都加载进显存，但每个token只激活其中一部分；Dense模型则不同，显存成本和计算成本是一起增长的。

所以在总参数量相同的前提下，MoE模型能拿到更高的token吞吐。Nemotron 3.5 Lightning就是例子，它的总参数是30B，每token只激活3B，吞吐表现优于同等参数规模的稠密模型，比如Gemma 4 31B。

不过这个优势不是无条件的。在高并发场景下，MoE的延迟优势会收窄。

部署前要算的四笔账

选Dense还是MoE，不能只看参数数量。真正决定的是部署约束，至少有这么几项要提前想清楚：

  • 显存预算：MoE要把全部专家装进显存，预算不够直接出局
  • 并发需求：高并发下MoE的延迟优势会变窄，需要重新评估
  • 微调计划：MoE微调要小心路由失衡问题
  • 量化行为：量化对路由层和循环投影层的影响，跟稠密模型的组件不一样

这四项里，微调和量化是最容易被低估的。MoE微调时如果处理不当，会出现router imbalance（路由失衡）。量化也不是一刀切——路由层和循环投影层对量化的反应，跟稠密模型里的组件并不相同。

一句话的选型逻辑

参数数量本身说明不了什么。同样30B，一个每token激活3B，一个全量激活，跑起来是两回事。

要判断该选哪个，先看显存够不够装下所有专家，再看并发压力下延迟能不能接受，然后确认微调方案能不能避开路由失衡，最后验证量化对路由层的影响是否在可控范围内。这四步走完，答案基本就出来了。