什么是稀疏模型？MoE 混合专家，解锁大模型低成本扩容的关键

沐光而行

摘要：想要大模型变得更聪明，最简单思路就是增加参数量。但传统稠密模型，参数越大推理算力开销就同步暴涨，硬件成本会快速触达天花板。稀疏模型（主流实现为 MoE 混合专家架构）另辟蹊径：模型总参数量可以做得极其庞大，但每一次计算，只唤醒一小部分参数参与运算，把模型总规模和单次推理算力解耦。本文用通俗比喻对比稠密模型与稀疏模型，拆解路由调度原理，算清算力收益，同时客观讲清 MoE 的训练短板与工程难题，看懂它为什么成为大模型规模化的重要技术路线。

前言

       大模型行业有一个直观认知：参数量越大，模型知识储备、理解、推理能力上限往往越高。但传统架构有一个绕不开的痛点：参数量上涨，推理的计算开销几乎同步上涨。想要更强能力，就要付出成倍的算力、显存成本。
于是就诞生一个核心问题：能不能做出一个总参数量巨大的模型，但是每次实际运行只激活一小部分参数？这就是稀疏模型的核心思想，工业界落地最多的方案就是 MoE 混合专家模型（Mixture of Experts）。

一、先看懂稠密模型：全员上岗的传统大模型

普通的稠密大模型，可以类比一间大型办公室。无论输入什么样的内容，办公室里面所有员工（全部参数、神经元）都必须全部参与工作。每输入一个 token，模型全部网络层完整执行矩阵运算。
稠密模型的算力开销大致和参数量成正比：参数翻倍，推理计算量几乎同步翻倍。想要提升模型能力，只能不断堆参数，但算力、显存开销随之飙升，很快就撞上硬件的物理天花板。
举个例子：700 亿参数稠密模型，推理就需要上百 GB 显存。如果直接把模型拉到万亿参数规模，普通硬件完全扛不住推理，落地成本高到难以接受。
二、稀疏 MoE 模型：按需上岗，专家分诊

稀疏 MoE 架构不再让全部参数同时参与运算。它会把 Transformer 网络中部分前馈网络，拆分成大量并行独立子网络，每一个子网络叫做一个专家（Expert）。
架构里新增一套路由（门控）机制作为调度中心。当一段文本 token 送入 MoE 层，路由会判断这个输入更适合交给哪几位专家处理，一般只挑选 1‑2 个专家执行计算，其余专家保持休眠不参与本次运算。

通俗比喻：

• 稠密模型 = 创业公司开会，不管讨论财务还是设计，全公司所有人都必须到场参会；
• MoE 稀疏模型 = 大型综合医院。院内有成百上千专科医生，但患者挂号就诊，系统只会分配 1‑2 位对口专科医生接诊，其余医生继续待命，不会被本次请求占用。医院总医生数量可以非常多，但单次就诊只会激活少数人。
  

总参数量由全部专家累加而来，可以做到万亿级别；但处理每一段输入时，只有少数专家被唤醒，真正参与计算的只有激活参数量。这就实现了：模型总规模很大，但单次推理计算量被控制在较低水平。
在训练过程中，专家会自发产生能力分化，不需要人为指定分工。有的专家慢慢擅长代码生成，有的擅长法律文本，有的处理日常闲聊。当输入 Python 代码相关问题，路由就会把 token 分发到擅长代码的专家，其他专家不参与运算，输出依然专业可靠。
三、算力收益到底有多大？算一笔直观的账

我们引用行业公开案例做对比：某 MoE 模型总参数量 1.8 万亿，路由每次只激活 2 个专家，单 token 实际激活参数量约 2000 亿。

• 如果是同等规模稠密模型：每一次推理，1.8 万亿参数全部参与计算；
• MoE 稀疏模型：只使用 2000 亿激活参数完成计算。
  

同等总参数规模下，稠密模型计算量大约是 MoE 的 9 倍，推理阶段算力开销被压缩至原来的 1/9 左右。

关键特性：只要激活参数量维持不变，就算继续扩充模型总参数量，推理的算力消耗几乎不会明显上涨。

⚠️重要区分：算力节省主要体现在推理阶段。训练阶段收益没有推理这么夸张：

• 训练时，不仅要计算被激活专家的梯度；路由调度本身也会带来额外通信开销；
• 为避免出现 “少数专家忙到爆炸，大量专家全程躺平” 的专家坍塌问题，训练会加入负载均衡辅助损失，用来约束路由，尽量把任务均匀分配到各个专家，这部分也会带来额外计算消耗。
  

即便有额外开销，对比训练同等总参数的稠密模型，MoE 依旧可以在单位算力下拿到更好的模型效果，这也是它被大量研究与落地的原因。
再换一组横向对比：一个 700 亿参数稠密模型推理，需要大量显存与算力。而 MoE 模型总参数量可以做到它的 8 倍以上，但激活参数量依旧维持 200 亿级别，推理算力开销和 700 亿稠密模型处于同一量级，甚至更低。这就意味着，一台原本只能跑几百亿稠密参数模型的硬件，就可以承载总知识容量接近万亿级别的 MoE 大模型。

补充现实约束：虽然推理计算量下降，但是全部专家参数依然需要存放在显存当中，所以 MoE 对显存总容量依旧有很高要求，并不能直接跑到很小的消费级显卡上面。

四、MoE 稀疏模型躲不开的工程难题

看上去收益巨大，但 MoE 并不是万能银弹，现实落地有不少棘手问题：

• 专家负载失衡、专家坍塌如果路由调度做得不好，会出现少数专家承接绝大多数输入，大量专家几乎得不到训练，彻底闲置。部分专家持续高负载，形成计算热点，拉高推理延迟；闲置专家白白占用显存，模型真实能力无法发挥。行业普遍依靠负载均衡损失、令牌丢弃等手段缓解该现象。
• 通信开销上涨token 需要在不同专家之间分发、汇总结果，分布式集群部署时，大量跨 GPU 的数据搬运会带来通信压力，会吃掉一部分算力收益。
• 小数据集场景效果受限MoE 更适合大规模训练数据；如果任务数据集规模很小，稀疏架构更容易发生过拟合，表现往往不如同等激活规模的稠密模型。
• 微调难度更高稠密模型成熟的微调方案不能直接照搬，稀疏模型需要专门针对专家层做超参、正则策略调整。
  

五、总结：稀疏模型到底解决了什么问题

稀疏 MoE 模型的核心价值，不是靠牺牲模型精度换取速度，而是通过条件计算、按需激活，让大模型可以在不显著抬高推理算力的前提下，大幅扩充整体知识容量。

• 稠密模型：总参数量 ≈ 推理算力上限；
• MoE 稀疏模型：总参数量可以无限做大，推理算力由激活参数量决定，二者完成解耦。
  

它回答了大模型时代一个至关重要现实命题：我们能不能把模型做得更大更强，同时保证它可以实际跑起来？MoE 给出了可行的答案。
现在不少开源、闭源大模型，都已经采用 MoE 稀疏架构，它已经成为下一代超大规模大模型非常关键的技术路线。

免责声明：本文属于科普文章，不同厂商 MoE 模型路由策略、专家数量、负载均衡方案实现存在差异，案例数据来自公开技术文档，仅供学习参考。