UltraEP: Unleash MoE Training and Inference on Rack-Scale Nodes with Near-Optimal Load Balancing

发表时间: 2026-06 · arXiv:2606.04101

文章标题：UltraEP: 在机架规模节点上通过近乎最优的负载均衡释放MoE训练和推理的潜力
作者/机构：Xinming Wei, Chao Jin, Tuo Dai, Yinmin Zhong, Shan Yu, Chengxu Yang, Bingyang Wu, Zili Zhang, Jing Mai, Qianchao Zhu, Zhouyang Li, Yuliang Liu, Guojie Luo (北京大学计算机学院, RedNote, 上海人工智能实验室, 独立研究员)

A1 主要贡献

大规模专家并行（Expert Parallelism, EP）已成为训练和服务前沿混合专家（MoE）模型的关键，但它也加剧了设备级的专家负载不均衡，导致计算掉队、令牌（token）all-to-all通信瓶颈和激活值内存尖峰。现有均衡器基于历史负载周期性地重新分配专家，但这对于负载模式非平稳的生产部署环境而言并不可靠。

本文介绍了UltraEP，这是首个用于机架规模节点（Rack-Scale Nodes, RSNs）上大规模EP的MoE训练和服务的精确负载、实时均衡器。与先前基于历史预测的解决方案不同，UltraEP在每次门控（gating）之后，根据精确的实时负载信息，在每个微批次（microbatch）和每个层级上进行重新平衡。


图1. UltraEP在负载保真度、决策时机和平衡频率方面与先前解决方案的不同之处。

这一实时平衡策略之所以可行，得益于机架规模节点（RSNs）的出现。RSNs通过将高带宽的扩展（scale-up）链路扩展到整个机架的数十个GPU，使得整个EP组可以保持在单个高带宽域内，从而使关键路径上的平衡在物理上成为可能。然而，仅有RSNs是不够的，还需要解决控制平面和数据平面的挑战。


图2. 与标准RDMA集群相比，机架规模节点内扩展的scale-up域示意图。

为应对这些挑战，UltraEP引入了两项关键创新：
1. 控制平面：配额驱动的规划器 (Quota-driven planner)。该规划器联合优化专家复制和令牌重路由，直接求解每个专家实例最终应承载的令牌负载配额。它通过高效的基于阈值的二分搜索来直接优化重路由后的负载，避免了传统方法中规划与路由分离导致的次优解。
2. 数据平面：RSN原生的通信机制。针对实时复制产生的动态、不规则的专家状态传输，UltraEP设计了专门的通信方案。它通过设备端的持久化瓦片流 (persistent tile streaming) 来饱和带宽，并通过基于中继的块流 (chunk-streaming relay) 树来缓解热门专家的扇出（fan-out）瓶颈。

UltraEP被设计为生产部署友好型系统，与常见的张量、流水线和数据并行兼容，并作为一个独立的运行时库，可以无缝集成到现有的训练和推理框架中。

本文的主要贡献如下：
* 我们对大规模MoE训练和推理预填充（prefill）中的非平稳专家负载不均衡进行了定性分析（§ 3）。
* 我们设计了UltraEP，这是首个在RSNs上为大规模EP MoE部署设计的实时、精确负载均衡器（§ 4）。
* 我们构建了用于关键路径平衡的配额驱动规划（§ 5）和RSN原生的专家状态通信机制（§ 6）。
* 我们验证了UltraEP近乎最优的平衡质量、接近理想的吞吐量和生产级别的可扩展性（§ 8）。

A3 背景知识与关键观察

2. 背景知识

机架规模节点 (Rack-Scale Node, RSN)

如上文图2所示，一个机架规模节点（RSN）将扩展（scale-up）域从单个4/8-GPU服务器扩展到整个机架，通常涵盖64个以上的GPU【2, 39, 42, 73】。一个RSN仍由多个服务器组成，但跨服务器的GPU通过机架范围的扩展（scale-up）网络结构【29, 40, 58】直接连接。与扩展（scale-out）网络相比，scale-up提供更高的单GPU带宽（数百GB/s至~TB/s）和类加载/存储的内存语义，而scale-out使用网络消息传递，每个NIC通常只提供几十GB/s的带宽。对于MoE模型，一个EP组通常可以容纳在一个RSN内，使专家分派保持在快速的scale-up网络上，而不是较慢的scale-out网络上。


图3. 专家并行（EP）下的MoE前向传播示意：4个专家，EP=2，top-k=2。

分布式MoE训练与推理

  • MoE架构演进。早期的MoE模型（如GShard【26】，Mixtral【21】，Switch Transformer【15】）采用粗粒度设计，专家数量少但体积大。目前，前沿MoE模型（如Google的Gemini 3 Pro【7】，GLaM【14】，OpenAI的GPT-OSS【43】，DeepSeek的DeepSeekMoE【6】和DeepSeek-V3/R1【8, 11】，Qwen MoE系列【62, 63】，Meta的Llama-4【34】）已演变为细粒度设计，使用数百个更小、计算更轻量的专家。这一趋势提升了专家的特化能力和扩展灵活性，但也使得路由分布和专家负载均衡更具动态性。
  • LLM推理。LLM推理包括预填充（prefill）和解码（decode）两个阶段。Prefill是计算密集型的，并行处理提示并填充KV缓存。Decode是内存密集型的，因为每一步都需要从内存中反复获取大量的模型权重和KV缓存。这两个阶段直接影响用户感知的延迟指标，如首个令牌时间（TTFT，主要由prefill决定）和每个输出令牌时间（TPOT，反映解码速度）。
  • 专家并行 (Expert Parallelism, EP)。如图3所示，EP【26】将专家划分到不同GPU上，并将令牌路由到托管其所选专家的GPU。每个rank首先为其本地令牌计算门控决策，然后进行全局路由元数据交换，以确定每个对等方的发送/接收大小和偏移量，最后通过all-to-all通信分派令牌。与通用通信库相比，DeepEP【9】通过高性能核、拓扑感知调度和潜在的去重或重叠来优化令牌all-to-all通信。
  • 并行策略组合。MoE训练和推理通常将张量并行（TP）【56】，流水线并行（PP）【19, 27, 36, 46】和数据并行（DP）【48, 52】与EP结合使用。EP通常作为嵌套在外部PP/DP布局内的内部并行模式，其中每个MoE层形成一个EP组。
  • 算法侧与系统侧负载均衡的关系。算法侧的路由正则化和系统侧的均衡是互补的。训练时的辅助路由损失主要用于稳定优化、防止路由崩溃【53】和保持专家特化。例如，GShard【26】通过辅助损失鼓励期望上的均衡利用，而DeepSeekMoE【8, 60】则根据近期负载更新专家级路由偏置。两者都促进了长期的均衡，但无法保证每个微批次的实时负载均衡。因此，系统侧技术用于纠正运行时不均衡，不能替代路由损失的建模目标。

3. 专家负载分析

我们观察到，在服务和训练中，专家负载分布都表现出高度倾斜、异构和动态的特性。

服务预填充 (Serving Prefill)

在服务中，预填充阶段是专家负载不均衡的主要来源。如图4所示，专家流行度在不同语义（如科学、编码和混合领域）的流量之间急剧变化。即使在单个领域内，热门专家也会在不同批次间漂移。这种工作负载既高度倾斜又非平稳。


图4. 在Qwen3-235B（128专家中激活top-8，EP=64）上采样的预填充阶段专家负载分布。负载在前向步骤、数据域和层之间变化。不均衡比率表示最大单专家负载与平均值的比值。

训练 (Training)

训练展现了不同但同样具有挑战性的模式。如图5所示，在训练早期，由于路由器特化尚未稳定，专家负载高度不稳定。随着训练进行，平均分布变得更平滑，但强烈的动态性依然存在。即使是DeepSeek风格的路由补偿也无法消除振荡。在更细的粒度上，由采样随机性引起的微批次间抖动也依然可见。


图5. 在GLM4.5-106B-A12B（使用GShard风格辅助损失）和DeepSeek-V3（使用DeepSeek风格辅助损失）上采样的训练初期和后期专家负载分布（EP=64）。

基于历史的均衡方法的局限性

我们研究了EPLB【12】在大规模EP下缓解rank级不均衡的效果。如图6所示，EPLB依赖历史负载统计，无法追踪预填充或训练中快速、非平稳的负载变化。当实际负载偏离用于推导专家布局的统计数据时，EPLB甚至可能加剧不均衡，产生新的尖峰和掉队者。这促使我们设计一种能够响应瞬时负载而非基于过时测量的实时方案。


图6. 使用EPLB前后EP=64下的Rank级不均衡。EPLB的重新平衡间隔在预填充为50批次，训练为3个全局批次。左图为混合数据预填充，右图为第3510个全局批次的训练。

A2 方法细节

4. UltraEP 系统设计

UltraEP旨在通过精确负载实现实时专家负载均衡。每个EP组位于一个RSN的scale-up域内，而跨机架的scale-out扩展使用PP和DP。本节介绍UltraEP的专家布局与内存管理、执行流水线、优化问题公式化，并提炼出实际挑战。

4.1 专家布局与内存管理

  • 专家布局。如图7所示，我们区分逻辑专家（模型定义的专家身份）和物理专家（rank上的具体存储槽）。每个rank保留相同数量的主槽（main slot）和冗余槽（redundant slot）。主槽托管逻辑专家的原始物理实例，而冗余槽要么托管一个逻辑专家的副本，要么保持为空。这种固定布局使运行时保持简洁和确定性，并产生一对多的逻辑到物理映射。

  • 仅复制策略 (Replication Only)。UltraEP采用仅复制的均衡策略，从不重排主专家。这种无重排设计是有效的，因为大规模EP减少了每个rank上的本地主专家数量（通常为2或4个）。此时，重排带来的边际效益递减，却会引发大量的状态迁移、控制复杂性和局部性破坏。相比之下，复制能经济高效地扩展实际瓶颈的服务能力。

  • 跨层缓冲区复用。对于主专家，UltraEP保留标准的内存布局。对于每个冗余槽，它不保留优化器状态（优化器更新仅在主专家上应用），并在各层之间共享权重/梯度缓冲区。在Qwen3-235B-A22B（94个MoE层，128个专家）中，这将单个冗余槽的内存占用从3.3GB权重和6.6GB梯度减少到每rank 36MB和72MB，代价是在前向关键路径上增加了每个层级的权重物化（weight-materialization）期限。

表1. UltraEP中使用的符号。


图7. 专家布局和缓冲区管理（示例：8个专家，单层，EP=4，n_slot=1）。冗余专家槽在各层之间复用权重和梯度缓冲区，没有优化器状态。主专家保留全套缓冲区。

4.2 计算-通信流水线

  • 前向：即时规划与专家复制 (Eager Planning and Expert Replication)。如图8所示，UltraEP首先收集全局路由信息以获得精确负载。基于此，每个rank在无需额外同步的情况下，确定性地计算出相同的复制和重路由计划。重路由将路由器输出的“令牌到逻辑专家”分配转换为“令牌到物理专家”。复制决策确定后，UltraEP将主专家的权重分发给其远程副本。此同步过程可与重路由重叠，但令牌分派需等待其完成以避免带宽竞争。因此，规划和权重复制都在关键路径上，对时效性要求极高。


图8. 启用UltraEP的MoE前向传播过程。

  • 后向：权重再物化与梯度归约 (Weight Rematerialization and Gradient Reduction)。如图9所示，后向执行首先将冗余专家的权重恢复到与前向传播时相同的状态。此通信可与权重梯度（Wgrad）计算重叠。MoE后向传播完成后，每个主专家将其所有远程副本贡献的梯度聚合到主梯度缓冲区中。此归约操作保证了与无副本情况的等价性，并且必须在下一个MoD层开始前完成，因为冗余梯度缓冲区也是跨层复用的。后向执行不重新进行复制规划，而是复用前向传播缓存的元数据。


图9. 启用UltraEP的MoE后向传播过程。

4.3 问题公式化

我们为每个EP组独立求解一个在线优化问题。相关符号见表1。

  • 输入：静态元数据 ($R$, $E$, $h$, $n_{\text{slot}}$) 和运行时负载 $\Lambda$。
  • 输出：一个配额感知的复制计划 $\mathcal{P} = \{p_{r,e}\}$ 和一个与 $\mathcal{P}$ 一致的重路由拆分 $s_{r, e, i}$。
  • 目标：前向目标是最小化总延迟：

    其中各项分别代表规划、重路由、权重分发、令牌all-to-all和MoE计算的延迟。
    对应的后向目标是：

    后向传播复用前向的元数据，且副本相关的通信被隐藏在计算下，因此暴露路径上只剩下令牌all-to-all和MoE计算。
  • 模型：MoE计算延迟由最繁忙的rank决定，后向计算近似为前向的两倍：

    令牌all-to-all延迟由最繁忙的发送或接收rank决定：

    权重分发延迟由托管最热门主专家的rank决定：
  • 约束：
    1. 主专家的位置不可变。
    2. 每个rank的冗余槽预算为 $n_{\text{slot}}$，且同一逻辑专家不能在同一rank上出现多次。
    3. 副本引入的后向通信必须被完全隐藏。
    4. 每个新创建的副本至少要承载 $q_{\min}$ 的配额。

4.4 实际挑战

  • 控制平面：微小的决策窗口。实时平衡必须在极短的延迟预算内做出高质量的决策。这面临组合决策空间巨大和负载非平稳的挑战。
  • 数据平面：RSN带宽利用不足。平衡流量的非对称和高动态性暴露了新的系统瓶颈。现有通信栈为静态、可预测的集合通信优化，难以适应UltraEP中的不规则流量，导致非负载开销放大和热门专家的扇出瓶颈。

5. 配额驱动的规划

UltraEP将平衡规划视为一个由精确运行时负载驱动的联合复制-重路由问题。我们不先决定副本再用单独的重路由策略修补，而是直接求解最终的每个实例的负载配额 $q$。

5.1 复制

  • 阈值公式化。我们寻找最小的负载阈值 $\tau$，使得所有rank的负载都能通过复制被降到 $\tau$ 以下。对于一个候选阈值 $\tau$，我们定义rank $r$ 需要卸载的超额负载 $exc_r(\tau)$ 和可以吸收的空闲负载 $slk_r(\tau)$：

    一个阈值 $\tau$ 是可行的，如果超额负载可以被重新分配到有空闲资源的rank上，而不违反槽预算或无重复约束。

  • 配额构建。UltraEP在平均rank负载和初始最大rank负载之间对 $\tau$ 进行二分搜索，并为每个探针运行一个贪婪的可行性预言机。对于一个候选 $\tau$，预言机按降序访问过载的rank及其主专家，将尽可能多的负载从最热门的专家转移到具有最大空闲且符合条件的rank上。此过程同时创建副本并更新其配额。这种方法之所以高效，是因为它以配额为耦合变量，在选择副本的同时预留了重路由容量，避免了枚举副本集或令牌级路由。

5.2 重路由

  • 基于局部性的配额分解。一旦配额 $q$ 确定，重路由仅需实现一个与求解出的配额目标相匹配的源端拆分 $s$。对于每个专家，UltraEP首先让源自同一主机rank的令牌消耗该主机的配额，以利用局部性减少跨rank流量。剩余的源需求则按比例分配到剩余的配额容量中。

  • 令牌分配。配额指定了源到实例的聚合计数。每个rank将此分解结果存储为按物理实例排序的累积配额。在分派时，通过一次上界查找即可确定每个令牌的目的地，该过程独立于优化程序。

5.3 GPU原生求解

UltraEP在设备上完全实现了配额求解，避免了关键路径上的CPU同步和设备-主机元数据移动。该算法利用warp级并行和数据局部性，通过一个协作线程块在共享内存中暂存负载矩阵和放置状态，跨warp评估多个阈值探针，并使用warp级归约来寻找符合约束的目标。整个求解过程从一个CPU侧的组合搜索转变为一个紧凑的GPU常驻可行性问题。

算法1：复制与重路由联合求解

6. RSN原生的平衡通信

UltraEP的平衡流量是在RSN scale-up网络上的一种运行时自适应的稀疏传输图。我们优化了两个瓶颈：非负载开销和热门专家的扇出。

6.1 用于数据传输的持久化瓦片流 (Persistent Tile Streaming)

  • 机制。权重分发和梯度归约都使用相同的执行单元：将专家权重或梯度划分为固定大小的瓦片（tile），并将求解的放置计划编译为设备常驻的瓦片传输任务。UltraEP运行一个持久化内核，其线程块不断从全局任务流中拉取下一个瓦片任务。对于权重分发，每个源瓦片被暂存到共享内存一次，然后存储到所有远程副本目的地。对于梯度归约，来自远程副本的梯度瓦片被加载并累加到主专家的本地梯度缓冲区中。内核在每个线程块内对共享内存瓦片进行双缓冲，从而将任务查找、地址转换和同步等开销折叠到瓦片流水线中，并被数据移动所隐藏。

  • 重叠感知的资源占用。瓦片流内核通过常驻线程块数量来控制资源。在前向关键路径上，启动足够多的线程块以饱和带宽。在可重叠的后向路径上，则明确限制资源占用，以最小化与其他计算内核的竞争。

6.2 用于热点扇出的块流中继 (Chunk Streaming Relay)

  • 机制。对于副本数量超过中继阈值的热门专家，UltraEP构建一个轻量级的两级中继：源rank首先将数据发送给一小组中继节点，然后每个中继节点再转发给其分配的叶子节点。中继调度工作在由连续瓦片组成的块（chunk）上，因此中继rank可以在一个块到达后立即转发它，通过块级流化将两个阶段流水线化，无需等待整个专家传输完成。


图10. 热门专家扇出的中继方案。假设rank 0上的一个专家需要多播到rank 1-9，选择rank 2, 5, 8作为中继。图中省略了叶子节点和更细粒度的瓦片，展示了每个rank上收发通道随时间的状态。

  • 负载感知的重继调度。内核构建中继拓扑以平衡所有rank的传出流量。它首先跟踪分配给每个rank的发送字节量，然后逐一处理符合中继条件的的热门专家。对于每个专家，它从该专家的副本rank中选择发送量最小的作为第一级中继。剩余的副本则被附加到那些即使接收了新叶子节点后发送量仍然最小的中继上。通过这种方式，热门专家的扇出压力被分散到具有空闲发送能力的rank上。

A7 补充细节

7. 实现

  • 设计。我们将UltraEP设计为一个独立的运行时库，与训练/服务框架及MoE令牌all-to-all后端解耦。核心库包含约9.6K行C++（包括设备内核）和Python代码。我们将其集成到Megatron-LM【56】和SGLang【70】中，额外代码均少于1K行。我们使用DeepEP【9】进行令牌分派/合并。
  • RSN内存语义。对于RSN scale-up网络上的通信，我们采用GPU初始化的单边对等内存访问。初始化时，所有rank分配对称缓冲区，并将RSN内部的对等句柄解析为设备常驻的地址表。
  • 端到端集成。UltraEP将冗余专家作为层共享的内部缓冲区进行管理，而主专家的持久模型状态由外部框架支持。这些冗余专家被排除在框架侧的参数/梯度桶、优化器状态和检查点之外。为了在流水线并行中匹配前向和后向的平衡计划，UltraEP为每次飞行的MoE调用分配一个虚拟层ID，该ID允许后向传播时从内部状态中检索匹配的前向平衡计划。由于UltraEP仅在EP组内操作，它与注意力侧DP、TP和模型级DP保持正交。

A4 实验环境

  • 测试平台：实验在一个公共云RSN集群上进行，每个机架包含64个GPU（16台服务器）。预填充实验使用1个机架，训练实验使用2或4个机架，生产级训练使用2560个GPU。硬件配置见表2。
  • 模型与并行设置：评估了五个不同规模和稀疏度的MoE模型，包括Qwen3-235B、GLM4.7-358B、GLM4.5-106B、DeepSeek-V3和自研的RefMoE-288B。所有实验均使用bf16精度。并行设置见表3。
  • 训练方案：开源模型在200B令牌上训练约4500个全局批次。生产模型在15T令牌上训练。根据模型特性，使用GShard或DeepSeek风格的负载均衡辅助损失。
  • 服务负载：查询来自现实世界的推理工作负载，包括STEM（编码、数学、科学）和混合领域，输入长度从几百到数万个令牌不等。

  • 基线：

    • Megatron-LM【56】 / SGLang【70】：不带负载均衡的基线。
    • EPLB【12】：一种广泛使用的、基于近期负载计算专家放置计划的算法。
    • LPLB【13】：一种基于线性规划的求解器，在EPLB基础上为每个微批次调整重路由。
    • EPLB+：为了隔离规划算法的收益，我们将UltraEP的规划器替换为EPLB和轮询重路由，但保留其通信机制。
    • Ideal：一个强制均衡的上限，通过修改路由器使令牌均匀分发到专家。

  • 评估指标：训练性能报告为TFLOPS/GPU；服务性能报告为每秒请求数（RPS）与首个令牌时间（TTFT）的关系。同时报告rank级的最大/平均不均衡比率。

表2. RSN配置。

表3. 评估的模型和并行设置。

A4 实验结果

端到端性能

  • 训练。如图11所示，在三个模型上，UltraEP的平均吞吐量达到了理想性能的94.6%，并将rank级不均衡度控制在1.01–1.03。与Megatron-LM相比，平均吞吐量提升了42%。基线方法的吞吐量因其平衡计划滞后于实际负载而出现明显波动，而UltraEP则保持稳定。


图11. 端到端训练性能：在三个模型上20个训练迭代中的吞吐量变化。

  • 服务预填充。如图12所示，预填充负载更倾斜、更非平稳。在此环境下，UltraEP的增益更大，达到了理想吞吐量的90%–97%，相较于SGLang和EPLB，吞吐量分别提升了1.56倍和1.29倍。


图12. 端到端预填充性能：在两个数据域和两个模型上的RPS-平均TTFT权衡。

延迟分解

如图13所示，我们分解了Qwen3-235B-A22B训练中每MoE层的延迟。与理想情况相比，UltraEP引入的额外开销极小（前向0.33ms，占总延迟的1.8%），表明其关键路径开销已最小化。MoE计算延迟已接近理想值，证实了rank级负载不均衡基本被消除。与理想情况的主要差距在于令牌all-to-all通信，这是由真实MoE训练中不均匀的令牌路由造成的，而非平衡开销。


图13. Qwen3-235B-A22B训练期间前向和后向传播的延迟分解。

激活内存占用

如图14所示，不均衡会导致接收端最热的rank上激活内存占用激增（训练中峰值高出理想情况2倍，服务中高出11倍）。UltraEP通过平滑接收端热点，显著降低了MoE激活内存峰值，使其接近理想情况，从而降低了内存溢出风险。


图14. 峰值GPU内存分解。

消融研究

  • 平衡质量。如图15和表4所示，我们将UltraEP的配额求解器与EPLB+进行比较。UltraEP的平衡质量分布更接近理想，尾部更小。同时，UltraEP的求解延迟降低了27.4%，消耗的冗余槽减少了57.9%，并通过局部性优化将令牌流量减少了3.9%。这验证了UltraEP直接优化路由后负载的优越性。


图15. EPLB+与UltraEP平衡质量的深入比较。上图：所有训练和预填充评估中的不均衡度分布；下图：在各种MoE、EP和冗余设置下的模拟平衡效果。

表4. 图15中模拟的平均平衡指标，包括求解时间、消耗的冗余槽、最大副本扇出和流量比率。

  • 通信性能。如图16所示，我们将UltraEP的通信优化与主流通信后端（PyTorch distributed【28】和DeepEP【9】）进行比较。在所有不均衡水平下，UltraEP比它们快3.1至5.5倍。对于高扇出专家，启用中继可带来额外的1.3至1.8倍增益，有效缓解了扇出瓶颈。


图16. 在Qwen3-235B和EP64上，不同不均衡水平下专家权重分发的通信延迟比较。

生产规模MoE训练

如图17所示，在2560个GPU上训练RefMoE-288B时，尽管存在大规模硬件和网络的可变性，UltraEP仍能维持超过92%的理想吞吐量，相比无平衡情况平均提升9.6%，同时保持了训练的收敛性。


图17. 2560-GPU RefMoE-288B训练的吞吐量和损失曲线。

A5 结论

UltraEP为在RSN上进行的大规模EP MoE训练和服务预填充实现了精确负载的专家平衡。通过将基于配额的规划与RSN原生的专家状态通信相结合，UltraEP能够响应已实现的路由并执行实时平衡，同时保持关键路径开销很小。我们的评估验证了其接近理想的吞吐量、近乎最优的平衡质量和生产级别的可扩展性。由于UltraEP同时覆盖了训练和推理，其抽象可以自然地扩展到交替执行这两个过程的强化学习（RL）流水线中。

方法细节中的引用汇总

以下是论文方法细节章节（Section 4, 5, 6, 7）中引用的参考文献及其上下文描述：

  • 引用 [9] DeepEP: A high-performance communication library for MoE training and inference (2025)

    • 引用段落: Section 7, 第1段
    • 原文描述: "We use DeepEP [9] (hybrid-ep branch optimized for intra-rack communication, v1.2.1+7febc6e) for token dispatch/combine in both frameworks."
    • 中文描述: “我们在两个框架中都使用DeepEP【9】...进行令牌的分派/合并。”

  • 引用 [28] PyTorch distributed: experiences on accelerating data parallel training (2020, VLDB Endowment)

    • 引用段落: Section 8.5, 第2段 (实验结果-通信性能)
    • 原文描述: "...and use PyTorch distributed [28] batch send/recv as a more general baseline."
    • 中文描述: “...并使用PyTorch distributed【28】的批量发送/接收作为一个更通用的基线。”

  • 引用 [37] Efficient large-scale language model training on gpu clusters using megatron-lm (2021, SC)

    • 引用段落: Section 7, 第3段
    • 原文描述: "By setting the ring size to the maximum in-flight microbatches, we accommodate PP and virtual PP [37] while keeping UltraEP agnostic to PP scheduling details..."
    • 中文描述: “通过将环形缓冲区的大小设置为最大飞行中的微批次数，我们适应了PP和虚拟PP【37】，同时保持UltraEP对PP调度细节的无关性...”

  • 引用 [56] Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism (2019, arXiv)

    • 引用段落: Section 7, 第1段
    • 原文描述: "We integrate UltraEP into Megatron-LM [56] for training..."
    • 中文描述: “我们将UltraEP集成到用于训练的Megatron-LM【56】中...”

  • 引用 [70] SGLang: Efficient Execution of Structured Language Model Programs (2024, NeurIPS)

    • 引用段落: Section 7, 第1段
    • 原文描述: "...and SGLang [70] for serving..."
    • 中文描述: “...以及用于服务的SGLang【70】...”