RDMA POINT-TO-POINT COMMUNICATION FOR LLM SYSTEMS

发表时间: 2025-10 · arXiv:2510.27656

原文: https://arxiv.org/abs/2510.27656

作者/机构: Nandor Licker, Kevin Hu, Vladimir Zaytsev, Lequn Chen

速读

一句话结论 本文提出了可移植的 RDMA 点对点通信库 TransferEngine，通过统一异构网络硬件的无序交付机制打破了云厂商硬件锁定，在解耦式推理、强化学习权重更新和混合专家模型路由中实现了业界领先的通信性能。

要解决什么问题 原有大语言模型系统高度依赖 NCCL 等集体通信库，这类库要求通信成员固定、必须同步初始化且传输缓冲区大小统一，导致解耦式推理、混合专家模型（MoE）路由和异步强化学习微调等需要动态、稀疏点对点通信的场景卡在灵活性上。虽然基于远程直接内存访问（RDMA）的点对点通信能解决此问题，但现有高性能实现（如 NVSHMEM）深度绑定特定硬件。具体而言，传统硬件（如 NVIDIA ConnectX）的 RC 协议提供有序交付，而云厂商硬件（如 AWS EFA）的 SRD 协议本质是无序交付。这种底层机制的割裂导致开发者无法用一套代码在不同云环境中榨干网络带宽，严重制约了新兴模型架构的跨平台部署。

怎么做的 核心思路是放弃对网络消息有序到达的依赖，提取异构 RDMA 硬件“可靠但无序交付”的共性，构建统一的点对点通信抽象层 TransferEngine。为绕开底层协议在排序保证上的差异，该方法引入了核心原语 IMMCOUNTER。它不依赖操作顺序，而是通过轮询底层完成队列并在批量接收到带有立即数的数据后递增计数器，以原子化方式向接收方传递完成通知。在架构上，TransferEngine 为每个 GPU 分配固定在同 NUMA 节点的工作线程，透明管理多个网络接口控制器（NIC），将单次传输切片并负载均衡到多个网卡上，从而在 AWS 实例上聚合四个 100 Gbps 网卡跑满 400 Gbps 带宽。其关键部件包括：第一，双边 SEND/RECV 接口，通过循环缓冲区池处理小载荷的 RPC 风格通信；第二，单边 WRITE 接口，支持零拷贝的连续或分页内存写入；第三，统一虚拟内存观察者（UVM Watcher），通过在内存中分配标志位让 CPU 线程持续轮询 GPU 状态，一旦检测到 GPU 内核执行进展就立即触发网络传输，在缺乏硬件级异步通信支持的设备上实现了计算与通信重叠。针对 MoE 路由场景，方法进一步设计了基于主机代理的调度与合并机制，先交换极小的路由信息并投机性地将少量令牌发送到私有缓冲区以隐藏网络延迟，随后再将大批量令牌直接写入连续的共享接收缓冲区，避免了为每个 rank 分配上限为 $N \cdot T \cdot \max(R, E)$（其中 $N$ 为 rank 数，$T$ 为令牌数，$R$ 和 $E$ 为路由专家和总专家数）的庞大独立接收缓冲区，大幅减少了内存占用和写入次数。

效果如何 实验在配备 8 块 H200 GPU 的节点上进行，网络硬件对比了单卡 400 Gbps 的 ConnectX-7 和双卡 200 Gbps 的 EFA。对比基线包括英伟达官方点对点库 NIXL、基于 NVSHMEM 的 pplx-kernels，以及代表 MoE 路由最高水平但深度绑定 ConnectX 的 DeepEP。在基础通信中，TransferEngine 仅需 64 KiB 分页写入即可跑满带宽，性能略优于 NIXL。在异步强化学习微调中，该方法通过全网卡并行的单边写入，将万亿参数模型从 256 张训练卡到 128 张推理卡的权重更新时间压缩至 1.3 秒，比现有全局集体通信框架快 100 倍以上。在 MoE 解码路由测试中，该方法在 16 和 32 卡节点间场景下击败 DeepEP 创下 ConnectX-7 最低延迟纪录，同时首次让 EFA 具备了可用性（延迟仅比 ConnectX-7 高 30%），且比 pplx-kernels 快一个数量级。代价与局限在于：由于高度依赖主机 CPU 代理，扩展到 64 卡时 CPU 调度开销会显著增加；此外，这套为解码优化的内核在处理大批量预填充任务时，因未像 DeepEP 那样利用 NVLink 进行节点内局部求和来减少网络传输量，存在较高内存开销，预填充延迟不如 DeepEP。

A1 主要贡献

本文旨在解决新兴大语言模型（LLM）系统中点对点通信的硬件可移植性问题。

A3 背景知识与相关工作 (缩写)

2.1 网络技术

2.2 编程接口

2.3 相关工作

A2 方法细节 (缩写)

3 TRANSFERENGINE

TransferEngine是一个基础库，它通过抽象异构硬件，在一个简单的协议下实现高效的基于RDMA的点对点通信。它暴露了SEND/RECV操作来实现类似RPC的接口。对于KvCache传输，它提供分页WRITEs用于批量写入。对于RL权重传输，它暴露了低延迟高吞吐的WRITE操作。对于MoE路由，它特化了针对多个对端的WRITEs，以实现低延迟的SCATTER和BARRIER操作。所有操作之间没有任何排序保证。一个立即数可以与WRITEs关联，在接收方收到数据后递增一个计数器。

图1. TransferEngine管理跨NUMA节点的GPU，每个GPU带多个NIC。命令被转发给工作线程，工作线程响应回调处理器或IMMCOUNTER。
图1. TransferEngine管理跨NUMA节点的GPU，每个GPU带多个NIC。命令被转发给工作线程，工作线程响应回调处理器或IMMCOUNTER。
3.1 概述和设计目标
3.2 架构
3.3 API 设计

TransferEngine暴露的API（如图2所示）实现了对RDMA的抽象：

#[serde] struct NetAddr(Bytes);
#[serde] struct MrDesc{ ptr: u64, rkeys: Vec<(NetAddr, u64)> }
struct MrHandle(NonNull<c_void>);
type Offset = u64;
struct Pages{ indices: Vec<u32>, stride: u64, offset: Offset }
struct PeerGroupHandle(u64);
struct ScatterDst{ len: u64, src: Offset, dst: (MrDesc,Offset)}
enum OnDone { Callback(fn () -> ()), Flag(Atomic<bool>) }

trait TransferEngine {
    fn main_address() -> NetAddr;
    // 内存区域管理
    fn reg_mr(ptr, len, device) -> (MrHandle, MrDesc);
    // 双边 Send/Recv
    fn submit_send(addr: NetAddr, msg: &[u8], cb: fn () -> ());
    fn submit_recvs(len: u64, cnt: u64, cb: fn (&[u8]) -> ());
    // 单边 Write
    fn expect_imm_count(imm: u32, count: u32, cb: fn () -> ());
    fn submit_single_write(len: u64, imm: Option<u32>,
                           src: (MrHandle, Offset),
                           dst: (MrDesc, Offset), OnDone);
    fn submit_paged_writes(page_len: u64, imm: Option<u32>,
                           src: (MrHandle, Pages),
                           dst: (MrDesc, Pages), OnDone);
    // 对一组对端的单边 Write
    fn add_peer_group(addrs: Vec<NetAddr>) -> PeerGroupHandle;
    fn submit_scatter(h: Option<PeerGroupHandle>, OnDone,
                      imm: Option<u32>, src: MrHandle,
                      dst: Vec<ScatterDst>);
    fn submit_barrier(h: Option<PeerGroupHandle>, OnDone,
                      imm: u32, dst: Vec<MrDesc>);
    // 用于 CPU-GPU 同步的观察者
    fn alloc_uvm_watcher(cb: fn(u64,u64) -> ()) -> NonNull<u64>;
}
3.4 实现
3.5 硬件特定优化

TransferEngine内的DOMAIN针对其控制的硬件进行了特化和优化：

4 KVCACHE TRANSFER

本节概述了一个依赖TransferEngine、经过生产测试的解耦式推理实现。在解耦模式下，一个预填充（prefiller）节点对输入令牌运行预填充，并将生成的KV页以及任何额外上下文（如用于推测解码的最后一个令牌的隐藏状态和logits）传输到解码器（decoder）节点，解码器节点随后逐个解码令牌。

图3. 预填充器和解码器之间的KV传输
图3. 预填充器和解码器之间的KV传输
图4. 不同方法的权重传输数据路径。
图4. 不同方法的权重传输数据路径。
图5. 流水线化的权重传输执行。
图5. 流水线化的权重传输执行。

5 RL ROLLOUT WEIGHT TRANSFER

在异步强化学习微调中，训练和推理在不同的GPU上运行。每次训练步骤后，新权重必须被推送到推理节点，对于万亿参数模型，使用现有框架可能需要几十到几百秒。我们的解决方案为Kimi-K2（1T参数）、DeepSeek V3（671B）和Qwen3（235B）等规模的模型实现了1.3秒的跨机器参数更新【12, Kimi Team et al., Kimi k2: Open agentic intelligence, 2025】【6, DeepSeek-AI et al., Deepseek-v3 technical report, 2025】【37, Yang et al., Qwen3 technical report, 2025】，将权重从256个训练GPU（bf16）传输到128个推理GPU（fp8）。

5.1 点对点权重传输
5.2 流水线化权重传输执行

6 MOE DISPATCH/COMBINE

我们介绍了一套围绕TransferEngine构建的用于MoE调度和合并的低延迟内核，它依赖一个主机代理线程来协调GPU和NIC。在节点内，我们还利用NVLink来减少网络负载。尽管代理线程增加了延迟，我们在保持预填充性能有竞争力且无需任何调整的情况下，实现了业界领先的解码性能。这些内核展示了基于代理的MoE调度在支持更广泛网络卡（如EFA）上的可行性。因此，我们专注于解码性能（每个rank 128个token），因为它受延迟限制，并且更容易受到跨设备增加的PCIe、驱动和固件开销的影响。

图6. Dispatch和Combine的GPU-CPU-NIC协调
图6. Dispatch和Combine的GPU-CPU-NIC协调
6.1 架构
6.2 Dispatch
6.3 Combine
6.4 与DeepEP的比较

A4 实验环境 (总结)

A5 实验结果 (总结)

7.1 点对点通信

7.2 MoE调度/合并

7.2.1 私有缓冲区大小的影响 (图9)
7.2.2 发送和接收延迟 (图10)
7.2.3 解码延迟 (图11)
7.2.4 预填充延迟 (图12)

A6 结论 (总结)

现有的用于LLM系统的RDMA解决方案存在供应商锁定问题，尤其是在AWS EFA等定制云硬件上缺乏可行的实现。本文提出的TransferEngine通过识别异构RDMA硬件间的共同功能（可靠但无序的交付）来解决这一问题。通过在底层协议之上构建一个不依赖排序保证的可靠抽象层，我们透明地将支持扩展到多种RDMA NIC，特别是EFA和ConnectX。

我们通过三个生产系统展示了这种方法的有效性：用于解耦式推理的KvCache传输、为万亿参数模型实现1.3秒更新的RL权重更新，以及在ConnectX-7上实现业界领先延迟并在AWS EFA上首次实现可行性能的MoE调度/合并。TransferEngine为现代LLM架构提供了可移植的点对点通信能力，在补充集体通信库的同时，避免了供应商锁定，尤其适用于云原生部署。