万亿参数只激活三十分之一：稀疏架构深意何在

一、从一组参数说起

当前大模型领域出现了一类值得关注的设计：模型的总参数量达到万亿级别（如 1.04 万亿），但在单个 token 的推理过程中，实际参与计算的参数量却只有约 320 亿。也就是说，激活比例大约为 3%。这种“总参数量”与“激活参数量”之间存在巨大落差的架构，正是稀疏混合专家（Sparse Mixture-of-Experts，简称 MoE）的核心特征。

理解这组数字的意义，需要先厘清两个常被混淆的概念：总参数量决定了模型的容量上限，即它能“记住”多少知识、表达多复杂的函数；激活参数量则决定了每个 token 在推理时实际付出的计算代价。传统稠密（Dense）模型中，两者是相等的——参数量多大，每个 token 就要算多少。而在稀疏 MoE 中，两者被解耦了。

这一个解耦动作，带来的是大模型工程思路的一次重要转向。

二、稀疏 MoE 的基本原理

2.1 从稠密到稀疏

稠密 Transformer 的每一层通常包含一个前馈网络（FFN）。对于每个输入 token，这个 FFN 的全部参数都会参与计算。当模型规模扩大到数千亿甚至上万亿参数时，单 token 的计算量（FLOPs）会随之线性增长，推理成本和延迟都变得难以承受。

MoE 的思路是：把原来单个大型 FFN 拆分成多个并行的“专家”子网络，并引入一个路由（Router/Gating）机制。对于每个 token，路由器根据其表示特征，只选择少数几个专家参与计算，其余专家保持静默。

用一个简化示意表达：

# 伪代码：稀疏 MoE 前向过程的核心逻辑
def moe_forward(x, experts, router, top_k=2):
    # x: 当前 token 的隐藏状态
    scores = router(x)                    # 计算每个专家的得分
    indices, weights = top_k_select(scores, k=top_k)  # 只选 top-k 个专家
    output = 0
    for idx, w in zip(indices, weights):
        output += w * experts[idx](x)     # 仅被选中的专家参与计算
    return output

在这段逻辑中，无论专家总数有多少，每个 token 只经过 top_k 个专家。这就是“总参数大、激活参数小”的直接来源。

2.2 参数与计算的解耦

假设一个 MoE 层有 N 个专家，每个专家参数量为 P，每次激活 k 个专家。那么：

• 该层的总参数量约为 N × P；
• 每个 token 的实际计算量约为 k × P。

当 N 远大于 k 时，总参数量可以做得非常大，而单 token 计算量仍保持在较小水平。以文首的数字为例，1.04 万亿总参数对应约 320 亿激活参数，激活比例约 3%，意味着每个 token 只“唤醒”了全部参数中极小的一部分。

这种设计的价值在于：模型容量可以继续 scaling，但推理成本不必同步 scaling。

三、这种架构解决了什么问题

3.1 容量与成本的矛盾

大模型的一个基本经验是：参数量越大，模型在知识储备、推理能力、多任务泛化上的上限通常越高。但稠密模型面临一个硬约束——训练和推理的计算成本随参数量线性上升。当参数量进入千亿、万亿区间，稠密架构的推理成本会高到难以规模化部署。

稀疏 MoE 提供了一条折中路径：用大总参数量保证容量，用小激活参数量控制单 token 计算量。这使得“万亿参数”在工程上变得可负担。

3.2 专家分工带来的专业化

从表示学习的角度看，不同专家可以逐渐分化出不同的处理倾向。路由机制让模型学会根据 token 的特征，把它分配给更“擅长”处理这类输入的专家。这种分工类似于集成学习中的多专家协同，但又通过端到端训练实现了更紧密的耦合。

需要注意的是，专家分工并不一定对应人类可解释的语义类别，它更多是训练过程中自发形成的一种条件计算模式。但整体上，这种条件计算让模型在相同计算预算下，能够利用更多的参数容量。

3.3 训练效率的考量

在训练阶段，稀疏激活同样带来好处。虽然总参数量大，但每个 token 的反向传播只涉及被激活的专家，梯度计算量与实际激活参数相关。配合合理的并行策略（如专家并行），可以在有限硬件资源下训练更大规模的模型。

当然，这也带来新的工程挑战：路由的负载均衡、专家并行的通信开销、训练稳定性等，都是稀疏架构必须处理的问题。

四、命名背后的技术表达

一个模型的命名往往承载着对自身技术路线的定位。从这组参数配置来看，命名中的关键信息值得解读。

“K2”这类编号，通常暗示这是某一技术系列的迭代版本，代表在架构或训练方法上的阶段性演进。编号本身是一种版本管理，也是一种技术连续性的声明。

“大模型”这一限定，强调其规模定位处于行业前沿区间。在万亿参数级别，模型已经进入需要专门工程体系支撑的范畴，不再是单机可运行的规模。

更值得关注的是命名与架构之间的呼应。当一个模型以稀疏 MoE 为核心卖点时，它的命名往往试图传递两个信号：一是规模上的领先性（总参数达到万亿级），二是效率上的可控性（激活参数仅数百亿）。这两个信号合在一起，构成了对“大而可用”这一工程目标的表达。

换句话说，命名不只是一种标识，它是对技术路线的一次凝练陈述：我们选择了稀疏化道路，在容量与效率之间寻找新的平衡点。

五、如何客观评估这类模型

对于开发者和企业用户而言，面对“万亿总参数、百亿激活参数”这样的描述，需要建立一套理性的评估框架。

第一，区分总参数与激活参数。 总参数量影响的是模型容量和潜在能力上限，激活参数量影响的是推理成本、延迟和吞吐。两者不能混为一谈。看到“万亿参数”时，应同时关注“每 token 激活多少”。

第二，关注激活比例与路由策略。 激活比例决定了计算效率，而路由策略（如 top-k 的取值、负载均衡机制）直接影响模型的实际表现和训练稳定性。这些细节往往比总参数量更能说明工程成熟度。

第三，结合实际任务验证。 参数规模不等于任务效果。在具体场景中，需要通过评测验证模型在目标领域的表现，而不是仅凭参数规模做判断。

第四，评估部署成本。 即使激活参数较小，万亿级总参数的模型在显存占用、专家并行通信、服务调度上仍有较高门槛。企业需要根据自身基础设施条件评估可行性。

六、稀疏架构的工程挑战

稀疏 MoE 并非没有代价。以下几点是工程落地中需要正视的问题。

负载均衡。 如果路由器总是把 token 分配给少数几个专家，其余专家得不到充分训练，就会造成参数浪费。常见做法是引入辅助损失（auxiliary loss）来鼓励负载均衡。

通信开销。 在专家并行模式下，不同专家分布在不同的设备上，token 需要被发送到对应设备再收回结果。这种 all-to-all 通信可能成为瓶颈，尤其在跨节点场景下。

训练稳定性。 路由决策是离散的，梯度估计需要特殊处理（如使用软路由或 straight-through 估计）。加上专家数量多、参数规模大，训练过程中的数值稳定性需要额外关注。

推理调度。 在服务阶段，不同 token 可能激活不同专家，导致计算路径动态变化。如何高效批处理、如何管理专家权重加载，都是推理系统需要解决的问题。

这些挑战说明，稀疏 MoE 不是简单的“参数堆叠”，而是一套需要架构、训练、推理协同设计的系统工程。

七、对开发者的实践启示

如果你是开发者或技术决策者，这类架构的兴起带来几点可操作的启示。

在模型选型时，建立多维评估表。 把总参数、激活参数、激活比例、上下文长度、推理延迟、部署资源需求等指标并列比较，而不是只看单一数字。

在成本估算时，以激活参数为主要依据。 单 token 计算量更接近激活参数而非总参数，这直接影响推理成本和吞吐估算。

在架构设计上，关注条件计算思想。 稀疏 MoE 背后的核心思想是“按需计算”。这一思想也可以迁移到其他系统设计中，比如动态批处理、自适应计算等。

在技术跟踪上，保持对路由与并行策略的关注。 这些是稀疏架构能否真正落地的关键，也是区分不同实现成熟度的重要维度。

八、小结

万亿总参数、百亿激活参数，这组数字背后是稀疏 MoE 架构对“容量与效率”矛盾的一次系统性回应。它通过参数与计算的解耦，让模型规模可以继续扩展，同时把单 token 计算量控制在可接受范围。命名中的版本编号与规模定位，则是对这一技术路线的凝练表达。

对开发者和企业而言，重要的不是记住某个具体数字，而是理解这套架构的逻辑：总参数决定上限，激活参数决定成本，路由策略决定效率，工程实现决定可行性。 只有把这几层拆开来看，才能对这类模型做出理性判断，并在实际场景中做出合适的技术选择。

稀疏化不是终点，而是大模型工程在规模与效率之间持续寻找平衡的一个阶段。理解它的原理与边界，比追逐参数数字更有长期价值。