FuseLink Multi-NIC Communication

导言

一台服务器装有八张 400 Gbps NIC，不等于任意一张 GPU 都能拿到八张网卡的总带宽。现有 GPU 集群通常把 GPU 与“最近的”NIC 静态绑定；当 LLM 推理请求、MoE token 或推荐模型 embedding 产生不均衡流量时，热点 GPU 会堵在一张 NIC 上，旁边的 NIC 却可能空闲。

OSDI 2025 论文 FuseLink 的核心思想，是把 NVLink/NVSwitch 从“服务器内部的 GPU 互连”重新解释为“跨服务器网络的数据路径延伸”：流量先经 NVLink 到达更适合访问空闲 NIC 的中继 GPU，再通过 RDMA 发往远端。本文沿论文 Figure 1、2、3、4、5、8 还原这条设计链，并用其余实验结果说明收益、代价与边界。

八张 NIC 同时存在，真正稀缺的却不一定是 NIC 数量，而是流量重新取得这些 NIC 使用权的能力。这是我读完 FuseLink 论文 后认为最值得保留的判断。

八张网卡为何仍堵在一张

常见 GPU 服务器把每张 GPU 的跨机流量绑定到一张 PCIe 路径最短的 NIC。这样做很合理：直连 NIC 能给出稳定的满带宽，拓扑和路由也容易预测。问题是，它隐含了三个条件：每个 worker 都经直连 NIC 发送、各 worker 同时通信、流量体量大致相等。

动态 AI 负载很少同时满足这三个条件。

论文 Figure 1，完整保留两组对比与原始图注。左侧把 GPU 流量固定给专属 NIC；右侧 FuseLink 把 NVLink、PCIe 与 NIC 组合成可动态选择的数据路径。

Figure 1 的右图不是说 GPU 可以无代价地访问任意 NIC，而是先把“专属 NIC”抽象成一个共享资源池。之后还要回答两个更难的问题：哪些 NIC 此刻真的空闲，以及间接访问这些 NIC 是否仍有足够带宽。

论文先在八张 Hopper GPU、八张 400 Gbps NIC 和 eight-lane NVLink 的服务器上观察三类负载：

• 分离式 LLM serving：prefill 完成后向 decode 发送请求状态与 prefix cache；到达时间和请求长度随机，使各实例呈现不同的 on-off 流量。
• Expert Parallel MoE：gate 为不同 token 选择不同 expert，即使 expert 数量平均分配，跨 worker 的 all-to-all 数据量仍不相等。
• DLRM：不同 worker 的 embedding cache miss 和传输量不同，最慢 worker 决定一次迭代何时结束。

论文 Figure 2，完整保留四个子图与原始图注。(a) 关联平均 NIC 利用率与通信成本；(b) 展示 serving 中 NIC 轮流忙闲；(c) 是 expert 间不均衡流量矩阵；(d) 是 DLRM worker 的归一化流量。

Figure 2 的四个子图应连起来读：

1. 利用率影响关键路径。 图 (a) 中 NIC 利用率越接近理想值，通信在总耗时中的占比越低；这只是估算出的机会空间，不是 FuseLink 的端到端加速曲线。
2. 不均衡的形态并不统一。 Serving 是时间维度上的 on-off，MoE 是 expert 对之间的二维稀疏矩阵，DLRM 则是 worker 之间不同的流量体量。很难在任务启动前用一份静态映射同时解决。
3. 资源不足与资源闲置可以同时发生。 论文 Table 1 报告 LLM serving、EP 和 DLRM 的 NIC 利用率分别只有 13%–53%、29%–65% 和 59%–82%。热点 worker 被自己的 NIC 限制时，其他 NIC 并没有自动加入关键路径。

图 2 没有证明什么

Figure 2 证明了作者测试环境中存在可利用的流量不均衡，但没有证明“所有 AI 负载都不均衡”。Ring AllReduce 一类同步 collective 往往产生更规则、均匀的通信，反而不是 FuseLink 最适合的场景。

为什么不能直接喷向所有 NIC

既然 NIC 会空闲，最直接的想法是把一个 GPU 的流量 striping 到多张 NIC。可这只移动了瓶颈：同一 GPU 的 PCIe 接口有总带宽上限，非直连 NIC 还可能穿过 PCIe root complex、CPU memory 甚至跨 NUMA 的 UPI。

论文 Figure 3，完整保留拓扑、三条路径、带宽与原始图注。作者环境中直连 PCIe bridge 为 49.3 GB/s，经 CPU memory 为 23.7 GB/s，跨 UPI 只剩 12.0 GB/s。

Figure 3 给出了一个非常具体的约束：NIC 在机器里，并不代表它对每张 GPU 都是等价的。 图中的 49.3、23.7 和 12.0 GB/s 是作者机器上的测量，不应外推为所有 PCIe/NUMA 拓扑的固定值；但相对关系足以说明，直接让源 GPU 穿过任意 PCIe 路径，无法可靠地聚合多 NIC 带宽。

FuseLink 因此增加一个中继动作：源 GPU 先经 NVLink 把数据交给与目标 NIC 直连的 GPU，再由该 GPU 上的 buffer 通过 RDMA NIC 发出。数据路径由

source GPU -> indirect PCIe path -> NIC

变成

source GPU -> NVLink/NVSwitch -> relay GPU memory -> direct PCIe path -> NIC

这不是绕路吗？从跳数看是；从瓶颈看未必。前提是 NVLink 中继带宽高于原来的间接 PCIe 路径，而且中继不能把 relay GPU 自己的计算、通信和显存挤坏。

FuseLink 如何改写数据路径

FuseLink 在 NCCL 的 network layer 下接管连接建立、buffer 注册和 send/recv。NCCL proxy thread 不再直接向固定 RNIC 提交 work request，而是把网络操作交给 FuseLink；FuseLink 维护多 NIC 的 RDMA Queue Pair、监控每张 NIC 的负载，并选择本轮数据应落在哪张 GPU 的 relay buffer。

论文 Figure 4，完整保留架构、控制/数据路径、relay buffer 与原始图注。示例中 W1 没有发送流量，W0 除 NIC0 外还经 GPU1 memory 使用 NIC1。

Figure 4 里需要分清四类对象：

• Worker 与应用 buffer：W0–W3 仍按 NCCL 原有接口提交通信，应用看到的网络 buffer 虚拟地址不因选 NIC 而改变。
• Relay buffer：实际物理内存可位于源 GPU，也可位于更适合访问某张 NIC 的 peer GPU；它会消耗中继 GPU 的显存并跨多次 chunk 传输存在。
• 控制路径：worker 通过 shared-memory queue 把操作交给 scheduler；虚线不承载 payload。
• 数据路径：粗实线从 worker 写入实际映射的 GPU memory，再由相应 NIC 的 QP 发出。示例中 W0 的一部分数据经 NVLink 写到 GPU1 memory，随后走 NIC1。

完整过程可以压缩成五步：

1. 探测拓扑。 初始化时发现 GPU、NIC、PCIe 与 NVLink 关系，为每个 GPU-NIC 组合选择直连路径或 relay GPU，并建立 RDMA connections。
2. 接收方发 credit。 Credit 包含接收 memory region、请求大小和接收端空闲 NIC；RDMA 绕过远端处理器，发送方必须先得到这些资源信息。
3. 发送方合并两端状态。 Scheduler 同时考虑本端 NIC 与 credit 中的远端 NIC 状态，优先选择 direct NIC，必要时选择双方都可用的 indirect NIC。
4. 重映射并传输。 网络 buffer 被映射到合适的 relay GPU physical memory；GPU producer 在填充 buffer 时就沿 NVLink 完成中继，随后 RNIC 读取该 memory。
5. 接收端归位。 数据可能先到与接收 NIC 直连的 router GPU，再经服务器内部互连到真正请求数据的 GPU。

这里移动的是 buffer 的物理承载位置与后续 payload；credit、NIC 状态和 QP 选择属于控制信息。把这两个平面混在一起，很容易误以为 CPU scheduler 在搬运数据。

重映射为何胜过事后 memcpy

让 relay GPU 取得数据至少有两种做法。Figure 5 把最重要的 D1、D2 摆在一起：左侧在 producer 写网络 buffer 时就改变物理去向，右侧则等原 buffer 就绪后再由 CPU 发起一次 GPU 间 memcpy。

论文 Figure 5，完整保留 D1、D2、图例与原始图注。D1 将 network buffer 重映射到 GPU1；D2 先在 GPU0 产出，再由 CPU 发起 GPU0 到 GPU1 的异步复制。

两条路径的差异不在“是否经过 NVLink”，而在 NVLink copy 何时成为数据生产的一部分：

• D1：写入即中继。 应用仍写同一个虚拟 network buffer，但其 physical memory 已映射到 GPU1。GPU0 的 producer store 经 NVLink 直接落到 relay buffer，不再保留旧 mapping，也不需要 CPU 等待 ready 后补一次 copy。
• D2：产出后再中继。 GPU0 先完成本地 network buffer，通知 CPU；CPU 发起 GPU0 到 GPU1 的异步 memcpy，等 relay buffer 就绪后才能继续 RDMA。

有一个反直觉结果：论文 Figure 6 显示 D2 的纯 GPU 间批量 memcpy 带宽高于 D1 的逐次 load/store，但 D1 的间接 NIC 吞吐反而最高。D1 少了一份重复数据拷贝和一次 GPU-CPU 同步，还能把中继与分块的跨机传输流水重叠。系统优化关心的是端到端关键路径，不是其中某个 copy primitive 的峰值。

论文只说明 FuseLink 利用虚拟地址机制解耦 network buffer 地址与 physical memory；它没有公开列出具体 CUDA API 调用。CUDA 的 Virtual Memory Management 文档 可以解释“地址与内存分离”的通用机制，但不能代替 FuseLink 源码证据。

重映射不是免费午餐

Relay buffer 会占用 peer GPU 显存。FuseLink 为 relay memory 设置可配置上限，并在释放 relay memory 足以满足本地任务时优先归还；这是一种 best-effort OOM 缓解，不是严格内存隔离。论文也报告一次 remapping 约需 95–193 μs，因此只有在足够大的消息和稳定的 on-off 阶段中才容易摊薄。

调度器如何借网卡又不抢网卡

空闲只是一种瞬时状态。W0 刚把长流量借给 NIC1，W1 可能马上恢复通信并需要自己的直连 NIC1。如果 FuseLink 继续平均喷洒流量，W1 会被低优先级中继流量拖慢。

论文 Figure 8，完整保留六个阶段、两个子图与原始图注。原图为简化 credit 省略了 memory region 等常规字段；蓝色表示 W0/W2 路径，绿色表示恢复通信的 W1/W3 路径。

Figure 8a 展示“借用”：

1. 接收端在 credit 中报告 NIC2、NIC3 空闲；
2. W0 先走自己的 direct NIC；
3. scheduler 再选择 idle indirect NIC，并通过 relay GPU 扩展 W0 的数据路径。

Figure 8b 展示“归还”：

1. 原 NIC owner W1 恢复提交操作，completion 表明 NIC 已重新忙碌；
2. credit 不再公布 idle NIC，W0 后续操作回到 direct NIC；
3. scheduler 调整 sender routing 与 relay buffer mapping。

FuseLink 不只读取 NIC TX/RX counter，而是观察高优先级 worker 的 RDMA work request completion。原因是隔离依赖身份：看到 NIC 有流量还不够，必须知道是不是该 NIC 的 direct owner 正在使用。每个 GPU 在自己的 direct NIC 上拥有最高优先级，peer worker 只能借用空档。

这套调度刻意接受三个有界误差：

• 状态晚一点。 “busy”由新 completion 触发，晚于真实发送开始；论文以 NCCL 默认 512 KB chunk、400 Gbps 网络估算约 10 μs 延迟。
• 争用留一点。 Scheduler 限制发往 indirect NIC 的 outstanding operations，但不追求零争用；owner 恢复时可能仍有少量低优先级请求在途。
• 坏路径走一次。 NIC 状态变化后，当前 chunk 可能先走一次 suboptimal path，重映射只保证后续发送回到更优路径。

这不是实现妥协之外的瑕疵，而是论文另一层重要思想：用大消息、分块流水和较长 on-off 周期换取低成本的近似调度，不在 microsecond 控制面里追求全局精确状态。

实验究竟支持到哪里

论文实验平台包含 Intel 8480C CPU、八张 NVIDIA Hopper GPU、八张 ConnectX-7 400 Gbps NIC，以及经 NVSwitch 连接、上限约 200 GB/s 的 eight-lane NVLink。基线是启用 PXN 的 NCCL；NVIDIA 对 PXN 的说明显示，PXN 同样能经 NVLink 使用中间 GPU，但它主要为固定拓扑选择路径和聚合消息。论文强调 FuseLink 进一步动态发现 idle NIC、在收发两端重路由，并聚合多 NIC 带宽。

单 GPU 跨机带宽

FuseLink 把 NCCL 约 50 GB/s 的单 NIC 基线提升到使用六张 NIC 时的 212 GB/s。论文给出的近似上界是：

$$
B_{\text{FuseLink}}
\lesssim
B_{\text{direct NIC}}
+
\min!\left(B_{\text{NVLink}}, \sum B_{\text{indirect NICs}}\right).
$$

B_direct NIC 是源 GPU 的直连 NIC 带宽，B_NVLink 是中继数据能穿过服务器内部互连的聚合带宽，右侧求和是可用间接 NIC 带宽。实验到六张 NIC 后不再线性增长，限制来自 NVLink 已接近饱和，而不是 NIC 数量用完。

控制面成本

论文 Table 3 报告：post/pull operation 为 0.8–1.4 μs，查询 NIC load 为 0.9–1.6 μs，处理 send 为 2.8–3.5 μs，处理 recv 为 4.9–5.6 μs；一次 relay remapping 为 95–193 μs。作者通过批量检查 NIC 状态、限制 outstanding indirect operations，把这些成本摊到大消息的通信时间里。

端到端负载

• OPT-30B 分离式 serving：不同实例数和 TP degree 下，TTFT 相对 NIC binding 改善 1.04–2.73×。实例越多、流量越动态，收益通常越明显。
• Mixtral 8×22B EP training：TP=4、EP=8 时吞吐最高改善 1.3×；后期 gate 逐渐平衡 expert load，NIC 流量更均匀，FuseLink 收益随之缩小。
• DLRM training：32 个 GPU worker 与独立 embedding server 的测试中，迭代速度最高改善 1.2×；收益取决于 embedding cache size 和 cache miss 带来的跨机传输量。

这些数字证明的是作者硬件、模型、流量和 NCCL PXN 基线下的收益。论文正文与官方页面没有给出可供本文独立审计的源码仓库；“约 3000 行 C++、以 NCCL network plugin 部署、应用无需改代码”目前只能视为论文报告的实现事实，而不是本文完成过源码复核或复现实验的结论。

适用边界与我的判断

FuseLink 最适合以下组合：多 GPU、多 NIC、服务器内部 GPU 互连明显快于间接 PCIe 路径，且应用产生大块、分阶段、跨 worker 不均衡的 point-to-point 流量。分离式推理的 KV/prefix cache、EP token dispatch 与不均匀 embedding 传输都符合这个画像。

不应直接外推的场景包括：

• 均匀 collective：Ring AllReduce 等通信让各 NIC 同步工作，没有足够 idle NIC 可借；论文认为需要重排 worker placement 等额外改造。
• 高频短流量：状态可能在调度、credit 往返和 remapping 完成前已经变化，有界争用与一次 suboptimal send 的占比会上升。
• 显存极紧张任务：relay buffer 上限只能控制新增占用，不能给未知模型峰值提供严格 OOM 保证。
• 非 NVIDIA 平台：论文认为统一寻址、peer memory access 与标准 RDMA primitive 具有可迁移性，但实验只覆盖 NVIDIA Hopper、NVLink/NVSwitch 与 ConnectX-7。

我的判断是，FuseLink 最有价值的不是“212 GB/s”这个单点数字，而是三层设计方法：

1. 先重画资源边界。 原本属于 scale-up 域的 NVLink 被纳入 scale-out 数据路径，空闲 NIC 才真正成为可调度资源。
2. 让优化进入数据生产路径。 D1 没有追求最高 memcpy 带宽，而是用地址重映射消掉额外 copy 与同步，缩短端到端关键路径。
3. 用工作负载规律降低控制成本。 Scheduler 不构建昂贵的全局精确视图，而是利用大 chunk、on-off 周期和 direct-owner 优先级，把错误限制在可接受范围。

回到开头：八张 NIC 的问题从来不只是“总带宽有多少”，而是热点 GPU 能否在正确时刻，以不伤害邻居的方式，取得空闲 NIC 的可用数据路径。FuseLink 给出的答案是 NVLink 中继、buffer 重映射和 worker-aware credit scheduling；论文证明它在动态点对点 AI 负载上成立，也坦率留下了 collective、短流量、显存隔离和跨硬件验证的边界。

参考资料

• Zhenghang Ren et al., Enabling Efficient GPU Communication over Multiple NICs with FuseLink, OSDI 2025, pp. 91–108.
• FuseLink 论文 PDF，本文 Figure 1、2、3、4、5、8 均从该版本完整裁取。
• NVIDIA, Doubling all2all Performance with NVIDIA Collective Communication Library 2.12，PXN 的官方背景。
• NVIDIA, CUDA Virtual Memory Management API，用于理解虚拟地址与 physical memory 解耦的通用机制。