1. 论文基本信息

1.1. 标题

RDMA 点对点通信在大型语言模型 (LLM) 系统中的应用 (RDMA Point-to-Point Communication for LLM Systems)

1.2. 作者

Nandor Licker, Kevin Hu, Vladimir Zaytsev, Lequn Chen 所属机构均为未明确标注的“1”。

1.3. 发表期刊/会议

未明确标注发表期刊或会议。

1.4. 发表年份

2025年10月31日

1.5. 摘要

新兴的大型语言模型 (LLM) 系统模式，如分解推理 (disaggregated inference)、专家混合 (Mixture-of-Experts, MoE) 路由和异步强化微调 (asynchronous reinforcement fine-tuning)，需要超越简单集体通信 (collectives) 的灵活点对点通信 (point-to-point communication)。现有的实现方案通常与特定的网络接口控制器 (NIC) 绑定，这阻碍了它们集成到推理引擎中以及在不同硬件提供商之间的可移植性。

本文介绍了 TransferEngine，它通过桥接常见 NIC 的功能来暴露一个统一的接口。TransferEngine 提供了带有 ImmCounter 原语的单边 WRITEIMM 操作，用于完成通知，而不依赖网络传输的顺序保证，并透明地管理每个 GPU 上的多个 NIC。作者展示了 TransferEngine 在 NVIDIA ConnectX-7 和 AWS Elastic Fabric Adapter (EFA) 上均能达到 400 Gbps 的峰值吞吐量。

通过三个生产系统展示了 TransferEngine 的能力：

1. 用于分解推理和动态扩展的 KvCache 传输。

2. 万亿参数模型的强化学习 (RL) 权重更新，实现了 1.3 秒的更新时间。

3. MoE 调度/合并 (dispatch/combine) 实现，在 ConnectX-7 上超越了 DeepEP 的解码延迟，并在 EFA 上首次实现了可行的延迟。

   作者证明，他们的可移植点对点通信方案能够补充集体通信，同时避免供应商锁定。

1.6. 原文链接

https://arxiv.org/abs/2510.27656 PDF 链接: http://arxiv.org/pdf/2510.27656v1 发布状态: 预印本 (arXiv preprint)

2. 整体概括

2.1. 研究背景与动机

2.1.1. LLM 发展带来的新通信需求

大型语言模型 (LLM) 的快速发展带来了新的系统模式，例如：

• 分解推理 (Disaggregated Inference)：将 LLM 推理过程中的不同阶段（如预填充 prefill 和解码 decode）分离到不同的设备上运行。

• 专家混合 (Mixture-of-Experts, MoE) 路由：模型结构中包含多个专家网络，根据输入动态选择部分专家进行计算。

• 异步强化微调 (Asynchronous Reinforcement Fine-tuning)：训练和推理过程在不同设备上异步进行，需要高效地同步模型权重。

  这些新模式的共同特点是需要灵活的、动态的、非标准化的通信模式，这与传统 LLM 框架普遍依赖的集体通信 (collective communication) 方式（如 NCCL 或 torch.distributed）形成了冲突。集体通信虽然适用于静态的、数据并行或模型并行等模式，但存在以下局限性：

1. 固定成员资格 (Fixed Membership)：需要预先知道所有参与者，阻碍了动态扩展 (dynamic scaling)。
2. 同步初始化 (Synchronized Initialization)：要求所有参与者进行全局协调才能形成“通信世界”，增加了初始化开销。
3. 操作顺序 (Operation Ordering)：强制所有参与者就操作序列达成一致，即使在某些情况下不需要严格顺序，也需要额外的同步。
4. 形状统一性 (Shape Uniformity)：限制了所有参与者之间传输数据的大小，即使对于点对点通信也是如此。

2.1.2. 现有 RDMA 方案的局限性与供应商锁定

高性能计算 (HPC) 领域长期使用基于远程直接内存访问 (RDMA) 的原语（SEND、RECV、WRITE）来实现灵活的低延迟、高带宽传输。然而，这些强大的原语在 LLM 框架中却很少被利用。主要障碍在于硬件的多样性缺乏统一的抽象：

• 硬件异构性：云服务提供商部署了不同的 RDMA 实现。例如，NVIDIA ConnectX NICs 使用传统的可靠连接 (Reliable Connection, RC) 传输协议，提供按序交付；而 AWS Elastic Fabric Adapter (EFA) 实现了专有的可扩展可靠数据报 (Scalable Reliable Datagram, SRD) 协议，其特点是可靠但无序交付。
• 供应商锁定 (Vendor Lock-in)：现有的解决方案往往与特定供应商绑定。
  • DeepEP 需要仅 ConnectX 提供的 GPU 启动 RDMA (IBGDA)。
  • NVSHMEM 在 EFA 上性能严重下降。
  • Mooncake 和 NIXL 等最新库要么不支持 EFA，要么对 EFA 的支持仍处于初步阶段。 因此，目前缺乏在不同云提供商之间可行的 LLM 推理解决方案。

2.1.3. 论文的切入点

本文的切入点在于解决 RDMA 硬件多样性带来的可移植性问题。核心洞察是：ConnectX 的 RC 协议可以忽略顺序保证，而 EFA 的 SRD 协议本身就是无序的。这意味着“可靠但无序的交付”是这两种异构 RDMA 硬件的共同功能。通过利用这一共同点，可以构建一个统一的抽象层。

2.2. 核心贡献/主要发现

本文的主要贡献是提出了 TransferEngine，一个可移植的 RDMA 通信库，并验证了其在 LLM 生产系统中的有效性：

1. 统一的 RDMA 抽象层：TransferEngine 桥接了不同 RDMA 硬件（如 NVIDIA ConnectX-7 和 AWS EFA）的功能，提供了一个统一的接口，从而实现了可移植性，避免了供应商锁定。
2. 创新的完成通知原语：引入了 ImmCounter 原语，用于在 WRITEIMM 操作中进行完成通知。这个原语不依赖网络传输的顺序保证，克服了 EFA SRD 无序交付的挑战。
3. 透明的多 NIC 管理：TransferEngine 能够透明地管理每个 GPU 上的多个 NIC，这对于在某些平台上（如 AWS p5 实例上聚合多个 EFA NIC 达到高带宽）至关重要。
4. 卓越的性能：在 NVIDIA ConnectX-7 和 AWS EFA 上均展示了 400 Gbps 的峰值吞吐量。
5. 生产系统中的应用和验证：
   • KvCache 传输：在分解推理中实现了 KvCache 的高效传输，支持动态扩展，且兼容 CUDA Graph，实现了低延迟的逐层传输。
   • 强化学习 (RL) 权重更新：通过点对点 RDMA WRITE 直接从训练 GPU 到推理 GPU，实现了万亿参数模型 1.3 秒的权重更新，比现有框架快 100 倍以上，并利用了集群的全部带宽。
   • MoE 调度/合并 (Dispatch/Combine)：在 ConnectX-7 上实现了超越 DeepEP 的解码延迟，并且是在 EFA 上首次实现了可行的 MoE 实现。
6. 点对点通信的价值：证明了灵活的点对点通信能够有效补充集体通信，满足现代 LLM 工作负载的需求，并且通过可移植的抽象可以避免供应商锁定。

3. 预备知识与相关工作

本节旨在为读者提供理解 TransferEngine 工作原理及其在 LLM 系统中应用的必要背景知识。

3.1. 基础概念

3.1.1. 大型语言模型 (LLM) 系统模式

• 分解推理 (Disaggregated Inference)：一种将 LLM 推理过程中的不同阶段（通常是预填充 prefill 和解码 decode）分离到不同计算节点或设备上执行的架构。预填充阶段处理输入提示 (prompt) 并生成 KV 缓存 (KvCache)，解码阶段则利用 KvCache 逐个生成输出词元 (token)。这种分离允许独立扩展或优化每个阶段，提高资源利用率和吞吐量。
• 专家混合 (Mixture-of-Experts, MoE) 路由：一种神经网络架构，其中模型包含多个“专家”子网络。对于给定的输入，一个门控网络 (gating network) 会选择一个或多个专家来处理该输入。这种架构允许模型拥有巨大的参数量（即“稀疏激活”），同时保持计算成本相对较低，因为它只激活模型的一小部分。路由 (routing) 指的是将输入数据发送到选定专家的过程，而 调度 (dispatch) 和 合并 (combine) 是 MoE 中涉及数据在专家之间传输和结果聚合的关键通信步骤。
• 异步强化微调 (Asynchronous Reinforcement Fine-tuning)：一种强化学习 (RL) 训练范式，其中模型（通常是 LLM）的训练和推理（或数据收集 rollout）过程在不同的计算设备上并行且异步地进行。训练设备负责更新模型权重，而推理设备负责使用当前权重生成数据。为了保持模型一致性，需要高效地将训练好的新权重从训练设备传输到推理设备。异步 (asynchronous) 意味着这些过程不必严格同步等待彼此完成，从而提高了效率。

3.1.2. 通信范式

• 集体通信 (Collective Communication)：指涉及通信组中所有（或大部分）进程的通信操作，例如广播 (broadcast)、规约 (reduce)、全规约 (all-reduce)、散射 (scatter)、聚集 (gather) 等。这些操作通常在分布式训练中用于同步模型参数或梯度。例如，NCCL (NVIDIA Collective Communications Library) 和 torch.distributed 是 LLM 框架中最常用的集体通信库。
• 点对点通信 (Point-to-Point Communication)：指两个特定进程或设备之间直接进行的通信操作。与集体通信不同，点对点通信不涉及整个通信组，而是专注于一对一的数据传输。SEND 和 RECV 是典型的点对点操作。本文强调，对于 LLM 的新系统模式，点对点通信提供了比集体通信更高的灵活性和更低的开销。

3.1.3. RDMA 技术

• RDMA (Remote Direct Memory Access)：远程直接内存访问。这是一种网络技术，允许网络适配器 (NIC) 直接访问远程计算机的内存，而无需 CPU 的介入。这极大地减少了数据传输的延迟和 CPU 开销，因为数据路径绕过了操作系统内核（即 kernel bypass），并消除了中间的内存拷贝（即 zero-copy）。RDMA 是现代高性能计算系统和数据中心网络的关键技术。
• NIC (Network Interface Controller)：网络接口控制器，俗称网卡。它是计算机连接到网络的硬件组件。在 RDMA 环境中，NIC 具备特殊的硬件功能，可以直接读写远程内存。
• RDMA 操作：
  • 两边操作 (Two-sided Operations)：需要发送方和接收方都参与协调的通信模式。典型的例子是 SEND（发送）和 RECV（接收）。发送方发起 SEND 操作，接收方必须提前或同步地 POST 一个 RECV 请求，指定一个注册过的内存区域来接收数据。接收方通过完成队列 (completion queue) 收到通知。
  • 单边操作 (One-sided Operations)：只需要发送方参与，接收方无需显式地 POST 接收请求即可完成数据传输。发送方知道接收方内存的地址和访问权限（通过 RKEY，即 Remote Key），可以直接将数据写入或从远程内存中读取数据。
    • WRITE：最基本的单边操作，将本地内存的数据写入远程内存。
    • WRITEIMM (Write with Immediate)：WRITE 操作的扩展，除了数据传输外，还会发送一个 32 位的“即时值 (immediate value)”，这个值会通过接收方的完成队列通知接收方，而不需要接收方进行额外的 READ 操作。
    • READ：单边读取远程内存的数据到本地内存。
    • Atomic 操作：单边原子操作，如原子比较并交换 (Compare-and-Swap) 或原子加 (Fetch-and-Add)，用于在远程内存上执行原子性的修改。本文指出 READ 和 Atomic 操作的延迟不适合其目的。

3.1.4. RDMA 传输协议

• Reliable Connection (RC)：可靠连接。RDMA 规范中最常用的传输协议之一。它提供可靠的、按序的 (in-order) 数据交付，并且是基于连接的。ConnectX NICs 主要使用 RC。

• Unreliable Connection (UC)：不可靠连接。提供不可靠、无序的数据交付，但也是基于连接的。

• Unreliable Datagram (UD)：不可靠数据报。提供不可靠、无序的数据交付，并且是无连接的。

• Scalable Reliable Datagram (SRD)：可扩展可靠数据报。AWS EFA 实现的专有协议。它提供可靠的 (reliable) 数据交付，但本质上是无序的 (out-of-order)。这是本文 TransferEngine 设计的关键点，因为它必须适应这种无序特性。

  以下是论文中 Table 1 的数据转录：

  	RC	UC	UD	SRD	Ours
  Reliability	✓	✗	✗	✓	✓
  Ordering	✓	✗	✗	✗	✗
  Connection	✓	✓	✗	✗	✗
  SEND/RECV	✓	✓	MTU	✗	✓
  WRITEImm	✓	✓	✗	✓	✓
  READ	✓	✗	✗	✗	✗
  Atomic	✓	✗	✗	✗	✗

以下是原文 Table 1 的解释：

• Reliability (可靠性)：数据是否保证被送达。RC、SRD 和 TransferEngine 都提供可靠性。UC 和 UD 不提供。
• Ordering (顺序性)：数据是否保证按发送顺序交付。RC 提供顺序性。UC、UD、SRD 和 TransferEngine 都不提供或不依赖顺序性。
• Connection (连接性)：是否需要建立连接。RC 和 UC 是基于连接的。UD、SRD 和 TransferEngine 是无连接的。
• SEND/RECV：是否支持两边发送/接收操作。RC 和 UC 支持。UD 仅支持 MTU (Maximum Transmission Unit) 大小的数据报。SRD 和 TransferEngine 不支持原生两边 SEND/RECV，但 TransferEngine 提供了封装。
• WRITEImm：是否支持带即时值的单边写入操作。RC、UC、SRD 和 TransferEngine 都支持。
• READ：是否支持单边读取操作。RC 支持。其他协议和 TransferEngine 不支持或不优先使用。
• Atomic：是否支持单边原子操作。RC 支持。其他协议和 TransferEngine 不支持。

3.1.5. GPU 内存技术

• GPUDirect RDMA：NVIDIA 技术，允许 RDMA NIC 直接访问 GPU 内存（通过 PCIe），从而消除 CPU 内存拷贝和 CPU 参与，进一步降低延迟。
• GPUDirect Async (IBGDA)：GPUDirect RDMA 的一个扩展，允许 GPU 本身直接发起 RDMA 传输，进一步绕过 PCIe 开销。目前仅 ConnectX NICs 支持。
• UVM (Unified Virtual Memory)：统一虚拟内存。NVIDIA CUDA 提供的内存管理功能，允许 CPU 和 GPU 共享同一个虚拟地址空间，简化了编程模型。
• GDRCopy (GPUDirect RDMA Copy)：一个库，用于在 GPUDirect RDMA 可用的系统上实现低延迟的 CPU 到 GPU (host-to-device) 或 GPU 到 CPU (device-to-host) 的内存拷贝。

3.1.6. LLM 特定概念

• KvCache：在自回归 LLM 推理中，模型会缓存之前计算的 Key (K) 和 Value (V) 向量（即 KvCache）。这避免了在生成每个新词元时重复计算历史信息，从而提高推理效率。KvCache 传输是分解推理的关键部分。
• 词元 (Token)：LLM 处理文本的基本单位，可以是单词、子词或字符。
• fp8, bf16, fp32：浮点数格式。
  • fp32 (single-precision floating-point)：标准的32位浮点数，提供高精度。
  • bf16 (bfloat16)：16位浮点数格式，通常用于深度学习训练，精度低于 fp32 但范围与 fp32 相同，可以节省内存和计算资源。
  • fp8 (float8)：8位浮点数格式，用于进一步降低内存和计算需求，尤其适用于推理。

3.1.7. 分布式训练技术

• FSDP (Fully Sharded Data Parallel)：PyTorch 提供的一种数据并行策略，它将模型参数、梯度和优化器状态分片 (shard) 到不同的 GPU 上，而不是复制完整的模型。这允许训练更大的模型，因为每个 GPU 只需存储模型的一部分。
• Gloo：一个用于分布式机器学习的通信库，由 Facebook 开发。它支持各种集体通信操作，并可以在 CPU 和 GPU 上运行。在本文中，它用于跨 MeshGroup 的全局屏障同步。

3.2. 前人工作

作者在相关工作中提及了多个与 TransferEngine 目标和功能相关的研究：

• 分解推理 (Disaggregated Inference)：

  • Splitwise (Patel et al., 2024)、DistServe (Zhong et al., 2024) 和 Mooncake (Qin et al., 2025) 是早期展示分解推理架构优势的工作，它们将 LLM 推理的预填充和解码阶段分离到不同的设备上。本文的 KvCache 传输用例正是这一范式的实现，通过 TransferEngine 将预填充和解码集群通过 RDMA 连接。

• 点对点网络库 (Point-to-Point Network Libraries)：

  • NVSHMEM (Langer et al., 2021)：提供集体操作以及灵活的点对点通信。支持 GPU 启动 (IBGDA) 和主机代理通信 (IBRC)。然而，本文指出 NVSHMEM 在 EFA 上性能严重下降。
  • NVIDIA Inference Xfer Library (NIXL) (NVIDIA, 2025)：旨在为 LLM 推理提供点对点通信，基于 UCX。本文指出 NIXL 对 EFA 的支持仍处于初步阶段 (v0.6.1, 2025年10月)。
  • Mooncake (Qin et al., 2025)：也提供 RDMA 传输引擎，但缺乏对 EFA 的支持。
  • 其他库如 UCCL (Zhou et al., 2025) 和 MSCCL++ (Shah et al., 2025) 专注于集体通信的网络层优化，而非点对点通信。

• 分布式 KvCache 存储 (Distributed KvCache Storage)：

  • Mooncake Store 和 DeepSeek 3FS (DeepSeek AI, 2025) 提供了 KvCache 的分布式存储解决方案，但目前也缺乏对 EFA 的支持。本文的方法通过提供可移植的 RDMA 原语来补充这些系统，使其适用于云部署。

• 计算-通信重叠 (Compute-Communication Overlapping)：

  • Flux (Chang et al., 2024)、COMET (Zhang et al., 2025)、Zheng et al., 2025a,b 等研究侧重于 LLM 内核中计算与集体通信的重叠。本文的工作与此正交，但 TransferEngine 确实支持后台传输。

• LLM 框架：

  • 本文指出 TransferEngine 和 MoE 内核可以集成到 vLLM (Kwon et al., 2023)、SGLang (Zheng et al., 2024)、TensorRT-LLM (NVIDIA, 2023)、FlashInfer (Ye et al., 2025) 等 LLM 推理框架和内核库中。
  • 其点对点权重更新方法可以被 Slime (Wu et al., 2025)、OpenRLHF (Hu et al., 2025a)、AReaL (Mei et al., 2025)、veRL (Fu et al., 2025)、LlamaRL (Sheng et al., 2024)、NVIDIA Nemo (Hu et al., 2025a) 等强化学习框架采用。

3.3. 技术演进

LLM 系统的通信需求正从早期静态的、以集体通信为主的模式，演进到对动态、灵活点对点通信的迫切需求。

• 早期阶段 (Collective-centric)：LLM 训练和推理主要依赖 NCCL 等库提供的集体操作，适用于数据并行和模型并行。
• 新LLM架构驱动 (New LLM Architectures Drive)：随着 MoE、分解推理和异步 RL 微调等架构的出现，需要更细粒度、更具弹性的通信方式来处理稀疏、动态的数据流和异步更新。
• 硬件异构性挑战 (Hardware Heterogeneity Challenge)：不同的云服务提供商部署了不同的 RDMA 硬件（如 NVIDIA ConnectX 和 AWS EFA），它们具有不同的协议特性（如顺序性）。这导致了现有高性能通信库的供应商锁定和可移植性问题。
• 统一抽象层的需求 (Need for Unified Abstraction)：为了在异构硬件上实现高性能和可移植性，需要一个能够抽象底层硬件差异，并提供统一接口的通信层。TransferEngine 正是这一演进路径上的关键一步，它识别并利用了不同 RDMA 协议中“可靠但无序”的共同特性，构建了一个跨硬件的通用抽象。

3.4. 差异化分析

TransferEngine 与相关工作的核心差异和创新点在于其跨异构 RDMA 硬件的可移植性和对无序交付的创新处理：

• 与现有 RDMA 库的对比：

  • NVSHMEM：虽然提供点对点通信，但在 AWS EFA 上性能严重下降，无法提供跨平台的高性能。TransferEngine 在 EFA 上实现了可行的性能。
  • NIXL 和 Mooncake：这两个新近的库虽然也提供 RDMA 传输引擎，但 NIXL 对 EFA 的支持仍是初步，Mooncake 则完全不支持 EFA。TransferEngine 是第一个在 EFA 上实现生产级性能的解决方案。
  • DeepEP：专注于 ConnectX NICs，依赖于其独有的 GPU 启动 RDMA (IBGDA) 特性。TransferEngine 不依赖 IBGDA，而是通过主机代理线程（host proxy thread）和 UVM 观察者 (UVM Watcher) 实现了更广泛的硬件兼容性，并能在 ConnectX-7 上超越 DeepEP 的解码延迟。

• 对无序交付的适应：

  • TransferEngine 核心洞察是 ConnectX 的 RC 协议可以被配置为忽略顺序性，而 EFA 的 SRD 协议本身就是无序的。通过放弃对网络传输顺序的依赖，并引入创新的 ImmCounter 原语进行完成通知，TransferEngine 能够在两种协议上提供统一且高效的服务。这与依赖 RC 协议强顺序保证的 DeepEP 等方案形成鲜明对比。

• 多 NIC 管理：

  • TransferEngine 透明地管理每个 GPU 上的多个 NIC，对于 EFA 等需要聚合多个 100 Gbps NIC 才能达到 400 Gbps 峰值带宽的场景至关重要。这确保了在异构硬件上都能充分利用网络带宽。

• 应用场景的广度：

  • TransferEngine 不仅仅是一个通信库，还通过 KvCache 传输、RL 权重更新和 MoE 调度/合并三个生产系统中的应用，全面展示了其在处理不同 LLM 通信模式方面的能力，包括分页写入、批量传输和协调的散射操作，这些都是现有集体通信库难以高效处理的场景。

    总结来说，TransferEngine 的创新之处在于它通过识别并利用异构 RDMA 硬件的共同“可靠但无序”交付特性，并设计了相应的 ImmCounter 机制，从而提供了一个高性能、可移植且避免供应商锁定的点对点通信解决方案，有效弥补了现有 LLM 框架在处理新兴动态通信模式方面的不足。

4. 方法论

本节将深入探讨 TransferEngine 的设计原理、架构、API 接口、实现细节以及硬件特定优化。

4.1. 方法原理

TransferEngine 的核心思想是抽象底层 RDMA 硬件的复杂性，提供一个最小化的、统一的 API，并利用异构 RDMA 硬件（如 NVIDIA ConnectX 和 AWS EFA）之间共同的“可靠但无序”交付特性。

其背后的直觉是：

1. RDMA 硬件的共同能力：尽管 ConnectX 的 RC 协议提供按序交付，但我们可以选择不依赖它；而 EFA 的 SRD 协议本身就是可靠但无序的。这意味着“可靠但无序的交付”是一个通用的交集功能。如果我们可以构建一个通信库，在设计上就不依赖传输的顺序性，那么它就可以在这两种截然不同的硬件上高效地工作。

2. 克服无序交付的挑战：无序交付的主要挑战在于如何知道一个传输何时完成以及多个传输的完成状态。TransferEngine 通过引入 ImmCounter 原语来解决这个问题。ImmCounter 允许发送方在 WRITEIMM 操作中携带一个即时值，接收方在收到数据和即时值时，可以原子地更新一个计数器。这样，接收方无需依赖消息的到达顺序，只需检查计数器是否达到预期值，即可判断传输批次是否完成。

3. 透明管理多 NIC：为了充分利用现代服务器的带宽潜力（例如，AWS P5 实例需要聚合多个 EFA NIC 才能达到 400 Gbps），TransferEngine 被设计为透明地管理每个 GPU 上的多个 NIC。它可以将传输请求分片 (shard) 和负载均衡 (load-balance) 到可用的 NIC 上，以实现最大吞吐量。

4. 低延迟和高吞吐量：通过利用 RDMA 的 zero-copy 接口、绕过内核 (kernel bypass) 以及针对不同硬件的特定优化，TransferEngine 旨在实现极低的延迟和极高的吞吐量。

   通过这些原理，TransferEngine 旨在为 LLM 系统提供一个灵活、高性能、可移植的点对点通信解决方案，以支持分解推理、MoE 和异步强化学习等新兴模式。

4.2. 核心方法详解

4.2.1. 架构概览 (Overview and Design Goals)

TransferEngine 旨在通过最小化 API 来抽象底层 RDMA 接口的复杂性。它支持多种接口，包括 EFA 的 SRD 协议和通过 libibverbs 可编程的 ConnectX-7 等 NIC。系统会透明地检测拓扑结构，以管理每个 GPU 的多个 NIC。例如，单个 ConnectX-7 NIC 提供 400 Gbps 带宽，而 AWS p5 实例需要聚合四个 100 Gbps EFA NIC（或两个 200 Gbps EFA NIC 用于 p5en 实例）才能达到同等带宽。

单个 TransferEngine 实例跨越多个线程，以管理节点内的所有 GPU 和 NIC。通过 zero-copy 接口和硬件特定优化，实现低延迟操作。

为了弥合 RDMA RC 的按序保证与 EFA SRD 的无序交付之间的鸿沟，TransferEngine 仅依赖于其新颖的 ImmCounter。所有完成通知都通过轮询完成队列 (completion queue) 来处理，并在批量收到即时值后交付通知。通知通过回调 (callbacks) 或原子标志 (atomic flags) 交付。

以下是原文 Figure 1 的示意图，展示了 TransferEngine 的架构。

该图像是论文中图1的示意图，展示了TransferEngine管理位于不同NUMA节点、配备多个NIC的GPU。请求由TransferEngine发起，经过Worker处理，完成信息通过ImmCounter和Callback Worker回调反馈。

Figure 1. TransferEngine managing GPUs across NUMA nodes, each with multiple NICs. Commands are forwarded to workers, which respond back to the callback handler or ImMCouNTER.

图 1 解释：

• TransferEngine：顶层抽象，负责协调整个系统。
• Worker：每个 GPU 都会启动一个或多个 Worker 线程，这些 Worker 线程固定在 CPU 核心上，负责处理通信任务。
• NUMA Node：TransferEngine 跨越不同的 NUMA 节点管理 GPU 和 NIC，优化内存访问。
• GPU：计算单元，通过 PCIe 连接 NIC。
• NIC (Network Interface Controller)：网络接口控制器，负责实际的网络传输。每个 GPU 可能有多个 NIC。
• Domain Group (DoMAINGROUP)：每个 GPU 对应一个 DoMAINGROUP，它协调与该 GPU 相关联的所有 RDMA NIC。
• Domain (DoMAIN)：DoMAINGROUP 内部的每个 DoMAIN 专门负责管理一个单独的 NIC，处理队列对 (queue pair) 管理、工作提交和完成轮询。
• Commands：来自应用层的通信请求（如 WRITEIMM）被发送到 Worker。
• ImmCounter / Callback Handler：Worker 处理请求并将完成通知（特别是 ImmCounter 的增量）发送给回调处理程序或 ImmCounter 模块，用于异步通知应用层通信完成。

4.2.2. 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; // Memory Region Management
  fn reg_mr(ptr, len, device) -> (MrHandle, MrDesc); // Two-sided Send/Recv
  fn submit_send(addr: NetAddr, msg: &[u8], cb: fn () -> ());
  fn submit_recvs(len: u64, cnt: u64, cb: fn (&[u8]) -> ()); // One-sided 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); // One-sided Write to a group of peers
  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>); // Watcher for CPU-GPU synchronization
  fn alloc_uvm_watcher(cb: fn(u64,u64) -> ()) -> NonNull<u64>;
}

API 接口详细解释：

• 核心数据结构：

  • NetAddr(Bytes)：网络地址，用于识别和发现远程对等体，可序列化。
  • $MrDesc{ ptr: u64, rkeys: Vec<(NetAddr, u64)> }$：内存区域描述符，可序列化，包含远程内存地址 ptr 和 rkeys（远程键），其中 rkeys 是一个列表，包含每个关联 NIC 的网络地址和远程键。远程键是 RDMA 接收方提供给发送方以允许其写入其内存区域的凭证。
  • $MrHandle(NonNull<c_void>)$：本地内存区域句柄，用于在本地提交传输。
  • $Offset = u64$：偏移量类型。
  • $Pages{ indices: Vec<u32>, stride: u64, offset: Offset }$：描述分页内存区域，包含页面索引、步幅和起始偏移。
  • $PeerGroupHandle(u64)$：对等体组句柄，用于批量操作。
  • ScatterDst{ len: u64, src: Offset, dst: (MrDesc, Offset)) }：散射操作的目标描述，包含长度、源偏移和目标（远程 MrDesc 和偏移）。
  • $OnDone { Callback(fn () -> ()), Flag(Atomic<bool>) }$：完成通知的枚举类型，可以是回调函数或原子布尔标志。

• TransferEngine Trait 方法：

  • main_address() -> NetAddr：返回 TransferEngine 实例的主网络地址，用于身份识别和发现。
  • reg_mr(ptr, len, device) -> (MrHandle, MrDesc)：内存注册。将内存区域注册到引擎中，返回一个可序列化的 MrDesc（用于与对等体交换以提交 WRITE 操作）和一个本地 MrHandle（用作传输源）。可以注册主机端缓冲区和 GPU 内存。
  • submit_send(addr: NetAddr, msg: &[u8], cb: fn () -> ())：两边发送。向指定地址 addr 发送消息 msg。提交操作会进行一次拷贝，允许调用者立即重用或释放缓冲区。发送完成后通过回调 cb 通知。
  • submit_recvs(len: u64, cnt: u64, cb: fn (&[u8]) -> ())：两边接收。预先发布一个缓冲区池，期望接收 cnt 个最大长度为 len 的消息。每收到一条消息，一个缓冲区会从池中临时取出，供回调函数 cb 处理，处理完毕后自动重新入池。
  • expect_imm_count(imm: u32, count: u32, cb: fn () -> ())：ImmCounter 机制。注册一个期望，当特定即时值 imm 的计数器达到 count 时，通过回调 cb 通知。
  • submit_single_write(len: u64, imm: Option<u32>, src: (MrHandle, Offset), dst: (MrDesc, Offset), OnDone)：单边写入。将 src（本地句柄和偏移）处的数据写入 dst（远程描述符和偏移）处。数据长度为 len。可选地携带一个 32 位即时值 imm。完成通知通过 OnDone 指定。
  • submit_paged_writes(page_len: u64, imm: Option<u32>, src: (MrHandle, Pages), dst: (MrDesc, Pages), OnDone)：单边分页写入。将 src（本地句柄和分页描述）处的数据（每个页面长度为 page_len）写入 dst（远程描述符和分页描述）处。可选地携带一个 32 位即时值 imm。完成通知通过 OnDone 指定。引擎将这些操作翻译成可能多个零拷贝的单边 RDMA WRITE 操作，并在可用 NIC 上进行分片和轮询。
  • add_peer_group(addrs: Vec<NetAddr>) -> PeerGroupHandle：添加一个对等体组，返回一个句柄。
  • submit_scatter(h: Option<PeerGroupHandle>, OnDone, imm: Option<u32>, src: MrHandle, dst: Vec<ScatterDst>)：散射操作。将源缓冲区 src 的一个切片发送到对等体组中每个对等体的接收缓冲区的不同偏移处。
  • submit_barrier(h: Option<PeerGroupHandle>, OnDone, imm: u32, dst: Vec<MrDesc>)：屏障操作。一个仅包含即时值的操作，用于通知对等体。
  • alloc_uvm_watcher(cb: fn(u64,u64) -> ()) -> NonNull<u64>：UVM 观察者。注册一个回调函数 cb，当内存中的一个字（word）发生变化时被调用。它分配一个统一虚拟内存 (UVM) 位置，可以被设备（包括 CUDA Graph 内核）更新，并由 CPU 线程使用 GDRCopy 持续轮询。回调函数会接收旧值和新值，以响应 GPU 端的进展。

4.2.3. 实现细节

TransferEngine 使用 Rust 实现，通过精心优化的内存分配、线程管理和同步机制来最小化延迟并实现高吞吐量。

• 线程模型：

  • 每个 DoMAINGROUP 都会启动一个 Worker 线程，该线程被绑定到 NUMA 节点上的一个 CPU 核心，该 NUMA 节点与关联的设备（GPU）相连。这旨在最小化调度和内存访问延迟。
  • 特定于域的数据结构在绑定后分配，以确保内存被预留在正确的 NUMA 节点。
  • 一个 Worker 线程负责处理多达 4 个 DoMAIN（每个 DoMAIN 管理一个 NIC）。
  • 还有一个专用的线程负责轮询 GPU 以更新 UVM 观察者。
  • 线程间通信通过无锁队列 (lock-free queues) 完成。

• 工作流：

  • API 请求被转发到服务于相应设备的 DoMAINGROUP（第一个 DoMAINGROUP 也服务于主机）。
  • 在一个紧密的循环中，域 Worker 会轮询新任务，优先提交新的请求。
  • 根据硬件和配置，请求会在可用的 DoMAIN 之间进行分片和负载均衡。
  • 复合请求的第一次 WRITE 会立即发布到 DoMAIN 的发送队列。
  • 当没有新的请求时，Worker 会继续处理挂起的请求，发布写入以填充硬件管道。
  • 随后，轮询完成队列以查询已完成的传输和即时计数器增量。
  • 事件会被聚合，以向每个传输交付通知，并将传输交给所有组共享的专用回调线程。

• 分片策略：

  • DoMAINGROUP 内部的分片是灵活的。传输可以按索引 targeting 特定 NIC。
  • 单个 WRITE 可以被拆分。
  • 分页传输 (submit_paged_writes)、散射 (submit_scatter) 和屏障 (submit_barrier) 操作（它们都转换为多个 WRITE）可以在所有 NIC 之间进行分片。

4.2.4. 硬件特定优化 (Hardware-Specific Optimizations)

TransferEngine 中的 DoMAIN 针对其控制的硬件进行了专门优化：

• AWS EFA：

  • 使用 libfabric 实现 EFA 支持，每个 NIC 在 DoMAINGROUP 内管理一个 fabric domain。
  • 由于 EFA 与 RDMA 规范有所不同（RDMA 规范不要求即时值写入具有有效的目标描述符，而 EFA 需要），TransferEngine 对所有传输强制使用有效的描述符。
  • 对于批量传输和对等体组，采用工作请求 (WR, Work Request) 模板化 (templating)，预填充并保留 libfabric 描述符的公共字段，然后再发布。

• NVIDIA ConnectX-7：

  • 通过 libibverbs 实现 ConnectX 支持。
  • 对于每个对等体，使用一个 UD 队列对 (queue pair) 来交换 RC 握手信息。
  • 为每个对等体创建 2 个 RC 队列对：一个用于两边 SEND/RECV 操作，另一个用于单边 WRITE 和 WRITEIMM 操作。这种分离是必要的，因为 RECV 和 WRITEIMM 完成都按发布顺序消耗工作请求，这允许提供高级别的 RECV 语义同时支持 WRITEIMM 而不产生干扰。
  • 除了 WR 模板化外，还采用 WR 链式连接 (chaining)，通过 ibv_send_wr 的 next 指针链接多达 4 个工作请求，减少了对 NIC 的 doorbell 响铃次数。
  • 启用 IBV_ACCESS_RELAXED_ORDERING 以允许 NIC 和 GPU 内存之间进行无序 PCIe 事务，从而减少延迟。

4.2.5. 三个生产系统中的应用

本论文通过三个生产系统展示了 TransferEngine 的实际应用：

4.2.5.1. KvCache 传输 (Section 4)

用于分解推理 (disaggregated inference)。

• 流程：预填充器 (prefiller) 节点接收请求，处理输入词元并生成 KvCache 页面和任何额外的上下文（如最后一个词元的隐藏状态和用于推测解码的 logits），然后将这些数据传输到解码器 (decoder) 节点，解码器节点逐个解码词元。
• 通信机制：
  • 解码器预分配 KvCache 页面和上下文存储，然后使用 submit_send 将请求发送给预填充器，指示 KvCache 页面索引。
  • 在分块预填充期间，每层注意力输出投影后，UVM 观察者 (alloc_uvm_watcher) 的值会递增。TransferEngine 检测到变化后，启动该层的传输，通过 submit_paged_writes 拷贝当前块的 KvCache 页面。
  • 最后一个块完成后，上下文通过 submit_single_write 拷贝。
  • 预填充器使用 submit_recvs 等待指令。
  • 完成通知：预填充器不发送显式完成消息。解码器预先知道期望的传输数量，使用 expect_imm_count 通过 TransferEngine 接收传输完成通知并开始解码。
• KvCache 布局和优化：处理预填充器和解码器之间 KvCache 分片或复制的差异。对于 MLA (Liu et al., 2024)，如果使用张量并行，会复制压缩的 KvCache 条目，预填充器与解码器随机匹配以平衡复制传输。对于 GQA (Ainslie et al., 2023)，依赖于页级偏移和步幅来选择源 KvCache 的切片拷贝到目标 KvCache 的对应偏移处。KvCache 布局时头部在前，以确保连续性，减少写入次数并确保单个写入足够大。
• 错误和取消处理：通过心跳消息检测传输层故障。解码器触发的取消必须由预填充器明确确认。每个请求的取消令牌可以停止所有未来的传输，并在所有挂起操作完成后发送取消确认。

4.2.5.2. 强化学习 (RL) 权重更新 (Section 5)

用于异步强化学习微调，实现跨机器参数更新。

• 问题：现有框架在万亿参数模型上进行权重更新可能需要数十到数百秒。
• 本文方案：实现 1.3 秒的万亿参数模型跨机器参数更新 (例如 256 个训练 GPU (bf16) 到 128 个推理 GPU (fp8))，比现有 RL 框架快 100 倍以上。
• 点对点权重传输 (Point-to-Point Weight Transfer)：

  • 现有框架通常形成一个全局集体通信世界，将权重收集到训练子组的 Rank0，然后广播到每个推理子组的 Rank0，瓶颈在于训练 Rank0 的 NIC。

  • 本文的点对点方法是每个训练 GPU 通过单边 RDMA WRITE 直接将权重发送到推理 GPU，从而利用所有 NIC 的全部集群带宽。

    以下是原文 Figure 4 的示意图，展示了权重传输的数据路径。

    该图像是图4，展示了不同方法下权重传输的数据路径示意图。左侧(a)为Rank0-based方案，权重数据通过训练工作节点0的GPU和NIC传出。右侧(b)为点对点(Point-to-Point)方案，训练和推理工作节点GPU之间直接通过NIC进行数据传输，结构更为灵活。

Figure 4. Weight transfer data path for different approaches.

图 4 解释：

• 左侧 (a) Rank0-based：所有训练 GPU 将权重传输到训练集群的 Rank0 GPU，然后 Rank0 GPU 再将权重广播到推理集群的 Rank0 GPU，最后再分发到其他推理 GPU。这种模式在 Rank0 处形成通信瓶颈。

• 右侧 (b) Point-to-Point：每个训练 GPU 直接将权重通过其 NIC 传输到对应的推理 GPU。这种点对点通信模式能充分利用集群中所有 GPU 和 NIC 的带宽，避免单点瓶颈。

• 初始化：控制器脚本执行三个步骤：

  1. 收集所有训练和推理 GPU 的参数元数据（权重名称、形状、数据类型、DTensor 分片）。
  2. 计算静态权重传输调度，映射哪个训练 GPU 发送哪个参数到哪个推理 GPU，以及顺序。
  3. 将调度广播给所有训练 GPU。

• 运行时：在每个训练步骤中，控制器指示训练 GPU 开始发送权重。推理节点对传输过程无感知，因为它使用单边操作。

• 流水线权重传输执行 (Pipelined Weight Transfer Execution)：

  • 训练作业使用 FSDP (Fully Sharded Data Parallel) 分片模型权重。不同参数类型（如 MoE vs. 非 MoE）需要不同的 FSDP 分片策略。

  • 每个分片策略将全局 DeviceMesh 划分为不相交的 MeshGroup。MeshGroup 内的参数并行传输，而 MeshGroup 之间按顺序处理。

  • 每个参数张量的传输被视为一个任务，并分解为四个重叠的流水线阶段：

    以下是原文 Figure 5 的示意图，展示了流水线权重传输的执行。

    该图像是图5，展示了流水线权重传输执行的示意图，包含H2D内存复制、数据融合与量化、RDMA传输及Gloo屏障同步等步骤，表现了多网格组间的流水线处理过程。

Figure 5. Pipelined weight transfer execution.

图 5 解释： 这张图展示了四个流水线阶段如何重叠执行，以充分利用硬件资源：

1. H2D Memcpy (Host-to-Device Memory Copy)：如果 FSDP 将权重卸载到 CPU，则将权重从主机内存复制到设备 (GPU) 内存。
2. Parameter Preparation (参数准备)：重构完整权重（full_tensor()）、应用投影融合、量化（如果需要）。
3. RDMA Transfer (RDMA 传输)：零拷贝 WRITE 操作，将权重传输到远程推理 GPU 内存。
4. Global Barrier (全局屏障)：在所有 full_tensor() 调用完成后，使用 Gloo 通过以太网进行跨 MeshGroup 的同步。

• 内存优化：full_tensor() 和其他 GPU 操作会增加 GPU 内存使用量。为避免内存不足 (OOM) 错误，只有当当前进行中的任务占用的临时 GPU 内存少于可配置的水位线 (watermark) 时，才启动新任务。

4.2.5.3. MoE 调度/合并 (Dispatch/Combine) (Section 6)

实现 MoE 调度和合并的低延迟内核。

• 核心机制：依赖主机代理线程 (host proxy thread) 来协调 GPU 和 NIC。节点内通信利用 NVLink 减少网络负载。

• Split Kernels：调度 (dispatch) 和合并 (combine) 分为独立的内核。

  • 发送方：准备数据到发送缓冲区，以便写入对等体。
  • 接收方：将词元从接收缓冲区洗牌 (shuffle) 到其他内核使用的张量中。

• 优化目标：最大化 GPU 利用率（所有 SMs 和内存带宽），同时保持短运行时间以允许交错其他工作（重叠和微批处理）。

• 主机代理作用：主机代理使用 GDRCopy 轮询 GPU 进展，并在源缓冲区准备好时调用 TransferEngine。

  以下是原文 Figure 6 的示意图，展示了 MoE 调度和合并过程中的 GPU-CPU-NIC 协调。

  该图像是图6的示意图，展示了GPU、CPU和NIC在Dispatch与Combine过程中的协同工作流程，体现了数据通过NVLink和不同阶段的同步与传输机制。

Figure 6. Dispatch and Combine GPU-CPU-NIC coordination

图 6 解释：

• GPU Kernels：在 GPU 上执行的内核，包括调度和合并。

• Unified Memory / GDRCopy：GPU 内核通过统一内存更新状态，CPU 上的主机代理线程使用 GDRCopy 轮询这些状态。

• Host Proxy Thread：在 CPU 上运行，负责协调 GPU 和 NIC。它接收 GPU 的进展信号，并调用 TransferEngine。

• TransferEngine / libibverbs / libfabric：TransferEngine 库，作为底层 RDMA 驱动（libibverbs for ConnectX, libfabric for EFA）的抽象层。

• NVLink：在同一节点内的 GPU 之间进行高速互联，用于节点内通信。

• RDMA NIC：负责节点间的 RDMA 通信。

• 最小化代理开销：通过减少发出的写入数量来最小化代理开销。

  • 所有对等体首先交换路由信息和每个专家的词元计数，以确定在连续接收缓冲区中的唯一范围进行写入。
  • 由于这些载荷很小，其延迟可以通过投机性地将少量词元调度到私有（per-source）缓冲区来隐藏。
  • 合并操作发出单个散射 (scatter) 请求，因为它重用了路由信息。
  • 路由信息始终由 TransferEngine 处理，但载荷可以通过 NVLink 在同一节点内拷贝。
  • 每个 Rank 为每个节点间对等体最多发出 2 个 WRITE（用于调度）和 1 个 WRITE（用于合并）。

• 接收缓冲区大小：接收缓冲区必须足够大，以容纳发送到当前 Rank 的所有词元。假设有 $N$ 个 Rank 托管 $E$ 个专家，每个调度 $T$ 个词元到 $R$ 个专家，接收缓冲区的上限是 $N \cdot T \cdot \max(R, \frac{E}{N})$。发送方将写入打包到这样的连续缓冲区中，而不是依赖更大的按 Rank 接收缓冲区。为最小化开销，较大的调度接收缓冲区可以被合并发送重用。

4.2.5.3.1. 调度 (Dispatch)

调度内核接收词元及其需要路由到的 $R$ 个专家索引，返回一个张量，该张量打包了所有分配给本地专家的词元。

以下是原文 Figure 7 的示意图，展示了调度到私有和连续缓冲区。

该图像是图7示意图，展示了在两个Rank之间基于Top-K索引的输入Token路由过程，数据从发送缓冲区发送到接收缓冲区和私有缓存，体现了高效数据分发机制。

Figure 7. Dispatch into private and contiguous buffers

图 7 解释：

• Input Tokens：输入词元。

• Router Output (Top-K Index)：路由器的输出，指示每个词元应该发送到哪个专家。

• Sender Buffer (Pack to Send)：发送方将词元打包到发送缓冲区。

• Receiver Buffer (Merge from Peers)：接收方从不同对等体接收到的词元合并到接收缓冲区。

• Private Cache：用于隐藏路由信息交换延迟的私有缓存。

• RDMA (Inter-node)：节点间通过 RDMA 进行通信。

• NVLink (Intra-node)：节点内通过 NVLink 进行通信。

• 调度流程：

  1. 内核首先在共享内存中计算发送给每个专家的词元数量，并通过统一内存将计数传输给主机。
  2. 然后它向代理发出信号，代理使用 TransferEngine 启动路由信息到所有对等 Rank 的散射 (submit_scatter)。
  3. 输入词元被复制到发送缓冲区，创建一个连续的源，以便散射到每个对等体。
  4. 代理被通知将词元散射到每个接收对等体的私有缓冲区中，直到固定限制。对于解码大小的批次，从调度内核启动到第一次传输的延迟约为 15 微秒（EP=64）。此时，路由和词元传输使 NIC 带宽饱和。
  5. 一旦路由信息被接收并且可以确定每个源 Rank 的词元位置，剩余的词元被散射到对等体，并将它们连续地放置到共享接收缓冲区中。主机端处理路由和调度第二轮传输的工作需要数十微秒。初始传输中的词元数量被选择以隐藏此开销。
  6. 所有传输被确认完成并且所有传入写入都被计入后，通过 TransferEngine 的屏障同步代理。

• NVLink 优化：在 RDMA 传输在后台挂起的同时，发送内核会通过 NVLink 向同一节点内的对等体传输词元。NVLink 对等体通过自己的屏障进行同步：在写入对等体之前，每个 Rank 必须确保数据已被读取并且可以被覆盖（通过松弛语义的标志）。在载荷写入后，Rank 之间通过 release-acquire 标志进行同步。

• 写入顺序：发送内核中的写入顺序是延迟关键的。NVLink 通过虚拟内存暴露，将读写透明地转换为互连上的事务。加载是昂贵的，而存储是“即发即忘”的，直到遇到内存屏障。为了避免主机系统和 NVLink 对等体之间的屏障导致减速，策略是先向主机发出信号，然后在网格屏障之后发出 NVLink 写入。这增加了发送内核的总执行时间，但降低了到第一次 RDMA 传输的关键路径延迟。

• 接收端：接收内核被调用后，它等待 TransferEngine 通过 ImmCounter 和 GDRCopy 报告所有传输的完成。依赖于基于路由信息计算的索引，词元被重新排序，并在专家之间进行可选填充，以适应分组 GEMM (Grouped GEMM) 内核的布局。接收内核处理大量词元，通过在所有可用 SMs 上分割工作并最大化流水线来充分利用 HBM 带宽。

4.2.5.3.2. 合并 (Combine)

由于路由信息在调度阶段是集中的，合并操作通过单个散射 (scatter) 传输所有载荷。

• 流程：
  1. 在发送和合并之间的空闲时间（GPU 通常会执行分组 GEMM），准备合并命令。
  2. 发送方（类似于调度）准备发送缓冲区，并通过 NVLink 将词元推送到节点内对等体。
  3. 主机代理被通知将散射请求发送到 TransferEngine，之后内核完成执行。
  4. 接收方在等待所有词元被接收之前，将从路由信息派生出的所有相关偏移量缓存在共享内存中。
  5. 词元的加权平均值在每个 Rank 上本地计算。
• 缓冲区重用与屏障：合并阶段重用调度阶段的缓冲区。因此，需要 NVLink 和 RDMA 屏障来确保在覆盖发送缓冲区之前所有先前的操作都已完成。此时，主机代理也等待 TransferEngine 确认所有写入已发出。特别是对于 EFA，它也等待接收确认，最大化写入发布和状态检查之间的间隔很重要。

4.3. 补充背景知识：Attention 机制中的 KvCache

KvCache 是 LLM 推理中的一个关键优化，特别是在自回归生成时。这里对 Attention 机制和 KvCache 进行一个简要的补充说明，以便初学者更好地理解其传输的重要性。

4.3.1. Attention 机制

Transformer 模型的核心是自注意力 (self-attention) 机制。对于一个输入序列，每个词元 (token) 会生成三个向量：

• 查询 (Query, $Q$)

• 键 (Key, $K$)

• 值 (Value, $V$)

  注意力计算公式如下： $$\mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$ 其中：

• $Q$ 是查询矩阵。

• $K$ 是键矩阵。

• $V$ 是值矩阵。

• $Q K^T$ 计算查询与所有键的点积，表示每个查询对所有键的相似度。

• $\sqrt{d_k}$ 是缩放因子，其中 $d_k$ 是键向量的维度。它用于防止点积结果过大，导致 softmax 函数梯度消失。

• $\mathrm{softmax}$ 函数将相似度分数转换为权重，使其总和为 1。

• 这些权重与值矩阵 $V$ 相乘，得到加权后的值向量，表示上下文信息。

4.3.2. KvCache (Key-Value Cache)

在自回归生成（即模型一次生成一个词元）时，为了生成当前的词元，模型需要计算当前的查询向量 $Q_{current}$，并将其与之前所有已生成的词元的键向量 $K_{prev}$ 和值向量 $V_{prev}$ 进行注意力计算。

如果没有 KvCache，每次生成新词元时，都需要重新计算整个序列（包括历史词元）的 $K$ 和 $V$ 向量，这会导致计算量呈二次方增长，效率极低。

KvCache 的作用就是缓存这些历史 $K$ 和 $V$ 向量。

• 在生成第一个词元（或处理输入提示 prompt 阶段，即 prefill 阶段）时，会计算所有输入词元的 $K$ 和 $V$ 向量并将它们存储起来。

• 在生成后续词元（即 decode 阶段）时，新的词元只需要计算自己的 $Q_{new}$、 $K_{new}$ 和 $V_{new}$。然后，当前的 $Q_{new}$ 会与已缓存的 $K_{prev}$ 加上新计算的 $K_{new}$ 组合成的新的 $K$ 序列，以及已缓存的 $V_{prev}$ 加上新计算的 $V_{new}$ 组合成的新的 $V$ 序列进行注意力计算。计算完成后，新的 $K_{new}$ 和 $V_{new}$ 也会被添加到 KvCache 中。

  KvCache 传输的重要性：在分解推理架构中，预填充器生成完整的 KvCache，然后将其传输给解码器。解码器接收 KvCache 后，才能开始逐词元地生成输出。因此，KvCache 的高效传输是实现分解推理高性能的关键，也是 TransferEngine 致力于优化的一个重要用例。

5. 实验设置

本节详细描述了 TransferEngine 及其应用系统的实验设置，包括使用的硬件、评估指标和对比基线。

5.1. 数据集

论文中没有使用传统意义上的公共数据集，而是针对 LLM 系统中的特定通信场景进行性能评估。实验涉及的数据流包括：

• KvCache 页面：用于分解推理，传输 KvCache 的键值对页面。

• RL 模型权重：用于异步强化微调，传输万亿参数量级模型的权重（bf16 到 fp8）。

• MoE 词元和路由信息：用于 MoE 调度和合并，传输词元 (fp8) 和缩放因子 (fp32) 以及路由信息。

  这些数据流的特点是：

• KvCache：通常是分页传输，具有动态大小和结构。

• RL 权重：批量传输，数据量巨大，需要高吞吐量。

• MoE：小批量、细粒度的调度和合并，对延迟敏感，需要频繁的点对点通信。

5.2. 评估指标

论文使用了以下关键指标来评估 TransferEngine 的性能：

5.2.1. 吞吐量 (Throughput)

• 概念定义：吞吐量衡量在单位时间内通过通信链路传输的数据量。它是评估网络系统效率和数据处理能力的重要指标。高吞吐量意味着系统能够更快地传输大量数据。
• 数学公式： $$\text{Throughput} = \frac{\text{Total Data Transferred}}{\text{Time Taken}}$$
• 符号解释：
  • $\text{Total Data Transferred}$：在一次传输操作中实际发送的总数据量，通常以比特 (bits) 或字节 (bytes) 为单位。
  • $\text{Time Taken}$：完成数据传输操作所需的时间。
  • 吞吐量的单位通常为 Gbps (Gigabits per second) 或 MB/s (Megabytes per second)。

5.2.2. 延迟 (Latency)

• 概念定义：延迟衡量从通信请求发出到接收到第一个响应或数据完成通知所需的时间。它是评估系统响应速度和实时性能的关键指标。低延迟对于交互式应用和需要快速同步的分布式系统至关重要。
• 数学公式： $$\text{Latency} = T_{\text{receive}} - T_{\text{send}}$$
• 符号解释：
  • $T_{\text{receive}}$：接收方完成接收或收到完成通知的时间点。
  • $T_{\text{send}}$：发送方发出传输请求的时间点。
  • 延迟的单位通常为微秒 ($\mu s$) 或毫秒 (ms)。

5.2.3. 每秒操作数 (Operations per Second, op/s)

• 概念定义：每秒操作数衡量系统在单位时间内可以完成的特定操作的数量。这个指标通常用于评估系统处理并发请求或小规模、频繁操作的能力。例如，在 RDMA 中，这可能指每秒可以完成多少次 WRITE 操作。
• 数学公式： $$\text{Operations per Second} = \frac{\text{Number of Operations}}{\text{Time Taken}}$$
• 符号解释：
  • $\text{Number of Operations}$：在给定时间内完成的操作总数。
  • $\text{Time Taken}$：完成这些操作所花费的总时间。

5.3. 对比基线

论文将 TransferEngine 的性能与以下基线进行了比较：

• 硬件基准测试工具：
  • ib_write_bw (rdma-core)：ConnectX NICs 上的标准 RDMA 写入带宽测试工具。
  • fi_rma_bw (libfabric)：EFA NICs 上的标准 RMA (Remote Memory Access) 带宽测试工具。这些工具用于测量底层硬件的峰值性能，作为 TransferEngine 达到硬件极限的参考。
• NIXL (NVIDIA Inference Xfer Library) v0.6.1：NVIDIA 专门为 LLM 推理设计的点对点通信库。论文使用其 EFA 和 ConnectX 版本进行比较。
• DeepEP (Zhao et al., 2025)：一个高效的专家并行通信库，被认为是目前最高性能的开源 MoE 实现之一。DeepEP 依赖于 ConnectX 的 IBGDA (GPUDirect Async) 功能。
• pplx-kernels (Licker et al., 2025)：一个可移植的开源 MoE 内核实现，基于 NVSHMEM v3.4.5 构建。它在 ConnectX-7 上进行了评估，但 NVSHMEM 在 EFA 上的性能被认为不可用。
• UCCLEP (Mao et al., 2025)：另一个 MoE 专家并行通信库。论文提到其公布的延迟显著更高，因此没有进行详细比较。

5.4. 硬件配置

所有评估均在以下硬件配置的节点上进行：

• GPU：$8 \times$ NVIDIA H200 GPU，通过 NVLink 互连。
• NICs：
  • 每个 GPU 配备单个 400 Gbps ConnectX-7 NIC。
  • 或者，每个 GPU 配备双 200 Gbps EFA NICs（总计 400 Gbps 聚合带宽）。
• CPU：双插槽 Intel Sapphire Rapids CPUs。

5.4.1. MoE 调度/合并的特定设置

• 模型：DeepSeek-V3 模型设置。
• 词元大小：调度 $7168 \times \text{fp8}$ 词元，具有 $56 \times \text{fp32}$ 缩放因子。
• 合并张量：合并相同维度的 bf16 张量。
• 批次大小：解码 (decode) 评估使用 128 个词元批次；预填充 (prefill) 评估使用 4096 个词元块。
• 专家路由：每个词元被调度到 8 个随机专家。
• 迭代次数：10,000 次热身迭代 (warmup iterations)，随后是 10,000 次基准测试运行。计时数据在所有 Rank 之间聚合。
• 模拟工作负载：通过插入大型 GEMM (General Matrix Multiply) 操作来模拟重叠工作和清除缓存。

6. 实验结果与分析

6.1. 点对点通信性能

KvCache 传输和 RL 权重更新的性能主要由单次写入 (submit_single_write) 和分页写入 (submit_paged_writes) 的吞吐量决定。作者将 TransferEngine (TE) 和 NIXL v0.6.1 这两个高级库与底层 NIC 的硬件基准测试进行比较，测量在不同消息大小下所占带宽的比例。在 ConnectX 上，使用 rdma-core 的 ib_write_bw 进行比较；在 EFA 上，使用 libfabric 的 fi_rma_bw 测量单个 NIC 的峰值带宽，并将其翻倍以匹配运行在两个 NIC 上的 TransferEngine。

以下是原文 Figure 8 的图表，展示了点对点通信性能。

该图像是论文中展示的图表，编号为图8，表现了点对点通信的带宽相对性能。图表分为两个部分，左侧是单次写入（Single Write），右侧是分页写入（Paged Write），比较了不同方法（Ours-EFA, Ours-CX7, NIXL-EFA, NIXL-CX7）在不同数据大小下的相对带宽变化。

Figure 8. Point-to-Point communication performance

图 8 解释： 该图表展示了两种主要写入模式（单次写入和分页写入）下，不同库在不同消息大小（从 4KiB 到 64MiB）下能够达到的峰值带宽百分比。

• 单次写入 (Single Write)：

  • 在消息大小较小（如 4KiB, 8KiB）时，所有库和硬件的带宽利用率都较低。
  • 随着消息大小的增加，带宽利用率逐渐提高。
  • TransferEngine (Ours-EFA, Ours-CX7) 和 NIXL (NIXL-EFA, NIXL-CX7) 在消息大小达到 16MiB 左右时，能够接近或达到峰值带宽。
  • ConnectX-7 (CX7) 上的性能通常优于 EFA，且饱和速度更快。
  • TransferEngine 略快于 NIXL。

• 分页写入 (Paged Write)：

  • 分页写入在较小的消息大小下就能实现更高的带宽利用率。

  • TransferEngine 在 32KiB 的消息大小下即可达到饱和。

  • NIXL 在 64KiB 的消息大小下达到饱和。

  • 同样，ConnectX-7 上的性能通常优于 EFA。

    核心发现：

• 要使单次 WRITE 饱和，需要至少 16MiB 的消息。

• 分页 WRITE 则在较小消息（TransferEngine 32KiB，NIXL 64KiB）下就能达到饱和。

• TransferEngine 的性能与 NIXL 相当接近，且略优。

• EFA 需要更大的消息才能达到饱和，这解释了在 MoE 路由中观察到的性能差距。

  以下是原文 Table 2 的数据转录：

  		EFA		CX-7
  		Single	Paged	Single	Paged
  1 KiB		16 Gbps	17 Gbps (2.11M op/s)	44 Gbps	91 Gbps (11.10M op/s)
  8 KiB			138 Gbps (2.10M op/s)		320 Gbps (4.89M op/s)
  16 KiB			274 Gbps (2.08M op/s)		367 Gbps (2.80M op/s)
  64 KiB			364 Gbps (0.69M op/s)		370 Gbps (0.71M op/s)
  256 KiB		54 Gbps		116 Gbps
  1 MiB		145 Gbps		245 Gbps
  32 MiB		336 Gbps		378 Gbps

表 2 解释： 该表提供了 EFA 和 ConnectX-7 在不同消息大小下单次写入和分页写入的绝对性能数据。

• 256 KiB 单次写入：这是 MoE 路由的典型大小。TransferEngine 在 EFA 上达到 54 Gbps，在 ConnectX-7 上达到 116 Gbps。
• 64 KiB 分页写入：这是 KvCache 页面的典型大小。EFA 和 ConnectX-7 都能使可用带宽饱和（EFA 364 Gbps，ConnectX-7 370 Gbps）。
• RL 权重传输的消息大小远超过饱和点，因此可以充分利用带宽。

6.2. RL 权重更新性能

• 1.3秒更新：论文展示了 TransferEngine 能够实现万亿参数模型（如 Kimi-K2, DeepSeek V3, Qwen3）在 1.3 秒内完成跨机器参数更新。这比现有 RL 框架快 100 倍以上。
• 充分利用集群带宽：通过点对点 RDMA WRITE 直接从每个训练 GPU 发送到推理 GPU，TransferEngine 能够利用集群的全部带宽，避免了传统 Rank0-based 方案中的瓶颈。
• 流水线执行：流水线机制（H2D memcpy、参数准备、RDMA 传输、全局屏障）确保了不同硬件资源的同时利用，避免了 OOM 错误。

6.3. MoE 调度/合并性能

作者评估了 MoE 内核在 8、16、32 和 64 个 GPU 上的解码和预填充性能，并与 DeepEP (最先进的开源实现) 和 pplx-kernels (基于 NVSHMEM 的可移植开源实现) 进行了比较。

6.3.1. 私有缓冲区大小的影响

以下是原文 Figure 9 的图表，展示了私有缓冲区大小对 p50 解码延迟的影响。

该图像是图表，展示了不同私有缓冲区大小对两种网络适配器（EFA和ConnectX-7）在多种EP配置下的相对解码延迟速率影响。图中横轴为最大私有Token数，纵轴为相对延迟下降百分比，EP64、EP32、EP16、EP8代表不同的EP配置。

Figure 9. Impact of private buffer size on $\mathsf { p 50 }$ decode latency

图 9 解释： 该图展示了在不同 EP 配置（专家并行度）下，私有缓冲区大小（最大私有词元数）对中位数 ($p50$) 解码延迟下降百分比的影响。0% 表示达到最佳延迟时的私有缓冲区大小。

• 当私有缓冲区大小减少时，性能开始下降。
• 隐藏延迟：私有缓冲区的设计目的是隐藏路由信息交换的延迟。图中显示，在没有足够私有词元（即私有缓冲区过小）时，性能会显著下降。
• 节点内 (Intra-node)：对于节点内通信，至少需要约 32 个词元才能隐藏路由交换的延迟。
• 节点间 (Inter-node)：
  • ConnectX-7 (CX7) NICs：只需要 24 个词元就可以隐藏延迟。
  • EFA NICs：由于路由交换较慢，当私有缓冲区小于 32 个词元时，性能下降更为明显。
• 结论：这个实验结果证明了私有缓冲区在隐藏通信开销方面的有效性，并指导了针对不同硬件选择合适的缓冲区大小。

6.3.2. 发送和接收延迟

以下是原文 Figure 10 的图表，展示了 EP=64 时单独发送和接收延迟。

该图像是一个柱状图，展示了不同方案在 Dispatch-Send、Dispatch-Recv、Combine-Send 和 Combine-Recv 四个环节的延迟对比，单位为微秒。柱状图中包含三种方案：Ours-EFA-SRD、Ours-CX7-RC 和 DeepEP-CX7-GDA，具体数值显示在柱顶部。

Figure 10. Separate Send and Receive Latency for $\\mathrm { EP } { = } 6 4$

图 10 解释： 该图对比了 TransferEngine (Ours-EFA-SRD, Ours-CX7-RC) 和 DeepEP-CX7-GDA 在 $EP=64$ 专家并行度下，调度发送、调度接收、合并发送和合并接收这四个阶段的平均延迟。

• 调度发送 (Dispatch-Send)：Ours-CX7-RC 的延迟最低（14 µs），其次是 Ours-EFA-SRD (17 µs)。DeepEP 较高 (24 µs)。这表明 TransferEngine 在发送数据时的内存拷贝效率高。

• 调度接收 (Dispatch-Recv)：DeepEP 的延迟最低 (26 µs)，而 Ours-CX7-RC (35 µs) 和 Ours-EFA-SRD (41 µs) 较高。论文解释说，DeepEP 在调度接收阶段表现优异，而 TransferEngine 的调度接收是“异常值”，因为它通过 NVLink 加载数据。

• 合并发送 (Combine-Send)：Ours-CX7-RC (2 µs) 和 Ours-EFA-SRD (2 µs) 的延迟显著低于 DeepEP (24 µs)。这得益于 TransferEngine 的高效内存拷贝。

• 合并接收 (Combine-Recv)：Ours-CX7-RC (10 µs) 和 Ours-EFA-SRD (12 µs) 的延迟也低于 DeepEP (20 µs)。这是因为 DeepEP 涉及在发送端进行部分和的累积。

  核心发现：

• TransferEngine 在调度和合并的发送阶段通常优于 DeepEP，因为它的实现只进行内存拷贝。

• 合并接收也更快，归因于更快的累积。

• 调度接收是一个例外，因为 TransferEngine 通过 NVLink 加载数据。

• 总体而言，这些内核的总执行时间不到传输时间的 15%，表明代理开销很小。

6.3.3. 解码延迟

以下是原文 Figure 11 的图表，展示了解码延迟。

该图像是论文中展示不同方法在EP64、EP32、EP16和EP8四种场景下调度（Dispatch）和合并（Combine）延迟的柱状图，比较了Ours-EFA-SRD、Ours-CX7-RC、DeepEP-CX7-GDA、pplx-CX7-GDA和pplx-CX7-RC五种方案的性能表现。

图 11 解释： 该图展示了在不同专家并行度 ($EP=8, 16, 32, 64$) 下，MoE 调度和合并内核的解码延迟，对比了 Ours-EFA-SRD、Ours-CX7-RC、DeepEP-CX7-GDA 和 pplx-CX7-GDA (以及 pplx-CX7-RC)。

• ConnectX-7 (Ours-CX7-RC vs. DeepEP-CX7-GDA)：
  • 在大多数 EP 配置下，Ours-CX7-RC 实现了新的最先进性能，超越了 DeepEP。
  • EP=8 (节点内)：Ours-CX7-RC 略慢于 DeepEP（约 2 µs）。这主要是由于 TransferEngine 使用 NIC 交换路由信息，而 DeepEP 可能在节点内有更优化的 NVLink 同步或 IBGDA。
  • EP=16, 32 (节点间)：Ours-CX7-RC 在调度和合并阶段均优于 DeepEP。这得益于批量传输和合并阶段的有效流水线。
  • EP=64：合并阶段 Ours-CX7-RC 仍然优于 DeepEP，但调度阶段 Ours-CX7-RC 略慢。这表明在 64 个 Rank 时，主机代理线程的 CPU 开销开始变得明显，因为每个 56 个节点间对等体的传输排队开销约为微秒级。
• EFA (Ours-EFA-SRD)：
  • TransferEngine 是第一个在 EFA 上实现可行延迟的 MoE 实现。这弥补了现有解决方案的空白。
  • 尽管 EFA 在 256KiB 写入时吞吐量不到 ConnectX-7 的一半，但其延迟仅比 ConnectX-7 落后约 30%。这说明 EFA 的延迟特性对于 MoE 这种对延迟敏感的工作负载是可接受的。
• pplx-kernels (基于 NVSHMEM)：

  • pplx-CX7-GDA 和 pplx-CX7-RC 的延迟明显高于 DeepEP 和 TransferEngine，尤其是在 NVSHMEM 于 EFA 上表现“不可用”的情况下。这突出了 TransferEngine 在 ConnectX 和 EFA 上的性能优势。

    结论：TransferEngine 基于主机代理的实现不仅使 EFA 可用，而且在 ConnectX-7 上也显著超越了基于 IBGDA 的 DeepEP 内核，成为了新的最先进技术。

6.3.4. 预填充延迟

以下是原文 Figure 12 的图表，展示了 MoE 预填充延迟。

该图像是一个条形图，展示了图12中MoE预填充的延迟情况，对比了不同方案（Ours-EFA-SRD、Ours-CX7-RC和DeepEP-CX7-GDA）在调度和合并阶段，随着EP规模变化的平均延迟及对应误差范围。

Figure 12. MoE Prefill Latency. Bar height is mean. Error bars show p01, p25, p50, p75, p95, p99.

图 12 解释： 该图展示了在不同专家并行度 ($EP=8, 16, 32, 64$) 下，MoE 预填充的调度和合并延迟，对比了 Ours-EFA-SRD、Ours-CX7-RC 和 DeepEP-CX7-GDA。pplx-kernels 由于在 4096 词元时效率低下，未包含在比较中。

• 调度 (Dispatch) 侧：
  • DeepEP 在 Rank 数量较少时表现更好。原因在于 DeepEP 使用 RDMA 仅传输词元的一个副本，然后通过 NVLink 将其副本移动到其他 Rank。
  • 当 $EP=64$ 时，多个副本落在同一节点的机会减少，这种优化效果随之减弱，TransferEngine 的性能变得更具竞争力。
• 合并 (Combine) 侧：

  • DeepEP 的发送端部分和 (sender-side partial sum) 显著减少了 RDMA 传输的字节数，因此显示出更低的延迟。尽管其累积精度降低到 bf16。

  • TransferEngine 的合并阶段延迟相对较高。

    核心发现：

• 在预填充场景下，DeepEP 针对其特定的传输策略（如在发送端进行部分求和以减少 RDMA 字节）可能具有优势。
• TransferEngine 当前的解码优化内核在预填充场景下存在内存开销限制，这限制了可部署模型的范围，如果不对传输进行分块处理。这表明在预填充方面，TransferEngine 仍有优化空间。

6.4. 与 DeepEP 的比较总结

• DeepEP：提供最先进的延迟性能，但仅限于 ConnectX，因为它依赖于 IBGDA 和 m1x5 驱动。DeepEP 内核依赖 RC QP 的强顺序保证，将词元平衡到 SMs 上，并逐个通过 QP 传输。这导致首次传输的延迟较低，但涉及每个词元更多的工作和更多的网络包。使用 Atomic 操作进行词元计数和完成通知。
• TransferEngine (本文方案)：更具可移植性，支持 EFA 和 ConnectX，采用主机代理线程进行协调。

  • 尽管有额外的代理线程开销，但在 ConnectX-7 上解码延迟超越了 DeepEP。

  • 在 EFA 上是首次可行的实现。

  • TransferEngine 在首次传输启动前的花费时间较长，因为有额外的 GPU-CPU-NIC 通信开销（通过 PCIe）。但是，批量传输实现了更好的网络利用率。

  • 我们的内核在调度和合并的发送侧表现优异，因为它们主要涉及内存拷贝。

  • MoE 预填充方面，DeepEP 在较少 Rank 时表现更好（通过 NVLink 复制词元副本，减少 RDMA），并且在合并阶段通过发送端部分和减少 RDMA 字节。而 TransferEngine 在预填充时存在内存开销限制。

    总结：TransferEngine 在牺牲部分初始延迟以换取更强的可移植性和批量传输效率，并在解码场景下取得了领先性能。它在 EFA 上的可行性是其最大的突破。

7. 总结与思考

7.1. 结论总结

本文提出了 TransferEngine，一个针对 LLM 系统设计的可移植 RDMA 点对点通信库，旨在解决现有方案的供应商锁定问题和新兴 LLM 模式（如分解推理、MoE 路由、异步强化微调）对灵活通信的需求。

TransferEngine 的核心创新在于识别并利用了异构 RDMA 硬件（NVIDIA ConnectX-7 和 AWS EFA）中“可靠但无序”交付这一共同功能。通过在其之上构建一个不依赖消息顺序的抽象层，并引入 ImmCounter 原语进行完成通知，TransferEngine 成功提供了一个统一的接口，并能透明地管理每个 GPU 上的多个 NIC。

实验结果表明，TransferEngine 在 ConnectX-7 和 EFA 上均能达到 400 Gbps 的峰值吞吐量。通过在 KvCache 传输、RL 权重更新和 MoE 调度/合并这三个生产系统中的应用，本文验证了 TransferEngine 的有效性：

• KvCache 传输实现了分解推理的动态扩展和低延迟传输。

• RL 权重更新实现了万亿参数模型 1.3 秒的更新时间，比现有框架快 100 倍以上，充分利用了集群带宽。

• MoE 调度/合并在 ConnectX-7 上超越了 DeepEP 的解码延迟，并在 EFA 上首次实现了可行的 MoE 性能。

  总而言之，TransferEngine 为现代 LLM 架构提供了可移植的点对点通信能力，有效补充了集体通信，同时成功避免了供应商锁定，为云原生部署提供了关键支持。

7.2. 局限性与未来工作

论文中虽然没有明确列出“未来工作”的章节，但从实验结果和讨论中可以推断出一些潜在的局限性和未来研究方向：

• MoE 预填充性能：

  • 论文指出，TransferEngine 目前的解码优化内核在预填充场景下存在内存开销限制，这限制了可部署模型的范围，尤其是在不进行分块传输的情况下。在预填充阶段，DeepEP 在某些配置下仍表现出优势，特别是在减少 RDMA 字节和使用 NVLink 复制方面。
  • 未来工作：需要进一步优化 TransferEngine 的 MoE 内核，使其在预填充场景下也能达到与解码场景类似的领先性能，可能需要引入更精细的传输策略或内存管理机制（如分块传输）。

• 主机代理的 CPU 开销：

  • 在 MoE 调度/合并的 64 个 Rank 配置下，调度阶段 TransferEngine 的延迟略高于 DeepEP。论文指出这可能是由于主机代理线程的 CPU 开销变得明显，因为每个 56 个节点间对等体的传输排队开销约为微秒级。
  • 未来工作：需要探索如何进一步降低主机代理的 CPU 开销，或者在 ConnectX 等支持 GPU 启动 RDMA (IBGDA) 的硬件上，考虑混合使用 IBGDA 来处理部分对延迟极其敏感的传输，以减轻 CPU 代理的负担。

• 对新云 RDMA 解决方案的兼容性：

  • TransferEngine 解决了 ConnectX 和 EFA 的可移植性问题，但云服务提供商不断推出新的专有 RDMA 解决方案（如 Alibaba Cloud eRDMA, Google Falcon）。
  • 未来工作：尽管 TransferEngine 提供了统一的接口，但底层仍然需要针对每个新的 RDMA 协议实现特定的 DoMAIN。持续地适配和优化对新硬件的支持将是一个长期的任务。

• 更全面的故障容忍机制：

  • 论文提到了 KvCache 传输中的错误处理和取消机制，如心跳消息和取消令牌。
  • 未来工作：对于大规模分布式系统，更全面的故障检测、恢复和容错机制（例如，节点故障、网络分区等）可能需要进一步研究和集成到 TransferEngine 中。

7.3. 个人启发与批判

7.3.1. 个人启发

• “可靠但无序”的通用抽象：TransferEngine 的核心洞察在于识别并利用了异构 RDMA 硬件（NVIDIA ConnectX 的 RC 协议可以忽略顺序，AWS EFA 的 SRD 协议本身无序）的共同特性，即“可靠但无序”的交付。这种从底层硬件特性中提取通用抽象的能力非常具有启发性，对于在碎片化硬件生态中构建可移植系统提供了一个范例。它表明，通过巧妙的设计，可以避免对最严格、最特定硬件能力（如 RC 的强顺序保证）的依赖，从而拓宽兼容性。
• ImmCounter 的巧妙设计：ImmCounter 原语的引入是解决无序交付挑战的优雅方案。它允许接收方在不依赖消息到达顺序的情况下，通过原子计数器有效追踪传输完成状态。这种机制是构建高性能异步通信的关键，在许多分布式系统中都有潜在的应用价值。
• 点对点通信的价值再确认：在 LLM 领域，集体通信一直是主流。然而，随着 MoE、分解推理和异步 RL 等新模式的兴起，论文强有力地证明了灵活、高性能的点对点通信是不可或缺的。TransferEngine 不仅提供了一个通信库，更通过三个生产级用例展示了点对点通信在解决实际 LLM 系统挑战中的巨大潜力。
• 流水线优化和异构资源利用：RL 权重更新中提出的四阶段流水线执行，以及 MoE 调度/合并中 NVLink 和 RDMA 的协同利用，体现了对异构计算和通信资源的精细化管理和优化。这种细致入微的系统设计对于榨取硬件性能至关重要。
• Rust 在高性能系统中的潜力：TransferEngine 使用 Rust 实现，这表明 Rust 在高性能、低延迟系统编程中具有巨大潜力，其内存安全特性和对并发的原生支持使其成为此类基础设施项目的一个优秀选择。

7.3.2. 批判

• “可移植性”的深度：尽管 TransferEngine 实现了用户层面的统一接口，但底层仍需针对不同的 RDMA 协议（libfabric for EFA, libibverbs for ConnectX）进行专门的 DoMAIN 实现。这意味着，当新的云提供商推出自己的专有 RDMA 硬件时，TransferEngine 仍需要投入开发以添加新的后端。因此，其“可移植性”更多体现在用户 API 层面，而非底层硬件驱动的完全通用化。未来的工作可以探索更高级别的抽象，甚至是在底层驱动层面实现更强的通用性。
• 主机代理的开销与 IBGDA 的权衡：TransferEngine 为了可移植性，选择使用主机代理线程而非 ConnectX 独有的 IBGDA。尽管论文表示在 ConnectX-7 上其性能优于 DeepEP，且主机代理开销在大多数情况下可控，但在大规模（如 64 个 Rank）MoE 调度时，主机代理的 CPU 开销仍可能成为瓶颈。对于 ConnectX 平台，是否可以考虑一种混合策略，即在 IBGDA 可用的情况下利用其零 CPU 开销和 GPU 发起的优势，而在 EFA 等不支持 IBGDA 的平台上继续使用主机代理？这可能提供更好的平台特定优化。
• 预填充性能的差距：MoE 预填充的实验结果显示 TransferEngine 仍有改进空间，尤其是在 DeepEP 采用的一些优化策略（如减少 RDMA 字节）下，DeepEP 仍有优势。这表明 TransferEngine 在 MoE 的某些特定场景或数据模式下，可能尚未达到最佳性能。未来需要更深入地研究和优化其在预填充阶段的效率。
• 缺乏更全面的系统级评估：论文主要关注吞吐量和延迟。其他系统级指标，如 CPU 利用率、内存占用、能源效率以及在更长时间运行下的稳定性等，对于生产系统而言也至关重要。例如，主机代理线程的 CPU 开销如果长期存在，可能会影响节点上其他任务的性能。
• 故障恢复和一致性模型：论文在 KvCache 传输中提到了错误和取消处理，但对于更复杂的分布式系统故障（如网络分区、节点崩溃）下的故障恢复机制和数据一致性保证，没有深入讨论。在 LLM 生产环境中，鲁棒性是关键考量。