MoE 是什么?混合专家架构详解

MoE混合专家模型架构

MoE(Mixture of Experts,混合专家)把模型里的前馈层拆成很多个「专家」,由一个路由器决定每个 token 只走其中几个。总参数量可以很大,每次实际参与计算的却只有一小部分

MoE 路由器把 token 分派给少数专家

MoE 路由器把 token 分派给少数专家

MoE 是 Mixture of Experts 的缩写,中文叫「混合专家」。它是一种模型架构:把网络里的某些层拆成很多个结构相同的子网络(专家),再加一个路由器,为每个输入决定只启用其中的几个。

它要解决的矛盾很实际——模型参数越多通常越强,但每多一个参数,每次生成都要多算一次。MoE 的思路是让参数总量继续涨,但每次只用其中一小部分,把「模型有多大」和「一次要算多少」拆开。

先用一句话抓住它

MoE 是让模型「很大但每次只用一小块」:总参数上千亿,每个 token 只激活其中几十亿。

生活里的类比是大医院的分诊台。医院里有几十个科室,但你挂号看病并不会把所有科室都走一遍;分诊台看一眼你的症状,把你分到最相关的一两个科室。医院整体能力等于所有科室之和,你这次消耗的却只是那一两个科室的资源。路由器就是那个分诊台。

为什么会出现这个词

想法本身不新,1991 年 Jacobs 等人就提出过混合专家。真正变得实用是 2017 年 Shazeer 等人把稀疏门控用到 Transformer 上,之后 GShard 和 Switch Transformer 把 MoE 正式做进了 Transformer 的前馈层,用 Top-1、Top-2 路由把这套结构跑通。

到 2024 年之后,随着开源权重模型往万亿参数走,MoE 几乎成了大模型的默认选择——因为稠密模型继续放大,推理成本会同步线性上涨,而 MoE 能让成本涨得慢得多。一个被广泛引用的例子是 DeepSeek-V3:总参数 6710 亿,但每个 token 只激活约 370 亿,也就是不到 6% 的参数承担了这一步全部的计算。

flowchart LR
    Token["输入 token"] --> Router["路由器<br/>算出每个专家的得分"]
    Router -->|top-k| E1["专家 1"]
    Router -->|top-k| E3["专家 3"]
    Router -.未选中.-> E2["专家 2"]
    Router -.未选中.-> E4["专家 N"]
    E1 --> Sum["加权求和"]
    E3 --> Sum
    Sum --> Out["该层输出"]

它通常包含什么

在现代大模型里,MoE 层一般替换掉 Transformer 块中的前馈网络。一个 MoE 层包含若干个专家(通常就是各自独立的前馈网络)和一个路由器。路由器为每个 token 算出各专家的打分,经 softmax 得到概率分布,然后取分数最高的 k 个专家参与计算,该层的输出是这 k 个专家结果的加权和。大规模模型里 k 常见取到 8。

常见的设计变体有几种。标准 MoE 让所有专家都参与 top-k 竞争。共享专家让一部分专家常驻激活、不参与路由,负责承接通用知识,路由器只在剩下的专业专家里选。细粒度专家把专家切得更小、同时激活更多个,在同样参数量下得到更丰富的组合。专家选择路由反过来让专家挑 token,负载更均衡。

训练上还有一个绕不开的问题:负载均衡。如果不加约束,路由器会逐渐把大量流量集中到少数几个专家上,其余专家几乎不被使用,这叫专家坍塌。常规做法是加辅助的均衡损失,并给每个专家设容量上限。

和稠密模型的区别

传统 Transformer 的前馈层是稠密的:所有参数都参与每一次计算。MoE 是稀疏的:只有被选中的那几个专家参与。区别体现在两处成本上——计算成本由激活参数决定,所以 MoE 便宜;显存成本由总参数决定,所以 MoE 反而更吃显存,因为所有专家都得常驻等着被调用。

这就是为什么 MoE 不是无条件更优。当部署受限于显存、或者你更看重实现简单和内存占用小时,稠密模型仍然是合理选择。分布式部署下协调大量专家还会带来额外的通信复杂度。

和模型参数、推理成本的关系

MoE 让「参数量」这个指标变得需要区分说明。看到一个模型标着几千亿参数,要先问是总参数还是激活参数:前者决定要多少显存装得下,后者决定每个 token 要算多少、大概多快多贵。两个数字都不给的宣传口径,参考价值有限。

对使用者的实际影响是:同等价位下你能用到的模型「知识面」变宽了,因为总参数上去了;但延迟和吞吐更多由激活参数决定。这也是近两年很多模型在价格没怎么涨的情况下能力明显变强的原因之一。

容易误解的地方

最常见的误解是把「专家」当成人类意义上的领域分工,以为有个专家专管数学、有个专管中文。实际路由是在 token 级别、由训练中自发形成的模式决定的,一句话里不同的 token 可能走完全不同的专家,这些专家学到的分工也往往不对应任何人类可命名的领域。

第二个误解是「MoE 一定更省」。省的是每次计算量,不是显存和工程复杂度。小规模部署下,MoE 的收益常常被通信开销和显存压力抵消掉。

第三个误解是把激活比例越低越好当成结论。业界确实在往更低的稀疏率走,但也有研究提示存在一个合适区间,过低会影响质量。最优激活率、路由机制怎么做得比线性路由更好、专家数量扩到几百个时如何保持训练稳定,都还是开放问题。

怎么判断它该不该关心

如果你只是调用 API,MoE 主要影响你的两件事:看参数规格时分清总参数和激活参数;以及理解为什么有些模型「很大但很便宜」。除此之外不需要特别关注。

如果你要私有化部署或者做本地推理,那 MoE 的取舍就很实际了:先按总参数估显存够不够,再按激活参数估速度,最后确认推理框架对你选的这个 MoE 结构支持得好不好。显存不足时,一个激活参数相近的稠密模型往往比硬跑 MoE 更省事。

资料来源