DeepSeek MoE专家负载均衡技术解析

探索DeepSeek-R1专家负载均衡的核心技术，同时深入分析MoE模型在实际推理场景中的性能表现。 本文将围绕几个关键方向展开：一是DeepSeek-R1专家负载均衡的数据分析，二是专家Overlap分析及其对模型性能的真实影响，三是细粒度MoE模型的技术演进与优化路径。 上周同事提供了一份线上DeepSeek-R1推理过程的Expert激活数据，用于研究专家负载均衡算法。数据来自公司内部请求，观察发现前10层专家分布基本均衡，但越到后期不均衡程度越明显。当时讨论时怀疑是否因内部请求偏向电商领域导致失衡，于是顺着这个方向做了排查。恰好读到Intel那篇《Semantic Specialization in MoE Appears with Scale: A Study of DeepSeek-R1 Expert Specialization》[1]，文章从语义角度剖析了MoE专家的专业化特性。加上前两天看到某个公众号采访一位院长，提到一个有趣的观点——“Dense模型适合toB业务，MoE模型适合toC业务”，于是顺势做了些分析，记录在此。 ## 专家Overlap分析 根据该论文的第一个Word-in-Context实验，DeepSeek-R1前10层专家之间的Overlap概率相对较高，这与线上数据分析结果一致。 值得注意的是，到第10层之后，不同语义以及相似语义之间的区分度才真正清晰起来。由于细粒度MoE（256选8）设计，模型产生的区分度也显著降低。论文还对比了Mistral的两个MoE模型（8选2），结果表明语义对不同专家的区分度差异较大。这一结论实际上支撑了DeepSeek向更细粒度专家方向发展的技术路线，此前我曾撰写过一篇关于DeepSeek MoE技术演进的文章，对此有过讨论。 当然，背后可能涉及多个因素： 1. Shared Expert的重要性：它消除了部分专家间的相互影响，从而降低了Routed Expert Overlap的概率？ 2. 本质上是否由Routed Expert的数量决定？ 3. R1强化学习的工作流是否进一步增强了Expert Specialization？ 但值得注意的是，在模型后20层中，层间Overlap的差异仍然很大，并未继续下降，这与线上数据分布也是一致的。 值得思考的是：每层模型的AlltoAll通信时间受限于分布式部署的带宽和延迟。模型深度增加会拉长TPOT（每个Token的处理时间），虽然可以通过ScaleUP手段缓解，但考虑到GB200的可靠性与成本，这种取舍未必划算。此外，上图中第40层Overlap出现明显抖动——一方面模型在较后层中可以通过更稀疏的专家选择来降低Overlap，另一方面是否存在类似Scaling Law的规律，后续再详细探讨。 ## SAE分析 该论文的另一亮点是使用Sparse Auto Encoder（SAE）的特征来分析专家路由模式。关于SAE，我之前写过几篇分析文章。 从论文中SAE的分析结果来看，不同专家确实在负责不同的推理及认知专业化任务，这与DeepSeek设计细粒度MoE和专家专业化的初衷高度吻合。  实际上，有研究建议从SAE角度分析大模型，并通过对SAE Activation施加约束，将其作为强化学习工作流的一种手段。SAE在概念可视化方面，像Anthropic和OpenAI都做了展示，例如Anthropic多模态模型对金门大桥概念的可视化。  OpenAI和Claude在这方面布局已久，而国内相对滞后。 ## 从范畴论视角看R1 这是一个搁置已久的专题——我一直想抽出一周时间系统分析并写篇笔记，但近几个月被各种项目截止日期追着跑。先简短记录一些感受。从范畴论角度理解R1的完整训练流程如下： 1. V3-Base模型本质上是通过一系列数据集的Pre-train流程构成一个预层范畴（Presheaf）。 2. R1-Zero在此基础上强化了一些Morphism的权重，这些权重在MoE模型基础上赋予模型更强的泛化能力。 3. 随后在V3-Base基础上混合R1-Zero的Coldstart数据与一些General样本，构建出最终的R1。  比较好奇的是，在整个后训练过程中，DeepSeek是否记录了梯度更新情况？结合SAE进行分析或许能挖掘出更多发现。尽管ORM取得了不错的结果，但PRM本身仍存在一些过程上的缺陷，从SAE视角或许能揭示更多原因，某种意义上还能为ORM训练添加更抽象、更具泛化能力的约束。 当然，这也面临算力挑战——SAE的算力消耗与RL工作流整体效率之间的权衡。 ## MoE Scaling Law 开头提到的观点——“Dense模型适合toB业务，MoE模型适合toC业务”，值得推敲。GPT-4是MoE模型，它适合toB还是toC？Llama3是Dense模型，它又适合toB还是toC？本质上，在算力约束下，MoE成为继续提升Scaling的必然手段。当然，MoE模型本身存在Gating数值稳定性问题，加上推理模型通常温度参数设置偏低，使得模型幻觉程度有所增加，因此不太适合某些toB场景。 最近有一篇《Chain-of-Experts: 释放MoE专家的沟通潜能》[2]很有意思，它通过同层专家之间的互相处理得到最终output hidden，有点RNN的味道。但这种机制迭代次数增多后，训练与推理效率很难兼顾。  从本文第一节的配图看，似乎在一定程度上与DeepSpeed-MoE[3]中提出的pyramid-MoE结构相似——模型层数越深，专家专业化程度越高，专家数量与TopK选择数量也需要相应提升？  这其实也是近期一直在思考的问题：MoE的本质是否与HNSW（Hierarchical Navigable Small World）算法存在某种相似性？  借助Grace+Blackwell架构，能否做出一些有趣的东西？大致构想了一个增量MoE算法： 1. 先按相对细粒度的模型训练，例如256个Routed Experts，TopK=8。 2. 训练到500B tokens时，模型在后若干层逐渐添加新专家。 3. 反复训练过程，将模型逐步迭代成金字塔结构。 4. 在PostTraining阶段，基于SAE或某些层的MoE路由规则冻结部分Expert参数，或者在此基础上加上KL散度约束以降低幻觉。 为什么需要Grace？因为某种程度上需要CPU侧更大内存空间来做专家权重的置换，而PCIe带宽本身太小。这种模型部署后在推理阶段还会面临更多挑战。设计模型架构时必须兼顾推理性能，这部分尚未完全想透——隐约觉得在这种模型下，顺便实现Next Few Layer的Expert Prediction/Prefetch可能是一条可行路径。 在基础设施和分布式系统视角下，与模型的协同优化还有很多工作要做。