混合专家模型（MoE，Mixture of Experts）是一种让大模型“按需调用一部分参数”的架构：它在同一层里准备多组被称为“专家”的网络，每个 Token 进来时先由一个路由器判断该交给哪几个专家处理，其余专家这次不参与计算。所以混合专家模型的核心不是把模型做得更大，而是把“总参数”和“每次真正用到的参数”拆开——参数表可以写得很大，单次计算却只动用其中一小部分。
这种拆分解释了参数表里最容易看错的一件事：一个模型标注几千亿参数，不等于生成每个词都要把几千亿参数全算一遍。对使用者来说，看懂总参数与激活参数这两个数字，基本就看懂了 MoE 模型一半的性价比宣传。
专家和路由器分别在做什么
先看它在模型内部的位置。主流大模型的主干是 Transformer，每一层里除了注意力部分，还有一个负责加工信息的前馈网络。稠密模型的做法是让所有 Token 都走同一套前馈网络；MoE 则把这一块换成多组并列的专家，再在前面加一个路由器。
处理一个 Token 时，路由器会给每个专家打分，只挑分数最高的几个（常见的是 2 个，也有挑 8 个的），被挑中的专家各自算出结果，再按路由分数加权合并。没有被挑中的专家不计算、不耗算力，但它们的参数仍然完整保存在模型里，随时可能在下一个 Token 被叫到。
打个不那么技术化的比方：稠密模型像一家所有员工什么活都干的公司，来什么单子全员一起上；MoE 更像一家分了工的公司，前台先判断这单该派给谁，只叫相关的几组人开工，其他人待命。待命的人不是不存在，公司养他们的成本照样要付——这个细节后面讲显存时还会回来。
总参数与激活参数，要分开看
MoE 模型的参数表通常会出现两个数字：
| 数字 | 含义 | 决定什么 |
|---|---|---|
| 总参数 | 全部专家加上其余部件的参数总和 | 模型要占多少存储和显存、知识容量的上限 |
| 激活参数 | 处理单个 Token 时真正参与计算的参数 | 单次推理大致要花多少计算量、速度和成本的量级 |
两个公开例子能把差距看得很直观。Mistral 的 Mixtral 8x7B 每层放了 8 个专家、每个 Token 挑 2 个，总参数约 467 亿，单个 Token 实际用到的约 129 亿，计算量更接近一个百亿级模型，而不是一个近五百亿模型。DeepSeek-V3 走得更远：总参数 6710 亿，单个 Token 激活约 370 亿，激活比例只有百分之五点多。
所以评价一个 MoE 模型时，只报总参数容易高估它的运行成本，只报激活参数又会低估它的部署门槛。两个数字要一起看：激活参数帮你估算它跑得快不快、贵不贵，总参数帮你判断它到底装不装得下。
和稠密模型、量化分别差在哪
MoE 最常被拿来和另外两个概念混在一起，这里分开说。
和稠密模型比，差别在“每次用多少”。稠密模型的总参数等于激活参数，每个 Token 都把全部参数过一遍，结构简单、行为稳定，代价是模型越大、每个词越贵。MoE 用总参数换容量、用激活参数控制单次成本，适合想把模型规模继续做大、又不想让推理账单跟着总参数一起涨的团队。
和模型量化比，差别在“改的是哪一层账”。量化是把已有参数用更低的精度存下来，参数个数不变，变的是每个参数占多少位；MoE 参数的精度不动，变的是每次调用哪一部分。两者并不冲突，很多实际部署会把 MoE 架构和量化叠加使用，一个管“用多少”，一个管“每个多占地方”。
三个最常见的误解
第一个误解是把专家理解成按学科分工的人类专家，以为某个专家专管数学、某个专管写诗。实际的划分是训练中自己长出来的，依据是数据分布和路由分数的统计规律，边界模糊，也没人给专家贴过岗位标签；同一个专家完全可能既处理代码、也处理某类日常对话。
第二个误解是总参数越大就按比例越聪明。总参数增加确实能扩大容量，但最终效果还取决于训练数据、路由是否均衡、专家有没有被充分训练。一个总参数惊人、却有一半专家很少被调用的模型，实际表现可能还不如参数更小但训练扎实的模型。
第三个误解是激活参数小，本地就一定跑得动。计算量确实按激活参数走，但显存要装下的是全部专家。也就是说，MoE 省的是算力账，不是存储账：一个总参数几千亿的 MoE 模型，哪怕每个 Token 只激活几百亿，普通设备依然装不下它的完整权重。
它的代价：均衡、通信和训练难度
MoE 不是免费的扩容。最突出的麻烦是负载均衡：如果路由器总把 Token 塞给少数几个热门专家，这些专家会被挤爆，其他专家长期闲置，容量就浪费了。训练时通常要加额外的约束，逼路由器把活分得均匀一些，但约束太强又会干扰模型本身的学习，怎么平衡一直是各家实现里的重要差别。
第二个麻烦在部署侧。专家往往被拆开放到多张显卡甚至多台机器上，Token 算完一层要被送到对应专家所在的设备，算完再送回来，设备之间的通信开销会吃掉一部分稀疏计算省下的时间。这也是为什么 MoE 在大规模服务端跑得划算，到了小规模、低并发的场景，优势反而没有参数表上看起来那么大。
第三个麻烦是训练和微调更复杂。路由决策本身要参与学习，专家分工会在训练中不断漂移；下游微调时数据量一小，还容易出现某些专家被过度使用、某些几乎退化的问题，调起来比稠密模型更挑经验。
什么场景适合用 MoE
判断一个模型该不该选 MoE，可以落到三个具体问题上。
- 服务的是海量请求、按 Token 收费或计成本：激活参数直接决定单次计算量，MoE 的账算得过来，这是它在云端大模型里流行的主要原因。
- 想继续扩大模型容量，但推理预算涨不动：MoE 允许总参数先涨上去，把容量和单次成本部分解耦。
- 准备在单机或小设备上本地跑：先看总参数和量化后的体积能不能装下，再看激活参数，顺序别反了；装不下时，激活参数再小也没有意义。
回到最初的问题：混合专家模型是什么？它是一种用路由器实现稀疏激活的架构安排，让模型拥有大参数的容量，只付小参数的单次计算成本。下次再看到某个模型宣传“总参数几千亿”，先追问一句它的激活参数是多少、完整权重有多大，这两个答案比总参数本身更能说明它真实的成本和门槛。
