去年我写了个小模型做文本分类全部参数只有1.5B单卡就能跑。结果效果还行但跟大模型比就是被吊打。我就想为什么那些几百B甚至上T参数的大模型推理速度没比我的小模型慢一万倍答案就在MoEMixture of Experts混合专家架构里。今天这篇我把它拆开了揉碎了讲清楚。先用人话解释MoE在干嘛传统的Dense模型处理每个token所有参数都要参与计算。就像一个大公司接了个小活儿全员出动。MoE不一样。它把模型分成很多个专家Expert每个token只激活其中一小部分专家。核心思想参数多 ≠ 计算量多。GPT-4据说有1.8T参数但每次推理只激活其中的一小部分比如370B。所以它虽然参数量是别人十倍推理速度却只慢了2-3倍。MoE的关键组件1. 专家网络Experts每个专家本质上就是一个小型FFN前馈神经网络。MoE层的专家数量通常是8个、16个、32个甚至更多。DeepSeek V4号称用了256个专家每层激活其中8个。这个配置在MoE里算是比较激进的。2. 门控网络Router/Gate这是MoE的指挥官。它决定把每个token送给哪个专家。门控网络输出一个概率分布告诉模型这个token去专家3和专家7。这个门控是可学习的——它跟模型一起训练学会如何分配任务。我刚开始没想通一个问题如果门控也在训练它会不会让所有token都跑去那个最强的专家那MoE不就退化成了Dense模型答案是不会因为加了负载均衡损失Load Balancing Loss。这个损失函数惩罚分配不均衡的情况强迫门控把token分散到不同专家。3. 稀疏激活核心逻辑每个token只激活Top-K个专家其他专家的输出直接变成0。GPT-4用的是Top-2。DeepSeek V4有点不同它用了一种更精细的细粒度专家机制每个token激活的数量更多8个但每个专家的容量更小。这个设计有个好处——专家更专业化每个专家只处理一个更细的子任务。4. 负载均衡这是MoE工程实现中最难受的地方。分布式场景下的通信瓶颈。假设你把专家分布在64张GPU上你的batch里有256个token。门控网络决定token A去专家1token B去专家5…但是专家1可能在GPU 0上专家5在GPU 3上。于是GPU之间需要大量的All-to-All通信来搬运token和结果。这就是MoE训练的最大瓶颈——通信成本。我有个朋友在搞千问的MoE训练他说有一半精力花在优化通信上。后来他们用了腾讯云的Ti-ACC做通信压缩才算把这个瓶颈压下去。5. 专家容量Expert Capacity每个专家一次能处理的token数量是有限制的。超出容量的token会被丢弃dropped。听起来不靠谱对吧但实际上少量dropout不影响整体质量而且会迫使门控网络更均衡地分配token。但如果dropout太多问题就大了——信息丢失。这个参数是需要仔细调的。我试过不同的容量设置总结下来容量大则效率低很多专家闲着容量小则信息丢失太多token被丢。找到一个平衡点很关键。几家大厂是怎么做的GPT-4虽然没有官方详细说明但业内人士基本确认GPT-4使用了MoE架构1.8T参数每次推理激活370B参数。用了16个专家组每个组8个专家。OpenAI的工程能力确实强MoE通信优化做得很好所以GPT-4的推理速度比同等参数量的Dense模型快很多。千问Qwen千问系列从Qwen1.5开始就转向MoE了。Qwen2-MoE用了8个专家每个token激活2个。千问团队公开了一篇技术博客详细讲了他们是怎么解决MoE的通信瓶颈的。核心思路是分组共享 通信重叠——让一部分专家在算另一部分专家在传避免等待。DeepSeek V4DeepSeek V4的MoE实现我觉得是最有意思的。它用了256个专家但跟传统的MoE不同它把专家做得很细粒度——每个专家的FFN中间维度很小所以每个专家的计算量很小。然后每个token激活8个专家做更精细的任务分解。这带来一个好处专家可以更专。传统MoE的专家可能学到的是混合概念但DeepSeek的细粒度专家可以精确到专门处理数学公式中的等号这种级别。但代价也很明显256个专家意味着门控网络需要处理的专家数量多这增加了门控的计算量。这就是为什么DeepSeek V4在推理时需要那么好的硬件——专家太多通信开销也大。MoE的坑汇总训练不稳定MoE训练比Dense模型更容易崩溃。常见问题专家崩溃某个专家逐渐停止接收token变成植物人。解决方法加auxiliary loss或者用Z-lossDeepSeek的方法。训练震荡门控网络频繁改变token分配策略。解决方法降低学习率或者使用更平滑的softmax门控。推理显存占用高虽然计算量小但MoE模型需要把所有专家参数都加载到显存里因为不确定哪个专家会被激活。这导致7B的MoE模型可能跟70B的Dense模型加载的显存差不多但推理速度更快。所以部署MoE模型对显存要求很苛刻。比如DeepSeek V4需要高端A100/H100集群才能跑起来。推理batch size受限因为每个专家处理的token数量受专家容量限制batch size不能太大。否则大量token会被drop。Batch serving时的吞吐优化是MoE推理的一个研究方向。MoE vs Dense数字说话我拿自己的实验数据说一下7B Dense模型 vs 7B MoE8个专家Top-2激活参数量7B vs 56B但激活参数只有14B训练速度1x vs 0.8x通信开销推理速度1x vs 2.5x计算量小效果MMLU benchmark持平 vs 好2-3个百分点结论就是MoE用更小的计算量达到更好的效果但工程复杂度翻了好几倍。写在最后MoE让我觉得最有趣的地方是——它打破了参数越多越慢这个直觉。你还能想象吗GPT-4有1.8T参数但每次生成一个token只用了其中370B。如果把模型比作一个图书馆Dense模型每次找你都要翻遍所有书而MoE直接告诉你去哪几本书里找就行。但说真的MoE的工程落地还远没到开箱即用的程度。今年可能还会看到更多MoE变体和优化方案。下一个值得关注的方向是MoE训练时的通信优化——因为这才是制约大厂做大MoE模型的核心瓶颈。谁解决了通信问题谁就掌握了下一代大模型的钥匙。有兴趣的话下期我可以写写MoE的分布式训练实践聊聊我在单机多卡环境下怎么蹭MoE训练的。