FEPLB 阅读笔记：用 Copy Engine 几乎零成本地做 MoE 负载均衡

笔记日期： 2026-08-02 作者： Zhongzhu Zhou 阅读论文： FEPLB: Exploiting Copy Engines for Nearly Free MoE Load Balancing in Distributed Training 论文作者： Shuyao Qi, Haoyuan Liu, Shizhen Zhao（上海交通大学） arXiv： 2604.19654 发表状态： Preprint（cs.DC），2026 年 4 月

1. 为什么读这篇论文，它到底在解决什么问题

先看一个足以让任何训练大规模 Mixture-of-Experts（MoE）模型的人皱眉的数字：在 GLM-5 的 MoE 层上，128 个专家、不加辅助负载均衡损失的情况下，负载不均平均会白白浪费每个 MoE 层 18.6% 的 GPU 时间——而且不是训练开始时的一次性现象，也不是某种极端数据分布下才会出现的病态情况，而是持续性的、每一步训练都在发生的浪费。原因很简单：不同 token 路由到哪个专家是由学出来的路由器决定的，每个 micro-batch 里各专家收到的 token 数量都在随机波动，而同步训练要求每一步都等最慢的那块 GPU 干完活。

常见的几种应对方式各有各的问题。可以给路由器加一个辅助均衡损失，但这会限制路由器本可以学到的模式，并且会实际拖累模型质量——这正是为什么像 DeepSeek-V3 这样的前沿 MoE 模型近年来在逐渐放弃辅助损失。也可以干脆接受不均衡，白白浪费算力。或者——这是此前系统类工作的主战场——可以在运行时动态重新调度哪块 GPU 处理哪个专家的 token。问题在于（这篇论文用扎实、可复现的实验证明了这一点），几乎所有此前的动态调度方案都要为这份灵活性付出额外通信的代价，而这份额外通信恰恰要跟你训练策略里其他部分正在满负荷使用的同一份硬件资源（GPU 的流式多处理器 SM，以及节点间网络）抢资源。

FEPLB 的核心洞察一旦看懂就会觉得非常朴素——而且是那种事后看显而易见、但此前似乎没人真正为 MoE 负载均衡把它用起来的洞察：在 NVIDIA Hopper 架构的 GPU 上，有一块硬件——NVLink Copy Engine——可以在同一节点内的 GPU 之间搬运数据，完全不占用任何 SM 周期，而当前的 MoE 训练框架几乎从来没有用过它。 如果把动态负载均衡的流量走 Copy Engine，而不是走 Expert Parallelism（EP）和 Pipeline Parallelism（PP）已经在用的那条通信路径，你就得到了一个真正与硬件资源正交的新并行维度，它不会跟训练步骤里的任何其他环节争抢资源。这就是全部的核心想法。论文剩下的篇幅，是把这个想法变成一个能在不改动 EP 语义、不改动 Grouped GEMM 内核、且调度算法足够便宜到每个 micro-batch 都能跑一遍的实际系统。

如果你从事分布式 LLM 训练系统的工作——涉及 MoE 路由、EP/PP/TP 编排，或 GPU 通信调度——这篇论文提供了一个紧凑、实测充分的案例，背后是一条值得内化的更普适的原则：在设计更聪明的调度算法之前，先搞清楚瓶颈究竟是算法问题，还是资源争抢问题。 有时候答案不是”调度得更聪明”，而是”找到没人用的硬件，把它用起来”。

前置知识

如果你已经很熟悉 Mixture-of-Experts 路由、Expert Parallelism，以及 NVLink 与 Copy Engine 的区别，可以直接跳到第 2 节。否则，这里是理解本文所需的最小词汇表。

Mixture-of-Experts（MoE）层。 不是让每个 token 都过一个统一的稠密前馈网络（FFN），MoE 层维护许多更小的 FFN”专家”（GLM-5 用了 128 个），加上一个轻量级路由器，对每个 token 选出一小部分（top-$k$）专家来实际计算。这样总参数量可以扩展到万亿级别，而每个 token 的实际计算量（因而 FLOPs 成本）大致保持不变，因为每个 token 只会激活少数几个专家。代价是路由器的选择是学出来的、依赖数据的，没人能提前知道某个 micro-batch 里到底有多少 token 会落到某个专家身上。

Expert Parallelism（EP）。 由于单块 GPU 装不下动辄数千亿参数的专家权重，MoE 训练会把不相交的专家子集分散到不同 GPU 上——比如 EP = 8 时，8 块 GPU 各自持有 $128/8=16$ 个专家。路由器决定好每个 token 该去哪之后，一个 all-to-all dispatch 通信步骤会把每个 token 的激活值物理发送到它所选专家所在的 GPU，专家计算完，再通过 combine 步骤把结果发回来。这一对 dispatch/combine 就是本文特别小心、从不改动的”标准 EP 路径”。

Pipeline Parallelism（PP）。 模型的各层被切分成串行的多个 stage，分布在多块 GPU（或 GPU 组）上，micro-batch 像流水线一样依次流过。PP 和 EP 是正交的：EP 切分的是”同一层内部”（哪些专家放在哪里），PP 切分的是”跨层”（哪些层放在哪里）。

Grouped GEMM。 当一块 GPU 要跑 16 个不同的专家，而每个专家分到的 token 批量大小又各不相同（因为路由不均匀）时，你不能简单调用一次大矩阵乘法——需要一个 Grouped GEMM 内核，能高效地把许多大小不一的小矩阵乘法批量打包在一起执行。对本文至关重要的一点是：Grouped GEMM 的吞吐量对每个专家的 batch size 非常敏感——把一个专家的 token 批量拆成两半分给两块 GPU（比如为了转移一半 token 到另一块设备），会产生两个更小的矩阵乘法，在计算或访存受限区间的效率都会低于一个更大的矩阵乘法。正是这一条硬件事实，决定了 FEPLB 的重均衡算法（见后文）迁移的是整个专家，而不是拆分某个专家的 token 批量。

Straggler（长尾拖后腿设备）效应与同步训练。 在标准的同步数据并行或专家并行训练中，每台设备都必须完成当前步骤的工作，优化器才能更新（以保证所有副本数值一致）。这意味着每一步中最慢的设备（straggler）决定了所有其他设备的节奏。如果路由不均导致某块 GPU 这一步比平均多分到 30% 的 token，其他所有 GPU 都要空等它追上来。本文的两个核心评价指标”token straggler”和”GEMM straggler”，衡量的正是最慢设备相对于平均水平的超额负载。

NVLink 与 Copy Engine。 NVLink 是 NVIDIA 节点内 GPU 之间的高带宽互连（H100 NVLink 4.0 双向带宽 900 GB/s，而本文实验环境下节点间 RDMA/InfiniBand 的有效带宽大约只有 50 GB/s）。通常，当你想在两块 GPU 之间搬运数据时——比如通过一次 NCCL 集合通信或一个自定义 kernel——这次数据搬运是由运行在 GPU 流式多处理器（SM）上的 kernel 来编排的，SM 正是你跑矩阵乘法用的那批计算单元。Copy Engine 是 GPU 内部另一块独立的专用硬件，唯一职责就是通过 PCIe/NVLink 做异步内存拷贝；它走一条完全独立的硬件数据通路，不消耗 SM 周期，也不会干扰正在并发运行的 Grouped GEMM kernel。换句话说：你可以让 SM 满负荷跑专家计算，同时通过 Copy Engine 在 NVLink 上搬数据，两者互不拖累。本文整个系统贡献都建立在这一条硬件事实之上。

资源层面的正交性，作为一种设计原则。 论文明确提出了核心设计原则：EP 和 PP 都同时占用 RDMA/NVLink 带宽和 GPU SM 周期。如果要在不打扰 EP 和 PP 的前提下引入一个新的”负载均衡并行维度”，它就必须使用两者都不碰的资源。FEPLB 的答案：Copy Engine（用于数据搬运）加上空闲的 CPU 周期（用于调度决策）——这是当前 MoE 框架里完全没被用来做这件事的两类资源。

有了这些词汇，后面的内容会顺畅很多。

2. 架构总览：FEPLB 到底构建了什么

FEPLB 只引入了一种全新的机制——Two-Phase Dispatch（两阶段派发）——再加一个轻量的 CPU 端贪心调度器，每个 micro-batch 决定要重新均衡哪些专家、迁到哪里去。它不需要改动 EP 通信后端（比如 DeepEP），不需要改优化器，也不需要改模型架构。你原有的 EP/PP 配置原封不动保留，FEPLB 作为额外的一个并行维度叠加在上面。

图 1（原论文 Fig.3）：FEPLB 系统架构。训练循环（上半部分）在 checkpoint 时刻周期性地通过 Router Predictor 重新优化专家到设备的分配。每个 micro-batch 内部（下半部分），静态专家走未经修改的 EP dispatch/compute/combine 路径（绿色），一部分可配置数量的动态专家则通过 Two-Phase Dispatch 走 SM-free 的 NVLink 权重重分布（蓝色），由 CPU 端 Load Balancer（橙色）协调调度。

flowchart TD
    A["路由器给出本 micro-batch 的\ntoken-到-专家分配决策"] --> B["把每台设备本地的专家\n划分为静态（始终本地计算）\n与动态（可参与重分布），参数 dyn"]
    B --> C["静态专家：标准 EP dispatch\n发送到指定设备（RDMA/NVLink）"]
    B --> D["动态专家：把整个 EP 域内的\ntoken 收集到本地 NVLink 域内"]
    C --> E["GPU 在 SM 上计算静态专家\n（这是 Phase 2 可以隐藏在其中的时间窗口）"]
    D --> F["CPU 负载均衡器：贪心地\n把最忙设备匹配到最闲设备"]
    F --> G["NVLink Copy Engine 拷贝专家\n权重与已重排的 token，SM-free，\n节点内约 900 GB/s"]
    E --> H["GPU 计算重新均衡后的\n动态专家"]
    G --> H
    H --> I["Combine：结果通过标准\nEP 路径返回源设备"]

系统运行在两个不同的时间尺度上。在宏观层面，Router Predictor 会周期性地（在 checkpoint 时刻）根据积累下来的历史路由统计信息，重新优化专家到物理设备的分配，把迁移成本分摊到不那么频繁、代价低的事件上。在微观层面——每一个 micro-batch——Two-Phase Dispatch 都会做细粒度的、逐步的重均衡，纠正路由器这一步恰好产生的不均衡，而这恰恰是那种缓慢、低频的宏观重新分配根本追不上的部分（路由是数据依赖的、逐步波动的，不是按 epoch 变化的）。

3. 设计原则：正交动态并行的形式化表述

在讲机制之前，值得先停下来讨论一下论文的核心设计论证，因为这是最值得迁移到其他系统问题上的部分。

核心主张： 一个新的 MoE 负载均衡并行维度必须与 Expert Parallelism（EP）和 Pipeline Parallelism（PP）正交——意味着它不能扰动 (1) EP 的跨节点通信模式或流量，(2) PP 的跨 stage 调度节奏，并且 (3) 必须完全不消耗 GPU SM 周期，因为 SM 是训练步骤中最稀缺、争抢最激烈的资源。

为什么这很关键，具体体现在哪里。 论文详细分析了此前的动态调度系统是如何未能通过这一检验的：

• Tutel 在运行时在 Expert-Parallel 和 Data-Parallel 两种执行模式间切换，但切换需要根据模式不同地划分专家权重在各 GPU 上，也就意味着需要额外通信来重新分布这些权重划分。它没能满足正交性条件 (1)：扰动了 EP 的通信量。
• SmartMoE 从一份预先计算好的并行策略菜单里选择。这比单一静态策略更灵活，但菜单本身是在假设路由统计已知且稳定的前提下离线算出来的——面对 MoE 实际上逐 micro-batch 波动、依赖数据的路由分布，这个假设很脆弱。
• FasterMoE 在 EP 域内复制”热门”（过载）专家（“shadow expert”机制），并把 dispatch 通信和计算流水化，试图隐藏延迟。问题在于：流水化需要把一次批量传输拆分成多个分阶段的小传输，而像 DeepEP 这样的现代批量传输通信库正是针对一次性大规模传输做优化的——在 DeepEP 之上再拆阶段并不能免费地重叠起来，反而会增加额外的通信流量。论文自己重新实现的 FasterMoE（3.3 节，见下文）直接测量了这一点：流水化的 FasterMoE（pipe=2）相对不流水化的基线，多花了 46.8% 的 dispatch 时间和 40.2% 的 combine 时间。它严重违反了条件 (1)。
• Triton Distributed 把张量并行 MoE 计算和通信融合进自定义 Triton kernel 里。这很巧妙，但融合意味着SM 本身现在要同时做通信工作和计算工作——论文测得，随着更多 GPU 加入集合通信（融合进同一个 kernel 的通信工作也随之增加），前向传播时间比 EP 基线慢 1.6–3.3 倍。它彻底违反了条件 (3)：为了通信消耗了 SM 周期。

表 1（原论文 Table 1）用一行话概括了资源分离的论证：

并行维度	作用范围	通信	计算
EP	跨节点	RDMA / NVLink	GPU SM
PP	跨节点	RDMA / NVLink	GPU SM
FEPLB	节点内	NVLink Copy Engine	CPU

表中每一个已有的并行维度都共享同一组资源池：RDMA/NVLink 带宽和 GPU SM 周期。FEPLB 是唯一两者都不用的一行——它只在节点内起作用，通信走 Copy Engine（与 RDMA 物理上完全独立的一条数据通路），调度计算跑在 CPU 上，而不是 SM 上。这正是为什么 FEPLB 能够天然地与任意 EP/PP 配置共存，而无需重新配置两者中的任何一个——因为根本不存在需要争抢的共享资源。这是本文最重要的设计选择讨论，也值得当作一条通用的系统设计经验法则内化下来：在给一个已经资源饱和的系统增加新能力时，先看看有没有真正闲置未用的硬件资源可以用，而不是想办法在大家已经在争抢的资源上做更精巧的穿插调度。

显而易见的替代方案，以及它为什么行不通。 可以想象试图把 FEPLB 的重均衡通信塞进EP 已经在用的 RDMA/NVLink 路径里，用细粒度的时间片划分或优先级调度来避免争抢。论文没有直接测试这条路，但 FasterMoE 的流水化实验结果实际上就是一次天然实验，展示了会发生什么：任何与 EP 批量传输共享同一条物理通道、同一批由 SM 驱动的 kernel 的方案，都不可避免地会增加开销，因为像 DeepEP 这样的批量传输库是针对一次性大规模传输优化的，而非分阶段/穿插传输。FEPLB 自身方案的边界条件是：它依赖于存在一条真正独立、有足够能力的硬件数据通路（Copy Engine + NVLink，带宽充足）——这在 900 GB/s 节点内 NVLink 的 Hopper 级别 GPU 上是成立的，但在没有可比拟的、独立于 SM 的高速拷贝通路的老一代架构上，这条假设就不成立，或者用处会小得多。

4. 方法细节展开：Two-Phase Dispatch

图 3（原论文 Fig.2）：Two-Phase Dispatch。Phase 1（EP dispatch）把静态专家的 token 跨节点路由（约 50 GB/s），并把动态专家的 token 收集进 NVLink 域；Phase 2（NVLink Copy Engine 重分布）在节点内、SM-free 地拷贝动态专家的 token 与权重，速度约 900 GB/s，且不做任何跨节点均衡。

4.1 划分：静态专家 vs. 动态专家

每台设备本地的专家被划分为两类，由一个可调整的整数参数 $\text{dyn}$ 控制：

• 静态专家（数量 $= E_{\text{local}} - \text{dyn}$，其中 $E_{\text{local}} = 128/\text{EP}$）：始终在本地按未经修改的标准 EP dispatch/compute/combine 路径处理。它们除了计算模型输出之外还承担一个额外作用——它们的计算时间为 CPU 调度器和 Copy Engine 做重均衡工作提供了不会阻塞关键路径的时间窗口（详见 4.3 节）。
• 动态专家（数量 $= \text{dyn}$）：本 micro-batch 内，其权重（以及分配给它的 token）有资格通过 Copy Engine 从过载设备拷贝到欠载设备。

以 EP = 8、共 128 个路由专家为例，每台设备本地持有 $128/8=16$ 个专家。设置 $\text{dyn}=4$ 意味着这 16 个专家中有 4 个是动态的（可重均衡），12 个是静态的（无论负载如何都始终在本地处理）。这一个整数是论文的主要可调旋钮，第 6 节会详细考察它的敏感性。

4.2 Phase 1：EP dispatch（未修改）+ 动态 token 收集

Phase 1 完全按照任何未经修改的 MoE 训练流水线那样运行标准 EP dispatch：根据路由器给出的每个 token 的专家分配，把静态专家对应的 token 通过现有 EP 后端（比如 DeepEP）发送到指定设备，走正常的跨节点 RDMA/NVLink 路径——FEPLB 完全不碰这条路径。与此同时，去往动态专家的 token 会从整个 EP 域内收集到对应的本地 NVLink 域（即本地节点内），并在那里完成重排，为可能的节点内重分布做准备。Phase 1 完成后，NVLink 域内每台设备都清楚地知道自己动态专家当前的确切 token 数量——正是在这一刻，本步骤真实的不均衡才变得可见、可操作。

4.3 Phase 2：NVLink Copy Engine 重分布（SM-free 的部分）

这里才是 FEPLB 真正与”什么都不做”不同的地方。CPU 端负载均衡器检查刚刚观测到的动态专家 token 数量，运行一个贪心匹配算法（下面正式化为算法 1）：反复挑选最过载设备上最忙的动态专家，把该专家的权重——连同它已经重排好的 token——拷贝到最欠载的设备，并设定一个最小 token 阈值 $\tau$，避免为 token 数量太少的专家做无谓的拷贝（拷贝开销划不来）。关键在于，这次拷贝是作为 Copy Engine 在专用 CUDA stream 上发起的传输，意味着它不消耗任何 SM 周期，可以与 GPU 计算静态专家的过程完全并发（正是 4.1 节提到的”双重作用”时间窗口）。一旦静态专家计算和权重拷贝都完成，GPU 就用重新均衡后的负载计算动态专家，然后通过标准的（同样未修改的）EP 路径完成 Combine，把结果返回给这些 token 的源设备。

由于每个 token 依然是由完全同一个专家、完全同样的权重处理的——只是执行这次计算的物理设备换了——Two-Phase Dispatch 保留了精确的 MoE 语义。这不是一种近似,也不是路由规则的改变,而是对”已经决定好的计算发生在哪里”这件事做了负载感知的透明搬迁。

4.4 算法 1，逐步展开

论文的算法 1（下面重新标注、稍作展开）是完整的每训练步通信规则，包含前面叙述部分略过的一个细节：误差反馈（error feedback），对本地缩放因子做误差反馈，类似误差补偿量化方案的思路，用来纠正每台动态专家设备使用本地缩放因子而非全局同步缩放因子所带来的偏差（根据论文自己的消融实验，这样做比同步全局缩放因子的经验保真度更好，代价是需要周期性重新同步）。

算法 1：带 Two-Phase Dispatch 与误差反馈的
        选择性 FEPLB 通信
──────────────────────────────────────────────
输入：固定的选定动态专家集合 S（每台设备大小为 dyn）
输入：误差缓冲区 R^(l)，对 l ∈ S 初始化为零
输入：世界大小 N，量化器 Q(·;s)，缩放规则 Scale(·)

 1: 对每个训练步骤：
 2:     对每台设备 d：
 3:         对每个本地专家 l，其权重梯度批量为 W_g^(l)：
 4:             若 l 不属于 S（静态专家）：
 5:                 // 标准、未修改的 EP 路径
 6:                 通过 EP 后端把 W_g^(l) 发往指定设备
 7:                 在本地 SM 上计算专家 l
 8:                 通过 EP 后端 combine 结果
 9:             否则（l ∈ S，动态专家）：
10:                 U^(l)   <- 把专家 l 的 token 收集进 NVLink 域
11:                 load_d  <- token_count(U^(l))     // 本步实际观测值
12:                 // CPU 端贪心调度（与第 6-8 步的静态专家
                     // SM 计算并发进行）
13:                 若 load_d > 平均负载 + tau：       // 判定为过载
14:                     target <- argmin_d'( load_d' )  // 最欠载设备
15:                     发起 Copy Engine 传输：
                         weights(l) + 已重排 token(U^(l))  -->  target
                         （SM-free，专用 CUDA stream，节点内约 900 GB/s）
16:                 结束
17:                 等待（静态专家计算 AND 权重拷贝）都完成
18:                 在（可能已更换的）设备上计算专家 l
19:                 通过 EP 路径把结果 combine 回源设备
20:             结束
21:         结束
22:     结束
23:     // 宏观层面（低频）：Router Predictor 在 checkpoint 时刻
     //   根据历史路由统计更新专家到设备的分配
24: 结束

有两个实现细节值得特别强调，正是这两点让方案便宜到足以每个 micro-batch 都能跑一遍：

1. 只做整专家迁移，从不拆分 token 批量。 Grouped GEMM 的吞吐量对每个专家的 batch size 高度敏感（见”前置知识”一节）；把一个专家的 token 拆分给两台设备，会产生两个更小、效率更低的矩阵乘法。所以算法始终把一个专家的全部权重和它当前的全部 token 批量作为一个原子单元整体迁移——从不迁移其中一部分。
2. 无需协调即可保证确定性。 由于贪心算法是每台设备已知的观测 token 数量（Phase 1 之后所有设备都知道）的一个确定性函数，每台设备可以独立地推导出完全相同的权重拷贝方案，无需任何额外的协调往返。论文报告这次贪心遍历在单个 CPU 核心上大约耗时 50 微秒——相对于它需要隐藏在其中的静态专家计算窗口来说绰绰有余。

4.5 一个具体数字化的走局例子

为了让算法 1 的抄象描述落地，不妙以一个具体数字化的例子走一遍。假设 EP=8、每设备 16 个专家、$\text{dyn}=4$，本次 micro-batch 路由后发现 8 台设备中某一台（记为设备 3）的 4 个动态专家分别收到了 [820, 340, 190, 150] 个 token，总计 1,500 个；而另一台设备（设备 6）的 4 个动态专家只收到 [90, 70, 60, 40] 个 token，总计 260 个。全局平均每设备动态专家 token 总数假设为 700。

贪心调度器的执行过程如下：

1. 找最忙设备上最忙专家： 设备 3 总计 1,500 个 token，远高于平均值 700，是本步最过载的设备。它上最忙的动态专家是那个收到 820 个 token 的专家（记为专家 A）。
2. 找最闲设备： 设备 6 总计只有 260 个 token，远低于平均值，是最低载的设备。
3. 判定最小 token 阈值 $\tau$： 假设 $\tau = 100$。专家 A 的 820 个 token 远超过阈值，值得迁移。
4. 发起 Copy Engine 传输： 将专家 A 的权重（假设单专家 72 MiB，与 GLM-5 相同）连同已重排好的 820 个 token 一起从设备 3 拷贝到设备 6。按 900 GB/s 的 NVLink 带宽，72 MiB 的权重传输只需约 $72\text{MiB} / 900\text{GB/s} \approx 80\ \mu s$，远小于静态专家计算窗口（论文实测为毫秒级）。
5. 重新计算负载： 迁移后，设备 3 的动态专家总计从 1,500 降到 680（接近平均值），设备 6 的动态专家总计从 260 升到 1,080。一次迁移就把两者的差距从 1,240（1500-260）拉近到 400（1080-680），降幅达 68%。
6. 重复迭代（可选）： 若还有预算窗口，可以对剩余不均衡的专家对重复这个过程，但论文的实际实现中每步只做一轮贪心匹配，依靠多个连续的训练步逐步收敛到均衡状态，而不是在单步内迅速达到完美均衡。

这个例子直接说明了为什么整专家迁移在实践中行得通：只要不均衡集中在少数几个异常繁忙的专家身上（而不是均匀地分散在所有专家上），那么一次拷贝就能收回大部分不均衡，而拷贝本身的延迟（~80 μs 的数据传输加上约 50 μs 的调度决策）相对于静态专家的计算窗口（通常为毫秒级）而言微乎其微。

5. 数学展开：内存开销与 straggler 指标

5.1 内存开销推导

FEPLB 需要为拷贝进来的动态专家权重预留缓冲区空间。设 $W_{\text{expert}}$ 为单个专家的权重大小，$\text{max\_num\_dyn}$ 为一台设备可能同时需要持有拷贝副本的最大动态专家数量，缓冲区大小就是：

$$B_{\text{buffer}} = \text{max\_num\_dyn} \times W_{\text{expert}} \tag{1}$$

对 GLM-5 而言，每个专家占用 72 MiB。取 $\text{max\_num\_dyn}=8$：

$$B_{\text{buffer}} = 8 \times 72\ \text{MiB} = 576\ \text{MiB} \tag{2}$$

相对于 H100 的 80 GB HBM3 容量，占比为：

$$\frac{576\ \text{MiB}}{80 \times 1024\ \text{MiB}} \approx 0.70\% \tag{3}$$

背后的设计直觉： 这个缓冲区是在模型的所有 MoE 层之间复用的，而不是每层各分配一份——它是一块共享的临时区域，随着前向/反向传播过程中不同层的动态专家依次经过而被反复覆盖写入。这正是为什么这个开销能保持在不到 1% 的水平，与模型的 MoE 层数无关；如果是按层分配，一个足够深的模型（GLM-5 原版有 78 层，而本实验为了可行性用了 18 层的精简版）会把这份开销按层数成倍放大,“几乎免费”这个说法就站不住了。这是一个值得明确指出的设计选择——论文并没有着重强调它,但它对于”开销很小”这个结论能否推广到全深度的生产级模型至关重要。

5.2 Token straggler 与 GEMM straggler 的形式化定义

论文的两个评估指标精确定义为：

$$\text{TokenStraggler} = \max_{d} T_d - \bar{T} \tag{4}$$ $$\text{GEMMStraggler} = \max_{d} G_d - \bar{G} \tag{5}$$

其中 $T_d$ 是分配给设备 $d$ 的 token 数量，$\bar{T}$ 是所有设备 token 数量的均值，$G_d$ 是设备 $d$ 上 Grouped GEMM 的实际墙钟执行时间，$\bar{G}$ 是其均值。这两个量衡量的都是单台最慢设备相对于全组平均水平的超额负载——这正是决定同步训练中其他所有设备要空等多久的量，因为流水线（或 DP 组）无法越过最慢的参与者继续前进。

为什么两个指标都要报告，而不是只报一个？ Token straggler 衡量的是 Grouped GEMM 输入端的不均衡（最忙设备落了多少 token），而 GEMM straggler 衡量的是这一不均衡的实际后果——真正被浪费掉的墙钟计算时间。这两者未必完全同步变化：Grouped GEMM 的效率本身是 batch size 的非线性函数（batch 太小单 token 效率低，batch 太大则计算饱和），所以同样大小的 token 数量不均衡,转化成的 GEMM 时间不均衡可能更大或更小,取决于受影响的专家落在效率曲线的哪个区间。论文的表 3 和表 4 正是出于这个原因分别报告了两个指标——表 3（token straggler）显示 FEPLB 的优势随 EP 从 2 扩到 8，从 51% 增长到 70%；表 4（GEMM straggler）则显示了一个相似但数值上不同的趋势，从 50% 到 68%，证实了两个指标相关但并不等价。

5.3 推导 18.6% 浪费 GPU 时间这一核心数字

这个数字（来自图 1 的动机性测量,而非 FEPLB 自身的结果——它刻画的是基线问题）来自：

$$\text{WastedTimeRatio} = \frac{\max_d(\text{LayerTime}_d) - \overline{\text{LayerTime}}}{\max_d(\text{LayerTime}_d)} \tag{6}$$

在 GLM-5 的 MoE 层（128 专家，EP=8，无辅助损失）上跨 7,000 个训练迭代取平均。这与公式 4-5 是同一种 straggler-相对-均值的结构，但应用在每层总墙钟时间而不是具体的 token 数量或 GEMM 时间上，并表示成一个比例（相对于最大值,这样可以直接回答”这一层有多大比例的墙钟时间是在空等最慢设备”），而不是绝对差值。论文的图 1(b) 显示这个比例在各迭代之间噪声很大,大致在 10% 到 25% 之间波动,报告的平均值是 18.6%——这种波动性本身就是论文观点的一个证据：不均衡是路由的一种持续性统计特征，而不是可以用某个一次性修复方案解决的偶发异常。

6. 设计选择讨论：为什么这样做、显而易见的替代方案是什么、边界在哪里

设计选择 1：用 Copy Engine 而非基于 SM 的通信。 为什么有效： Copy Engine 是与 SM 物理上分离的硬件数据通路，所以用它做重均衡确实不会跟正在进行的计算产生任何争抢。显而易见的替代方案： 用一个轻量的 NCCL 点对点 send/recv 或自定义 CUDA kernel 来做节点内拷贝，这样更灵活（比如可以在拷贝过程中顺带融合一次反量化/重新量化步骤），但必然要消耗 SM 周期，直接破坏”正交并行维度”这个核心主张。边界在哪里： Copy Engine 方案受限于节点实际的 NVLink 拓扑结构。在标准的 8 卡 H100 节点上，全部 8 块 GPU 共享同一个全连接 NVLink 域，节点内任意对任意的拷贝都很直接。但在节点内 NVLink 连接只有部分互连的架构上（更老、更廉价的节点设计），某些设备对可能需要经过一块中间 GPU 中转,或退化到更慢的 PCIe 通路——论文没有讨论这种情况,这是整套方案一个隐含的边界条件。

设计选择 2：整专家迁移，而非 token 级拆分。 为什么有效： 保留了 Grouped GEMM 的效率，因为从不会产生更小、效率更低的子批量矩阵乘法。显而易见的替代方案： 把一个过载专家的 token 按比例拆分到两台或更多设备上，这样可以获得更细粒度的均衡控制（理论上可以把负载均衡到任意精度，而不是只能按整专家为单位）。论文自己承认的失效之处：“当前的局限性包括不支持 token 级拆分的整专家迁移，这在低 EP 度下限制了均衡的粒度。“这一点在 PP=4,EP=2 的结果中（3.2 节）有具体体现：EP 只有 2 时，每台设备持有 64 个专家，FEPLB 的反向传播时间（14.4 ms）比 FasterMoE（14.0 ms）略差一点，因为在这么低的 EP 度下，整专家迁移没法把不均衡细分得足够精细——相对于不均衡的程度，每台设备上独立的”块”（专家）数量本身就不够多。

设计选择 3：贪心的”最忙配最闲”匹配，而非最优分配求解器。 为什么有效： 简单、确定性（所有设备无需协调往返就能独立推导出同一份方案），并且快（约 50 微秒），足以每个 micro-batch 都跑一遍。显而易见的替代方案： 把重均衡建模成一个最优传输/最小费用流问题并精确求解，原则上在多台设备同时以复杂模式过载/欠载时，可能得到比贪心遍历更优的全局重分布方案。为什么没有采用： 精确求解器几乎肯定要花上比 50 微秒多几个数量级的时间，会突破它需要藏身其中的静态专家计算时间窗口——论文隐含的判断是：当”足够好、且几乎免费”这条硬件通路本身就没有额外边际成本时，“可证明最优”并不值得为此付出延迟代价。

设计选择 4：dyn 是设备级的静态参数，而非逐步自适应。 为什么有效： 保持了每台设备上（若 dyn=4、EP=8 则有 12 个以上）静态专家的快速路径完全不受影响、可预测；固定的 dyn 也让整套方案容易理解、可以离线调好一次。显而易见的替代方案： 根据每一步观测到的不均衡严重程度动态调整 dyn（不均衡更严重时用更多动态专家，较轻时用更少），有可能进一步压榨图 6 中显现出的收益递减尾部。边界在哪里： 论文自己的敏感性研究（见第 7 节）显示 dyn 超过 4 之后的边际收益相当有限（从 dyn=4 到 dyn=8 只提升 1-3 个百分点），说明自适应调节带来的复杂度可能并不划算——但这是一个针对 GLM-5 特定路由分布和实验工作负载的经验性结论，论文没有测试更极端的路由偏斜分布（比如来自不同训练方式的路由器,或训练早期路由尚未稳定的阶段）是否会改变这个权衡。

7. 实验走读

7.1 实验设置

硬件：NVIDIA H100 SXM5 GPU（80 GB HBM3），NVLink 4.0（节点内双向 900 GB/s），节点间 400 Gbps InfiniBand。软件：Megatron-LM MoE 框架，DeepEP 负责 dispatch，NVIDIA Transformer Engine 做混合精度，多流 cuBLAS 实现的 Grouped GEMM，FEPLB 在此基础上实现（所有基线共享完全相同的通信/计算内核，以保证公平对比）。模型：GLM-5 的精简层数版本（18 层，而非原版 78 层——论文说明由于 FEPLB 在每个 MoE 层内独立运作，减少层数用于实验可行性并不影响逐层评估的有效性），128 个路由专家，top-$k$ 路由，不加辅助均衡损失（即更困难、更贴近实际的不均衡状态）。测试了三种 PP/EP 配置：PP=4,EP=2（8 卡，每设备 64 专家）；PP=4,EP=4（16 卡，每设备 32 专家）；PP=2,EP=8（16 卡，每设备 16 专家）。

对比基线：(1) Before LB——纯 EP，不做任何重均衡；(2) FasterMoE，作者重新实现，用 SM-free 的 NVLink Copy Engine 传输 + DeepEP dispatch 以保证公平对比（同时测试了不流水化的 pipe=1 和流水化的 pipe=2 两个变体）；(3) Triton Distributed——张量并行 MoE 融合计算-通信；(4) Tutel——EP/DP 模式自适应切换；(5) FEPLB。

7.2 逐层执行时间（原论文表 2）

图 2（原论文 §3.2、表 2）：三种 PP/EP 配置下，Before-LB、FasterMoE、Triton Distributed、Tutel 与 FEPLB 各自的每 MoE 层前向/反向执行时间（ms）。Triton Distributed 在前向传播上比基线慢 1.6-3.3 倍，因为它融合计算-通信的 kernel 会消耗 SM 周期，且随着更多 GPU 加入集合通信，这一开销进一步恶化。Tutel 大致持平或略微改善前向时间，但因为权重划分带来的通信而在反向传播上多花 15-16% 的开销。FEPLB 始终追平或超过每一个基线：在 PP=2,EP=8 配置下，前向时间从 6.9 ms 降到 6.0 ms（-13%），反向从 12.5 ms 降到 10.6 ms（-15%）。在 PP=4,EP=2（第 6 节讨论过的低 EP 场景）下，FEPLB 前向时间与 FasterMoE 打平（都是 7.9 ms），但反向略差一点（14.4 ms vs. 14.0 ms）——这是整个评估中 FEPLB 唯一没有明显占优的地方，直接归因于低 EP 度下整专家迁移的粒度限制。

图 3（原论文 Fig.1）：(a) GLM-5 MoE 层（128 专家，EP=8，无辅助损失）在 7,000 个训练迭代中的逐 GPU token 分布，显示出全部 8 块 GPU 之间持续性的、随机的不均衡。(b) 浪费 GPU 时间分析：平均而言，负载不均每层浪费 18.6% 的 GPU 时间。

7.3 正交性验证：FEPLB 是否真的没有触碰 EP 通信？

图 4（原论文 Fig.4）：Before-LB、FasterMoE（pipe=1 与 pipe=2）与 FEPLB 各自的 EP 通信时间（Dispatch 与 Combine 阶段），在 EP=8 时测量。这张图是论文对自己第 3 节核心正交性主张的直接实测检验。pipe=1 的 FasterMoE 相对 Before-LB 几乎没有额外开销，与 FEPLB 表现一致。但 pipe=2——本意是通过重叠 dispatch 和计算来隐藏延迟的流水化变体——反而多花了 46.8% 的额外 dispatch 时间和 40.2% 的额外 combine 时间，恰好印证了第 3 节预言的失效模式：把一次 DeepEP 批量传输拆成流水线阶段，增加的是通信量，而不是把它隐藏起来。相比之下，FEPLB 在这项测试中测得 低于 1% 的开销，实证证实了 Phase 2 基于 Copy Engine 的重分布确实没有扰动它并行运行的标准 EP dispatch/combine 路径。

7.4 各配置下的负载均衡质量

图 5（原论文 Fig.5）：三种 PP/EP 配置下的 token straggler（上图）与 GEMM straggler（下图）柱状图，对比 Before-LB、FasterMoE 与 FEPLB（图例中标注为 DynamicMoE）。随着 EP 增加，FEPLB 和 FasterMoE 表现出相反的扩展趋势——这是论文里比较有意思的一个实证发现。在 EP=2 时（路由分布相对稳定，因为每设备 64 个专家意味着单个专家的 token 数量是在一个较大的”块”上取平均），FasterMoE 基于预测的调度在 token straggler 上实际上略微领先 FEPLB（55% vs. 51% 的降幅），不过 FEPLB 在 GEMM straggler 上已经领先（50% vs. 46%）。但随着 EP 增大到 4 再到 8（专家分布到更多设备上，粒度更细，逐设备路由更稀疏、更难预测），FasterMoE 的预测准确度明显下降——它的 token straggler 降幅随 EP 增大反而从 55% 掉到 39%。FEPLB 纯粹反应式的方法（Phase 1 之后观测实际 token 数量，而非提前预测）则朝相反方向改善，从 51% 提升到 70%。在 EP=8 时，FEPLB 的 token straggler 比 FasterMoE 低 2 倍（2,021 对 4,036 个超额 token），GEMM straggler 低 1.8 倍（0.352 ms 对 0.625 ms）。这里的设计层面的启示是：基于预测的调度会随着被预测对象变得更嘈杂而退化，而像 FEPLB 这样的反应式、事后观测方案对这种不可预测、依赖数据的路由波动天然更鲁棒——而这种波动正是整篇论文要解决的核心问题。

7.5 对动态专家数量（dyn）的敏感性

图 6（原论文 Fig.6）：三种 PP/EP 配置下，token straggler 随 $\text{dyn} \in \{2, 4, 8\}$ 变化的曲线。即使 $\text{dyn}=2$ 也能实现相当可观的 straggler 降幅，因为在实践中不均衡往往集中在少数几个异常繁忙的专家身上，而不是均匀分散在设备上全部 16-64 个专家中（这与论文中对 GIFT 一类相关工作类似的、按层易受量化误差影响程度做剖析的逻辑相呼应）。dyn 从 2 增加到 4 能再带来 1-3 个百分点的改善；从 4 到 8，又是 1-3 个百分点——明显是收益递减。论文最终选定 $\text{dyn}=4$ 作为”实用的默认值”，这对 GLM-5 具体剖析出的工作负载来说是合理的选择，不过正如第 6 节所指出的，这是一个经验性的调优结论，而非理论推导出来的最优值，对路由偏斜更极端的模型/数据集，这个权衡完全可能发生变化。

7.6 与相关系统的对比总览

在进入可复现性讨论之前，值得把本文提到的几个主要对比系统汇总到一张表中，方便快速形成对整个设计空间的全景理解：

系统	核心机制	是否改变 EP 通信量	是否占用 SM	预测 vs. 反应式	随 EP 度增大的趋势
Tutel	EP/DP 模式切换	是（权重重划分）	是	无	未详细评估
SmartMoE	预计算策略菜单	取决于选定策略	是	预测（离线）	未详细评估
FasterMoE (pipe=1)	热专家复制	否（无流水化时）	是	预测	多缴 EP=2 略优于 FEPLB
FasterMoE (pipe=2)	热专家复制 + 流水化	是（+46.8% dispatch）	是	预测	预测准确度随 稀疏路由退化
Triton Distributed	TP 融合计算-通信	是（融入同一 kernel）	是（融合）	无	前向时间慢 1.6-3.3×，GPU 越多越慢
FEPLB	Two-Phase Dispatch + Copy Engine	否（<1%）	否（CPU + Copy Engine）	反应式（观测实际 token 数）	EP=8 时领先 FasterMoE 2×

这张表最直接地回应了第 3 节的正交性讨论：只有 FEPLB 同时做到了“不改变 EP 通信量”和“不占用 SM”两个条件，其余方案至少违反其中一项。另一个值得注意的规律是预测式方案（FasterMoE、SmartMoE）在 EP 度较低、路由相对稳定时表现不错，但随着 EP 度提高、路由变得更稀疏且难以预测，它们的优势会逐渐消失；而 FEPLB 这种反应式方案则越到高 EP 度、路由越不可预测，相对优势反而越明显。

论文对自己的实验配置交代得相当具体，使得部分复现变得可行：Megatron-LM + DeepEP + NVIDIA Transformer Engine + 多流 cuBLAS Grouped GEMM，跑在配备 NVLink 4.0 和 400 Gbps InfiniBand 的 H100 SXM5 节点上。用精简到 18 层的 GLM-5 版本（而非完整的 78 层模型）是一个明确说明、合理的简化，为了实验可行性，同时保留了逐层评估的有效性，这对任何想在没有完整生产级基础设施的情况下复现核心机制的人来说都是合理的做法。但没有完全交代清楚的：精简版本使用的具体 GLM-5 隐藏维度和路由超参数（论文图 4 的图注提到 hidden=6144、4096 tokens/GPU、topk=8，这些信息有帮助但比较分散,而不是集中在一个专门的可复现性章节里），以及生成图 3 剖析结果所用的具体数据集/路由统计特征也没有公开。从零复现大致需要：(1) 一个专家数量相当、且不加辅助损失的 Megatron-LM MoE checkpoint（以复现”困难”的不均衡状态）；(2) 一条自定义的、通过 CUDA stream 发起的 Copy Engine 传输路径,因为标准的 PyTorch/NCCL 抽象并不直接暴露 Copy Engine 调度接口——这大概是任何想仅凭论文重新实现这套系统的人需要付出的最大工程量；(3) 贪心调度逻辑（算法 1），足够简单，可以直接根据伪代码重新实现。

8.5 为什么 token straggler 降幅与 GEMM straggler 降幅不完全一致：一个数值例子

第 5.2 节指出，两个 straggler 指标相关但不等价，这里用一个具体数字让这个论点变得直观。假设重均衡前，设备 A 比平均多 3,000 个 token，而这 3,000 个 token 均匀分布在 30 个中等大小的专家上（每个专家多 100 个 token），这种情况下 Grouped GEMM 效率曲线比较平缓，额外 100 个 token 带来的额外计算时间基本与 token 数成比例。但如果同样的 3,000 个额外 token 全部集中在另一台设备的 1 个专家上（这个专家本来只有 200 个 token，现在变成 3,200 个），那么这个专家的 Grouped GEMM 批量就从一个小批量变成了一个大批量，而大批量矩阵乘法在现代 GPU 上往往能更高效地饱和计算单元，单 token 处理时间反而会下降。两种情况下 token straggler 数值完全相同（都是 3,000），但 GEMM straggler 却可能相差几倍。这就是为什么表 3（token straggler）与表 4（GEMM straggler）的降幅百分比在每个配置下都不完全相同——例如 PP=4,EP=4 下 token straggler 降 63%、GEMM straggler 降 62%，数值接近但不相等，正是因为专家内部的 token 分布形状（集中在少数专家 vs. 分散在多个专家）会影响 Grouped GEMM 效率曲线上的实际位置。

9. 局限性的诚实评估

论文自己陈述的局限性范围很窄、很具体：“当前的局限性包括不支持 token 级拆分的整专家迁移，这在低 EP 度下限制了均衡的粒度。“这个说法诚实但不完整——第 10 节会讨论还有哪些地方被低估了。

评估范围本身也有一些论文没有着重讨论的局限：单一模型系列（GLM-5）、单一硬件世代（H100/NVLink 4.0），以及一个精简到 18 层的版本，而非完整的 78 层生产模型。论文合理地论证了逐层评估的有效性得以保留，因为 FEPLB 在每个 MoE 层内独立运作，但这个论证隐含地假设宏观层面的 Router Predictor 组件（在 checkpoint 时刻对整个模型运作）也以相同方式扩展——这一点在全深度模型上并没有得到实证验证。

10. 批判性分析

(a) 本文特有的弱点与缺陷。 首先，评估报告的是平均化的指标（在未明确说明的评估窗口内取平均的 straggler 降幅），而图 4-6 中的误差棒明显偏大——尤其是 PP=2,EP=8 配置下 token straggler 的置信区间大约横跨 3,000-10,000 个 token，占报告出的平均改善本身相当大的比例。论文没有为其核心的百分比降幅结论报告统计显著性检验（例如跨迭代的配对检验），而这类检验本可以增强我们对”FEPLB 相对 FasterMoE 的优势不是某个特定评估窗口的偶然产物”这一结论的信心。其次，引言中 18.6% “浪费 GPU 时间”这个核心数字（来自图 1）是在没有应用 FEPLB 的情况下测得的——它刻画的是基线问题，而非 FEPLB 的解决效果——但论文从未报告应用 FEPLB 之后的类似端到端浪费时间比例指标，只报告了范围更窄的 token/GEMM straggler 指标。读者只能靠推断,而不是直接看到,FEPLB 到底在墙钟时间意义上追回了开头那个 18.6% 里的多大一部分；把 51-70% 的 straggler 降幅换算成实际的单步时间加速，需要知道 MoE 层的不均衡到底占总步骤时间的多大比例,而论文并没有把这一点和开篇的统计数字联系起来。

(b) 作者低估或省略的局限性。 论文把 Copy Engine 方案描述为在”NVIDIA Hopper 架构上”广泛适用，但这个收益明确受限于 NVLink 拓扑结构——论文自己也提到”这一适用范围受限于当前的 NVLink 拓扑，而非设计本身”，并提到 GB200 NVL72 全互连的 72 卡 NVLink 域可以解除这个限制，但没有在这种硬件上做实测。考虑到目前生产环境中的大部分 MoE 训练都跑在（本文所测试的）8 卡 NVLink 域上，“Phase 2 未来有可能在无需跨节点通信的情况下重均衡整个 EP 组”这一说法是推测性的,而非实测出来的。其次，论文没有讨论当负载不均衡本身在单次训练过程中迅速变化时会发生什么——比如训练早期路由器尚未稳定时，路由分布可能比用于确定 $\text{dyn}=4$ 和最小 token 阈值 $\tau$ 的剖析窗口要偏斜得多（或以不同方式偏斜）；论文隐含地假设了整个训练过程中不均衡分布大致平稳，这在训练初期的”路由器预热”阶段是值得质疑的。第三，内存开销结论（5.1 节”温和，不到 1%“）依赖于”缓冲区跨层复用”这一实现细节，而论文并没有很显著地突出这一设计选择——如果某些 MoE 框架默认按层朴素分配（而非复用），这份开销会随 MoE 层数成倍放大，而论文没有讨论 Megatron-LM 需要做出怎样的内存管理 API 变更，才能保证这种复用在任意层数和流水线 stage 数下都能正确发生。

(c) 具体、可操作的改进建议。 第一，报告应用 FEPLB 之后类似 18.6% 那样的浪费时间比例指标,并直接与图 1 的基线数字并列展示，让读者能够直接看到实际的墙钟时间恢复量，而不是只能从 straggler 数量的降幅中推断。第二，在 GB200 NVL72 上（或者如果拿不到这类硬件，至少做一次受控仿真）运行并报告一次消融实验，以证实”全互连 NVLink 拓扑能让 Phase 2 重均衡整个 EP 组”这一说法——就目前所写的内容而言，这是论文最具前瞻性、也是实证支持最薄弱的一个论断。第三，测试 FEPLB 对真正非平稳的不均衡分布的敏感性——比如从随机初始化的路由器开始，剖析并评估训练最初几千步的表现，而不是只在一个已经预热好的模型的路由统计上做评估——以刻画本文选定的固定 $\text{dyn}$ 和 $\tau$ 超参数,是否能推广到不均衡很可能最严重、重均衡最有价值的训练早期阶段。第四，为核心的 straggler 降幅百分比提供统计显著性区间（而不仅仅是描述性的误差棒），最好采用针对每个基线在同一组训练迭代上做配对比较的方法，以排除相对 FasterMoE 的部分优势差距只是评估窗口方差、而非稳健的系统级优势这种可能性。

10.5 核心数据一览表

为了方便快速查阅，把本文涉及的关键实验数字汇总如下，供后续引用或自行对照：

指标	Before LB	FasterMoE	FEPLB	说明
Token straggler（PP=4,EP=2）	2,278	1,014 (−55%)	1,107 (−51%)	低 EP 度下 FasterMoE 预测略占上风
Token straggler（PP=4,EP=4）	4,649	2,471 (−47%)	1,697 (−63%)	FEPLB 开始领先
Token straggler（PP=2,EP=8）	6,666	4,036 (−39%)	2,021 (−70%)	FEPLB 领先 2×
GEMM straggler（PP=4,EP=2）	0.316 ms	0.170 ms (−46%)	0.157 ms (−50%)	FEPLB 已经略优
GEMM straggler（PP=4,EP=4）	0.652 ms	0.380 ms (−42%)	0.247 ms (−62%)	差距拉大
GEMM straggler（PP=2,EP=8）	1.110 ms	0.625 ms (−44%)	0.352 ms (−68%)	FEPLB 领先 1.8×
EP 通信开销（dispatch）	—	pipe=2 多 +46.8%	<1%	正交性验证关键数据
内存开销（576 MiB 缓冲区）	—	—	≈50.70% of 80GB	跨层复用，不随层数线性增长

需要提醒的是，表中每一行都是跨多个训练迭代取平均得到的统计量，误差范围在原论文图表中相当宽（见第 10 节批判分析 (a)），使用时应把这些百分比当作趋势性证据，而非逐位精确的保证。

11. 结语

FEPLB 是一个干净利落的例子，说明系统论文的核心贡献未必是一个新算法，而可以是一种新的资源：它注意到 Hopper GPU 上的 NVLink Copy Engine 在 MoE 训练过程中几乎完全闲置，而如果把动态负载重均衡的流量走这条通路，而不是走 Expert Parallelism 和 Pipeline Parallelism 已经在用的那条基于 RDMA/SM 的路径，就能得到一个真正正交的负载均衡并行维度——依构造而言，它不会跟训练步骤中发生的任何其他事情争抢资源。建立在这一观察之上的机制（Two-Phase Dispatch、一个简单的贪心调度器、为保留 Grouped GEMM 效率而做的整专家迁移）并不炫目，但很有效：在 GLM-5 不加辅助均衡损失的 MoE 层上，实现了 51-70% 的 token straggler 降幅和 50-68% 的 GEMM straggler 降幅，而实测 EP 通信开销不到 1%。这篇论文对系统研究者最具迁移价值的一课，远远超出了 MoE 本身的范畴：在为一个资源争抢问题设计更聪明的调度算法之前，先看看附近有没有闲置未用的硬件,能不能免费把问题解决掉。