大模型架构分类：密集模型与混合专家模型

一、概念定义：什么是密集模型与混合专家模型

当我们谈论大语言模型的架构分类时，最常见的划分维度之一，就是密集模型（Dense Model） 与混合专家模型（Mixture-of-Experts，简称 MoE）。这两类架构的根本区别，在于模型处理每一次输入时，究竟会激活多少参数。

密集模型指的是：在每次前向推理过程中，模型的全部参数都会参与计算。无论输入是一个简单的问候语，还是一段复杂的代码生成请求，整个网络都会被完整激活。可以把它想象成“用整个大脑思考每一个念头”——算力消耗恒定，但每次都用尽全力。

混合专家模型则采用了一种“按需激活”的策略。模型内部包含多个并行的子网络，每个子网络被称为一个“专家”。当输入到达时，一个被称为“路由器”或“门控网络”的组件会判断该任务适合由哪些专家处理，只激活其中一小部分专家参与计算，其余专家保持静默。因此，MoE 模型的总参数量可以非常庞大，但每次推理实际消耗的算力却远小于同等规模的密集模型。

从定义上看，两者的核心差异并不在于模型能否“思考”，而在于参数激活模式：密集模型是全量激活，MoE 是稀疏激活。这一差异直接决定了两类模型在训练成本、推理效率、部署门槛和适用场景上的不同走向。

二、背景与价值：为什么会出现 MoE 架构

随着大模型参数规模从亿级迈向千亿级甚至万亿级，密集模型的瓶颈日益明显：

1. 训练成本急剧上升：参数量越大，训练所需的算力、显存和时间呈非线性增长。
2. 推理延迟难以接受：每次推理都要激活全部参数，导致响应速度变慢，尤其在高并发场景下成本高昂。
3. 边际收益递减：单纯扩大密集模型规模，未必能带来同等比例的效果提升。

MoE 架构的出现，正是为了在“扩大模型容量”与“控制计算成本”之间找到平衡。它允许模型拥有极大的总参数量，从而获得更强的知识存储和表达能力，但每次推理只调用与当前任务最相关的专家子集，从而显著降低单次计算的 FLOPs（浮点运算次数）。这意味着：模型可以更大，但用起来不一定更贵。

对于企业用户和开发者而言，MoE 的价值在于：在同等推理预算下，可以部署总容量更大的模型；或者在同等模型容量下，获得更低的延迟和更高的吞吐。这对于需要处理多样化任务、同时又对成本敏感的在线服务场景尤为重要。

三、核心组成：两类架构的关键模块

3.1 密集模型的核心组成

密集模型的结构相对直观，通常由以下部分组成：

• 嵌入层：将输入 token 映射为向量表示。
• 多层 Transformer 块：每层包含自注意力机制和前馈网络。在密集模型中，每一层的前馈网络对所有 token 都执行相同的全量参数计算。
• 输出层：将最终隐藏状态映射为词表概率分布。

由于所有参数在每次推理中都会被使用，密集模型的显存占用和计算量是稳定且可预测的。这为工程部署带来了便利：无需复杂的路由逻辑，批处理效率高，硬件利用率容易优化。

3.2 混合专家模型的核心组成

MoE 模型在 Transformer 结构的基础上，将部分前馈网络层替换为专家层，并引入门控网络：

• 专家子网络：每个专家本身通常是一个小型前馈网络，拥有独立的参数。专家数量可以从几个到上百个不等。
• 门控网络（Router）：负责根据输入 token 的表示，计算其对各专家的亲和度分数，并选择 top-k 个专家进行激活。常见的选择策略是 top-2 或 top-1。
• 负载均衡机制：为了防止少数专家被过度激活、多数专家“饿死”，训练时通常会引入辅助损失函数，鼓励 token 在专家之间均匀分配。
• 共享层与专家层交替：并非所有层都是 MoE 层。通常模型中会保留一部分密集层作为共享基础，只在部分层中插入专家结构，以兼顾稳定性和容量。

这种“稀疏激活”的设计，使得 MoE 模型在总参数量上可以轻松达到密集模型的数倍，但实际计算量仅与激活的专家数量相关。

四、工作原理：从输入到输出的差异化路径

4.1 密集模型的工作流程

以典型的自回归生成模型为例，密集模型处理一个 token 的流程可以简化为：

输入 token → 嵌入向量 → 
对于每一层：
    自注意力计算 → 前馈网络（全部参数参与） → 
输出概率分布 → 采样下一个 token

每一步计算都涉及模型全部参数，因此计算图是静态的、确定的。这带来的好处是：编译优化容易、批处理效率高、推理框架可以充分预分配显存。但代价是：无论任务难易，计算开销恒定。

4.2 混合专家模型的工作流程

MoE 模型在专家层中的处理方式有本质不同：

输入 token → 嵌入向量 → 
对于每一层：
    自注意力计算 → 
    门控网络计算专家分数 → 
    选择 top-k 个专家 → 
    仅激活被选中的专家进行前馈计算 → 
    加权合并专家输出 → 
输出概率分布 → 采样下一个 token

关键点在于：门控网络的选择是动态的、与输入相关的。一个关于代码的 token 可能被路由到擅长编程的专家，一个关于诗歌的 token 可能被路由到擅长文学的专家。这种动态路由机制，使得 MoE 模型在理论上具备更强的“专业化分工”能力。

然而，动态路由也带来了工程挑战：不同 token 可能激活不同专家，导致批处理中专家计算不均衡，需要专门的并行策略和内核优化来保证硬件利用率。

五、典型场景：分别适合什么样的任务

5.1 密集模型的适用场景

• 低延迟、高并发在线服务：由于计算量恒定且可预测，密集模型非常适合对响应时间敏感的 API 服务。
• 边缘设备或资源受限环境：参数量相对可控，显存占用稳定，便于在有限硬件上部署。
• 任务类型单一、领域聚焦的应用：如果业务场景不需要极广泛的知识覆盖，密集模型可以通过精调达到很好效果，且推理成本更低。
• 对稳定性要求极高的生产系统：密集模型的行为更可预测，调试和监控相对简单。

5.2 混合专家模型的适用场景

• 多任务、多领域通用服务：需要同时处理编程、写作、翻译、问答等多种任务时，MoE 的专家分工可以提升整体效果。
• 超大规模模型部署：当希望获得千亿级甚至万亿级参数容量，但又不希望推理成本线性增长时，MoE 是自然选择。
• 训练阶段的算力优化：在相同算力预算下，MoE 可以训练出总参数量更大的模型，从而在多项基准上取得更好表现。
• 云端批量推理与离线任务：对于延迟不敏感但吞吐要求高的场景，MoE 可以通过专家并行和批处理优化获得较高性价比。

需要注意的是，MoE 并非在所有场景下都优于密集模型。如果任务非常单一，或者部署环境对动态路由的工程复杂度承受能力有限，密集模型仍然是更稳妥的选择。

六、相关概念区别：容易混淆的几个点

稀疏激活 vs 模型剪枝：两者都涉及“不激活全部参数”，但剪枝是永久移除参数，模型结构发生改变；MoE 是动态选择专家，参数仍然保留，只是每次推理激活子集。

MoE vs 多模型集成：集成学习是多个独立模型分别推理再合并结果，计算量随模型数量线性增长；MoE 是单个模型内部的路由机制，计算量仅与激活专家数相关。

MoE vs 条件计算：条件计算是一个更广义的概念，MoE 是条件计算在大模型中的一种具体实现形式。其他条件计算形式还包括早期退出、层跳过等。

总参数量 vs 激活参数量：这是理解 MoE 的关键指标。一个 MoE 模型可能拥有数千亿总参数，但每次推理只激活其中几十亿。宣传中提到的“参数量”需要区分是总参数还是激活参数，否则容易产生误解。

七、使用注意事项

1. 显存占用不等于计算量：MoE 模型虽然每次只激活部分专家，但所有专家参数都需要加载到显存中（或通过专家并行分布在多卡上）。因此，显存需求仍然与总参数量相关，不能简单按激活参数量估算。

2. 路由负载均衡问题：如果门控网络训练不当，可能导致少数专家过载、多数专家闲置。实际使用中需要关注专家利用率指标，必要时调整辅助损失权重。

3. 批处理效率：由于不同 token 可能路由到不同专家，批处理时容易出现“专家计算碎片化”。推理框架通常需要专门的专家并行和内核融合策略来提升吞吐。

4. 微调策略差异：对 MoE 模型进行微调时，需要决定是只调路由、只调专家，还是全量微调。不同策略对效果和成本的影响差异较大，需结合具体任务评估。

5. 选型建议：如果业务场景任务多样、对模型容量有较高要求、且具备一定的工程优化能力，可以优先评估 MoE 架构；如果场景单一、延迟敏感、部署环境受限，密集模型往往是更务实的选择。

八、总结

密集模型与混合专家模型代表了大模型架构设计的两种哲学：前者追求“全量计算、稳定可预测”，后者追求“稀疏激活、容量与效率的平衡”。理解这一分类，不仅有助于在技术选型时做出合理判断，也能帮助开发者更准确地解读模型参数、推理成本和部署需求。

回到定义本身：密集模型是每次推理激活全部参数的模型；混合专家模型是通过门控网络动态选择专家子集进行激活的模型。两者的根本差异在于参数激活模式，而这一差异，深刻影响了它们各自的适用边界与工程实践。在实际应用中，没有绝对的优劣，只有是否匹配业务场景与资源约束的取舍。