NCCL EP统一MoE通信生态：打破碎片化，加速大模型推理新纪元

关键词： MoE（Mixture-of-Experts）、NCCL、GPU 通信、Device-Initiated Communication、大模型推理

在通往通用人工智能的道路上，模型规模正以前所未有的速度扩张。当稠密的 Transformer 模型在计算和参数效率上触及瓶颈时，混合专家（Mixture-of-Experts, MoE）架构凭借其“加人加卡不加计算”的特性，成为扩展模型能力的关键路径。从 DeepSeek-V3 到 Mixtral，MoE 通过将模型参数解耦为稀疏的“专家”网络，在保持推理成本可控的前提下，实现了模型容量的显著增长。

然而，MoE 架构也引入了全新的、复杂的通信挑战。设想上万个“专家”子网络分布在数千张 GPU 上，每个输入 token 都需要根据动态计算的路由规则，被精确地分发到选中的少数几个专家进行处理，随后再将结果收集回来。这一过程不再是传统的大规模同步通信（如 AllReduce），而转变为一种细粒度、动态且全对全（All-to-All）的通信模式。

为应对此挑战，业界出现了 DeepEP、Hybrid-EP 等一系列设备端发起（Device-Initiated）的通信库。它们如同为 MoE 定制的“特快专递”，通过允许 GPU 直接发起远程直接内存访问（RDMA），绕过 CPU，显著降低了通信延迟。

表 I：MoE 常用通信库在统一 API、模式支持、编程接口及目标负载等维度的对比。分析表明，当前生态存在碎片化问题：DeepEP 和 pplx-kernels 虽性能卓越，但为低延迟（LL）和高吞吐（HT）模式提供了分离的 API；Hybrid-EP 则主要专注于训练场景。相比之下，NCCL EP 是唯一同时提供统一 C/Python API、支持双模式并完全构建于 NCCL 生态之上的解决方案。这种统一性简化了框架集成，避免了用户在不同库间切换的复杂性，标志着 MoE 通信向标准化、平台化迈出了关键一步。

但生态碎片化问题也随之凸显。 每个库都有其独特的 API，有的为推理优化，有的为训练优化，依赖的底层技术栈（如 NVSHMEM、IBGDA）也各不相同。这迫使开发者和框架维护者不得不在多种“方言”间疲于奔命，增加了部署的复杂性和维护成本。

正是在此背景下，NVIDIA 推出了 NCCL EP（Expert Parallelism）。它并未另起炉灶，而是选择了一条“大一统”的路径——将 MoE 通信能力原生、统一地集成进 NCCL（NVIDIA Collective Communications Library，NVIDIA 集体通信库）。

正如其研究论文所述：

“By building MoE communication natively within NCCL, NCCL EP provides a supported path for expert parallelism on current and emerging NVIDIA platforms.”
（通过在 NCCL 内部原生构建 MoE 通信，NCCL EP 为当前及未来的 NVIDIA 平台上的专家并行提供了一条受支持的路径。）

NCCL EP 的核心理念是： 提供一套统一的 ncclEpDispatch 和 ncclEpCombine API，底层根据工作负载（训练/推理）自动选择最优的通信算法（低延迟模式或高吞吐模式），并全面基于 NCCL 的设备端 API（Device API）。这意味着，开发者无需在多个库之间切换，仅凭一套 API 即可在 NVIDIA 硬件上获得优化的 MoE 通信性能。

图 1：NCCL EP 架构示意图。其低延迟内核设计借鉴自 DeepEP，高吞吐内核设计借鉴自 Hybrid-EP，两者均使用 NCCL GIN（GPU 发起的网络）进行节点间 RDMA 通信，同时保留其原生 NVLink 实现用于节点内通信。该架构揭示了 NCCL EP 的核心思想：博采众长，统一于 NCCL 框架之下。它并未重新设计内核算法，而是将业界验证过的优秀内核（DeepEP 用于低延迟，Hybrid-EP 用于高吞吐）进行适配，并将其底层通信原语替换为 NCCL Device API 中的 GIN 和 LSA。这样，NCCL EP 既继承了这些内核在各自场景的性能优势，又统一了通信后端，从而能够自动利用 NCCL 的拓扑感知能力（如选择 NVLink 或 PCIe）和生态系统兼容性。这种集成式设计旨在实现性能与可维护性的平衡。

那么，它的实际效果如何？根据实验数据：
* 在低延迟（LL）模式下，针对推理解码场景，NCCL EP 在 8 节点（64 GPU）集群上的分发（Dispatch）吞吐量，已与最先进的 DeepEP 持平甚至略有优势。
* 在端到端推理集成测试中（使用 vLLM 框架，Qwen3-30B-A3B 模型），NCCL EP 在 4 节点（32 GPU）规模上，其输出吞吐量达到 563.3 tok/s，平均每词元处理时间为 54.1 ms，与 DeepEP 的性能差距在 10% 以内，且该差距主要源于通信开销，是未来优化的重点。

这组数据表明，NCCL EP 作为后来者，在保持与原生 NCCL 生态兼容的前提下，其性能已足以媲美当前顶尖的专用通信库，有望成为未来 MoE 模型在 NVIDIA GPU 上部署的标准化通信方案。接下来，我们将深入 NCCL EP 的内部，解析其设计细节。

• 一、背景：MoE 通信为何如此“另类”？
  • 1.1 MoE 的前向传播过程
  • 1.2 MoE 通信的三大核心特点
• 二、NCCL EP 设计哲学：从“百家争鸣”到“书同文”
  • 2.1 统一 API，消除碎片化
  • 2.2 原生 NCCL，继承生态优势
  • 2.3 资源生命周期管理
• 三、核心剖析：NCCL EP 的两大通信模式
  • 3.1 低延迟模式 (Low-Latency Mode, LL Mode)：专为“解码”而生
  • 3.2 高吞吐模式 (High-Throughput Mode, HT Mode)：专为“训练”和“预填充”设计
• 四、底层力量：NCCL Device API 的魅力
  • 4.1 模块1：Load/Store Accessible (LSA)
  • 4.2 模块2：GPU-Initiated Networking (GIN)
  • 4.3 模块3：Multiterm
• 五、生态整合：从论文到生产
  • 5.1 Megatron-LM (训练)
  • 5.2 vLLM (推理)
• 六、相关工作：众星璀璨下的 NCCL EP
• 七、性能评估与未来展望
• 总结

一、背景：MoE 通信为何如此“另类”？

在深入探讨 NCCL EP 之前，有必要先理解其旨在解决的问题——MoE 通信的特殊性。传统的 Transformer 模型（如 GPT-3）通信模式高度规律且对称。在模型并行或数据并行场景下，通常使用 AllReduce 同步梯度，或使用 AllGather 聚合中间结果。这些通信原语的特点是：所有参与方交换的数据量相同，通信模式固定。

1.1 MoE 的前向传播过程

MoE 模型彻底改变了这一范式。其前向传播过程可拆解如下：

1. 路由（Gating）：每个输入 token 经过路由器（Router），产生权重分布，并选择最匹配的 k 个专家（top-k）。
2. 分发（Dispatch）：根据路由结果，将 token 数据及其元数据发送至所选专家所在的 GPU。
3. 专家计算（Expert Computation）：接收端 GPU 对收到的 token 执行专家网络（如 FFN）计算。
4. 收集（Combine）：将专家计算后的结果，按原始 token 顺序和路由权重进行加权求和，并收集回原始 GPU。

1.2 MoE 通信的三大核心特点

从上述流程中，可以总结出 MoE 通信的三大核心特点：

• 动态路由：通信模式在每个前向传播中动态变化，完全由当前批次的 token 路由结果决定。
• 不规则消息大小：不同专家在不同 GPU 上的“热度”各异，导致每对 GPU 之间交换的数据量高度不对称。
• 负载不均：“热门专家”会收到远多于“冷门专家”的 token，造成严重的通信与计算负载不均衡。

这些特点使得传统的 AllToAll 集体通信难以高效应对。标准的 NCCL AllToAll 假设所有 rank 间的通信量均衡，无法有效处理这种“马太效应”。因此，需要专门的 MoE 通信库，其必须具备在 GPU 端动态处理与灵活调度的能力。

二、NCCL EP 设计哲学：从“百家争鸣”到“书同文”

面对上述挑战，NCCL EP 的设计围绕“统一”和“原生”两个核心哲学展开。

2.1 统一 API，消除碎片化

这是 NCCL EP 最显著的贡献之一。它摒弃了以往多个 MoE 通信库各自为政的模式，提供了一套统一的 C 语言和 Python API。

表 II：NCCL EP C API 核心设计。该设计将 API 清晰地分为资源管理和通信两大类别。资源管理采用两级结构：ncclEpGroup_t 代表长期存在的通信组（管理连接、缓冲区等），而 ncclEpHandle_t 则封装每次前向传播的动态路由状态。这种设计既摊销了连接建立的开销，又适应了 MoE 路由的动态性。通信 API 中的 send_only 标志是实现计算与通信重叠的关键，允许在数据完全传输前释放 GPU 资源，与 NCCL 的异步流式执行模型高度一致。

开发者只需掌握 ncclEpDispatch 和 ncclEpCombine 两个核心原语，即可完成所有 MoE 通信任务。算法模式（低延迟 LL 或高吞吐 HT）在创建 MoE 组时通过配置参数决定，实现了代码级的一致性。

表 V：NCCL EP Python 封装中的 Buffer 类接口。该接口是连接上层框架（如 vLLM、Megatron-LM）与底层 C API 的关键适配层。设计充分考虑了 MoE 通信的实际需求：dispatch 和 combine 直接对应核心通信原语，返回的 handle 和 event 支持异步执行与状态管理；get_tokens_per_expert_list 为高吞吐模式提供精确的专家计数，便于后续可变批量 GEMM 计算；capture 和 destroy_handle 实现了资源的精细生命周期管理。此抽象层使框架开发者无需处理底层细节即可获得设备端通信的性能优势。

2.2 原生 NCCL，继承生态优势

NCCL EP 并非从头构建新的通信栈，而是深度集成于 NCCL 生态。这意味着它能无缝利用 NCCL 的拓扑感知、弹性与容错机制。部署 NCCL EP 的集群无需为新的通信库单独配置网络或注册内存，显著降低了运维复杂度。

2.3 资源生命周期管理

NCCL EP 采用了类似 NCCL 的资源管理模型，将长期存在的组（Group）与单次迭代的句柄（Handle）分离。Group 负责管理通信缓冲区、网络连接等长期资源，而 Handle 则封装单次前向传播的路由信息。这种设计既降低了重复分配资源的开销，又保证了路由的动态性。

图 2：NCCL EP 执行流程示意图。Group 在模型初始化时创建一次。随后在每个前向传播中，创建一个 Handle 封装路由信息，依次执行 Dispatch、专家计算（Expert FFN）、Combine 操作。分阶段（Staged）模式允许 Dispatch 和 Combine 的发送阶段与接收阶段重叠，实现计算与通信的流水线并行，这对于最大化 MoE 训练和推理场景的硬件利用率至关重要。

三、核心剖析：NCCL EP 的两大通信模式

NCCL EP 的另一精妙之处在于，它并非采用单一算法应对所有场景，而是在底层实现了两种高度优化的通信模式，并通过统一 API 暴露，以适应不同应用需求。

3.1 低延迟模式：为解码阶段优化

低延迟模式专为推理的解码阶段设计，此阶段批量通常很小（1-128个令牌），核心优化目标是降低延迟。

图 3：低延迟模式下的数据布局转换。它将二维的连续令牌输入，转换为三维的“专家主序”张量输出，便于后续高效计算。

核心设计：
* 全连接通信网格： 在集群内构建任意GPU间的直接通信路径，最小化通信跳数，以适配动态路由的高灵活性要求。
* 双缓冲通信： 使用两个内部缓冲区，实现发送与接收操作的流水线重叠，进一步提升通信效率。
* 内存占用优化： 相较于前代方案，实现了数量级的内存占用优化，为部署大规模MoE模型释放了更多显存空间。
* 3D专家主序布局： Dispatch操作的输出被组织为[本地专家数, 每专家令牌数, 隐藏维度]的三维张量。这种布局使属于同一专家的令牌在内存中连续存放，可直接作为批量或分组GEMM的输入，避免了额外的数据重排开销。

3.2 高吞吐模式：为训练与预填充设计

高吞吐模式面向训练和推理的预填充阶段，这些场景通常处理大批量数据（如4096个令牌以上），核心目标是最大化带宽利用率。

图 4：高吞吐模式下的输出布局。它输出一个二维的连续张量，并辅以独立的每专家令牌计数数组来标记数据边界。

核心设计：
* 分层通信策略： 充分利用服务器内的高速互联与跨节点网络。首先在NVLink域内聚合令牌，再通过RDMA进行节点间传输，有效提升大规模数据传输的效率。
* 高效硬件原语结合： 节点内通信利用Tensor Memory Accelerator进行高效数据搬运；跨节点通信则通过NCCL GIN原语实现GPU发起的直接RDMA。
* 2D连续布局与独立计数： Combine操作的输出是一个形状为[总接收令牌数, 隐藏维度]的二维连续张量，并附带一个记录各专家令牌数量的元数据数组。这种设计简化了内存管理，允许计算内核根据计数信息高效处理可变大小的专家批量。

3.3 性能对比

表 III：低延迟模式与高吞吐模式的设计对比

| 特性维度 | 低延迟模式 | 高吞吐模式 |
| :— | :— | :— |
| 目标场景 | 推理解码（小批量，1-128令牌） | 训练/预填充（大批量，4096+令牌） |
| 优化目标 | 极致延迟 | 极致吞吐与带宽利用 |
| 通信拓扑 | 全连接网状，直接通信 | 分层聚合，先节点内后节点间 |
| 输出布局 | 3D专家主序张量 | 2D连续张量 + 独立专家计数 |
| 归约方式 | 接收端逐令牌加权归约 | 分层归约 |
| 核心价值 | 最小化小批量处理延迟，直接对接分组GEMM | 优化大批量内存访问，支持可变批量计算 |

通过这两种模式分离的设计，NCCL EP能够以统一的API接口，同时满足MoE工作负载在延迟敏感型和吞吐敏感型场景下的极端性能要求。

四、底层支撑：NCCL Device API

NCCL EP的高性能实现，根本上得益于对NCCL Device API的全面应用。该API允许GPU内核直接发起通信，无需CPU介入，主要包含三个核心模块：

4.1 Load/Store Accessible
当通信GPU位于同一NVLink域内时，此模块允许GPU内核通过load/store指令直接访问对端显存，使通信延迟极低。

4.2 GPU-Initiated Networking
针对跨节点通信，此模块提供了一组设备端可调用的RDMA原语，使得GPU内核能直接将数据写入远端GPU显存，并完成通知。

4.3 Multiterm
提供在多个GPU间进行集体load/store操作的能力。

通过NCCL Device API，NCCL EP实现了真正的设备端通信，将CPU从关键数据路径中移除，使得通信与计算能在GPU内核中精细交织，这是实现MoE超低延迟与超高吞吐的关键。

五、生态整合：从训练到推理

一项技术的价值，很大程度上取决于其与现有主流生态系统的融合能力。NCCL EP 在设计之初便以无缝集成为目标，确保能够平滑接入当前主流的训练与推理框架。

5.1 Megatron-LM：训练框架集成

Megatron-LM 是大模型训练领域的标杆框架。NCCL EP 被集成为其 Flex 调度器的一个插件式后端。

图 6：NCCL EP 在 Megatron-LM Flex 调度器中的集成架构。NCCL EP（绿色部分）通过实现与原有 DeepEP（灰色部分）兼容的 API，成为其直接替代方案。

如图6所示，NCCL EP 通过实现与 DeepEP 完全兼容的 NCCLEPManager、NCCLEPDispatch 等 Autograd 函数以及 NCCLEPBuffer，实现了对原有通信后端的完全替换。这种“即插即用”的设计意味着用户无需修改模型代码或训练脚本，仅通过配置即可切换至 NCCL EP。其关键在于 NCCL EP 坚持统一的 API 和标准数据格式，显著降低了框架维护者和终端用户的迁移成本。

在具体实现中，NCCL EP 通过一个适配层，将 Megatron-LM 内部的多热（multi-hot）路由格式转换为自身所需的紧凑 top-k 格式，并确保了与 PyTorch 自动求导（Autograd）系统的无缝衔接，保障了反向传播过程中梯度的正确通信。

5.2 vLLM：推理框架集成

vLLM 是当前广泛使用的高性能推理框架，其 MoE 实现支持可插拔的 All-to-All 通信后端。NCCL EP 以新增后端的形式集成到 vLLM 中，并同时支持低延迟（LL）和分层拓扑（HT）两种通信模式。

通过一个统一的 NCCLEPBuffer 类，vLLM 可以在不同模式下复用同一套核心逻辑，仅在初始化时指定所采用的通信算法即可。这种集成方式使得开发者能够通过简单的配置文件修改，将底层通信库从 DeepEP 切换至 NCCL EP，从而利用 NCCL 生态的成熟性与性能优势。

六、相关工作与定位

NCCL EP 的诞生与发展离不开相关领域优秀工作的启发。通过对比，可以更清晰地理解其技术定位与独特价值。

| 类别 | 代表性工作 | 核心技术与定位 | 与 NCCL EP 的关系 |
| :— | :— | :— | :— |
| 设备端发起库 | DeepEP | 基于 NVSHMEM/IBGDA，追求极致性能的开源方案。 | NCCL EP 借鉴其低延迟（LL）模式思想，统一 API 并将其后端替换为 NCCL。 |
| | pplx-kernels | 同样基于 NVSHMEM/IBGDA，专为推理优化（集成于 vLLM）。 | 性能相当但生态独立，NCCL EP 未直接集成，而是提供替代方案。 |
| | Hybrid-EP | 采用 TMA/IBGDA 实现分层通信。 | NCCL EP 借鉴其分层拓扑（HT）模式设计，并将 IBGDA 替换为 NCCL。 |
| 可移植方案 | UCCL-EP | 依赖 CPU 代理与 GPUDirect RDMA，适配 EFA 等非 IB 网卡。 | NCCL EP 聚焦 NVIDIA 生态，直接利用 NCCL 实现跨平台统一性与可移植性。 |
| 框架级方案 | NCCLX AllToAllvDynamic | 自定义 NCCL 实现，支持超大规模（10万+ GPU）动态通信。 | NCCL EP 基于标准 NCCL 进行扩展，而非替换，更易于维护与开源协作。 |
| AMD 生态 | MORI | 基于 rocSHMEM 的 AMD GPU 直接通信方案。 | NCCL EP 当前专注于 NVIDIA 生态，暂不兼容 AMD 平台。 |

从对比中可见，NCCL EP 的独特定位在于扮演“整合者”的角色。它并非旨在颠覆现有方案，而是将 DeepEP 的低延迟思想与 Hybrid-EP 的分层拓扑思想等关键优化，融入并构建于标准的 NCCL 生态之上，通过一套统一的 API 为用户提供在 NVIDIA 平台上更原生、更易用的 MoE 通信解决方案。

七、性能评估

论文中的实验评估验证了 NCCL EP 的性能表现。测试基于先进的 NVIDIA EOS 集群，每个节点配备 8 张 H100 80GB GPU，通过 NVLink（900 GB/s）和 400 Gb/s InfiniBand 互联。

表 VI：性能评估实验的硬件平台配置。

低延迟（LL）模式性能：在分发（Dispatch）操作上，NCCL EP 的吞吐量与 DeepEP 相当。在单节点和小规模场景下略低，但在 8 节点（64 GPU）规模时优势开始显现，证明了基于 NCCL 实现路径的高效性与良好的扩展性。

图 7：低延迟分发吞吐量对比（NCCL EP vs. DeepEP）。多节点下 NCCL EP 表现匹配甚至更优。

在收集（Combine）操作上，NCCL EP 在 1 至 4 节点规模时性能落后 DeepEP 约 5-12%，但在 8 节点时基本持平。这表明在更复杂的归约通信模式上，NCCL EP 仍有优化空间，未来可通过优化接收端流水线等方式进一步提升。

图 8：低延迟合并吞吐量对比（NCCL EP vs. DeepEP）。

此外，在端到端的 vLLM 推理测试中，NCCL EP 也展现了令人满意的性能，能够有效支撑生产级推理场景。

表 VII 展示了 NCCL EP 与 DeepEP 在真实推理框架 vLLM 中的端到端性能对比。结果显示，在 Qwen3-30B-A3B 模型上，NCCL EP 的吞吐量和延迟指标（ITL/TPOT）比 DeepEP 落后约 7-10%。这一差距比纯内核测试更为显著，表明在实际应用环境中，除了底层通信，框架集成开销、调度策略等因素也被放大。作者指出，这并非由通信后端（GIN vs NVSHMEM）的差异直接导致，而与之前观察到的 Combine 内核性能差距有关。这为未来的工作指明了方向：不仅需要继续优化内核，还需从端到端的角度审视整个数据流，以实现与生产级系统更完美的融合。

尽管在吞吐量和延迟上仍与 DeepEP（基于 NVSHMEM）有约 10%的差距，但这差距是可以理解的。

• 首先，NCCL EP 是一个更年轻的项目，优化仍在进行中。
• 其次，正如论文中所指出的，DeepEP 在 Combine 操作上的开销更小，而 NCCL EP 的 Combine 操作目前是性能瓶颈所在。这部分是未来优化的重点。

NCCL EP 的论文以坦诚的态度总结了现状：“NCCL EP is currently an experimental API ”，并指出“training performance remains limited by ongoing high-throughput kernel optimization”。这反而让我们对它的未来充满期待。一个由 NVIDIA 主导，能够持续迭代、不断优化的官方 MoE 通信库，其潜力是巨大的。

总结

NCCL EP 的诞生，是 AI 基础设施领域一次重要的“整合”和“收敛”。它告诉我们，当一种新的计算模式（如 MoE）开始普及，与之配套的通信基础设施也需要从“野蛮生长”走向“标准化”。NCCL EP 以其统一的 API、原生集成、设备端发起通信和双模式优化 ，为我们描绘了未来 MoE 模型在 NVIDIA GPU 上部署的理想蓝图。

对于广大 AI 从业者和开发者而言，NCCL EP 的出现意味着：

• 开发更简单：无需学习多个 MoE 通信库的 API，一套 NCCL EP 搞定所有场景。
• 部署更安心：基于 NCCL 这个成熟稳定的通信库，享受其生态红利。
• 性能有保障：底层直接利用 NVIDIA 硬件的最高特性（NVLink, RDMA），性能表现可与专用库比肩。

虽然目前 NCCL EP 还是一个实验性的 API，高吞吐模式的优化也仍在路上，但它所代表的统一化、原生化的技术方向，无疑是正确的。可以预见，随着 NCCL EP 的不断完善和推广，它将有望成为 MoE 大模型时代的“通信标准”，为更大规模、更高效的模型训练和推理提供坚实的底层支持 。我们期待看到，这个诞生于 NCCL 原生生态的“新生儿”，在未来的 AI 大舞台上，能够展现出更强大的生命力。

关注“鲸栖”小程序，掌握最新AI资讯