我最早关注混合专家模型（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走出Transformer
MoE应用并不只限定在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工作补进去，同时增加一些与边缘端部署、小模型稀疏化相关的对比分析。如果有机会，我也会把合集里算法篇的经典工作整理成更详细的拆解文章，一篇篇讲清楚它们的设计动机和复现细节。
