在大语言模型 (LLM) 训练领域，超大规模混合专家 (MoE) 模型训练中的EP通信一直是业内公认的难题。EP通信本质上是 all-to-all通信，但由于其动态性和稀疏性两大特征—动态性体现为数据传输 pattern由运行时路由表决定，稀疏性则是每个 Token只需要给到 topk个 expert，而非全部 expert，这也导致该通信模式的落地实现与性能优化存在较大难度。本文将介绍 Hybrid-EP，一个全新的高效的MoE EP通信优化方案，并结合其在 NVIDIA Megatron系列框架、NVIDIA Quantum InfiniBand以及 Spectrum-X以太网平台的落地应用，论证该方案在实际模型训练中的优异效果。
背景：超大规模 MoE 模型训练的效率挑战
当前，以 DeepSeek-V3 (6710 亿参数、MoE 架构、激活参数占比仅 5.5%)为代表的超大规模 fine-grained MoE模型，正在成为 AI 领域的新一代主流技术方向。这类模型通过“超大参数规模 + 稀疏激活”在算力开销与模型性能之间取得平衡，但也对现有大模型训练框架提出了严峻挑战。
- 通信效率瓶颈：MoE 模型依托专家并行，训练过程中需要频繁执行 all-to-all通信，随着专家数量不断增多，EP 通信负担急剧增大。在未做优化的 DeepSeek-V3训练过程中，通信耗时占整体训练时长的比例可达 50% 以上。
- 负载不均衡：动态路由机制会使部分“热专家”接收的 Token 远高于均值，而“冷专家”则处于利用率不足的状态，导致设备间计算负载不均、算力浪费。这一问题在专家数量与激活专家数量持续增加的 fine-grained场景下尤为突出。
- 框架适配性挑战：现阶段的 MoE模型在并行策略、低精度计算和资源动态调度等方面提出了更高、更复杂的综合需求，需要通过针对性优化才能充分释放 NVIDIA Blackwell、NVIDIA Quantum InfiniBand 以及 Spectrum-X以太网这类新一代硬件架构的性能潜力。
核心技术分享：框架优化与通信方案创新
Megatron-Core 框架：MoE训练的核心基础支撑
Megatron-Core 作为 NVIDIA开源的大规模模型训练库，是超大规模 MoE模型训练的核心基石，其核心优势主要体现在三方面：
- 多维并行策略：支持张量并行(TP)、序列并行、流水线并行(PP)及 MoE 专家并行(EP)等多种策略，各策略可灵活组合，能够适配多样化和复杂的训练负载。
- 资源与训练效率优化：集成 FP8 混合精度训练、激活值 Offloading、分布式优化器及fine-grained重计算等功能，有效降低CPU 显存占用，全面支持各类大模型的训练需求。同时该框架整合了 MLA、注意力(Attention)、多层感知机(MLP)等多种高效算子，并通过多类融合(Fusion)优化与合理化的流水线调度策略，进一步提升算力执行性能。
- MoE 专项适配能力：针对 DeepSeek、Mixtral、Qwen 等主流 MoE模型提供完整适配支持，具备高效且可扩展的训练方案。
Hybrid-EP：高效的 MoE EP通信优化方案
Hybrid-EP 是全新设计的 MoE EP通信库，其充分利用 NVIDIA平台的软件及硬件先进技术，以达到在 RDMA + NVLink混合网络架构下 ，实现接近硬件极限的通信带宽，并最小化 GPU硬件资源的使用的目的。
Hybrid-EP实现了 MoE EP通信中的两大核心算子：dispatch (分发) 与 combine (聚合)。 其中 dispatch负责把 attention算子输出的 Tokens路由至对应的 experts，combine负责将 experts 输出的 Tokens反向路由还给 attention算子。此外，Hybrid-EP还实现了拓扑侦测功能，以完整的实现 EP通信的全部环节。
图1：Hybrid-EP 功能架构图。在单次训练迭代过程中，Transformer 层内 Hybrid-EP 算子的运行逻辑。标注为彩色的 Hybrid-EP 算子在前向与反向传播过程中的调用方式，及其与上下游算子的衔接关系。图中灰色线条代表 Token 及对应数据的流转路径，浅蓝色线条则为元数据(metadata)的传输路径，这类元数据可在该 Transformer 层的单次训练迭代中全程复用。
Hybrid-EP的设计目标与核心优化方向包括：
- 采用 NVIDIA平台最新的通信技术：Hybrid-EP在 NVLink 纵向扩展网络中，通过 TMA指令进行数据通信；在 RDMA 网络中采用底层的 IBGDA 网络技术进行数据通信。
- 基于 RDMA与 NVLink混合网络通信，实现跨域带宽利用率最大化：Hybrid-EP协同节点内 NVLink 与节点间 RDMA 通信，通过混合转发模式提升有效算法带宽。
- 精细的数据流水线设计，实现极致的延迟隐藏：Hybrid-EP 通过将数据细粒度地切分成chunk，并让 data chunk按顺序流经多级通信 data pipeline，掩盖掉绝大部分通信以及动态路由的延迟，使 EP通信的带宽能与高度优化的标准静态 all-to-all媲美。
- 最小化 GPU SM资源占用，最大化通信-计算重叠：Hybrid-EP通过充分利用每个 SM的能力，在硬件带宽即将跑满至峰值时，将 GPU SM的资源占用降至最低，从而释放更多的GPU SM资源供给到其他计算 kernel，最终 实现通信-计算重叠的最大化。
- 低精度训练支持：原生支持 FP8/BF16 dispatch 算子，以及 BF16 combine算子。
Hybrid-EP 将每个 CUDA block 设计成一个独立的数据 channel。即一个CUDA block 独立而完整地占用一个SM，用于运行整条完整的 data pipeline；CUDA block 中不同的 warps group ，分别负责这个 data pipeline中不同的 pipeline stage。CUDA blocks之间则是完全的数据并行，负责不同的 data chunk的处理，无需进行同步和通信。
图2：单个 CUDA block 内 dispatch 算子的数据流水线设计。展示了面向多节点 Token 分发的完整通信链路，清晰呈现出 RDMA、G2S、S2G 三类线程束组(warp group)协同完成 GPU 与节点间数据传输的流程。
图中虚线框部分表示 RDMA网络通信才会用到的 pipeline stage，如果只在 NVLink网络中通信则不会用到。其中 RDMA warp group负责使用 IBGDA技术向 RDMA网卡发射网络传输任务，完成不同节点间同轨道的 GPU(例如所有节点的0# GPU)之间的网络通信与 Token数据传输。G2S warp group则负责将该 GPU自身拥有的 Token数据以及其他节点同轨道的 GPU传输过来的 Token数据读取到 SM内部的 shared memory FIFO队列中。S2G warp group则负责将 SM内部的 shared memory FIFO队列中的 Token数据，写入到本节点内所有 GPU(包括该GPU自身)的输出 buffer中对应的位置。当然，在此过程中，会严格按照 routing map的信息进行 Token的路由和搬运，避免传输不需要的 Token数据。每个 CUDA block会使用上述的 data pipeline按顺序处理其分配到的 data chunk中的 Token数据。不同的 CUDA block使用相同的 data pipeline处理不同的 data chunk。
图 3：单个 CUDA block内 combine算子的数据流水线设计。展示了多节点 Token 合并过程中使用的完整通信路径，显示了线程束组(warp group)如何在节点内和节点间的多个GPU上进行分层归约操作，以完成最终的累加。
与 dispatch算子相同，虚线框部分只有 RDMA网络通信才会用到。因为 combine算子需要对于token进行高精度累加操作，而这部分目前只能在 SM内部的 CUDA core完成，所以需要分层次地进行累加工作。在多节点情况下，会先由 intra-node的相关的 warp groups完成对于Token的节点内的部分累加工作，再由 RDMA warp group将完成节点内部分累加工作的token发送给不同节点间的同轨道的GPU。最后再由 inter-node相关的 warp groups完成全局的累加工作，得到最终结果。在单节点的情况下，直接由 inter-node相关的 warp groups完成节点内的累加工作即可。累加工作过程中，会由相应的 G2S warp group将输入 Token读取至 SM内部的 shared memory G2S FIFO队列中，再由相应的 reduction warp group在 CUDA core中完成对于 Token的累加，并将结果存回到SM内部的 shared memory S2G FIFO队列中，并交由 TMA单元存回显存。
Hybrid-EP在诸多不同的硬件平台上都进行了测试，并取得良好表现，测试条件如下：
- HIDDEN_DIM = 8192, DATA_TYPE = BF16, 只传递token，不传输附属数据.
- NUM_OF_ATTN_TOKENS_PER_RANK = 4096.
- NUM_OF_EXPERTS_PER_RANK = 2.
- Routing map 按照uniform distribution随机生成.
- TOPK = 8.
- NVIDIA Quantum-X InfiniBand 轨道优化网络
首先是在单台 DGX Hopper平台上的测试，共计8张 GPU，可以看到 Hybrid-EP仅需要8个SM就可以基本打满 NVLink带宽：
图4：Hybrid-EP 单台DGX Hopper平台上测试
随后 ，在四台 DGX Hopper 集群上进行测试，共计8×4=32张GPU，四台 DGX Hopper 上同轨道的 GPU 之间各有一张 400 Gbps速率的 ConnectX-7网卡通过 NVIDIA Quantum-X InfiniBand 网络实现 RDMA连接。
考虑到 Hybrid-EP是使用 NVLink+RDMA混合网络进行层次化的通信，所以在测试中统计了两组数据：
- ConnectX-7网卡上真正达到的网速，这是使用途经网卡的实际数据量和通信总耗时计算出来的网卡实际带宽，即 NIC bus bandwidth。
- 站在算法层面统计的全局带宽，这是衡量 dispatch与 combine算子使用混合网络完成实际工作的带宽，即 algorithm bandwidth。
可以看到 Hybrid-EP仅需要大约4个SM，就可以接近网卡的最高带宽：
图5：Hybrid-EP 在四台DGX Hopper 集群上测试
最后，在 Grace Blackwell平台上测试 Hybrid-EP在大规模 NVLink网络中的性能，我们最终实际测试的 NVLink domain大小为共计36张GPU，即NVL36。可以看到 Hybrid-EP仅需要16个SM，就可以基本打满 NVLink带宽：
图6：Hybrid-EP 在Grace Blackwell平台上测试
以上为 Hybrid-EP单独测试的性能，本文后续还将展示 Hybrid-EP在Megatron-Core 框架中实际训练模型的性能数据。
实践案例：结合热点模型与硬件的落地验证
将 Hybrid EP引入PyTorch
HybridEP 基于模板和 CUDA C++ 实现，其输入和输出均为缓冲区地址。若要在基于 PyTorch 的 Megatron-Core框架中高效使用 HybridEP，需要完成一定的额外集成工作。目前 HybridEP已在 DeepEP 的 Hybrid-EP分支开源，并提供可直接调用的 PyTorch运算算子，便于用户快速完成集成与测试。
由于 HybridEP的内核只接受指针参数且不负责显存管理，因此需要设计一套合理的缓冲区管理与分配机制。根据使用场景的不同，HybridEP的缓冲区大致可以分为两类：
- Registered buffer：指经过特殊注册的显存，注册完成后可以被其他 rank上的 kernel访问，是全局唯一的静态缓冲区。具体的注册方式会因场景而异：在跨节点通信场景下，需要将显存注册到通信的 memory region；在非跨节点通信场景下，则需要通过 driver API 生成可在其他 rank中解析的 handle。
- 普通缓冲区：指通过 cudaMalloc申请的显存，可以由 PyTorch的 allocator管理，通常不是全局唯一。
由于缓冲区的申请和注册操作非常耗时，理想情况下这些操作只在 Python HybridEP初始化阶段完成。然而，MoE模型具有高度动态性，每个 iteration中当前 rank接收到的 Token数量会变化，从而导致所需缓冲区大小也随之变化。为此，可以采用“最坏情况预分配”的策略：按所有 Token都可能汇聚到同一 rank的上限来申请足够大的缓冲区。因为该缓冲区在全局范围内是唯一的，所以对显存总体占用仍然是可控的。
缓冲区准备过程大致分为两步：
- 申请足够的显存并完成 buffer注册；
- 将 registered buffer暴露给其他 rank。其流程如图所示：当前 rank先将 registered buffer对应的 memory handle发送给目标 rank，目标 rank的进程再通过打开该 handle 获得可进行远程访问的虚拟地址。
图7: 缓冲区的准备过程
由于 registered buffer无法由 PyTorch的 allocator管理，而 dispatch kernel的输出和 combine 的输入又都必须位于 registered buffer 中，同时我们又希望最终 Python侧的 HybridEP接口仍然以标准 PyTorch tensor作为输入输出，因此需要额外进行一次 device-to-device的显存拷贝，将结果从 registered buffer拷贝回对应的 PyTorch tensor，如图所示。
图8：如何将结果从已注册缓冲区转移到常规的 PyTorch 张量
然而，这一步额外的拷贝会对 HybridEP的性能产生负面影响。为此，在 HybridEP 中加入了 permute 功能，将这次 device-to-device 拷贝与 permute 操作融合在一起。这样一来，如图所示，单独的 D2D 开销被消除，HybridEP 的输出也可以直接交由 expert MLP 继续计算。
图9：混合专家并行的置换功能
最终，在 PyTorch 环境中，HybridEP的整体工作流程如图所示，其中在预处理完成之后，会有一次同步操作，这是因为 Torch需要依赖 GPU 侧的计算结果来确定后续需要的张量的大小，HybridEP会在预处理 kernel中计算后续的缓冲区尺寸大小。 如果能够在 host 端预先给出一个合适或足够安全的缓冲区大小，就可以完全省去这个同步。
图10：PyTorch 中混合 EP 工作流程的示意图
在Grace Blackwell上的优化实践
Megatron-Core已在 Grace Blackwell平台上集成 HybridEP，并可针对不同类型的 MoE模型进行优化。
- DeepSeek V3
针对DeepSeek-V3(256 epxerts， topk-8)的场景，不添加MTP的情况下，使用HybridEP相比DeepEP能获取约14%的性能提升。
| Model | Precision | Dispatcher | TFLOPS/GPU |
| DeepSeek-V3 | MXFP8 | DeepEP | 829 |
| DeepSeek-V3 | MXFP8 | Hybrid-EP | 943 |
- Qwen3 235B-A22B
对Qwen3 235B的场景，在BF16场景下相比A2A(all-to-all) dispatcher有5.5%的提升，在MXFP8上会有9.9%左右的提升。
| Model | Precision | Dispatcher | TFLOPS/GPU |
| Qwen 3 235B | BF16 | A2A | 665 |
| Qwen 3 235B | BF18 | Hybrid-EP | 698 |
| Qwen 3 235B | MXFP8 | A2A | 728 |
| Qwen 3 235B | MXFP8 | Hybrid-EP | 800 |
- DeepSeek V3 + Megaton FSDP
在Megatron-FSDP中，HybridEP仍然能够提供8%左右的性能提升
| Model | Precision | Dispatcher | TFLOPS/GPU |
| DeepSeek-V3 | MXFP8 | A2A | 597 |
| DeepSeek-V3 | MXFP8 | Hybrid-EP | 645 |
综合来看，HybridEP 在 Grace Blackwell 平台上的实践表明，其在不同模型规模、不同精度配置以及多种并行策略下，均能在保持数值精度的前提下显著提升端到端训练吞吐。具有良好的可扩展性和通用性，为新一代大规模 MoE训练提供了高效、稳定的通信与调度基础。
了解更多关于 NVIDIA 如何让混合专家模型MoE驱动最智能的前沿 AI 模型，在 NVIDIA Blackwell 系统上运行速度提升 10 倍。
