混合专家模型中的涌现式模块化（8 分钟阅读）

# EMO：面向涌现模块化的专家混合（MoE）预训练 | Ai2 来源：https://allenai.org/blog/emo 今天我们正式发布 **EMO** (https://huggingface.co/allenai/EMO)，这是一款全新的专家混合（MoE）模型，采用端到端方式预训练，使得模块化结构能够直接从数据中涌现，而无需依赖人工定义的先验条件。EMO 允许你在处理特定任务时仅使用其极小一部分专家（仅占总数的 12.5%），同时仍能保持接近全模型的性能；而在所有专家共同工作时，它依然是一款强大的通用模型。 大型语言模型通常以单体系统（monolithic systems）的方式训练和部署：单个模型被初始化、预训练、微调，并作为一个统一实体提供服务。但实际应用程序通常只需要部分能力——例如代码生成、数学推理或领域特定知识。随着前沿语言模型的参数量普遍达到万亿级别，对大多数用户而言，使用并适配全模型已变得不切实际，且会为那些可能根本用不到的参数带来不必要的计算成本与内存开销。 专家混合（MoE）模型似乎是缓解这一限制的自然方案。MoE 模型不再在每一层使用一个大型前馈网络，而是包含许多较小的网络（称为“专家”），并且针对每个输入 token 仅激活其中的一小部分。原则上，只需要单一能力的任务可以仅加载相关的专家。 然而在实践中，现有的 MoE 模型仍需要全模型协同才能良好工作。即使在单个输入内部，不同的 token 也常常激活不同的专家，导致一个任务在其生成过程中最终可能会用到所有专家。正如我们在论文中所示，部分原因在于标准 MoE 中的专家往往专注于介词或标点符号等低级词汇模式，而非更高层级的领域或能力。因此，专家的小子集无法独立可靠地运行。 相反，我们希望 MoE 模型的专家能够组织成连贯的组别，从而可以被选择性使用和组合。 在预训练期间促进这一目标的一种方法是根据预定义的语义领域（如数学、生物学或代码）将 token 路由到专家。BTX 和我们之前的 FlexOlmo 项目等前期工作已尝试过此路径。然而，预定义领域存在重要局限性。它们需要在预训练语料库上获取领域标签，这往往存在歧义且成本高昂，并且可能将过多的人类偏见引入模型自我组织的方式中。更重要的是，预先固定领域也会固定模型的模块化结构：如果在推理时出现新领域或新能力，很难明确该使用哪些专家。 这正是 EMO 的切入点。 我们证明，EMO——一个基于 1 万亿 token 训练、1B 活跃参数 / 14B 总参数（8 个活跃专家 / 128 个总专家）的 MoE 模型——支持专家的选择性使用：针对特定任务或领域，我们仅使用极小一部分专家（仅占总专家数的 12.5%）即可保持接近全模型的性能。同时，当所有专家共同工作时，EMO 依然保持强大的通用模型能力。相比之下，在相同数据上训练的、架构相同的标准 MoE 在选择性使用专家子集时会出现严重的性能下降。 ### **如何实现模块化的涌现？** 在 MoE 中，一个称为路由器（router）的小型网络负责决定每个 token 激活哪些专家。我们希望路由器能够学习到：来自相似领域的 token 应激活相似的专家子集。我们的关键观察是：*来自同一文档的 token 通常属于同一领域*。因此，我们利用文档边界作为弱监督信号：在训练期间，同一文档中的所有 token 都被限制从一个共享的专家池中选择其活跃专家。 例如，在一个拥有 10 个总专家且每个 token 激活 2 个专家的 MoE 中，同一文档内的所有 token 都被限制在同一组 4 个专家的池中进行路由，如上所示。该专家池由路由器自身选择：我们对文档中所有 token 的专家偏好进行平均，然后选出使用频率最高的专家作为该文档的共享专家池。不同文档可以使用不同的专家池，从而使反复出现的专家组直接从训练数据中涌现出来。 在实现该系统时有几点需要考虑： **负载均衡（Load balancing）。**一项技术挑战是负载均衡。在标准 MoE 训练中，负载均衡目标用于防止模型坍塌至仅使用少数几个专家。乍一看，这似乎与 EMO 的训练目标相冲突：我们明确限制了每个文档仅使用一部分专家。 冲突源于负载均衡通常应用的作用域。在许多 MoE 实现中，负载均衡是在局部计算的，通常仅限于包含少量文档的微批次（micro-batch）内。这种局部目标可能会促使同一文档内的 token 分散到许多不同的专家上，这直接与 EMO 保持文档内专家使用一致性的目标相悖。 为解决这一问题，我们在大量文档的全局范围内应用负载均衡。在这个更大的尺度上，两个目标变得互补：EMO 鼓励同一文档内的 token 使用连贯的专家池，而全局负载均衡则鼓励不同文档共同覆盖所有专家。在实践中，我们发现全局负载均衡对稳定训练至关重要。 **文档专家池大小（Document pool size）**：文档专家池大小控制了模块化约束的严格程度。较小的池会迫使同一文档中的 token 共享更紧密的专家集合，从而促进更强的模块化；较大的池则为模型提供更多灵活性，但会削弱约束。 我们没有固定单一的池大小，而是在训练期间对其进行随机采样。这防止了 EMO 对单一子集大小过拟合，并使其在推理时能够支持不同的专家子集大小。 ### **基准测试结果** 在通用基准测试中，EMO 的表现与标准 MoE 模型持平，这表明模块化目标并未以牺牲全模型性能为代价。然而，更关键的问题在于：当我们仅保留部分专家时，模型是否仍能正常工作？在此设定下，我们通过模型在少量任务验证数据上的路由使用情况对专家进行排序，保留最常用的专家并丢弃其余专家，从而构建任务特定的专家子集。 下图表明，EMO 在选择性使用专家时依然保持鲁棒性。当仅保留 25% 的专家（32 个专家的子集）时，EMO 在所有基准测试上的绝对性能仅下降约 1%；即使仅保留 12.5% 的专家（16 个专家的子集），整体下降也仅为约 3%。这一结论在微调前后均成立。相比之下，匹配的标准 MoE 随着专家子集变小而急剧退化，在最小的专家子集设定下，其性能通常接近甚至低于随机水平。 此外，我们证明为任务选择正确的专家出奇地低成本——仅需一个带有少样本示例（few-shot demonstrations）的例子，就足以识别出一个与使用完整验证集所选模块性能相当的模块。而且 EMO 并不绑定于任何特定的选择方法：它能与 Easy-EP 等现有的专家剪枝方法良好配合，两者相辅相成。 ### **专家子集专精于什么？** 为了了解 EMO 在训练后实际学到了什么，我们对 1.2 万篇预训练文档中前 100 个 token 的路由器激活进行了聚类。与标准 MoE 的对比十分鲜明。 EMO 的 token 聚类对应于诸如 *Health, Medical & Wellness*、*News Reporting*、*US Politics & Elections* 和 *Film & Music* 等主题。而标准 MoE 产生的聚类则如 *Prepositions*、*Proper Names*、*Copula Verbs* 或 *Definite Articles*。在 EMO 中，来自同一文档的 token 大多落在同一个聚类中；而在标准 MoE 中，它们则分散在多个聚类中。 这种对比在单个示例中最为直观。以一篇健康类文章为例——在 EMO 中，几乎所有 token 都会路由到 *Health, Medical & Wellness* 聚类中。而在标准 MoE 中，最主要的聚类是 *Possessives & Definite Articles*；模型会将该文章与任何碰巧使用了单词 *the* 或 *your* 的其他文本归为一类，而完全不管这些文本的实际内容是什么。 因为 EMO 形成的是映射到语义领域而非表面特征的模块，所以你可以挑选一个小的专家子集，依然得到一个可正常工作的模型——该组对应着一种真实的能力。 你可以在我们的交互式可视化平台 (https://emovisualization.netlify.app/) 中亲自探索这些聚类结果。 ### **本次发布内容** 我们发布了完整训练好的 EMO 模型 (https://huggingface.co/collections/allenai/emo)、在相同数据上训练的标准 MoE 对照基线模型，以及训练代码 (https://github.com/allenai/EMO)。我们希望这些资源对其他研究 MoE 涌现模块化的团队有所帮助。 仍有更多工作待完成。EMO 是使大型稀疏模型更具模块化的早期一步，但许多问题依然悬而未决：如何更好地选择和组合专家子集？如何在不破坏全模型的情况下更新模块？如何利用模块化结构实现更好的可解释性和可控性？发布这些模型应有助于社区深入研究这些问题，并朝着构建更易于部署、适配、检查与组合的模块化语言模型迈进。 ## 订阅以每月接收有关 Ai2 最新动态的更新。