总参数量已过时：读懂MoE模型的双数字时代

为什么"总参数量"不再是有用的指标

如果你刚开始接触大语言模型，被各种参数规模搞得晕头转向，那么有一个区别比头条数字重要得多——它决定了你如何真正理解一个模型的能力与成本。

过去很长一段时间，我们习惯用"总参数量"来衡量一个模型的强弱：7B、13B、70B、175B……仿佛数字越大越厉害。但随着**混合专家（Mixture-of-Experts，简称 MoE）**架构的普及，单一的总参数量已经无法准确描述一个模型的真实行为。蚂蚁集团实验室发布的 Ling 3.0 Tiny 就是一个极佳的示例，清晰地展示了这两个数字如今能拉开多大的差距。

混合专家的概念最早可以追溯到1991年Robert Jacobs等人的论文，但真正在大语言模型中大规模应用是近几年的事。Google的Switch Transformer（2021年）是第一个将MoE扩展到万亿参数级别的工作，证明了稀疏激活可以在不增加计算成本的前提下大幅扩展模型容量。此后，Mistral的Mixtral 8x7B（2023年底发布）成为开源社区中MoE架构的标志性模型，它用8个专家、每次激活2个的设计，在性能上媲美远大于其激活参数量的稠密模型。DeepSeek-V2、Qwen系列也相继采用了MoE架构。可以说，MoE已经从实验性技术变成了行业主流选择之一。

蚂蚁集团（Ant Group）是阿里巴巴关联公司，以支付宝为核心业务，近年来大力投入AI基础设施和大模型研发。其AI研究实验室在金融风控、自然语言处理、代码生成等方向均有布局。Ling（灵）系列模型是蚂蚁在通用大语言模型方向的代表作，定位于高效推理场景。选择MoE架构发布Ling 3.0 Tiny，反映了行业中一个明确的趋势：在部署成本敏感的商业场景（如金融服务的实时响应、移动端推理）中，用更大的知识容量配合更小的计算开销来实现性价比最优解。这与DeepSeek、Mistral等团队的技术路线不谋而合。

稠密模型与混合专家模型的核心区别

要理解这个问题，我们需要先区分两种基本架构。

稠密模型：每个参数都参与运算

稠密模型（Dense Model） 的工作方式很直接：对于每一个输入的 token，模型都会调用它全部的参数进行计算。也就是说，如果一个稠密模型有 8B 参数，那么处理每个 token 时，这 8B 参数都在"干活"。

这种设计简单、可预测，但代价是——模型越大，每个 token 的计算成本就越高，速度也越慢。参数量和计算量在稠密模型里是绑定的、一体的。目前主流的稠密模型包括Meta的LLaMA系列、Google的Gemma系列等，它们在中小规模（7B-70B）上仍然是非常有竞争力的选择，因为其工程实现简单、推理行为可预测、且硬件利用率更容易优化。

混合专家模型：只激活一部分参数

混合专家模型（MoE） 则采用了完全不同的思路。它把网络拆分成许多个"子网络"（即专家 experts），并配备一个路由器（Router）。对于每一个 token，路由器只挑选其中的少数几个专家来参与计算，其余的专家保持"休眠"。

路由器是MoE架构中最关键也最微妙的组件。它通常是一个轻量级的线性层，输入是当前token的隐藏状态表示，输出是对所有专家的打分（logits）。通过Top-K选择（比如选择得分最高的2个专家），路由器决定当前token由哪些专家处理。被选中的专家各自独立计算，然后按路由器给出的权重加权求和，得到最终输出。路由器的训练面临一个经典难题——负载均衡（load balancing）：如果路由器总是把token分配给少数几个专家，其他专家就会因训练不足而退化，形成"赢家通吃"的局面。为此，研究者通常会引入辅助损失函数（auxiliary loss）来鼓励均匀分配，或者采用专家容量限制（expert capacity）等策略。

这意味着，虽然模型整体拥有庞大的参数，但真正参与每次运算的只是其中一小部分。参数量和计算量在这里被解耦了。这正是 MoE 架构能够在保持较低推理成本的同时，扩展知识容量的关键所在。

两个关键数字：总参数与激活参数

于是，衡量一个 MoE 模型就需要两个数字，而不是一个：

• 总参数量（Total Parameters）：主要决定你的内存占用。因为无论某个专家是否被激活，它的权重都要被加载到显存中随时待命。
• 每 token 激活参数量（Active Parameters per Token）：主要决定速度和成本。因为实际的算术运算量只由被激活的那部分参数决定。

理解总参数量与显存的关系需要一些具体数字。以FP16（半精度浮点）格式为例，每个参数占用2字节。因此，一个7.9B参数的模型仅权重就需要约15.8GB显存。如果使用FP32则需要31.6GB，使用INT8量化可压缩到约7.9GB，INT4量化则约3.95GB。但这只是静态权重占用——实际推理时还需要额外显存存放KV缓存（随上下文长度线性增长）、激活值等中间计算结果。这就是为什么"总参数量决定能不能跑起来"：即使激活参数只有1.3B，你仍然需要把全部7.9B参数加载到显存中，因为路由器在每个token到来之前无法预知会选择哪些专家。一些工程优化如专家卸载（expert offloading）可以将不常用的专家放在CPU内存或磁盘上按需加载，但这会引入显著的延迟开销。

以 Ling 3.0 Tiny 为例：总参数 7.9B，每 token 激活约 1.3B。

这组数字揭示了一个惊人的事实：这个模型承载着接近 8B 模型的"知识足迹"（knowledge footprint），但每处理一个 token 所做的算术运算却大约只有一个 8B 稠密模型的六分之一。换句话说，它既有大模型的"脑容量"，又有小模型的"运算速度"。

这里的"知识足迹"指的是模型通过其全部参数所编码的世界知识总量。在稠密模型中，所有知识都压缩在同一组参数里，每次推理都会被全部"翻阅"。而在MoE模型中，不同的专家可以被理解为存储了不同领域或不同模式的知识——某些专家可能更擅长数学推理，另一些可能更擅长语言翻译。总参数量越大，模型能够"记住"的事实、模式和关联就越多，这就是知识容量。但存储知识和检索知识是两回事：MoE通过路由器实现了一种"按需检索"的机制，只调用与当前输入最相关的知识子集，从而避免了为获取大容量知识而付出大量计算的代价。

这也解释了为什么单看总参数量会产生误导——一个标注为"8B"的 MoE 模型，其推理成本可能远低于同名的稠密模型；反过来，一个激活参数很小的模型，其内存需求却可能相当可观。

学习者应该警惕的认知陷阱

在为这些新指标建立认知习惯时，有一个值得早早养成的谨慎态度：厂商公布的数字，在被独立方复现之前，本质上仍是营销话术。

Ling 3.0 Tiny 的 7.9B 总参数、1.3B 激活参数都是官方发布的数据，目前尚未见到独立的第三方评测（independent eval）来验证其真实表现。这并不是说这些数字一定不准确，而是提醒我们：在缺乏独立复现的情况下，任何性能宣称都应打上问号。

更进一步，该模型目前是 API-only（仅通过接口提供）。这带来了一个学习上的局限：你无法检视它的内部结构，也无法对它进行消融实验（ablation）。

消融实验是深度学习研究中验证设计决策的核心方法论。其基本思路是：系统性地移除或替换模型的某个组件，观察性能变化，从而推断该组件的实际贡献。例如，要验证MoE中路由器的有效性，研究者可能会将Top-K路由替换为随机路由，看性能下降多少；要理解专家数量的影响，可以逐步减少专家数观察效果。消融实验之所以重要，是因为模型的最终表现是所有组件协同作用的结果，单看整体指标无法归因。对于API-only的模型，由于无法访问权重和架构细节，研究者只能进行黑盒测试（如prompt变体实验），而无法进行这种精细的组件级分析，这大大限制了从中获取可迁移工程洞见的能力。

因此，即便它是一个不错的"使用对象"，它也不是一个理想的"学习对象"——你只能观察它的输出，却无从拆解它的机制。

对于希望深入理解 MoE 工作原理的学习者来说，开源、可检视的模型才是更好的研究素材。目前可供研究的开源MoE模型包括Mixtral 8x7B、DeepSeek-MoE、OLMoE等，它们都提供了完整的权重和详细的技术报告，允许研究者进行各种实验和分析。

为什么你应该关心总参数与激活参数的区别

网上关于"激活参数 vs 总参数"的解释大多有一个通病：一上来就跳进路由数学（routing maths）的公式堆里，却跳过了最关键的一环——为什么一个初学者应该关心这个区别。

答案其实很实际：

1. 它决定你能不能跑起来这个模型。总参数量对应显存需求，如果你的硬件装不下全部参数，模型根本无法加载，无论它激活多少。以消费级显卡为例，一张RTX 4090拥有24GB显存，在FP16精度下最多只能容纳约12B参数的模型权重（还需预留空间给KV缓存和运行时开销）。这意味着即使一个MoE模型的激活参数只有2B，如果总参数超过12B，单卡仍然无法直接运行，除非借助量化或模型并行技术。

2. 它决定你要花多少钱、等多久。激活参数量对应推理的计算量，直接影响 API 调用成本和响应延迟。在云服务定价中，计算成本通常与FLOPs（浮点运算次数）成正比，而每个token的FLOPs大致与激活参数量成线性关系。因此，一个激活1.3B参数的MoE模型，其每token推理成本大约只有一个8B稠密模型的六分之一——这在大批量调用场景下可以节省可观的费用。

3. 它决定你如何横向比较模型。用"总参数"去比较一个稠密模型和一个 MoE 模型，就像用"体积"去比较一辆卡车和一架无人机——数字本身没错，但完全没抓住重点。正确的比较方式应该是：用激活参数量来对标推理速度和成本，用总参数量来对标知识容量和内存需求，两个维度分别比较才有意义。

结语：从单一数字到双维认知

MoE 架构的兴起，标志着我们评估模型的方式必须从"一维"走向"二维"。总参数量告诉你模型"知道多少"，激活参数量告诉你它"跑起来多快、多贵"。Ling 3.0 Tiny 用 7.9B 总参数与 1.3B 激活参数的对比，把这两个维度的分离展现得淋漓尽致。

值得注意的是，这种"双维认知"可能还只是起点。随着架构创新的持续推进，未来我们可能还需要关注更多维度：比如模型的上下文长度如何影响KV缓存的显存占用、不同量化精度下的性能-效率权衡、以及推测解码（speculative decoding）等加速技术对实际吞吐量的影响。模型评估正在从单一标量走向多维向量，而理解"总参数≠激活参数"只是这个认知升级的第一步。

下一次再看到一个模型的"参数量"标题时，不妨多问一句：这是总参数，还是激活参数？只有搞清楚这一点，你才算真正读懂了这个数字。

核心要点