混合专家MoE没你想的那么玄乎：拆开GPT-4和DeepSeek V4的核心架构

上周跟一个朋友聊天他说他在读 MoE 的论文读了两天没太搞明白。我说你换个角度想——MoE 就像一家大型公司的组织架构。传统的大模型就像一个全能型员工一个人啥都得会。MoE 换了个思路你不是要让一个人啥都会吗那我换一下请一群专家每人只负责一个领域。出问题的时候让一个调度员判断该找谁。就这么简单。当然真要实现起来还是有不少技术细节。这篇文章我打算把 MoE 拆开揉碎了讲附带我最近看论文和实践的一些理解。先说说为什么要有 MoE传统 Transformer 模型有个硬伤——计算成本跟参数量是跟着模型规模一起膨胀的。GPT-3 是 1750 亿参数一张 A100 都装不下得上几十张卡并行跑。问题在于你输入今天天气怎么样这种简单问题的时候模型也需要激活全部 1750 亿参数。这不是浪费吗MoE 的思路就是只激活需要的那部分。把模型拆成多个专家子网络每个专家擅长处理不同类型的输入。输入来了路由机制选几个专家激活其他专家休息。效果立竿见影MoE 版本的模型参数总量可以做到很大比如万亿级别但每次推理只激活其中的一小部分计算成本和推理速度跟小模型差不多。这大概是 MoE 最核心的竞争力。MoE 的结构长什么样标准的 MoE 层由三部分组成专家网络通常就是几个 FFN前馈网络每个专家是一组独立的参数路由Router也叫门控网络决定每个 token 分配给哪些专家负载均衡确保 token 不会全部涌向同一个专家具体流程是这样的输入一个 token首先通过 Router 计算它跟各个专家的匹配度Router 给每个专家打一个分数。然后选 Top-K 个得分最高的专家。把 token 发给选中的专家让专家处理它。最后把专家输出做加权求和Router 的分数就是权重。我在实验里复现了一个简单的 MoE 层核心代码大概这样classMoELayer(nn.Module):def__init__(self,d_model,num_experts,top_k2):super().__init__()self.routernn.Linear(d_model,num_experts)self.expertsnn.ModuleList([FeedForward(d_model)for_inrange(num_experts)])self.top_ktop_kdefforward(self,x):# 计算路由权重routing_weightsF.softmax(self.router(x),dim-1)# 选Top-K个专家top_k_weights,top_k_indicestorch.topk(routing_weights,self.top_k,dim-1)top_k_weightstop_k_weights/top_k_weights.sum(dim-1,keepdimTrue)# 初始化和输出final_outputtorch.zeros_like(x)fori,expertinenumerate(self.experts):mask(top_k_indicesi).any(dim-1)ifmask.any():final_output[mask]top_k_weights[mask]*expert(x[mask])returnfinal_output当然这是简化版真正的工业实现要考虑负载均衡、专家容量、通信优化这些问题。但核心逻辑就是这几行代码。路由策略软路由 vs 硬路由这块是 MoE 论文里争论最多的话题之一。软路由token 分配给所有专家每个专家分配不同的权重。优点是梯度能回传到所有专家训练更稳定。缺点是计算量更大——激活了所有专家那还要 MoE 干嘛硬路由token 只分配给 Top-K 个专家其他专家不参与计算。这带来一个训练问题——非 Top-K 的专家没有梯度可能永远得不到训练。这个专家坍缩问题困扰了 MoE 很久。现在的工业实现GPT-4、DeepSeek V4、Mixtral 8x7B基本都是硬路由 Top-2。至于专家坍缩靠的是辅助损失函数和负载均衡策略来解决。负载均衡MoE 最头疼的问题想象一下如果 Router 总是把大部分 token 分配给同一个或少数几个专家剩下的专家就失业了。这不仅浪费了模型容量还会让模型性能下降。这个问题在训练初期特别容易出现——Router 的初始权重是随机的很容易让 token 集中到一两个幸运的专家上。解决策略到现在已经发展了好几代Batch-wise 负载均衡损失Switch Transformer 方案在损失函数里加一项负载均衡的惩罚鼓励 token 在各个专家间均匀分布。Expert Choice2023年论文反向思路——不再让 token 选专家而是让专家选 token。每个专家选最重要的一批 token。这个方案理论上更优实际效果也挺好。DeepSeek V4 的方案用了一种动态关联的负载均衡策略据他们论文的说法把专家之间的 token 分配偏差控制在了 5% 以内。DeepSeek V4 的 MoE 有多猛说到 MoE 就绕不开 DeepSeek V4。它的架构是目前 MoE 落地做的最极致的案例之一。DeepSeek V4 总参数量是 1.6T万亿但每次推理只激活 380 亿参数。激活率低于 3%。1.6T 是什么概念如果用传统 Dense 模型这个体量光推理成本就是一个天文数字。但 MoE 让它能在消费级场景跑起来。虽然 1.6T 不可能单卡跑但 380 亿激活参数的推理效率已经比很多百亿级 Dense 模型高了一个数量级。DeepSeek V4 用了 256 个专家Top-2 路由。这意味着每个 token 只激活 2 个专家。它还引入了一个叫 Multi-Head Latent Attention 的机制在注意力层也做了参数共享优化。本质上也是 MoE 的思维——注意力阶段就控制计算量不给后面的 FFN 层留太多输入。GPT-4 的 MoE 还没公开OpenAI 一直没有公开 GPT-4 的具体架构。但根据多方分析和泄露信息普遍认为 GPT-4 使用了 8 组专家每组约 220B 参数Top-2 激活。也就是推理时激活约 440B 参数。这个规模跟 DeepSeek V4 比显得有点保守但 GPT-4 发布更早那时 MoE 的工程实践经验还没那么丰富。有意思的是GPT-4 的专家分组设计据说是按功能域划分的——有的专家组擅长代码有的擅长推理有的擅长创意生成。这种领域专家的设计哲学跟 MoE 的直觉更接近。而 DeepSeek V4 的专家是更细粒度的256 个专家分布在不同的层级上每个专家不绑定特定领域。Router 动态学习 token 和专家的匹配关系。这两种设计思路目前没有定论谁更好只能说是不同的设计哲学。MoE 的工程挑战理论说完了聊聊工程实践里 MoE 最让人头疼的问题。通信瓶颈MoE 的一个核心特性——每个 token 要去不同的专家——天然要求跨设备通信。在分布式训练中专家分布在不同的 GPU 上token 需要频繁的 all-to-all 通信。我做过实验通信开销可以占到总训练时间的 30% 以上。优化方式包括专家放置策略把频繁被一起调用的专家放在同一节点、梯度压缩、异步通信。显存压力虽然推理时只激活部分专家但训练时所有专家的参数都要加载到显存里。1.6T 参数的 MoE 训练光存参数就需要 3.2TB半精度。训练 DeepSeek V4 据说用了上千张 GPU。专家负载不均衡前面说的负载均衡问题在训练中需要持续监控。一旦发现某个专家罢工需要及时调整损失函数的权重。推理部署MoE 模型的推理部署比 Dense 模型复杂。因为不同输入会激活不同的专家缓存和批处理策略都要重新设计。MoE 适合什么样的项目如果你正在考虑要不要在自己的项目里用 MoE我的建议分三种情况训练新模型如果你有大规模算力资源想从头训一个超大模型MoE 几乎是必选项。1B 以下的小模型用 Dense 更好参数量的优势体现不出来。微调已有 MoE 模型DeepSeek V4、Mixtral 8x7B 都开源了可以用它们的权重做微调。注意 MoE 模型的微调跟 Dense 模型不太一样——路由参数要不要冻结专家怎么调度这些都需要调。推理已有 MoE 模型直接用就好MoE 的推理接口跟普通模型没区别。优点是速度更快、成本更低。写在最后MoE 的核心思想其实很简单——别把所有鸡蛋放在一个篮子里。但实现起来确实有不少坑。说实话我觉得 MoE 对普通开发者的意义不在于从头训一个 MoE 模型而是在于理解它之后你能更好地用这些模型。知道它的路由机制你就知道为什么某些提示词效果更好。知道负载均衡的设计你就知道为什么某些场景下 MoE 模型的输出质量波动比 Dense 模型大。知道通信瓶颈在哪你就知道为什么 MoE 模型的推理服务提供商定价跟普通模型不一样。理解底层原理用起来才顺手。