混合专家MoE拆解：GPT-4、千问、DeepSeek为什么都选这个架构
去年我写了个小模型做文本分类，全部参数只有1.5B，单卡就能跑。结果效果还行，但跟大模型比就是被吊打。
我就想，为什么那些几百B甚至上T参数的大模型，推理速度没比我的小模型慢一万倍？
答案就在MoE（Mixture 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去专家1，token 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 V4
DeepSeek V4的MoE实现我觉得是最有意思的。
它用了256个专家，但跟传统的MoE不同，它把专家做得很"细粒度"——每个专家的FFN中间维度很小，所以每个专家的计算量很小。
然后每个token激活8个专家，做更精细的任务分解。
这带来一个好处：专家可以更专。传统MoE的专家可能学到的是混合概念，但DeepSeek的细粒度专家可以精确到"专门处理数学公式中的等号"这种级别。
但代价也很明显：256个专家意味着门控网络需要处理的专家数量多，这增加了门控的计算量。
这就是为什么DeepSeek V4在推理时需要那么好的硬件——专家太多，通信开销也大。
MoE的"坑"汇总
训练不稳定
MoE训练比Dense模型更容易崩溃。常见问题：
- 专家崩溃：某个专家逐渐停止接收token，变成"植物人"。解决方法：加auxiliary loss，或者用Z-loss（DeepSeek的方法）。
- 训练震荡：门控网络频繁改变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 MoE（8个专家，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训练的。