MoE混合专家

MoE(Mixture of Experts,混合专家)是一种模型架构:把网络中的前馈层拆成很多个并列的"专家"子网络,再配一个路由器(Router)。每个 Token 经过时,路由器只挑选其中少数几个专家参与计算,其余的完全不激活。

结果是总参数量和单次推理实际计算量被解耦了:模型可以很大(知识容量大),但每次推理只用其中一小部分(速度快、算力省)。

两个必须分清的数字

看 MoE 模型的规格时,有两个参数量:

• 总参数量:所有专家加起来的规模,决定模型能装下多少知识,也决定了显存占用。
• 激活参数量:单次推理实际参与计算的规模,决定计算成本和速度。

一个总参数几千亿、激活几百亿的模型,推理速度接近后者,但显存需求接近前者。这带来一个非常实际的后果:MoE 省算力,不省显存。所有专家都得常驻内存里,因为你不知道下一个 Token 会路由到谁。这就是为什么 MoE 在数据中心非常划算,在端侧却很难用。

与稠密模型的取舍

	MoE	稠密模型
同等能力下的推理算力	低	高
显存需求	高(要装下全部专家)	与参数量一致
训练稳定性	更难调(路由容易失衡)	更成熟
微调难度	更高	更低
部署复杂度	高(专家并行、路由开销)	低

工程上的难点

• 负载不均。路由器容易偏心,把大部分 Token 都送给少数几个专家,剩下的白养。训练时要加辅助损失强制打散。
• 专家不是按学科分的。"数学专家""代码专家"是流行的比喻但并不准确。路由是学出来的,专家的分工往往是人类难以解释的低层次模式,不对应可读的领域划分。
• 批处理效率。同一批里不同 Token 路由到不同专家,会打乱内存访问的规整性,需要专门的推理框架优化才能吃满硬件。
• 微调更麻烦。路由分布容易在微调中被破坏,导致某些专家彻底失活。

为什么现在到处都是 MoE

因为它直接对准了行业最痛的那笔账:训练和推理的算力成本。在算力预算固定的前提下,MoE 能训出知识容量更大的模型,推理时的每 Token 成本又不同比例上升。近年多个主流开源和闭源模型都采用了这个架构。

常见误解

"MoE 模型更小所以能在本地跑"——正好相反。它对显存的要求按总参数量算,通常比同等能力的稠密模型更难本地部署。