Mixture of ExpertsMoE学习

三个月前，我把键盘敲得噼里啪啦响，屏幕前一行字转圈：MoE到底怎么省算力的？

我当时想得特简单——把一个大FFN拆成几个小FFN，不就完事了。结果训练直接崩了，loss飞得像风筝断了线。抱着论文啃了三个通宵，被苏神那篇几何解释砸醒，又在8卡A100上测到脖子僵硬。今天把踩过的坑倒出来，你遇过哪个算我输。

先聊个反直觉的事：MoE省的不是显存，是计算量。 DeepSeek-V3总参数671B，每次推理只激活37B。参数量涨了快二十倍，计算量只多了个零头。核心操作就是：原来那个“万能老专家”FFN变成256个垂直方向的小专家。每个token过来，Router只挑对口的top-8干活，剩下248个喝茶。和职场一个样——活儿来了只喊当事人，别人继续刷手机。

Router看着简单，上手就炸。它要算每个专家的匹配得分，挑最高的k个。问题出在Router的logits方差大得离谱，动不动就崩成one-hot，top-k退化成了hard selection，梯度全断了。你瞪着眼看loss飞了，找不到原因。后来翻DeepSeek源码，发现人家加了一行z-loss约束：z_loss mean(exp(logits)) * 2。加上后loss稳得像老狗。第一次读论文压根没注意这行，自己踩过才刻进骨头里。

所以省算力的真相是：你只能在FLOPs层面省钱，显存预算一分不能少。 671B的参数依然得住显存，只是每次只算37B的矩阵。别理解成“卡不行也能跑大模型”——醒醒，该花的钱一分不会少。

说到这，下一个问题自然来了：参数量撑爆单卡，TP还是EP？

我最初思路很朴素：MoE层有N个专家，把不同专家放不同卡上，行了吧？这叫专家并行（EP）。一试就发现MoE还有Attention层，Attention层得用张量并行（TP）切，俩东西搅一起，通信图炸得头皮发麻。

我按捺不住，用类似DeepSeek-V3的MoE结构做了个小规模原型，在8卡A100上对比了两种方案：

• 方案A：纯TP-8——每个专家在卡间切片，每张卡持有所有专家的一个分片。
• 方案B：EP+TP混合（当时我随手记了个代号AD，还在琢磨细节，先留着）。

结果呢？方案A专家层通信开销大得离谱，方案B又撞上负载均衡的新坑。最后结论是：EP和TP不是二选一，得混着来。 Attention层做TP，专家层做EP，但切分策略得根据你的专家数和卡数控着来，没有银弹。

至于负载均衡为什么总是翻车，从aux loss到DeepSeek另辟蹊径，再到BasicMoE和DeepSeek在代码上的具体演变——这两块我踩得更惨，今天说不完。点个赞，下次专门写一篇续，把负载均衡的几何直觉和路由代码的五版迭代全倒出来。

最后送你一句话，可以截图带走：

MoE不是魔法，是工程的艺术。省的不是显存，而是你看问题的角度——从一个人扛到一群专家扛，最大的坑不是技术，是以为自己懂了。