我最早关注混合专家模型MoE这批论文其实是2023年底帮实验室整理年度顶会论文清单。当时GPT-4传出“多大16个专家模型”的八卦Mistral又突然放出一个8专家开源的MoE模型整个圈子对稀疏架构的热情一下子被点着了。但真开始看论文我发现一个尴尬的问题MoE方向看着火论文却散得很有的在讲门控网络的loss改进有的在折腾分布式通信还有的直接把MoE塞进多模态模型里刷榜。如果不按算法、系统、应用三条线做分类零基础的人根本不知道从哪里读起。这篇文章就是我整理这批2022到2023年MoE顶会顶刊论文合集时的主要思路和笔记。我不仅告诉你这个合集里为什么要把论文分成三大类还会把每一类里最关键的问题、最值得精读的工作、以及复现时最容易踩的坑一起说清楚。对刚想入坑MoE的研究生、准备做模型架构选型的算法工程师、还有需要评估MoE推理成本的系统同学来说这篇应该都能帮你省下不少选论文的时间。1. 我在整理合集时确定的边界2022到2023年间MoE的三条主线做论文合集最怕的就是贪多嚼不烂。MoE这个词在2022到2023年频繁出现在顶会顶刊上但不同论文解决的根本不是同一个问题。我划分三大类的基本原则是看论文的“主要产出物”产出新模型结构、新训练目标、新路由策略的归入算法产出新并行策略、显存管理方法、推理优化框架的归入系统产出新任务效果验证、新应用场景尝试、新评测结论的归入应用。这样分类有一个额外的好处同一篇论文如果既改了结构又做了系统优化我会按它的核心贡献归入最合适的一类但在摘要里标注清楚它涉及的其他维度。这种划分并不是说算法、系统、应用三者可以完全割裂。恰恰相反2022到2023年MoE论文的最大特点是互相依赖。算法类论文提出一个新的负载均衡损失函数系统类论文里的调度策略就需要跟进适配应用类论文发现专家数量加到64个后效果不涨反降算法类论文就得回头研究是不是路由策略出了问题。所以我做合集的第一个动作是给每篇论文加了一个“关联问题”字段把这种依赖关系显式记下来。为什么要锁定2022到2023年这个时间窗口理由也很直接。这个阶段是LLM训练成本急剧膨胀的时期研究者必须找到一种“既扩大参数量、又不线性增加计算量”的架构MoE的稀疏激活特性天然契合这个需求。而且这段时间正好是MoE从“工程界不太敢用”到“开源社区大规模验证可用”的转折期论文质量整体很高适合作为入门学习的核心区间。太早的MoE工作比如2017年那批理论价值高但实践距离远太晚的又还没经过充分沉淀。2. 算法类论文真正在改模型结构的那批工作算法类论文是合集里最庞杂的一部分也是新手最容易迷失的地方。很多入门文章只会告诉你“MoE就是Top-k路由器选专家”但实际读论文会发现2022到2023年的算法工作早就不纠结Top-k还是Top-1这种基础问题了它们都在解决更深层的结构缺陷。2.1 路由策略的演进从简单选择到负载感知分配早期MoE的路由策略就是让门控网络给每个专家打分选Top-k个专家做加权求和。但读2022年以后的论文你会看到路由问题被重新定义为“在专家利用率受限的前提下做分配”。我特别关注了一批引入负载均衡路由的工作。它们不满足于事后惩罚负载不均衡而是把路由决策本身设计成带约束的优化问题。有一类方法把专家看成容量有限的容器采用类似“尽量分配”的匈牙利匹配思路另一类则强调训练过程中路由分布的稳定性避免某个专家在某一批样本里被疯狂选中、下一批又被冷落。这两种思路各有优劣约束性好但计算开销上升稳定性好但牺牲灵活性。还有一个容易被忽略的点不同token的难度差异极大。简单token可能只需要一个专家就能处理好复杂token需要多个专家协作。所以不少论文开始探索“动态专家数量”的方案比如根据token的置信度决定到底激活几个专家。这类工作相当于把“稀疏激活”又往前推进了一步——不只稀疏在专家维度还稀疏在序列维度。2.2 专家分化问题为什么“混合专家”其实不专我在算法论文里最关注的一个概念叫expert specialization专家分化也就是不同专家到底有没有学到不同的能力。读论文和做实验都会发现MoE模型训练到一定程度后某些专家对标点符号、停用词这类简单token的响应权重特别高而真正负责复杂语义的只有少数几个专家。这明显违背了“让不同专家各司其职”的设计初衷。2022到2023年的算法类论文对这个问题的回应大致有三条路径。第一条是改造训练目标在损失函数里加入显式的专家分化正则让不同专家处理的知识尽量不重叠。第二条是改造初始化——既然自然分化不均匀那就人为给每个专家指定不同的初始化任务域。第三条是改造路由特征让路由器不只依赖当前token的隐状态还要参考历史路由信息例如这个专家最近处理过哪些类型的token。这三条路径的实验结果都显示专家分化确实能提升下游任务效果但代价是训练收敛变慢。我当时在合集里特别标注了一句话专家分化不是越彻底越好分化太强反而可能损害通用能力。这是很多只读标题的人容易忽略的结论。2.3 容量系数与专家数量两个关键超参的博弈算法类论文里容量系数capacity factor和专家数量是最常出现的两个超参数但大家往往把它们当成工程细节。我整理这批论文时发现2022到2023年很多争议其实都围绕这两个参数的平衡。容量系数决定了每个专家最多能处理多少token。系数太低token会被丢弃研究者发明了“token dropping”的兜底机制系数太高所有token都能被处理但MoE的计算优势就消失了。不同论文对这个系数的默认设置相差很大从1.0到2.0都有。这背后是各自训练任务的性质差异任务内token分布均匀的系数可以压得比较低分布极端的就必须留足余量。专家数量的问题更敏感。64个专家还是8个专家我看到的趋势是图像任务里专家数量不宜过多因为视觉token的多样性不如文本丰富而文本任务里在总参数量固定的前提下小专家数量多往往比大专家数量少的效果好。但这也带来了一个隐含风险推理时batch size如果不够大专家数量多反而导致每个专家利用率极低计算浪费在路由开销上。后来系统类论文里大量讨论的“批量调度”问题根源就在这里。2.4 算法类合集中我建议精读的几个工作方向这轮整理下来我建议真正想入门MoE算法的人不要平均用力。优先精读的方向包括动态路由与弹性专家激活、多任务门控与跨任务转移、结合注意力机制的分层MoE。这三个方向直接决定了下一代MoE模型还能不能继续涨效果也最容易迁移到新任务上。至于哪些论文可以泛读我自己的标准是只做了某个特定任务上的MoE适配、没有提出可泛化新机制的就只看结论和数据集。这样能避免被大量“不同任务同一套MoE结构”的论文淹没掉。3. 系统类论文让MoE在真实GPU集群上“能跑”的核心读算法论文的时候会产生一种错觉只要门控网络设计得好MoE模型就能正常工作。真到动手训练你很快就会发现自己主要是在跟显存OOM和通信超时斗争。2022到2023年的系统类论文本质上全部围绕三个词展开显存装不装得下、通信能不能同步、计算有没有浪费。3.1 全量专家驻留 vs 动态换入换出显存问题的两种解法MoE模型显存占用是同等参数稠密模型的很多倍因为全部专家权重都需要放到显存里虽然每次只激活一小部分。系统类论文里最根本性的分歧在于到底把全部专家一直放在显存里还是把不常用的专家换到CPU内存甚至硬盘上。全量驻留的优势是简单推理时任何专家都能被随时访问不增加I/O等待劣势是单机根本装不下一个大MoE模型必须做多机分布式。动态换入换出则主要存在于单机场景它利用MoE的实际局部性——一整个batch的token大概率只会落到少数几个专家上——把不涉及的专家留在大内存里。有一些2023年的工作就是沿着这个方向做优化效果确实好但要求负载预估足够准确否则换入换出本身就成了一笔巨大的开销。我的实操经验是如果你只是想在单卡上跑通一个小MoE模型做验证不要上“多专家多机”这种大工程用动态换入换出配合小专家数量就够。反过来如果要做规模化训练就别想着省通信老老实实走分布式全量驻留加高效同步是唯一靠谱的路线。3.2 all-to-all通信MoE系统绕不开的瓶颈MoE的分布式训练跟传统数据并行最大的区别在于多了一步all-to-all通信。数据并行只需要梯度同步而MoE训练中每个token可能被路由到任意一个GPU上的任意专家所以GPU之间必须频繁交换token数据这就是all-to-all通信的开销来源。读系统类论文你会发现几乎所有优化都围绕着“减少通信次数”和“提高通信效率”两个目标。有的工作提出对token做分组调度让同一批token尽量路由到同一批专家减少跨机访问有的工作则用“分层通信”先在同一节点内部做小规模交换再把跨节点的交换压缩到最少。这里有一个重要结论通信开销与专家数量强相关与模型维度弱相关。这意味着你把专家数从8个加到32个系统层的压力不是线性增加而是接近指数增长。算法类论文里那种“专家数量越大效果越好”的结果拿到系统层看往往是噩梦。我在合集里特意给每篇系统论文做了“可扩展性”标注明显看到2023年的工作比2022年更重视端到端的扩展性分析。3.3 训练稳定性与分布式并行策略的耦合MoE训练有个让系统RL工程师非常头疼的特征它的动态性极高。每个iteration里每个专家分配的token数都在变化导致负载不均衡进而引起部分GPU计算强度高、部分GPU闲置。这不是单靠加一个损失函数就能消除的它本质上是一个系统资源调度问题。2022到2023年的系统论文通常会对比并行方案。专家并行EP配合流水线并行PP几乎成了MoE大规模训练的标准配置但具体怎么切分专家、怎么安排设备组每篇论文都有不同的策略。我整理时发现一个规律效果最好的方案往往不是在全局最优而是在“通信模式简单”和“全局均衡”之间取折中。我建议读这批论文时不要跳过实验配置表。很多系统论文的核心贡献就是改动了一个并行配置的细节比如让同一设备组内专家数量保持2的幂次数、把某些跳层连接安排在设备边界内这些细节才是可以“抄作业”的地方。3.4 推理加速预填充与解码分离的思路训练只是一半MoE推理也是系统论文的重头戏。推理阶段有个显著特点预填充阶段处理输入的prompt计算密集可以并行度高解码阶段逐个生成token则高度依赖内存带宽每个token都要把激活的专家参数重新读一遍。MoE在解码阶段的问题特别突出——token批量小的时候专家利用率极低还频繁切换专家导致权重读取非常碎片化。2023年有几篇系统论文专门研究了这个问题提出把预填充和解码拆成两个阶段运行分别使用不同的并行策略和专家分配方式。这类论文的实用价值很高。如果你在业务里部署MoE模型想降低响应延迟优先搜“预填充解码分离”这个方向就对了。我在自己的GPU上验证过分离策略确实能把解码阶段的吞吐提升不少但实现复杂度也相应增加。对刚接触的人我建议先把常规的专家并行推理做对再考虑分离优化这种进阶手段。4. 应用类论文稀疏专家在真实任务中拿到的结果算法和系统文章读多了容易陷入“结构发力”的思维定式忘了MoE最终是要解决具体任务的。应用类论文在合集里主要承担两个作用一是验证新架构在真实数据上是否有效二是为后续改进提供任务场景素材。4.1 语言模型多语言与指令微调里的MoE收益2022到2023年MoE应用最成熟的还是在语言模型领域。我整理了一批涉及多语言任务的工作发现一个有趣的现象MoE结构在多语言场景里的收益比单语言更明显。原因是不同语言共享底层表示但又有各自独特的语法和词汇模式多个专家天然适合去分管不同语系或不同形态的语言。指令微调则为MoE提供了另一种可能让不同专家专门学习不同类型的指令意图。有论文尝试用可解释性分析方法观察不同专家对指令类别的响应差异结果确实观察到专家功能性分区的证据。这类工作让我觉得MoE在意图识别、任务型对话这类场景里有不小潜力。但应用类论文也暴露了不少问题。最典型的是稀疏模型在小数据集上不如稠密模型稳健。如果你的下游任务数据量很小MoE几乎必然过拟合。这个结论在合集里被多篇论文反复确认所以我不建议团队盲目把中小规模模型的稠密结构换成MoE。4.2 多模态视觉专家与跨模态路由的尝试多模态是2022到2023年MoE应用最热闹的方向之一。主流做法是把视觉encoder、文本encoder的输出统一映射到共享表示空间再通过路由分配到专家网络。由于图像token和文本token的数量往往不对等路由设计变得很有挑战性。有几篇论文的实验结果让我印象很深让MoE同时处理图像、文本、音频三种模态时不同模态的token对专家的偏好确实有明显差异个别专家几乎只接收图像token个别专家只吃文本token。这说明MoE可以天然实现“模态感知”的隐式分工不需要显式给每个模态指定专属专家。但应用类论文在这方面也遇到一个问题多模态推理时图像token数量通常庞大如果每个token都走一次路由选择整个系统的延迟会直线上升。有的论文的解决方案是把同一图像区域的所有token绑定到同一专家或者先做图像特征压缩再送进路由。这些细节应用层论文里写得比较清楚值得做多模态应用的读者仔细看。4.3 推荐系统与科学计算MoE走出TransformerMoE应用并不只限定在Transformer大模型里。我整理到推荐系统方向的论文时发现很多工作将MoE叠加在粗排和精排模型之上让不同专家学习不同用户群体的行为模式。推荐场景数据高稀疏、特征交互复杂MoE天然适合做“分而治之”。还有一类小众但很前沿的方向是科学计算比如分子性质预测、材料结构生成等。这些任务的数据量不大但数据维度高物理化学规则强。MoE在这里的优势是不同专家可以隐式学习不同条件下的物理规律比如一个专家擅长处理带金属原子的分子另一个专家擅长处理有机小分子。这类应用还比较早期但方向很有意思适合对交叉领域感兴趣的研究者。我对应用类论文的筛选标准是看三个东西任务是否具有普适价值、MoE带来的收益是否经过了与稠密模型的严格对比、有没有给出部署代价的分析。缺任何一样我就把该论文放到“泛读区”而不是“精读区”。4.4 应用类论文要警惕的“伪增益”读应用类论文最容易踩的坑是“伪增益”。很多论文报告MoE比稠密模型效果提升了几个百分点但仔细看实验条件MoE模型的参数量通常是稠密模型的几十倍计算量却不一定有提升甚至可能下降。做合集时我用了一个简单判断方法在论文实验里找出“同等计算量”设置下的对比结果而不是只看“同等参数量”。MoE的价值在于用同样多的计算量换取更强的表达力如果只拿参数量说事那任何大杂烩模型都能刷分。这一条经验我建议所有读MoE论文的人都牢牢记住。5. 论文合集的具体筛选标准、目录组织与阅读顺序做合集不只是把论文堆在一起更重要的是让读者能沿着一条清晰路径从入门到进阶。我整理2022到2023年这批MoE论文时在筛选和编排上花了不少时间下面直接分享我当时的操作过程。5.1 我从几百篇论文里筛出合集正文的四个标准第一个标准是“方法具有迁移性”。如果一篇论文只在某个特定数据集上有效、方法完全依赖任务特性我会直接排除因为它对多数读者没有借鉴意义。第二个标准是“实验设置可信”。重点看它是否报告了专家数量、容量系数、batch size、训练步数这些关键配置。一篇论文如果缺了这些基本参数哪怕结果再好看我都持保留态度。第三个标准是“与2022到2023年MoE核心问题相关”。具体来说就是看它是否推动了算法效果、系统效率或应用场景三方面的进步。那种单纯把已有MoE模块塞到新任务里、没有任何适配创新的文章不进正文。第四个标准是“开源或可复现”。2022到2023年有一个好趋势越来越多MoE论文公开了代码和权重。我优先收录这些工作因为读者看完论文后还能跑实验验证这对学习效率的提升非常明显。5.2 目录组织方式给三大类再做二级细分我的合集目录在算法、系统、应用三大类之下还有二级维度。算法类继续拆成路由策略、专家分化、训练目标、结构变体系统类拆成训练框架、推理优化、通信压缩、显存管理应用类则拆成语言模型、多模态、推荐系统、跨领域探索。这个组织方式很大程度上是跟着“论文入口问题”走的。读者读MoE论文时一般不会问“这属于算法还是系统”而是问“我想减少通信该看什么”“我想改进路由该怎么开始”。所以二级分类实际上就是读者常见问题的映射。另外我在每篇论文条目后面标了三个标签会议级别比如ICML、NeurIPS、ACL、MLSys、复现难度简单/中等/困难、推荐精读程度泛读/精读。这样别人拿到合集的第一个小时就能根据自己的时间安排制定阅读计划不用再自己去浪费时间摸索。5.3 我推荐的三种阅读路径根据读者背景不同我整理了三条有差异的阅读路径比单纯按顺序读要高效得多。对算法背景的人我建议先读算法类的路由策略子类然后跳到系统类训练框架子类最后再看应用类里和多模态相关的几篇。这样你能理解“我设计的路由在真机上是怎么跑的、落在多模态任务里又是什么表现”。对系统背景的人从系统类的推理优化开始读然后是训练框架接着读算法类里负载均衡相关的几篇。你把系统瓶颈理解了往回读算法论文时就能快速抓住算法设计对系统开销的潜在影响。对应用背景的人以应用类论文为主先精读语言模型和多模态子类遇到不懂的机制再反查算法类的基础章节。不要让应用类论文里那些“大模型MoE”的名词吓到你只需要理解路由和专家的概念就足以读懂大部分应用实验。5.4 精读与泛读的时间分配建议我自己的经验是一个两百页左右的MoE课业合集精读和泛读的时长比例大概在四比六。精读的论文不需要多但每篇都要能讲清楚“它解决的问题是什么、方法的核心机制是什么、实验结果强在哪里、局限性有哪些”。泛读的论文只需要记住“作者做了什么、结论是什么”就够了。精读建议优先选择那些同时被多个后续工作引用的论文它们往往是某个子方向的基础。泛读则可以用来快速拓宽视野了解2022到2023年MoE在应用上的整体版图。我在整理合集时发现很多新入行的读者最大的问题不是读得少而是把所有论文都当成精读材料结果一个月下来还在前几篇里打转阅读节奏全乱了。6. 跟着合集做一次最小复现最值得注意的几个坑论文读得再多不如动手跑一次实验。我在整理这堆MoE论文的同时自己也在一个小规模任务上做了一次最小复现跑下来最大的收获就是发现文本里读不出来、只有实践才会遇到的坑。6.1 复现的第一步是定一个“足够小”的实验池我第一次复现MoE最大的失误是目标定得太大试图直接在一个中等规模语言模型上做MoE改造。结果单卡显存不够分布式又还没配好卡了好几天。后来我把实验缩减成用一个很小的Transformer基座大概几十M参数在公开的文本分类数据集上对比稠密和MoE两种结构的收敛效果。这个小实验池只需要单卡就能跑而且能直观看到MoE到底带来多少收益。如果你也想复现我建议把第一步卡在“单卡能跑完、时间控制在几小时以内”这个规模别贪大。6.2 负载均衡损失设不好训练直接崩复现中我遇到最坑的问题是负载均衡的权重系数。MoE训练时如果负载均衡项权重设得太小几个专家会把大部分token抢走其他专家几乎不更新模型直接退化如果设得太大模型只顾着均衡分配忽略了下游任务loss效果又会变差。这一块没有万能公式。我的做法是在一个很小的代理任务上固定步数跑几组随机种子选出最稳的配置再搬到正式实验里。千万不要一上来就想在完整训练里调这个超参时间成本完全不可控。6.3 显存分配与通信日志一定要提前看如果你和我一样用分布式训练MoE提前看显存分配和通信日志真的很重要。我第一次跑的时候根本没看日志结果训练卡在一个奇怪的等待状态里查了半天才发现是某个通信组的token数量过多导致同步延迟异常。后来学乖了每次启动训练前先做一次短步数热身专门检查两个东西每个专家接收的token数量是否大致均衡每个GPU上分配的显存是否溢出边界。这一步看起来额外多花了点时间实际上能帮你节省排查问题的时间。6.4 用“小模型专家数少”验证学习率MoE对学习率比稠密模型更敏感这也是一个需要反复实验的经验。我在复现中发现同一个学习率在稠密模型上效果正常换到MoE结构上就出现loss震荡。原因是不同专家接收的token量不同梯度偏置也更大用一个全局学习率很难同时适配所有专家。如果你想在复现时少走弯路可以先尝试把专家数量设置得很少比如2-4个把基础学习率调低到稠密模型的一半左右看训练是否稳定。然后再慢慢扩大专家数量每扩大一次都重新校验学习率。这样操作听起来比较保守但在资源有限的情况下是最稳妥、最能预测结果的路径。最后顺手分享一点整理心得与扩展建议整理这批2022到2023年MoE论文合集的过程中我最大的体会是这个方向真正难的点不在于模型结构本身有多复杂而在于算法、系统、应用三个层面紧密咬合缺一不可。单独看任何一篇论文都觉得自己懂了但放到一起才意识到一个可靠的MoE系统是整个链条相互配合的结果。如果你也想做一个类似主题的论文合集我有两个具体建议。一是务必给论文标注“复现难度”和“是否开源”这是决定了读者能不能把论文转化成真正理解的关键信息。二是保持合集的迭代习惯2023年之后MoE的发展速度更快了又有很多新模型和新框架出现建议每过几个月就看一轮新论文把合集模块更新一下。这套论文合集我目前还在持续维护。后续我计划把2024年新发布的MoE工作补进去同时增加一些与边缘端部署、小模型稀疏化相关的对比分析。如果有机会我也会把合集里算法篇的经典工作整理成更详细的拆解文章一篇篇讲清楚它们的设计动机和复现细节。 MoE论文合集整理指南：算法、系统与应用三条主线
我最早关注混合专家模型MoE这批论文其实是2023年底帮实验室整理年度顶会论文清单。当时GPT-4传出“多大16个专家模型”的八卦Mistral又突然放出一个8专家开源的MoE模型整个圈子对稀疏架构的热情一下子被点着了。但真开始看论文我发现一个尴尬的问题MoE方向看着火论文却散得很有的在讲门控网络的loss改进有的在折腾分布式通信还有的直接把MoE塞进多模态模型里刷榜。如果不按算法、系统、应用三条线做分类零基础的人根本不知道从哪里读起。这篇文章就是我整理这批2022到2023年MoE顶会顶刊论文合集时的主要思路和笔记。我不仅告诉你这个合集里为什么要把论文分成三大类还会把每一类里最关键的问题、最值得精读的工作、以及复现时最容易踩的坑一起说清楚。对刚想入坑MoE的研究生、准备做模型架构选型的算法工程师、还有需要评估MoE推理成本的系统同学来说这篇应该都能帮你省下不少选论文的时间。1. 我在整理合集时确定的边界2022到2023年间MoE的三条主线做论文合集最怕的就是贪多嚼不烂。MoE这个词在2022到2023年频繁出现在顶会顶刊上但不同论文解决的根本不是同一个问题。我划分三大类的基本原则是看论文的“主要产出物”产出新模型结构、新训练目标、新路由策略的归入算法产出新并行策略、显存管理方法、推理优化框架的归入系统产出新任务效果验证、新应用场景尝试、新评测结论的归入应用。这样分类有一个额外的好处同一篇论文如果既改了结构又做了系统优化我会按它的核心贡献归入最合适的一类但在摘要里标注清楚它涉及的其他维度。这种划分并不是说算法、系统、应用三者可以完全割裂。恰恰相反2022到2023年MoE论文的最大特点是互相依赖。算法类论文提出一个新的负载均衡损失函数系统类论文里的调度策略就需要跟进适配应用类论文发现专家数量加到64个后效果不涨反降算法类论文就得回头研究是不是路由策略出了问题。所以我做合集的第一个动作是给每篇论文加了一个“关联问题”字段把这种依赖关系显式记下来。为什么要锁定2022到2023年这个时间窗口理由也很直接。这个阶段是LLM训练成本急剧膨胀的时期研究者必须找到一种“既扩大参数量、又不线性增加计算量”的架构MoE的稀疏激活特性天然契合这个需求。而且这段时间正好是MoE从“工程界不太敢用”到“开源社区大规模验证可用”的转折期论文质量整体很高适合作为入门学习的核心区间。太早的MoE工作比如2017年那批理论价值高但实践距离远太晚的又还没经过充分沉淀。2. 算法类论文真正在改模型结构的那批工作算法类论文是合集里最庞杂的一部分也是新手最容易迷失的地方。很多入门文章只会告诉你“MoE就是Top-k路由器选专家”但实际读论文会发现2022到2023年的算法工作早就不纠结Top-k还是Top-1这种基础问题了它们都在解决更深层的结构缺陷。2.1 路由策略的演进从简单选择到负载感知分配早期MoE的路由策略就是让门控网络给每个专家打分选Top-k个专家做加权求和。但读2022年以后的论文你会看到路由问题被重新定义为“在专家利用率受限的前提下做分配”。我特别关注了一批引入负载均衡路由的工作。它们不满足于事后惩罚负载不均衡而是把路由决策本身设计成带约束的优化问题。有一类方法把专家看成容量有限的容器采用类似“尽量分配”的匈牙利匹配思路另一类则强调训练过程中路由分布的稳定性避免某个专家在某一批样本里被疯狂选中、下一批又被冷落。这两种思路各有优劣约束性好但计算开销上升稳定性好但牺牲灵活性。还有一个容易被忽略的点不同token的难度差异极大。简单token可能只需要一个专家就能处理好复杂token需要多个专家协作。所以不少论文开始探索“动态专家数量”的方案比如根据token的置信度决定到底激活几个专家。这类工作相当于把“稀疏激活”又往前推进了一步——不只稀疏在专家维度还稀疏在序列维度。2.2 专家分化问题为什么“混合专家”其实不专我在算法论文里最关注的一个概念叫expert specialization专家分化也就是不同专家到底有没有学到不同的能力。读论文和做实验都会发现MoE模型训练到一定程度后某些专家对标点符号、停用词这类简单token的响应权重特别高而真正负责复杂语义的只有少数几个专家。这明显违背了“让不同专家各司其职”的设计初衷。2022到2023年的算法类论文对这个问题的回应大致有三条路径。第一条是改造训练目标在损失函数里加入显式的专家分化正则让不同专家处理的知识尽量不重叠。第二条是改造初始化——既然自然分化不均匀那就人为给每个专家指定不同的初始化任务域。第三条是改造路由特征让路由器不只依赖当前token的隐状态还要参考历史路由信息例如这个专家最近处理过哪些类型的token。这三条路径的实验结果都显示专家分化确实能提升下游任务效果但代价是训练收敛变慢。我当时在合集里特别标注了一句话专家分化不是越彻底越好分化太强反而可能损害通用能力。这是很多只读标题的人容易忽略的结论。2.3 容量系数与专家数量两个关键超参的博弈算法类论文里容量系数capacity factor和专家数量是最常出现的两个超参数但大家往往把它们当成工程细节。我整理这批论文时发现2022到2023年很多争议其实都围绕这两个参数的平衡。容量系数决定了每个专家最多能处理多少token。系数太低token会被丢弃研究者发明了“token dropping”的兜底机制系数太高所有token都能被处理但MoE的计算优势就消失了。不同论文对这个系数的默认设置相差很大从1.0到2.0都有。这背后是各自训练任务的性质差异任务内token分布均匀的系数可以压得比较低分布极端的就必须留足余量。专家数量的问题更敏感。64个专家还是8个专家我看到的趋势是图像任务里专家数量不宜过多因为视觉token的多样性不如文本丰富而文本任务里在总参数量固定的前提下小专家数量多往往比大专家数量少的效果好。但这也带来了一个隐含风险推理时batch size如果不够大专家数量多反而导致每个专家利用率极低计算浪费在路由开销上。后来系统类论文里大量讨论的“批量调度”问题根源就在这里。2.4 算法类合集中我建议精读的几个工作方向这轮整理下来我建议真正想入门MoE算法的人不要平均用力。优先精读的方向包括动态路由与弹性专家激活、多任务门控与跨任务转移、结合注意力机制的分层MoE。这三个方向直接决定了下一代MoE模型还能不能继续涨效果也最容易迁移到新任务上。至于哪些论文可以泛读我自己的标准是只做了某个特定任务上的MoE适配、没有提出可泛化新机制的就只看结论和数据集。这样能避免被大量“不同任务同一套MoE结构”的论文淹没掉。3. 系统类论文让MoE在真实GPU集群上“能跑”的核心读算法论文的时候会产生一种错觉只要门控网络设计得好MoE模型就能正常工作。真到动手训练你很快就会发现自己主要是在跟显存OOM和通信超时斗争。2022到2023年的系统类论文本质上全部围绕三个词展开显存装不装得下、通信能不能同步、计算有没有浪费。3.1 全量专家驻留 vs 动态换入换出显存问题的两种解法MoE模型显存占用是同等参数稠密模型的很多倍因为全部专家权重都需要放到显存里虽然每次只激活一小部分。系统类论文里最根本性的分歧在于到底把全部专家一直放在显存里还是把不常用的专家换到CPU内存甚至硬盘上。全量驻留的优势是简单推理时任何专家都能被随时访问不增加I/O等待劣势是单机根本装不下一个大MoE模型必须做多机分布式。动态换入换出则主要存在于单机场景它利用MoE的实际局部性——一整个batch的token大概率只会落到少数几个专家上——把不涉及的专家留在大内存里。有一些2023年的工作就是沿着这个方向做优化效果确实好但要求负载预估足够准确否则换入换出本身就成了一笔巨大的开销。我的实操经验是如果你只是想在单卡上跑通一个小MoE模型做验证不要上“多专家多机”这种大工程用动态换入换出配合小专家数量就够。反过来如果要做规模化训练就别想着省通信老老实实走分布式全量驻留加高效同步是唯一靠谱的路线。3.2 all-to-all通信MoE系统绕不开的瓶颈MoE的分布式训练跟传统数据并行最大的区别在于多了一步all-to-all通信。数据并行只需要梯度同步而MoE训练中每个token可能被路由到任意一个GPU上的任意专家所以GPU之间必须频繁交换token数据这就是all-to-all通信的开销来源。读系统类论文你会发现几乎所有优化都围绕着“减少通信次数”和“提高通信效率”两个目标。有的工作提出对token做分组调度让同一批token尽量路由到同一批专家减少跨机访问有的工作则用“分层通信”先在同一节点内部做小规模交换再把跨节点的交换压缩到最少。这里有一个重要结论通信开销与专家数量强相关与模型维度弱相关。这意味着你把专家数从8个加到32个系统层的压力不是线性增加而是接近指数增长。算法类论文里那种“专家数量越大效果越好”的结果拿到系统层看往往是噩梦。我在合集里特意给每篇系统论文做了“可扩展性”标注明显看到2023年的工作比2022年更重视端到端的扩展性分析。3.3 训练稳定性与分布式并行策略的耦合MoE训练有个让系统RL工程师非常头疼的特征它的动态性极高。每个iteration里每个专家分配的token数都在变化导致负载不均衡进而引起部分GPU计算强度高、部分GPU闲置。这不是单靠加一个损失函数就能消除的它本质上是一个系统资源调度问题。2022到2023年的系统论文通常会对比并行方案。专家并行EP配合流水线并行PP几乎成了MoE大规模训练的标准配置但具体怎么切分专家、怎么安排设备组每篇论文都有不同的策略。我整理时发现一个规律效果最好的方案往往不是在全局最优而是在“通信模式简单”和“全局均衡”之间取折中。我建议读这批论文时不要跳过实验配置表。很多系统论文的核心贡献就是改动了一个并行配置的细节比如让同一设备组内专家数量保持2的幂次数、把某些跳层连接安排在设备边界内这些细节才是可以“抄作业”的地方。3.4 推理加速预填充与解码分离的思路训练只是一半MoE推理也是系统论文的重头戏。推理阶段有个显著特点预填充阶段处理输入的prompt计算密集可以并行度高解码阶段逐个生成token则高度依赖内存带宽每个token都要把激活的专家参数重新读一遍。MoE在解码阶段的问题特别突出——token批量小的时候专家利用率极低还频繁切换专家导致权重读取非常碎片化。2023年有几篇系统论文专门研究了这个问题提出把预填充和解码拆成两个阶段运行分别使用不同的并行策略和专家分配方式。这类论文的实用价值很高。如果你在业务里部署MoE模型想降低响应延迟优先搜“预填充解码分离”这个方向就对了。我在自己的GPU上验证过分离策略确实能把解码阶段的吞吐提升不少但实现复杂度也相应增加。对刚接触的人我建议先把常规的专家并行推理做对再考虑分离优化这种进阶手段。4. 应用类论文稀疏专家在真实任务中拿到的结果算法和系统文章读多了容易陷入“结构发力”的思维定式忘了MoE最终是要解决具体任务的。应用类论文在合集里主要承担两个作用一是验证新架构在真实数据上是否有效二是为后续改进提供任务场景素材。4.1 语言模型多语言与指令微调里的MoE收益2022到2023年MoE应用最成熟的还是在语言模型领域。我整理了一批涉及多语言任务的工作发现一个有趣的现象MoE结构在多语言场景里的收益比单语言更明显。原因是不同语言共享底层表示但又有各自独特的语法和词汇模式多个专家天然适合去分管不同语系或不同形态的语言。指令微调则为MoE提供了另一种可能让不同专家专门学习不同类型的指令意图。有论文尝试用可解释性分析方法观察不同专家对指令类别的响应差异结果确实观察到专家功能性分区的证据。这类工作让我觉得MoE在意图识别、任务型对话这类场景里有不小潜力。但应用类论文也暴露了不少问题。最典型的是稀疏模型在小数据集上不如稠密模型稳健。如果你的下游任务数据量很小MoE几乎必然过拟合。这个结论在合集里被多篇论文反复确认所以我不建议团队盲目把中小规模模型的稠密结构换成MoE。4.2 多模态视觉专家与跨模态路由的尝试多模态是2022到2023年MoE应用最热闹的方向之一。主流做法是把视觉encoder、文本encoder的输出统一映射到共享表示空间再通过路由分配到专家网络。由于图像token和文本token的数量往往不对等路由设计变得很有挑战性。有几篇论文的实验结果让我印象很深让MoE同时处理图像、文本、音频三种模态时不同模态的token对专家的偏好确实有明显差异个别专家几乎只接收图像token个别专家只吃文本token。这说明MoE可以天然实现“模态感知”的隐式分工不需要显式给每个模态指定专属专家。但应用类论文在这方面也遇到一个问题多模态推理时图像token数量通常庞大如果每个token都走一次路由选择整个系统的延迟会直线上升。有的论文的解决方案是把同一图像区域的所有token绑定到同一专家或者先做图像特征压缩再送进路由。这些细节应用层论文里写得比较清楚值得做多模态应用的读者仔细看。4.3 推荐系统与科学计算MoE走出TransformerMoE应用并不只限定在Transformer大模型里。我整理到推荐系统方向的论文时发现很多工作将MoE叠加在粗排和精排模型之上让不同专家学习不同用户群体的行为模式。推荐场景数据高稀疏、特征交互复杂MoE天然适合做“分而治之”。还有一类小众但很前沿的方向是科学计算比如分子性质预测、材料结构生成等。这些任务的数据量不大但数据维度高物理化学规则强。MoE在这里的优势是不同专家可以隐式学习不同条件下的物理规律比如一个专家擅长处理带金属原子的分子另一个专家擅长处理有机小分子。这类应用还比较早期但方向很有意思适合对交叉领域感兴趣的研究者。我对应用类论文的筛选标准是看三个东西任务是否具有普适价值、MoE带来的收益是否经过了与稠密模型的严格对比、有没有给出部署代价的分析。缺任何一样我就把该论文放到“泛读区”而不是“精读区”。4.4 应用类论文要警惕的“伪增益”读应用类论文最容易踩的坑是“伪增益”。很多论文报告MoE比稠密模型效果提升了几个百分点但仔细看实验条件MoE模型的参数量通常是稠密模型的几十倍计算量却不一定有提升甚至可能下降。做合集时我用了一个简单判断方法在论文实验里找出“同等计算量”设置下的对比结果而不是只看“同等参数量”。MoE的价值在于用同样多的计算量换取更强的表达力如果只拿参数量说事那任何大杂烩模型都能刷分。这一条经验我建议所有读MoE论文的人都牢牢记住。5. 论文合集的具体筛选标准、目录组织与阅读顺序做合集不只是把论文堆在一起更重要的是让读者能沿着一条清晰路径从入门到进阶。我整理2022到2023年这批MoE论文时在筛选和编排上花了不少时间下面直接分享我当时的操作过程。5.1 我从几百篇论文里筛出合集正文的四个标准第一个标准是“方法具有迁移性”。如果一篇论文只在某个特定数据集上有效、方法完全依赖任务特性我会直接排除因为它对多数读者没有借鉴意义。第二个标准是“实验设置可信”。重点看它是否报告了专家数量、容量系数、batch size、训练步数这些关键配置。一篇论文如果缺了这些基本参数哪怕结果再好看我都持保留态度。第三个标准是“与2022到2023年MoE核心问题相关”。具体来说就是看它是否推动了算法效果、系统效率或应用场景三方面的进步。那种单纯把已有MoE模块塞到新任务里、没有任何适配创新的文章不进正文。第四个标准是“开源或可复现”。2022到2023年有一个好趋势越来越多MoE论文公开了代码和权重。我优先收录这些工作因为读者看完论文后还能跑实验验证这对学习效率的提升非常明显。5.2 目录组织方式给三大类再做二级细分我的合集目录在算法、系统、应用三大类之下还有二级维度。算法类继续拆成路由策略、专家分化、训练目标、结构变体系统类拆成训练框架、推理优化、通信压缩、显存管理应用类则拆成语言模型、多模态、推荐系统、跨领域探索。这个组织方式很大程度上是跟着“论文入口问题”走的。读者读MoE论文时一般不会问“这属于算法还是系统”而是问“我想减少通信该看什么”“我想改进路由该怎么开始”。所以二级分类实际上就是读者常见问题的映射。另外我在每篇论文条目后面标了三个标签会议级别比如ICML、NeurIPS、ACL、MLSys、复现难度简单/中等/困难、推荐精读程度泛读/精读。这样别人拿到合集的第一个小时就能根据自己的时间安排制定阅读计划不用再自己去浪费时间摸索。5.3 我推荐的三种阅读路径根据读者背景不同我整理了三条有差异的阅读路径比单纯按顺序读要高效得多。对算法背景的人我建议先读算法类的路由策略子类然后跳到系统类训练框架子类最后再看应用类里和多模态相关的几篇。这样你能理解“我设计的路由在真机上是怎么跑的、落在多模态任务里又是什么表现”。对系统背景的人从系统类的推理优化开始读然后是训练框架接着读算法类里负载均衡相关的几篇。你把系统瓶颈理解了往回读算法论文时就能快速抓住算法设计对系统开销的潜在影响。对应用背景的人以应用类论文为主先精读语言模型和多模态子类遇到不懂的机制再反查算法类的基础章节。不要让应用类论文里那些“大模型MoE”的名词吓到你只需要理解路由和专家的概念就足以读懂大部分应用实验。5.4 精读与泛读的时间分配建议我自己的经验是一个两百页左右的MoE课业合集精读和泛读的时长比例大概在四比六。精读的论文不需要多但每篇都要能讲清楚“它解决的问题是什么、方法的核心机制是什么、实验结果强在哪里、局限性有哪些”。泛读的论文只需要记住“作者做了什么、结论是什么”就够了。精读建议优先选择那些同时被多个后续工作引用的论文它们往往是某个子方向的基础。泛读则可以用来快速拓宽视野了解2022到2023年MoE在应用上的整体版图。我在整理合集时发现很多新入行的读者最大的问题不是读得少而是把所有论文都当成精读材料结果一个月下来还在前几篇里打转阅读节奏全乱了。6. 跟着合集做一次最小复现最值得注意的几个坑论文读得再多不如动手跑一次实验。我在整理这堆MoE论文的同时自己也在一个小规模任务上做了一次最小复现跑下来最大的收获就是发现文本里读不出来、只有实践才会遇到的坑。6.1 复现的第一步是定一个“足够小”的实验池我第一次复现MoE最大的失误是目标定得太大试图直接在一个中等规模语言模型上做MoE改造。结果单卡显存不够分布式又还没配好卡了好几天。后来我把实验缩减成用一个很小的Transformer基座大概几十M参数在公开的文本分类数据集上对比稠密和MoE两种结构的收敛效果。这个小实验池只需要单卡就能跑而且能直观看到MoE到底带来多少收益。如果你也想复现我建议把第一步卡在“单卡能跑完、时间控制在几小时以内”这个规模别贪大。6.2 负载均衡损失设不好训练直接崩复现中我遇到最坑的问题是负载均衡的权重系数。MoE训练时如果负载均衡项权重设得太小几个专家会把大部分token抢走其他专家几乎不更新模型直接退化如果设得太大模型只顾着均衡分配忽略了下游任务loss效果又会变差。这一块没有万能公式。我的做法是在一个很小的代理任务上固定步数跑几组随机种子选出最稳的配置再搬到正式实验里。千万不要一上来就想在完整训练里调这个超参时间成本完全不可控。6.3 显存分配与通信日志一定要提前看如果你和我一样用分布式训练MoE提前看显存分配和通信日志真的很重要。我第一次跑的时候根本没看日志结果训练卡在一个奇怪的等待状态里查了半天才发现是某个通信组的token数量过多导致同步延迟异常。后来学乖了每次启动训练前先做一次短步数热身专门检查两个东西每个专家接收的token数量是否大致均衡每个GPU上分配的显存是否溢出边界。这一步看起来额外多花了点时间实际上能帮你节省排查问题的时间。6.4 用“小模型专家数少”验证学习率MoE对学习率比稠密模型更敏感这也是一个需要反复实验的经验。我在复现中发现同一个学习率在稠密模型上效果正常换到MoE结构上就出现loss震荡。原因是不同专家接收的token量不同梯度偏置也更大用一个全局学习率很难同时适配所有专家。如果你想在复现时少走弯路可以先尝试把专家数量设置得很少比如2-4个把基础学习率调低到稠密模型的一半左右看训练是否稳定。然后再慢慢扩大专家数量每扩大一次都重新校验学习率。这样操作听起来比较保守但在资源有限的情况下是最稳妥、最能预测结果的路径。最后顺手分享一点整理心得与扩展建议整理这批2022到2023年MoE论文合集的过程中我最大的体会是这个方向真正难的点不在于模型结构本身有多复杂而在于算法、系统、应用三个层面紧密咬合缺一不可。单独看任何一篇论文都觉得自己懂了但放到一起才意识到一个可靠的MoE系统是整个链条相互配合的结果。如果你也想做一个类似主题的论文合集我有两个具体建议。一是务必给论文标注“复现难度”和“是否开源”这是决定了读者能不能把论文转化成真正理解的关键信息。二是保持合集的迭代习惯2023年之后MoE的发展速度更快了又有很多新模型和新框架出现建议每过几个月就看一轮新论文把合集模块更新一下。这套论文合集我目前还在持续维护。后续我计划把2024年新发布的MoE工作补进去同时增加一些与边缘端部署、小模型稀疏化相关的对比分析。如果有机会我也会把合集里算法篇的经典工作整理成更详细的拆解文章一篇篇讲清楚它们的设计动机和复现细节。