Enabling Efficient GPU Communication over Multiple NICs with FuseLink

作者和机构： Zhenghang Ren, Yuxuan Li, Zilong Wang, Xinyang Huang, Wenxue Li, Kaiqiang Xu, Xudong Liao, Yijun Sun, Bowen Liu (Hong Kong University of Science and Technology); Han Tian (University of Science and Technology of China); Junxue Zhang (Hong Kong University of Science and Technology); Mingfei Wang (MetaX Integrated Circuits); Zhizhen Zhong (Massachusetts Institute of Technology); Guyue Liu (Peking University); Ying Zhang (Meta); Kai Chen (Hong Kong University of Science and Technology)

A1 主要贡献

论文从引言中提取的核心问题是：在分布式机器学习任务中，GPU间通信效率对性能至关重要，但现有系统在处理不均衡通信流量时无法充分利用多个NIC，导致热点NIC成为瓶颈。具体而言，机器学习集群中每个服务器堆叠多个NIC以提升服务器间GPU通信带宽，但静态GPU-NIC绑定导致不均衡流量（如大语言模型服务、专家并行训练和推荐模型训练）下热点NIC拥塞，而其他NIC闲置。研究目标是设计一种框架，使任意机器学习负载能有效利用所有可用RDMA NIC进行数据传输，将多个NIC聚合为“FuseLink”以提升服务器间通信带宽，而无需调整并行策略或修改应用代码。

创新点包括：FuseLink通过整合高速服务器内连接（如NVLink）作为服务器间网络的扩展，实现动态NIC利用；它利用GPU高效中继流量到闲置NIC，并在NCCL中集成，实现无缝部署；FuseLink显著提升服务器间GPU通信带宽至212GBps，并加速动态流量机器学习任务，如LLM服务的首令牌生成延迟降低1.04-2.73倍、MoE模型训练吞吐量提升1.3倍，以及DLRM训练加速1.2倍。

图1展示了典型GPU服务器配置中静态绑定与FuseLink的对比，FuseLink解耦网络资源并启用灵活NIC利用。

A3 背景知识/关键Observation/设计原则

高速互连在机器学习中的重要性。 高速互连对于大规模机器学习至关重要。随着模型规模和数据集体积的增长，实际机器学习应用通常部署在分布式环境中，产生大量通信开销，因此需要高带宽网络。已有大量努力提升GPU通信带宽，包括专用服务器内GPU连接和服务器间网络。工业实践开发了快速专用GPU互连作为机器学习集群的核心部分，提供GPU间Tbps网络。例如，Nvidia构建了NVLink和NVSwitch来连接近距离GPU；Google为TPU组设计了专用芯片间互连（ICI）。然而，服务器间网络在单个NIC上的带宽相对低于服务器内网络。因此，GPU集群通常在每个服务器内堆叠多个NIC来满足GPU的服务器间带宽需求。NIC的常见配置是服务器内NIC数量与GPU数量相同，并将每个NIC安装在直接访问对应GPU插槽的PCIe插槽上。这确保每个GPU能获得其NIC的完整带宽。

现有系统在动态流量下的不足。 尽管有努力提升服务器间带宽，现有系统由于GPU流量与NIC的静态绑定导致低NIC利用率，无法充分利用服务器间带宽用于动态流量的机器学习任务。这种动态流量是广泛采用的机器学习任务的内在特性，包括模型服务、MoE模型和推荐模型中的嵌入传输。而且，在如NVL72系统这样的大型GPU互连域中，NIC负载不均衡更明显，其中72个GPU和NIC通过NVLink和RDMA连接。我们通过调查具有动态通信模式的机器学习任务来分析根本原因。

动态流量机器学习任务的测试。 我们测试了表1所示的典型动态流量机器学习任务。我们的测试在每个服务器配备八个Hopper GPU、通过八通道NVLink连接以及八个400Gbps NIC用于服务器间网络的服务器上进行。GPU流量通过直接NIC传输以最大化NIC吞吐量。我们的指标是NIC利用率和机器学习任务中通信的比例。我们通过静态NIC绑定与理想情况（GPU可以使用所有可用NIC进行通信）之间的速度差距来估计NIC利用率。图2a展示了平均NIC利用率和通信在总成本中的比例，以及利用所有NIC加速服务器间数据传输的估计理想利用率。

解耦LLM服务。 我们测试了典型解耦LLM服务案例，其中模型服务分为预填充阶段和解码阶段，处理后的请求从预填充阶段发送到解码阶段。我们从公共跟踪随机馈入输入请求，并记录将请求传输到解码阶段时的NIC利用率。结果显示在阶段间传输数据时只有13%-53%的NIC利用率，因为服务流量是随机的，取决于任务到达时间和请求长度，流量体积从数百MB到GB不等。即使使用高级优化技巧重叠通信和计算，我们也无法充分利用NIC，因为请求在GPU工作者间变化。图2b描绘了模型服务期间记录的四个NIC速度，显示一些NIC空闲而其他NIC繁忙。

MoE训练。 我们测试了MoE模型训练，使用Mixtral 8×7B模型，专家并行度为八，tensor并行度为四。我们记录GPU工作者将令牌传输到具有激活专家的同行工作者时的NIC利用率。NIC利用率显示29%-65%，通信占总成本的28%-55%。根本原因是MoE训练期间服务器间GPU通信的异步性和专家的不同令牌批次。图2c展示了专家模型间的流量图。EP训练将专家模型分配给GPU工作者，每个工作者训练专家的子集。即使模型分区相等，不均衡流量也会持续，因为专家层基于门层的输出对每个输入令牌进行稀疏激活。由于数据样本路由到不同专家，GPU工作者需要向同行工作者分派和收集数据，导致NIC间all-to-all流量不均衡。由于专家间流量体积不同，NIC和GPU的静态绑定在all-to-all通信受最大流量体积的GPU对限制时无法充分利用NIC带宽。

DLRM。 我们测试了基于DeepFM的深度学习推荐模型，使用Avazu数据集。DLRM由稠密模型和存储对象语义嵌入向量的大型查找表组成。在每个训练迭代中，GPU工作者从嵌入表服务器获取嵌入并推送梯度（如果未本地缓存），并使用数据并行训练稠密模型。嵌入传输体积在工作者间变化，导致不同流量体积。我们的结果显示嵌入传输实现59%-82%的NIC利用率，并占总成本的55%。图2d展示了八个GPU工作者间的不均衡流量分布，导致性能受最大嵌入传输的GPU工作者限制。

利用闲置NIC的机会。 通过分析图2中的动态流量机器学习任务，我们得出结论：静态NIC绑定不适合此类任务。这是因为使用静态NIC绑定实现最佳NIC利用率需要通过直接NIC传输、并发传输和相等流量体积。没有这些条件，通信性能受绑定到特定NIC的任务限制，而其他NIC保持闲置。这种闲置NIC容量可以被利用，通过动态调度流量到闲置NIC来加速通信。

多NIC通信的挑战。 多NIC通信非平凡，因为仅使用PCIe连接不会提升服务器间带宽。一方面，当所有NIC通过发送GPU的单个PCIe接口访问时，总带宽受限。另一方面，一些NIC与发送GPU间接连接，数据穿越PCIe根复合或甚至跨NUMA，导致次优NIC吞吐量。利用NVLink和机器学习任务中的不均衡流量，我们可以显著提升多NIC传输效率。

动态NVLink路由绕过PCIe。 现有GPU通信框架，如NCCL，利用NVLink绕过次优PCIe路径，当通过间接NIC传输数据时。然而，它们仅关注优化单个NIC，其他NIC受限于次优PCIe路径。这种限制阻止高效利用多个NIC进行高性能数据传输。图3展示了不同路径上的NIC速度。服务器间GPU通信带宽受PCIe接口和拓扑限制，特别是使用间接NIC时，需要数据穿越次优路径。为解决此问题，我们通过NVLink启用到同行GPU的动态流量路由，允许高效聚合多个NIC的带宽用于服务器间GPU通信。

A2 方法细节

FuseLink概述。 FuseLink通过动态调度工作者的流量到多个NIC来实现多NIC通信，对NIC负载状态敏感，而不是静态绑定流量到特定NIC。为了有效利用间接NIC，FuseLink通过服务器内连接路由流量到NIC访问的最佳GPU。FuseLink的主要设计目标是实现高效多NIC传输，同时最小化争用风险，并与现有机器学习基础设施兼容。图4展示了发送侧的FuseLink架构及其示例工作流程。

FuseLink以服务器间连接设置初始化。FuseLink探索服务器内拓扑并建立RDMA连接。在连接设置期间，FuseLink识别用于服务器间通信的可用NIC。基于拓扑，FuseLink为每个NIC和GPU选择最佳数据路径。如果NIC通过PCIe桥或PCIe交换机直接连接到GPU，则使用此直接路径，因为NIC可以以完整带宽访问GPU。否则，FuseLink选择一个路由GPU用于将数据中继到NIC。在图4中，当GPU0通过NIC1发送时，GPU1是路由器。

服务器间GPU通信以接收者发行信用开始，这些信用是包含启动RDMA所需资源的数据结构。这些资源包括接收内存区域和请求数据大小。关键的是，信用包含闲置NIC信息，这些信息来自FuseLink主动监控NIC接收负载状态。这允许发送者选择合适的NIC发送数据。信用在启用RDMA的应用中很常见，因为其绕过特性。

在发送侧，FuseLink拦截发送请求并等待接收者的信用。同时，FuseLink监控NIC发送负载状态。当信用到达时，FuseLink考虑发送NIC负载状态和接收负载状态来选择最佳NIC进行数据传输。而且，FuseLink利用服务器内GPU连接高效路由流量到NIC。例如，图4展示了从GPU0通过NVLink到GPU1的数据路由，并通过NIC1发送。

FuseLink在数据到达接收者时得到通知。请注意，数据可能传输到路由GPU而不是接收GPU，因为发送者可能选择与接收GPU间接连接的接收NIC。在这种情况下，我们首先在路由GPU上暂存接收数据以确保传输效率。然后，如果需要，通过服务器内连接路由流量到接收GPU。

与现有GPU通信框架相比，FuseLink引入了几个关键进步。

• 解耦网络资源。 FuseLink不是直接操作RDMA连接，而是引入一个抽象层，统一服务器内和服务器间连接。这种设计启用高效和灵活的NIC利用。

• 动态NIC利用。 FuseLink实时监控NIC状态，而不是静态绑定流量到特定NIC。这种方法允许检测闲置NIC并动态分配流量到它们，显著提升整体带宽利用率。

• 使用高带宽GPU链接的流量路由。 FuseLink不是静态绑定流量到NIC或中间GPU，而是充分利用高带宽GPU链接进行流量路由，从而绕过传统互连中的PCIe约束并提升通信效率。

挑战。 FuseLink通过允许服务器间GPU动态调度流量到NIC来支持多NIC传输。然而，这带来了几个技术挑战：

中继开销。（§4.1） FuseLink引入灵活的服务器内流量路由跨GPU来解决通过多个NIC传输时的带宽限制。然而，GPU并非天生优化用于中继数据到NIC。相反，GPU和服务器内连接优化用于设备间的内存I/O，这与基于PCIe的NIC不兼容。这种差距强制在网络传输期间频繁设备同步，显著减慢数据路径。例如，当GPU作为中继将数据从其他GPU传输到NIC时，数据必须在NIC访问前完全可用在中继GPU上。这导致中继GPU和发送GPU间的频繁同步。因此，NIC吞吐量与图3中的吞吐量相比仅有微小改进。我们通过内存重映射主动规划中继数据路径来解决此挑战，从而高效中继数据用于多NIC传输。

中断和争用风险。（§4.2,§4.3） 当利用NIC和GPU内存时，维护性能隔离具有挑战性。这些资源可能在数据传输期间争用NIC带宽，可能通过耗尽GPU内存中断任务。因此，服务器间带宽受限于NIC争用，如表2所列。争用的主要原因是FuseLink的策略：在同行工作者不参与通信任务时调度流量到闲置NIC。然而，动态流量机器学习任务中的NIC空闲是暂时的。当同行工作者启动新通信时，FuseLink在空闲期调度的大量流量可能仍在传输。我们通过在中继GPU上优先处理正在进行的任务并使用基于优先级的调度监控网络资源使用来解决此挑战。这种方法使发送者识别闲置NIC并消除中断风险。

调度开销。（§4.4） 动态调度流量到NIC本质上复杂，考虑到缓解争用风险和避免流量干扰及中断的要求，使控制开销的减少成为重大挑战。现有通信调度工作主要关注任务级调度以最大化网络资源利用。然而，它们无法识别闲置NIC资源并高效调度通信。我们通过实现高效的流量监控和调度策略来解决此问题，该策略平衡监控准确性和性能。

FuseLink设计概述。 我们说明FuseLink设计，重点解决上述挑战，实现高NIC利用率而不中断同行GPU。

高效服务器内中继。 高效中继数据跨GPU以在间接NIC上获得高带宽很困难，主要因为GPU互连和服务器间网络不兼容。这种不兼容强制在发送NIC前进行内存复制和设备同步，这会阻塞网络传输并延长消息延迟。

为解决此挑战，我们的洞见是利用通信期间网络缓冲区的现有内存I/O，并通过内存重映射重定向流量。FuseLink通过利用现有虚拟地址系统在不修改现有机器学习框架的情况下实现高效服务器内流量中继。该系统在统一虚拟内存地址空间中管理GPU内存，允许将虚拟内存地址映射到任意物理内存。利用此特性，FuseLink将网络缓冲区与物理内存解耦，并重映射它们到中继GPU上的缓冲区，从而当应用填充网络缓冲区时，通过内存I/O经服务器内连接重定向流量。

为了展示FuseLink使用重映射中继的理由，我们通过检查服务器间通信的两个步骤来探索设计空间。1 GPU工作者填充网络缓冲区，2 GPU通知CPU启动RDMA传输。为了在不修改代码的情况下配置数据路径，我们有以下候选解决方案。D1：修改步骤1，使GPU将数据写入中继GPU上的重映射缓冲区。D2：修改步骤2，使CPU将数据复制到中继GPU然后RDMA。D3：GPU线程将数据写入映射到主机内存的缓冲区。D4：CPU启动到主机内存的内存复制。

在四个候选中继方法中，D3和D4实现与图3中PCIe相同的带宽，因此受PCIe速度限制，无法提升中继效率。然而，D1和D2有优缺点，无法轻松比较。如图5所示。D2在异步批量执行内存复制时具有高服务器内带宽，而D1强制同步内存加载和存储，并涉及额外开销的内存重映射。然而，D1只有一个到中继GPU的复制步骤，实现更高数据路径效率和更低消息延迟。为此，我们设置性能基准来选择最佳服务器内中继方法。

基准间接NIC吞吐量。 我们测试多个GPU服务器上通过间接NIC的GPU通信带宽，配备八通道NVLink和400Gbps NIC。八通道NVLink的理论带宽为200 GB/s。实验通过两个服务器间GPU间不断发送消息进行，通过间接NIC路由流量，使用中继方法D1-D4分别路由从发送GPU到间接NIC的流量。我们记录服务器内流量中继带宽和不同数据块大小下的间接NIC吞吐量。图6展示了服务器内中继带宽和间接NIC吞吐量。

在四个中继方法中，D1相比D2-D4实现了间接NIC上的最高吞吐量。D3和D4通过PCIe路由数据到主机内存，因此受PCIe带宽限制。相反，D1和D2利用NVLink连接，实现更高中继带宽。当比较D1和D2时，我们观察到D2具有更高服务器内中继吞吐量，因为CPU启动的设备间内存复制批量内存复制，比GPU启动的内存复制实现更高吞吐量。

然而，D1实现了最高NIC吞吐量。原因是D1通过内存重映射在GPU和间接NIC间具有最高效数据路径，这带来了以下好处：

1 高间接NIC吞吐量：D1将网络缓冲区重映射到同行GPU，因此当中继完成时GPU填充发送缓冲区。D2引入跨GPU的额外数据复制，限制通过间接NIC的吞吐量。

2 通过间接NIC的低消息延迟：D1在没有额外CPU参与的情况下实现比D2更低的通过间接NIC的消息延迟。与D2的CPU启动中继复制不同，其中GPU必须与CPU同步以信号数据就绪带来额外延迟，D1消除此类同步开销。而且，D1通过与流水线服务器内和服务器间通信重叠来掩盖额外服务器内中继延迟，有效缓解小到中等消息的延迟惩罚。

通过基准测试，我们使用重映射网络缓冲区高效中继流量到间接NIC，因为三个关键性能优势：首先，与GPU间CPU启动数据复制相比，它没有流量的重复数据复制。其次，它有更少的设备同步，因为GPU线程可以直接写入同行GPU。第三，它避免CPU参与，这节省调用内存复制函数的延迟。

无中断中继。 虽然服务器内中继带来NIC吞吐量的显著好处，但它带来中断同行GPU的风险。具体而言，多NIC通信可能占用同行GPU带宽资源，中继GPU上的内存消耗可能耗尽同行GPU内存，导致意外的内存不足（OOM）错误。

无中断通信的中继。 FuseLink仅在间接NIC空闲期间加速GPU通信。虽然在服务器内所有NIC间均匀喷洒流量实现最佳NIC利用率，但它可能干扰或甚至中断通过直接NIC的同行GPU通信。FuseLink在NIC利用率和公平性间取得平衡。这确保同行GPU通信任务不受流量中继中断。

我们在图7中比较FuseLink无中断设计与流量喷洒，其中两个GPU分别通过两个NIC发送数据。第一个GPU有长服务器间流，而第二个GPU是受害者，具有相对短流并不断被第一个GPU中断。相反，FuseLink仅在第二个GPU没有服务器间流量时利用间接NIC，防止不公平问题。FuseLink控制服务器内中继期间的流量体积以避免干扰从事服务器内通信的GPU。在实践中，服务器内GPU通信，如tensor并行中的聚合，与通过NIC的服务器间通信重叠。为确保隔离，FuseLink在TP通信和中继期间标记NIC为忙碌，防止与服务器内通信和其他中继流量的争用。

无中断内存分配的中继。 如果中继GPU上运行任务的内存需求已知，FuseLink可以轻松通过限制中继内存的总大小消除OOM风险。不幸的是，准确计算GPU上运行任务的内存足迹仍然具有挑战性，现有的工作没有精确估计，留下由于中继缓冲区分配导致OOM的风险。为缓解此问题，FuseLink提供结合内存使用约束和自适应方法的尽力而为解决方案。

首先，FuseLink为中继内存使用设置可配置上限。如果GPU上的中继内存超过限制，FuseLink将停止分配更多中继内存，直到现有连接的内存被释放。虽然此限制无法完全消除OOM风险，但它允许FuseLink根据用户需求调整资源分配。例如，可以设置高内存限制以鼓励FuseLink进行更多使用GPU中继的多NIC传输，从而聚合多个NIC的更高带宽。

其次，FuseLink允许通过在释放能帮助满足中继GPU上运行任务的内存分配时移除中继内存来优先考虑运行任务的内存需求。具体而言，当内存耗尽时，FuseLink首先检查释放中继内存是否会释放足够空间。如果是，FuseLink释放中继内存让步给正在进行的任务。否则，这意味着任务无论中继内存如何都会遇到OOM错误。

NIC争用缓解。 我们接下来讨论如何高效利用闲置NIC同时避免GPU工作者争用NIC资源的挑战。这样做很困难，主要因为机器学习应用中不可预测和不均衡的流量。

FuseLink通过在NIC调度期间为来自不同GPU的流量分配不同优先级来缓解NIC争用。FuseLink监控NIC负载状态并标记NIC为忙碌或闲置，指示NIC是否为高优先级GPU工作。当GPU从事通信时，它被授予其直接NIC的最高优先级，防止同行GPU使用该NIC。而且，FuseLink限制调度到闲置NIC的未完成流量，从而减少高优先级GPU启动通信时的潜在争用。我们的方法基于1:1 GPU-to-NIC配置中GPU工作者完全利用其直接NIC的需求。

在通信期间，接收者将闲置NIC编码在信用中并发布给发送者，发送者基于双方NIC状态决定传输数据的NIC。此设计可分解为两个模块：1) §4.3.1 FuseLink通过检查高优先级GPU的完成网络操作来监控NIC负载状态。2) §4.3.2 FuseLink聚合双方闲置NIC以指导流量调度，通过内存重映射配置服务器内路由。

工作者感知的NIC监控。 FuseLink通过监控服务器内机器学习工作者发布的网络操作来标记NIC状态为闲置或忙碌。机器学习工作者通过先进先出（FIFO）队列将网络操作（如发送和接收）发布到FuseLink，而不是直接操作RDMA连接。FuseLink收集网络操作并向NIC发布工作请求。然后FuseLink轮询RDMA完成队列以获取完成的操作。

决定NIC是否闲置的直接解决方案是通过检查NIC TX和RX计数器。然而，读取计数器无法分辨哪个工作者正在发送或接收数据，这阻碍了多个工作者通过同一NIC传输数据时的争用预防。相反，FuseLink从RDMA连接上的工作请求监控NIC工作负载。请注意，我们将NIC状态配置为由在NIC上具有最高优先级的工作者决定。理由是我们旨在隔离流量并保证高优先级工作者的网络性能。

FuseLink通过定期检查高优先级工作者发布网络操作的新完成来识别闲置NIC。如果自上次轮询以来没有新完成，FuseLink将标记NIC为闲置。如图8a所示，NIC1闲置因为W1没有向W3发送数据，NIC0忙碌因为W0正在向W2发送。一旦发现闲置NIC，FuseLink将其他工作者的流量调度到闲置NIC。如果发现新完成，这意味着自上次以来存在新流量，FuseLink将标记NIC为忙碌。在这种情况下，我们不会调度流量到忙碌NIC。FuseLink将低优先级工作者的流量调度到其直接NIC以实现性能隔离。

标记NIC状态为闲置或忙碌的理由是机器学习应用通常有大流量，当它们有通信任务时可以完全占用NIC。因此，我们允许GPU工作者完全占用其直接NIC。如果GPU工作者共享直接NIC，FuseLink不会隔离这些工作者间的流量。

负载感知调度。 我们分三个步骤介绍负载感知流量调度：1) 聚合发送者和接收者侧的NIC负载状态，2) 选择NIC并启动数据传输，3) 通过内存重映射在接收者内部执行服务器内流量路由。

聚合NIC负载状态。 FuseLink通过接收者向发送者提供信用来协调通信，FuseLink配置信用包括接收者上的NIC负载状态。发布信用在RDMA通信中是必要的，因为RDMA的性质绕过远程侧处理器，使发送者不知接收者资源。使用信用的RDMA通信在现有分布式机器学习框架中很常见。获得信用后，发送者知道双方NIC负载状态。

选择发送NIC。 NIC选择基于NIC状态和工作者在NIC上的优先级。FuseLink如果工作者的直接NIC闲置，则选择它。否则，如果存在闲置间接NIC，则选择它。请注意，我们限制发布到间接NIC的未完成操作数量以减少争用风险。没有限制，我们可能向间接NIC发布太多请求，并在高优先级工作者开始通信时导致严重争用。如果没有发现闲置NIC，FuseLink选择直接NIC。

在接收者路由流量。 FuseLink将数据写入驻留在具有直接PCIe连接的GPU上的接收内存，以确保传输效率。然而，该GPU可能不同于请求接收的工作者GPU。在这种情况下，FuseLink将接收地址映射到接收数据所在内存。在发送侧，当获得信用时数据可能已在中继缓冲区上。FuseLink在下一个发送操作前重映射中继内存，代价是一个次优发送。

我们用图8a所示的示例演示流量调度。FuseLink首先在W1没有发布任何流量时识别NIC空闲。然后，对于W0发布的网络操作，FuseLink通过分配指示通过NIC1发送的信用来调度它们到NIC1。FuseLink重映射GPU1上的接收内存以启用高效NIC访问。在发送侧，FuseLink获得信用并向NIC1发布发送操作。因为数据已在GPU0上，数据通过次优数据路径发送。发送完成后，FuseLink重映射中继缓冲区到GPU1，使后续发送高效。

当NIC1上发生流量争用时，如图8b所示，FuseLink在W1向NIC1发布网络操作并获得完成时检测争用。在这种情况下，FuseLink执行类似于利用闲置NIC的步骤。FuseLink将后续网络操作调度回NIC0，并重映射路由内存以优化数据路径。

高效调度。 FuseLink在服务器中检测到闲置NIC时调度通信到多个NIC。我们的NIC监控和流量调度设计不强制严格的闲置NIC利用或精确争用预防，这由于控制平面效率要求难以实现。相反，我们有以下权衡以实现控制平面效率：

首先，FuseLink基于GPU工作者发布操作的新完成标记NIC负载状态，这晚于传输开始时间。延迟标记比检测NIC是否为GPU工作者发送流量更高效。延迟是可接受的，因为现有框架如NCCL将大消息分成块并在流水线中发送。在NCCL中，默认配置是512KB，这使延迟标记在400Gbps网络下约为10us。

其次，FuseLink允许有限数量网络操作的有限争用。在最坏情况下，FuseLink向闲置间接NIC调度一批操作，而同行工作者立即开始通信。这确保FuseLink流量调度的可扩展性在大型GPU集群中，因为FuseLink仅需要在通信期间收集同行节点的NIC利用信息。调度开销由NIC数量和并发连接决定，这些受硬件配置和机器学习应用限制。

第三，FuseLink允许有限的通过间接NIC的次优传输，因为选择的NIC可能到路由GPU有次优数据路径，如图8b在接收者调度期间所示。我们通过发送者重映射限制次优传输，假设下一个发送操作有最佳数据路径。我们的设计基于机器学习流量模式，即NIC负载状态不频繁变化，因为机器学习计算和通信持续长时间间隔。

优化后，控制平面开销主要来自以下组件：

NIC监控开销。 在发布操作前，FuseLink检查NIC状态并决定如何路由流量。为减少监控开销，FuseLink在发布一批网络操作后检查NIC状态。例如，FuseLink在调度八个网络操作后检查NIC状态。后续操作根据最后一批后的NIC状态调度。粗粒度NIC监控带来可接受的调度开销，因为机器学习应用通常有大消息大小并受带宽限制。

流量路由开销。 当NIC遇到空闲或争用时，FuseLink重映射接收者中继缓冲区并通过向发送者发布信用切换连接。开销包括检查NIC状态、获取新连接和重映射中继缓冲区。流量重路由发生在NIC状态变化时。在机器学习中，NIC使用显示典型开-关模式。因此，NIC状态不会频繁变化，带来有限的流量路由开销。

实现概述。 我们将FuseLink实现为独立网络模块，以替换NCCL中的默认Infiniband网络，NCCL是广泛使用的GPU通信库，从而机器学习应用无需修改代码即可使用FuseLink。我们通过拦截NCCL代理线程调用的网络层函数将FuseLink整合到NCCL中，这些线程原本向NIC发布RDMA工作请求。加载插件后，NCCL代理线程与FuseLink交互进行GPU通信，而不是直接操作NIC。我们的实现有约3000行C++代码。

在默认实现中，NCCL设置工作者线程作为代理，通过服务器间网络与同行GPU通信。代理线程构建RDMA连接并向NIC发布工作请求。机器学习进程通过写入代理线程处理的网络缓冲区发送数据。当接收数据时，机器学习进程指示接收缓冲区，并在数据就绪时从代理线程得到通知。

我们拦截代理线程函数调用以与FuseLink交互，包括连接建立、网络缓冲区注册和发送/接收数据。

连接建立。 代理线程不是构建原始RDMA连接，而是通过向FuseLink发布连接请求修改，FuseLink通过服务器内多个NIC设置连接来处理请求。连接设置后，代理线程获得用于发布发送和接收操作的连接ID。所有网络操作通过使用连接ID向FuseLink发布控制消息进行。

注册缓冲区。 默认情况下，NCCL在指定设备上注册缓冲区以启用RDMA NIC访问网络缓冲区。我们修改代理线程向FuseLink暴露网络缓冲区，FuseLink将缓冲区重映射到中继GPU并在RDMA NIC上注册网络缓冲区。由于每个缓冲区仅需在NIC注册一次，重映射到中继带来微小开销。请注意，当NIC争用出现时，FuseLink将网络缓冲区映射回原始GPU。因此，我们在中继GPU和原始GPU上注册网络缓冲区以避免重复注册。注册的内存区域基于网络缓冲区当前映射到的GPU选择。

发送与接收。 在NCCL中，高级通信任务，如发送大数据块和集体通信，被分成数据块。

在发送侧，如果没有收到新信用，发送函数返回空句柄。收到有效信用后，NCCL使用信用中指定的环槽和连接发送数据。如果环槽缓冲区在与选择的NIC不直接连接的GPU上，这意味着接收者为数据传输调度了间接NIC。FuseLink标记间接NIC并将数据重映射到中继GPU上的缓冲区。如果到中继GPU的数据传输成功启动，发送函数返回有效句柄。数据在中继缓冲区就绪后，发送者使用RDMA启动到远程侧的数据传输。

在接收侧，FuseLink收集NIC使用状态以识别闲置NIC和争用NIC。对于每个通道，FuseLink通过向发送侧提供指定NIC上连接的信用来分配一个NIC处理接收请求。FuseLink通过更改用于接收数据的环槽中的RDMA队列对（QPs）和内存地址来调度流量到其他NIC上的连接，这对应用透明。

A4 实验环境

数据集名称、规模及用途。 使用公共跟踪[5, Microsoft AzurePublicDataset, 2023]随机采样服务提示，用于解耦LLM服务测试，模拟Poisson到达率；Mixtral 8×7B和8×22B模型用于MoE训练；Criteo广告数据集[4, Criteo Display Advertisement Dataset, 2014]用于DLRM训练，配置为32个GPU工作者在数据并行中训练模型；Avazu数据集[61, Click-through rate prediction, 2014]用于DeepFM测试。

模型架构关键参数。 OPT模型[67, OPT: Open pre-trained transformer language models, 2022, arXiv]，30B参数，不同tensor并行度；Mixtral 8×7B和8×22B模型[18, Switch transformers: Scaling to trillion parameter models with simple and efficient sparsity, 2022, Journal of Machine Learning Research]，专家并行度8，tensor并行度4；DeepFM模型[22, DeepFM: A factorization-machine based neural network for CTR prediction, 2017, arXiv]用于推荐；DLRM模型[10, Understanding training efficiency of deep learning recommendation models at scale, 2021, IEEE International Symposium on High-Performance Computer Architecture (HPCA)]，训练批次大小1024，不同缓存大小（GB）。

硬件配置。 服务器配备Intel 8480C CPU、八个Nvidia Hopper GPU、八个Connect-X7 400Gbps NIC用于服务器间GPU通信；服务器内GPU通过八通道NVLink和NVSwitch连接，提供高达200GB/s带宽；每个NIC通过PCIe桥直接连接一个GPU；对于DLRM，专用服务器维护嵌入表。

软件配置。 FuseLink作为NCCL插件实现，基于RDMA原语；NCCL启用PXN作为基线；C++实现，约3000行代码；操作系统未指定，但兼容现有GPU集群。

A4 实验结果

微基准：带宽改进。 实验评估FuseLink在两个服务器间GPU间传输数据时的带宽改进。将发送数据分成512K消息（NCCL中常见大小）并发布到FuseLink控制器。基线中，流量静态绑定到一个NIC。FuseLink通过直接和间接NIC发送，使用GPU中继。改变FuseLink使用的最大NIC数量并记录平均带宽。如图9所示，FuseLink使用六个NIC实现高达212GBps带宽，相比默认设置的约50GBps（仅一个NIC），通过利用更多NIC获得更高带宽。上限取决于GPU和NIC间的瓶颈：如果NVLink带宽大于间接NIC带宽总和，FuseLink可聚合所有NIC带宽；否则，最大为直接NIC带宽加NVLink带宽。在此实验中，FuseLink带宽停止缩放因为NVLink达到最大吞吐量（来源：图9）。

微基准：调度开销。 实验评估FuseLink在处理RDMA操作和调度时的开销。NIC监控和NIC选择使用共享内存，实现0.9-1.6us延迟在一批网络操作上。中继重映射在优化NIC和GPU间数据路径时调用，每次重映射带来约95-193us延迟（来源：表3）。图10展示了FuseLink改变NIC以防止争用时的调度开销分解，包括刷新数据、改变NIC和重映射，总开销相对于分布式机器学习中的通信时间很小（来源：图10、表3）。

端到端评估：模型服务。 在解耦设置中测试FuseLink性能，将服务过程分为预填充和解码阶段跨服务器间GPU。测试OPT 30B模型在不同tensor并行度下，使用混合请求从公共跟踪采样，模拟Poisson到达率。通信成本包括发送前缀缓存和用户请求缓存。记录首令牌时间（TTFT）作为指标，包括请求计算和服务器间通信时间。图11a-11c展示了不同服务器内独立服务实例数量下的TTFT CDF图。FuseLink相对于NIC绑定的基线显示1.04-2.73倍加速，其中GPU仅通过直接NIC通信。特别是在较小TP度和更多实例下，FuseLink显示更大加速，因为NIC显示更多动态流量模式。改进归因于加速间阶段数据传输和提升服务吞吐量减少队列时间。表4展示了不同服务实例数量下的50th和99th百分位TTFT（来源：图11、表4）。

端到端评估：EP训练。 测试Mixtral 8×22B模型的专家并行MoE训练，tensor并行度4，专家并行度8，每个服务器有两个专家并行训练。记录训练迭代时间。图12展示了基线和FuseLink的迭代时间。FuseLink相对于基线提升训练吞吐量1.3倍。我们注意到FuseLink在后期迭代中带来较少性能增益，这可解释为门层设计试图在专家间实现负载平衡，使NIC间流量更接近均衡负载（来源：图12）。

端到端评估：DLRM训练。 在Criteo数据集上测试FuseLink在DLRM训练中的性能。配置32个GPU工作者在数据并行中训练模型，专用服务器维护嵌入表。每个迭代，GPU工作者转换分类特征为嵌入向量，如果缓存未命中则通过NIC从嵌入服务器获取。通信成本受嵌入缓存大小和训练批次大小影响。设置批次大小为1024。图13展示了不同缓存大小下使用FuseLink和静态绑定到直接NIC的平均迭代持续时间。FuseLink通过加速嵌入传输有效减少训练迭代时间（来源：图13）。

其他实验：中断风险。 图7比较了直接NIC通信、流量喷洒和FuseLink无中断中继下长流和短流的性能，FuseLink防止不公平问题，仅在没有服务器间流量时利用间接NIC（来源：图7）。

A5 结论

论文结论是：FuseLink启用服务器间GPU通过多个NIC高效通信，通过利用专用服务器内网络进行服务器内流量路由，充分利用GPU互连用于NIC通信。FuseLink在不中断同行GPU上正在进行的计算和通信任务的情况下实现提升的服务器间带宽。通过评估，验证FuseLink在动态流量机器学习任务中有效，实现高服务器间GPU带宽并加速包括LLM服务、EP MoE训练和DLRM训练的任务。

对未来工作的展望包括：在集体通信中应用FuseLink，可能需要调整工作者放置以产生不均衡流量；在一般GPU互连中扩展FuseLink，如不对称互连和其他GPU-NIC比率，利用标准通信原语确保通用性；处理调度中的角案例，如小块数据传输时的有限争用，但这些在机器学习负载中罕见。

汇总方法细节中的引用

方法细节中引用的参考文献汇总如下，每个包括编号、内容描述、引用段落及原文描述：

• [1, Gloo: Collective communications library with various primitives for multi-machine training, URL: https://github.com/facebookincubator/gloo]：在3 FuseLink Overview中引用，描述为静态绑定流量到NIC或中间GPU的对比，原文："Instead of statically binding traffic to NICs or intermediate GPUs [1, 44, 45]"。

• [6, Nvidia Unified Addressing, URL: https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA UNIFIED.html]：在4.1 Efficient Intra-server Relaying中引用，描述为利用虚拟地址系统管理GPU内存，原文："by taking advantages of the existing virtual address systems [6]"。

• [17, FaRM: Fast Remote Memory, 2014, 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14), URL: https://www.usenix.org/conference/nsdi14/technical-sessions/dragojeviĢG]：在3 FuseLink Overview中引用，描述为RDMA启用应用中信用的常见性，原文："Credits are common in RDMA-enabled applications [17, 28, 45, 62]"。

• [19, Estimating GPU memory consumption of deep learning models, 2020, Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering]：在4.2 Interruption-free Relaying中引用，描述为计算运行任务内存足迹的挑战，原文："accurately calculating the memory footprint of a running task on GPUs remains challenging, and existing works do not have precise estimations [19]"。

• [24, ARK: GPU-driven Code Execution for Distributed Deep Learning, 2023, 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), URL: https://www.usenix.org/conference/nsdi23/presentation/hwang]：在3.1 Challenges中引用，描述为GPU优化用于内存I/O与PCIe NIC不兼容，原文："both GPUs and intra-server connections are optimized for memory I/O between devices [24, 30]"。

• [28, Design guidelines for high performance RDMA systems, 2016, 2016 USENIX Annual Technical Conference (USENIX ATC 16), URL: https://www.usenix.org/conference/atc16/technical-sessions/presentation/kalia]：在3 FuseLink Overview中引用，同[17]，原文同上。

• [30, Evaluating modern GPU interconnect: PCIe, nvlink, NV-SLI, nvswitch and gpudirect, 2020, IEEE Transactions on Parallel and Distributed Systems]：在3.1 Challenges中引用，同[24]，原文同上；在4.1中引用，描述为设备间内存I/O优化，原文："both GPUs and intra-server connections are optimized for memory I/O between devices [24, 30]"。

• [34, Understanding communication characteristics of distributed training, 2024, Proceedings of the 8th Asia-Pacific Workshop on Networking, APNet ’24]：在4.3.1 Worker-aware NIC Monitoring中引用，描述为机器学习应用有大流量可占用NIC，原文："ML applications typically have large traffic that can fully occupy NICs when they have communication tasks [34]"。

• [44, Doubling all2all performance with NVIDIA collective communication library 2.12, URL: https://developer.nvidia.com/blog/doubling-all2all-performance-with-nvidia-collective-communication-library-2-12/]：在3 FuseLink Overview中引用，同[1]，原文同上。

• [45, Nvidia NCCL, URL: https://developer.nvidia.com/nccl]：在3 FuseLink Overview中多次引用，描述为NCCL使用信用和RDMA，原文同[17]；也在5 Implementation中引用，描述为NCCL代理线程和缓冲区注册。

• [51, CASSINI: Network-Aware job scheduling in machine learning clusters, 2024, 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), URL: https://www.usenix.org/conference/nsdi24/presentation/rajasekaran]：在3.1 Challenges中引用，描述为现有调度关注任务级，原文："Existing works on communication scheduling focus mainly on task-level scheduling [51, 64, 65]"。

• [62, Fast RDMA-based ordered Key-Value store using remote learned cache, 2020, 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20), URL: https://www.usenix.org/conference/osdi20/presentation/wei]：在3 FuseLink Overview中引用，同[17]，原文同上。

• [64, GREEN: Carbon-efficient resource scheduling for machine learning clusters, 2025, 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25), URL: https://www.usenix.org/conference/nsdi25/presentation/xu-kaiqiang]：在3.1 Challenges中引用，同[51]，原文同上。

• [65, Design and operation of shared machine learning clusters on campus, 2025, Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1, Asplos ’25]：在3.1 Challenges中引用，同[51]，原文同上。