Director: 通过在线主动专家放置加速分布式MoE服务

# Director: 通过在线主动专家放置加速分布式MoE服务

来源: https://arxiv.org/html/2607.08782
Qianli Liu¹, Kaibin Guo², Zicong Hong¹, Peng Li³, Fahao Chen⁴, Haodong Wang¹, Jian Lin¹, and Song Guo¹本研究得到香港研究资助局一般研究基金 (152169/22E, 152228/23E, 162161/24E, 162116/25E)、研究影响基金 (编号 R5060-19, R5011-23)、合作研究基金 (编号 C1042-23GF)、国家自然科学基金/香港研究资助局合作研究计划 (批准号 62461160332 & CRS_HKUST602/24)、卓越领域计划 (AoE/E-601/22-R)、国家自然科学基金 (编号 62471383) 以及 InnoHK (HKGAI) 的资助。通讯作者：Zicong Hong, Song Guo。

###### 摘要

专家并行已成为服务混合专家（MoE）模型的主流范式。其效率取决于 GPU 的通信延迟和计算延迟，而这两者又与专家在 GPU 上的放置方式相关。现有优化专家放置的工作侧重于利用过去请求的专家激活模式。然而，在面临多样且快速变化的请求模式时，这些方法存在缺陷，迫切需要一种在线、主动的方法。实现这种方法需要应对几个挑战：传入请求的专家激活不确定性、专家迁移的成本以及优化问题的 NP-hard 复杂性。因此，我们提出了 Director，一种新的分布式 MoE 服务系统，通过预测驱动的在线专家放置来最小化端到端延迟。Director 使用轻量级级联预测器或低比特量化副本来预测传入请求的专家激活模式。然后，一个在线迁移模块通过在计算密集型阶段执行迁移，实现近乎零停机的变化，将中断限制在可控范围内。其核心是一个基于松弛的专家放置优化器，在容量约束下运行，多项式时间复杂度，并达到 \(1+\epsilon\) 的近似比。最后，我们实现了一个原型，并通过大量实验证明，与现有工作相比，在流行的 MoE 模型（如 Mistral、DeepSeek 和 Qwen）上，端到端延迟降低了 11%～55%。

## I 引言

混合专家（MoE）模型[1 (https://arxiv.org/html/2607.08782#bib.bib1),2 (https://arxiv.org/html/2607.08782#bib.bib2),3 (https://arxiv.org/html/2607.08782#bib.bib3),4 (https://arxiv.org/html/2607.08782#bib.bib4),5 (https://arxiv.org/html/2607.08782#bib.bib5),6 (https://arxiv.org/html/2607.08782#bib.bib6),7 (https://arxiv.org/html/2607.08782#bib.bib7)] 已成为将大型语言模型（LLM）扩展到万亿参数规模同时保持计算成本比例化的流行架构。与使用所有参数的稠密模型不同，MoE 模型动态地将输入令牌路由到前馈网络（FFN）的一个子集，这些子集被称为*专家*。这种选择性激活使得所需的 FLOPs 随模型规模增加而亚线性扩展[8 (https://arxiv.org/html/2607.08782#bib.bib8),9 (https://arxiv.org/html/2607.08782#bib.bib9),10 (https://arxiv.org/html/2607.08782#bib.bib10)]。

MoE 模型参数数量的持续增长，由于巨大的内存占用，需要采用专家并行来进行分布式 MoE 服务[11 (https://arxiv.org/html/2607.08782#bib.bib11)]。在这种范式中，专家分布在一组 GPU 上，而非专家参数（如自注意力块）则复制到每个 GPU。通过每个 MoE 层的前向传播需要两步 all-to-all 通信：一步将令牌分派到其选定的专家，另一步聚合结果。这种范式有效利用了 MoE 的稀疏条件计算，使其成为服务大规模 MoE 模型的广泛采用标准。

尽管专家并行具有优势，但仍存在两个性能瓶颈：频繁 all-to-all 通信的高延迟以及 GPU 间计算负载的不均衡。通信瓶颈的产生是因为每个令牌的隐藏状态在每层 MoE 的 all-to-all 操作中必须被分派到所选专家。这些专家通常分散在不同 GPU 上，且隐藏状态规模较大。此外，负载不均衡是由于推理工作负载与模型训练数据之间的分布偏移所致。这种非均匀选择会导致掉队者（stragglers）。托管这些被过度选择的专家的 GPU 决定了整体延迟，因为聚合必须等到最后一个专家完成计算。

参见图 1 说明：离线专家放置、在线反应式专家放置和在线主动式专家放置的比较。为了加速分布式 MoE 服务，如图 1 (https://arxiv.org/html/2607.08782#S1.F1) 所示，近期工作可分为两种策略：*离线专家放置* 和 *在线反应式专家放置*。离线工作在开始服务之前计算静态的专家放置。通过分析历史路由模式和层间专家亲和度，它们将频繁共同激活的专家共置以最小化通信，并复制频繁专家以平衡负载[11 (https://arxiv.org/html/2607.08782#bib.bib11),12 (https://arxiv.org/html/2607.08782#bib.bib12),13 (https://arxiv.org/html/2607.08782#bib.bib13)]。然而，这些工作依赖于预分析的数据，当推理工作负载出现数据分布偏移时，其静态放置变得次优，导致性能下降。相比之下，在线工作能够适应工作负载。它们通过复制过载专家[14 (https://arxiv.org/html/2607.08782#bib.bib14),15 (https://arxiv.org/html/2607.08782#bib.bib15),16 (https://arxiv.org/html/2607.08782#bib.bib16)] 或选择移动专家还是请求[17 (https://arxiv.org/html/2607.08782#bib.bib17),18 (https://arxiv.org/html/2607.08782#bib.bib18)] 来响应动态工作负载。然而，它们通常采用在线反应式设计，针对最近一批请求进行优化，因此决策滞后于工作负载；在快速变化的输入下，这种滞后会导致持续的不匹配和较差的性能（见第 III 节）。

因此，我们提出了一种新的范式：用于分布式 MoE 服务的 *在线主动专家放置*。该方法将分析队列中的请求，并在处理它们之前优化 GPU 上的专家放置。这种预期的放置会将可能被共同激活的专家共置于同一个 GPU 上，以便处理即将到来的请求，从而减少昂贵的 GPU 间通信需求。此外，它确保计算工作负载均匀分布在所有 GPU 上，从而维持系统级负载均衡，防止因过载的 GPU 导致瓶颈。

然而，实现这一范式面临三个关键挑战：1）**路由路径不确定性**。在 MoE 中，第 \(l\) 层的门控是在第 \(l-1\) 层所选专家产生的表示上计算的，路由是数据相关的，并且在层间顺序耦合。因此，令牌的逐层路由无法事先确定；只有在正向传播过程中才会揭示，必须通过预测来估计。2）**自适应性成本**。运行时迁移专家会直接与计算竞争：当专家参数正在传输时，该专家无法进行计算，且数据传输本身会引入通信开销。因此，一个有效的系统必须在迁移和计算之间取得平衡，调度传输以限制停机时间，并确保任何重新配置都能带来性能增益。3）**专家放置的复杂性**。最优专家放置的搜索空间巨大，依赖暴力搜索或精确求解器来找到最优放置对于实时决策是不可行的。例如，DeepSeekMoE 16B 包含 27 个 MoE 层，每层有 64 个专家。当部署在 4 个 GPU 上进行专家并行时，在每一层，将 16 个专家分配给第一个 GPU 的方式数量为组合数 \(C_{16}^{64}\)。考虑到模型有 27 个可以独立配置的层，放置搜索空间的总大小接近 \((C_{16}^{64})^{27}\)。形式上，寻找最优放置的任务是一个 NP-hard 问题[19 (https://arxiv.org/html/2607.08782#bib.bib19)]。

为了应对这些挑战，本文提出了 Director，一个执行预测驱动、在线专家放置重新配置的分布式 MoE 服务系统。Director 使用级联预测器或量化 MoE 副本来准确预测路由，从而支持主动更新专家放置。然后，一个计算重叠的迁移模块通过在计算密集型阶段仅执行传输来实现近乎零停机的变更，将中断限制在可控范围内。我们总结贡献如下：

- • 我们设计了一种在线机制，将路由预测与执行相结合，并执行计算重叠的实时迁移，实现近乎零停机，使系统能够预测路由并调整放置，且影响可控。
- • 我们开发了一个多项式时间调度算法，能够找到具有可证明性能界限的专家放置。该算法有效平衡通信成本和 GPU 负载，以降低整体延迟。
- • 我们实现并评估了 Director 的原型。通过在多样化工作负载和硬件配置上的广泛实验，我们证明了与现有 MoE 服务系统相比，端到端延迟显著降低了 11%～55%。

## II 背景及相关工作

### II-A 混合专家

MoE 架构用 MoE 层替换了 Transformer 中的标准 FFN[20 (https://arxiv.org/html/2607.08782#bib.bib20)]。每个 MoE 层由一组称为*专家*的 FFN 子网络和一个可学习的*门控网络*组成，该门控网络将输入令牌路由到这些专家。对于每个传入令牌，门控网络计算相关性分数，并选择一小部分专家进行处理，通常是 top-k 路由。选定专家处理完令牌后，这些专家的输出被聚合，通常基于门控网络分配的分数进行加权求和。这种稀疏激活增加了模型的总参数数量，而不会成比例地增加单次前向传播的计算需求。

### II-B 专家并行

在专家并行中，专家被分布到不同的 GPU 上，而自注意力块、层归一化和门控网络等参数则复制到每个 GPU[11 (https://arxiv.org/html/2607.08782#bib.bib11),8 (https://arxiv.org/html/2607.08782#bib.bib8)]。在前向传播过程中，每个 GPU 首先将复制的组件应用于其本地令牌。然后，门控为每个令牌选择专家，之后令牌被打包并通过 all-to-all 通信发送到托管其目标专家的 GPU。一旦专家计算完成，第二次 all-to-all 通信将令牌输出返回给原始 GPU。这使模型能够进入下一层。

### II-C 专家并行优化

为了提升分布式 MoE 训练和推理的效率，人们引入了各种优化方法。

#### 模型架构与路由规则

一些工作修改模型结构以增加令牌在本地处理的可能性。例如，专家剪枝减少了专家数量，从而减少了 GPU 间通信[21 (https://arxiv.org/html/2607.08782#bib.bib21),22 (https://arxiv.org/html/2607.08782#bib.bib22)]。其他工作优化了前向传播中的门控选择。DeepSeek[6 (https://arxiv.org/html/2607.08782#bib.bib6),7 (https://arxiv.org/html/2607.08782#bib.bib7)]、FasterMoE[14 (https://arxiv.org/html/2607.08782#bib.bib14)] 和 TA-MoE[23 (https://arxiv.org/html/2607.08782#bib.bib23)] 强制执行约束，限制可以从其他 GPU 选择的专家数量。由于我们的工作专注于在系统层面优化专家放置，这些算法层面的优化是正交的。

#### 通信-计算流水线

一些工作认识到标准执行会导致顺序瓶颈，即 GPU 密集型计算被迫等待网络密集型数据传输。为了消除这种依赖，输入张量被分割成更小的块。这创建了一个流水线工作流，允许对一个块的计算与另一个块的 all-to-all 通信并发进行[24 (https://arxiv.org/html/2607.08782#bib.bib24),25 (https://arxiv.org/html/2607.08782#bib.bib25),16 (https://arxiv.org/html/2607.08782#bib.bib16),26 (https://arxiv.org/html/2607.08782#bib.bib26),27 (https://arxiv.org/html/2607.08782#bib.bib27),28 (https://arxiv.org/html/2607.08782#bib.bib28)]。它们使用均匀、随机的专家放置策略来优化流水线，这与我们的工作是互补的。

#### 专家放置

最后一类优化是优化 GPU 上专家的放置。这可以分为两类：离线确定最优放置或在运行时自适应。前者利用离线预分析来计算固定的专家布局[13 (https://arxiv.org/html/2607.08782#bib.bib13),29 (https://arxiv.org/html/2607.08782#bib.bib29)]。通过分析历史路由数据或跨层专家亲和度，它们创建了一个全局优化但静态的放置。后者通过将热门专家移动或复制到未充分利用的 GPU 上，以响应对观察到的流量[17 (https://arxiv.org/html/2607.08782#bib.bib17),14 (https://arxiv.org/html/2607.08782#bib.bib14),15 (https://arxiv.org/html/2607.08782#bib.bib15)]。另一项工作将专家中心方法（移动数据）与数据中心替代方案（移动专家）结合起来[18 (https://arxiv.org/html/2607.08782#bib.bib18)]。一个更新的范式动态地重新排列设备间的序列放置[30 (https://arxiv.org/html/2607.08782#bib.bib30),31 (https://arxiv.org/html/2607.08782#bib.bib31)]。然而，所有这些在线工作都是反应式的，基于过去的模式优化放置。这种固有的滞后将导致动态工作负载下的性能次优，这为我们的主动设计留下了一个关键缺口，即能够预测并适应传入的需求。

## III 动机

本节分析专家并行的特性，指出现有专家放置方法的瓶颈，揭示优化的机会。

参见图 2 说明：DeepSeekMoE 16B 单个层（以第 20 层为例）中专家选择频率，批次大小为 32。###### 发现 1. MoE 模型中专家激活模式在处理不同请求批次时随时间表现出显著的动态性。

离线和在线反应式方法都假设在服务过程中专家激活模式相对稳定[17 (https://arxiv.org/html/2607.08782#bib.bib17),29 (https://arxiv.org/html/2607.08782#bib.bib29),13 (https://arxiv.org/html/2607.08782#bib.bib13),14 (https://arxiv.org/html/2607.08782#bib.bib14),15 (https://arxiv.org/html/2607.08782#bib.bib15),32 (https://arxiv.org/html/2607.08782#bib.bib32)]。然而，在现实的多用户服务环境中，这一假设可能不成立。为了证明这一点，我们随机从文本生成[33 (