使用 RDMA 和 NCCL 解读 GPU 网络：InfiniBand、RoCE 与 Kubernetes 部署

状态：草稿（更新于 2026-10-06）。 本文以官方文档核实的内容为基础， 仅限使用软件 RoCE（rxe）亲自查看的部分（第 10 节末尾的「实测」） 是在一次性虚拟机中测得的数值。并未针对真实的 RDMA 硬件和 GPU 进行测量。 请先阅读文末的「核实过的版本与日期」和「未核实的内容」。 编写规则：以实测数据为基础，未测得的内容标记为「未实测」。

目录

• 摘要
• 1. 为什么 TCP 不够用
• 2. InfiniBand 与 RoCE v2
• 3. 层级与带宽
• 4. GPUDirect RDMA 与 GPUDirect Storage
• 5. NCCL
• 6. 测试方法
• 7. 常见故障
• 8. Kubernetes 中的 RDMA
• 9. 推理中需要 RDMA 的场景（与第六篇相连）
• 10. 动手尝试
  • 实测：通过软件 RoCE（rxe）复现 verbs 流量与两类故障
• 外部依据：通过论文和官方资料核实的内容
• 11. 面试常见问题
• 12. 常见误区
• 参考资料（实际打开过的资料）
• 核实过的版本与日期、未核实的内容

摘要

当多张 GPU 共同计算同一个模型时，通信便决定了性能。在服务器内部有 NVLink，而在服务器之间则由支持 RDMA（Remote Direct Memory Access）的 InfiniBand 或 RoCE（RDMA over Converged Ethernet）网络负责此项工作。NCCL（NVIDIA Collective Communications Library）则会检测这些层级并调度集合通信（如 all-reduce 等）。本文将探讨各层级的带宽差异、RoCE 复杂的原因、NCCL 环境变量与测试工具、故障排查顺序以及 Kubernetes 配置。

读完本文后能够在面试中解释的内容

1. TCP 不够用的原因，以及 InfiniBand 与 RoCE v2 的区别（特别是 PFC、ECN 在 RoCE 中所起的作用以及配置错误时的症状）。
2. NCCL 如何执行集合通信， nccl-tests 如何读取 busbw，多节点性能下降时的排查顺序。
3. Kubernetes 中 Pod 使用 RDMA 所需的组件，以及推理中需要 RDMA 的场景（KV 传输、专家并行、模型加载）。

作者背景。 我目前在普通以太网（1~2.5GbE 级别）环境中进行实验，没有 RDMA、InfiniBand、NVLink 和 VAST 的经验。本文是通过阅读官方文档整理而成的，并非运维经验谈。动手尝试的范围仅限于力所能及的范围内，未实际运行过的内容均已标注。

1. 为什么 TCP 不够用

根据 Dynamo 文档，RDMA 允许网络适配器直接将数据从一个主机的内存传输到另一个主机的内存（若使用 GPUDirect RDMA 则直接从 GPU 传输到 GPU），而无需经过 CPU、内核以及 TCP/IP 协议栈。通常，TCP 会伴随用户缓冲区与内核缓冲区之间的复制、系统调用以及中断。而由于 RDMA 由 NIC 直接读取和写入预先注册（ibv_reg_mr）并固定（pin）了页面的内存，因此能够实现内核旁路（kernel bypass）和零拷贝（zero-copy）。速度差距在算术上也非常巨大。1GbE 为 0.125GB/s，而 400Gb/s NIC 为 50GB/s，达到了 400 倍。因此，TCP 只是在没有 RDMA 时的替代路径（NCCL_IB_DISABLE=1 如果为真，NCCL 会退回到 IP 套接字）。

2. InfiniBand 与 RoCE v2

RoCE v1 仅使用以太网链路层，适用于单一广播域，而 v2 搭载了 UDP/IP 从而支持路由（维基百科）。

RoCE 复杂的原因。 由于 RDMA 对丢包非常敏感，因此在以太网中必须防止或减少丢包。NVIDIA Cumulus 文档解释了两种手段。PFC（Priority Flow Control）通过按优先级进行逐跳暂停来防止缓冲区溢出，而 ECN（Explicit Congestion Notification）则在交换机对拥塞数据包进行标记时，由接收端 NIC 发回 CNP（Congestion Notification Packet）以降低发送速率。在默认配置中，RoCE 数据使用优先级 3，CNP 使用优先级 6 的严格优先队列。Onyx 文档区分了无损（全网 PFC）、半无损（仅在主机与机架顶层交换机之间启用 PFC）以及有损（无 PFC）模式。DCQCN（SIGCOMM 2015）是一种基于 ECN 的 RoCE v2 拥塞控制技术，旨在减少 PFC 的副作用。根据摘要显示，它已在 Mellanox NIC 中实现并部署在微软数据中心。DCQCN 并不能替代 PFC。论文第 7 节指出，如果丢包率超过 0.1%，吞吐量就会急剧下降，因此 PFC 依然是必需的。PFC 可能会引发全网死锁（微软 2016 年的论文曾报告过一个实际案例：测试集群中未知 MAC 地址数据包的泛洪与 PFC 交织在一起导致了死锁，以及单个 NIC 持续发出 PAUSE 信号从而阻塞整个网络的事故。详见下文「外部依据」），并且有人评价以太网 DCB 的配置比 InfiniBand 更为复杂（维基百科）。

故障往往悄无声息地出现。MinIO MemKV 运行手册（非 NVIDIA 文档的第三方资料）指出，PFC 优先级、DSCP 映射以及 MTU 必须相互匹配；如果以太网 MTU 为 1500，则启用了 RoCE 的 MTU 会协商为 1024，若不匹配，则会以 IBV_WC_RETRY_EXC_ERR 结束，且这一问题仅在节点之间才会显现。

3. 层级与带宽

 노드(예: 8 GPU)
 GPU0 ... GPU7 ══ NVLink / NVSwitch ══ (노드 안 전체 연결)
   │PCIe          │PCIe
  NIC0    ...    NIC7 ──> 같은 번호 NIC 끼리 같은 리프 스위치 (rail)

若将第 4 代 NVLink 按单方向（一半）换算，约为 450GB/s，约为单张 NIC 的 9 倍（作者换算）。DeepSeek-V3 报告中的 H800 集群也是 NVLink 160GB/s 对比 InfiniBand 50GB/s，这种差距催生了第六篇中“TP 在节点内，PP 与 EP 在节点间”的趋势。而在 NVL72 等系统中，72 个 GPU 属于同一个 NVLink 域，因此边界会有所不同。 rail 架构已在 DGX SuperPOD 参考架构中得到确认，它将每台服务器编号相同的 NIC 连接到同一个叶交换机，从而使相同 rail 的服务器之间只需经过一台交换机。

4. GPUDirect RDMA 与 GPUDirect Storage

GPUDirect RDMA 允许 NIC 直接读取和写入 GPU 内存，从而省去了经由主机内存的步骤。官方文档的前提条件是：当两个设备共享同一个 PCIe 根复合体（Root Complex）且其间仅有 PCIe 交换机时效果最佳（若跨越 QPI/UPI 则性能会下降），并且 IOMMU 必须关闭或处于 1:1 直通状态。NCCL 文档指导用户 nvidia-peermem 模块应当在每次启动时加载，或者使用开源驱动程序的 DMA-BUF 路径（未加载和 ACS 也是常见原因），并使用 NCCL_NET_GDR_LEVEL 来限制 NIC 与 GPU 之间的最大距离（LOC、PIX、PXB、PHB、SYS）。

GPUDirect Storage（GDS）通过存储与 GPU 内存之间的 DMA 消除了 CPU 中转缓冲区（bounce buffer），并支持 cuFile API 以及本地 NVMe、NVMe-oF、Lustre、WekaFS、NFS over RDMA。如果不满足条件，它将降级为经过 CPU 内存的兼容模式，从而失去性能优势。

5. NCCL

运算。 根据 NCCL 2.32.3 文档，集合运算包括 AllReduce、Broadcast、Reduce、AllGather、ReduceScatter、AlltoAll、Gather、Scatter，同时还包含点对点 send/recv。所有 rank 必须使用相同的 count 和 datatype 进行调用，否则会产生挂起、崩溃、数据损坏等未定义行为。

算法与拓扑。 NCCL_ALGO 文档中列举的算法有 Ring、Tree、CollnetChain、CollnetDirect、NVLS、NVLSTree、PAT（NVLS 指的是 NVLink SHARP 卸载）。根据 NCCL 2.4 博客，Ring 可以用尽带宽，但延迟与 GPU 数量成正比；而双二叉树（double binary tree）能够保持带宽且延迟呈对数增长，在 Summit 的 24,576 个 GPU 上，其延迟比 Ring 最多改善了 180 倍（NVIDIA 的测量主张）。NCCL 在初始化时会检测 NVLink、PCIe、NIC 的连接状态以构建图谱，并通过 NCCL_TOPO_DUMP_FILE 输出检测结果。

文档警告不要将调试和调优变量保留在生产配置中，并指出一个基准测试的收益可能会在其他地方带来损失。在推理中，NCCL 用于 TP 的逐层 all-reduce，而 EP 的路径则取决于后端（allgather_reducescatter, DeepEP 等）。KV 传输由 NIXL/UCX 负责，因此不适用 NCCL 变量（第 6 篇）。

6. 如何测量

./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8                    # 노드 안 GPU 8장
mpirun -np 64 -N 8 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1  # 8노드 x 8 GPU (MPI=1 빌드)
ib_write_bw -d mlx5_0 -a                       # perftest 서버
ib_write_bw -d mlx5_0 <서버주소> -a            # 클라이언트. --use_cuda=0 을 더하면 GPU 메모리 경로
ib_write_lat -d mlx5_0 <서버주소>              # 꼬리 지연 확인

nccl-tests 会输出时间、algbw（크기/시간）以及 busbw。busbw 是通过乘以针对不同运算的修正系数，使其与 rank 数量无关并与硬件极限进行对比的值，其中 AllReduce 为 algbw × 2(n−1)/n, ReduceScatter、AllGather 以及 AlltoAll 为 algbw × (n−1)/n 。通过观察大消息的 busbw 离 NVLink 或 NIC 理论极限有多近，以及小消息的时间（延迟）来判断。NCCL 文档中的顺序是，先看节点内 nvbandwidth 和 nvidia-smi topo -m，再看节点间 ib_write_bw/ib_write_lat ，当这些值符合预期但只有 NCCL 变慢时，再去怀疑 NCCL 的配置。

7. 常见故障

8. Kubernetes 中的 RDMA

flowchart TB
  subgraph Node[GPU 노드]
    OFED[MOFED 드라이버<br/>ofedDriver]
    PEER[nvidia_peermem<br/>GPU Operator]
    DP[RDMA 공유 디바이스 플러그인]
    MUL[Multus + NetworkAttachmentDefinition]
  end
  OFED --> DP
  DP -->|rdma/hca_shared_devices_a 광고| KL[kubelet]
  KL --> Pod[파드: GPU + rdma 자원 + 보조 인터페이스 net1]
  MUL --> Pod
  PEER --> Pod

NVIDIA Network Operator（最新 v26.4.2, 2026-09-16）使用 NicClusterPolicy（README 中写作 NICClusterPolicy，名称固定为 nic-cluster-policy ）这单一资源来开启下层配置。其项目包括 MOFED 驱动程序容器（ofedDriver), rdmaSharedDevicePlugin, sriovDevicePlugin, secondaryNetwork（Multus、containernetworking 插件、IPoIB CNI）、 nvIpam, nicConfigurationOperator 等，且 MacvlanNetwork, HostDeviceNetwork, IPoIBNetwork CRD 会被转换为 NetworkAttachmentDefinition 。

• RDMA 共享设备插件（v1.5.4）使用 resourceName 和默认前缀 rdma 来公告 rdma/hca_shared_devices_a 等资源，并允许 Pod 通过 rdmaHcaMax 的数量来共享同一个 HCA。由于是共享方式，很难期待隔离性或带宽保证（作者解读）。 SR-IOV 设备插件会公告诸如 VF（虚拟函数）之类的网络资源，并且需要预先创建 VF。
• 主机网络与辅助接口。 hostNetwork 直接使用节点的 NIC，因此较为简单，但会共享节点网络，可能导致端口冲突（作者解释）。Multus 通过向 Pod 添加 eth0 以外的接口（net1 等），将 RDMA 专用网络与默认 CNI 隔离开来。
• GPU 侧。 Dynamo 的 AKS 指南建议将 GPU Operator 安装为 driver.rdma.enabled=true, driver.rdma.useHostMofed=true 以启用 nvidia_peermem ，并向 Pod 请求 rdma/hca_shared_devices_a: 1 。该指南指出，如果在节点上将 memlock 设为无限制，则不需要 IPC_LOCK ，而 vLLM 文档则建议添加 IPC_LOCK ，因此需根据环境进行选择。
• 拓扑感知的部署。 Dynamo 推荐使用 Grove 和 KAI Scheduler 来进行拓扑感知的 gang scheduling，并且可以通过 kvTransferPolicy（实验性功能）使 decode 倾向于调度在与 prefill 相同的可用区或机架中。GPU 需要与附近的 NIC 一起分配的原因在于 NCCL_NET_GDR_LEVEL 的距离限制和 rail 结构，而目前尚未确认在 Kubernetes 中如何成对进行分配。

9. 推理中需要 RDMA 的场景（连接第 6 篇）

NVIDIA 的 Dynamo 文档写道，如果通过 TCP 转移 KV，TTFT 约为 98 秒，而如果是 RDMA 则为 200~500ms。文档集中有附带条件：98 秒是在 Llama-3.1-8B、输入 8,000 个 Token、AWS p5.48xlarge 环境下 当 EFA Pod 的 NIXL 静默降级到 UCX 的慢速路径时测得的值，而 200~500ms 是同一文档标注为“基于规格的期望值”的数值（在同等条件的 EFA 上实际测得的 KV 传输附加开销为 37ms）。切勿将其简单理解为普通 TCP 与 RDMA 的对比（第 6 篇 “外部依据”）。

10. 动手尝试

由于没有 RDMA 硬件，因此属于软件和 TCP 的范畴。第 1、2 项未直接执行，第 3 项（软件 RoCE）记录了在下方“实测”中亲自执行的结果。

1. iperf3 用于确认以太网极限。 在两台服务器上运行 iperf3 -s 和 iperf3 -c <서버> -P 4 -t 10 ，并与上表中的 1GbE、2.5GbE 理论值进行比较。避开控制平面（etcd）节点，在业务闲时进行。 亲自执行的结果： 在三个不同的节点对（Pod 网络，10 秒）中，单流为 894~902Mbit/s，4 流为 901~912Mbit/s，结果完全相同（重传为 0），约为 1GbE 线速的 90~91%（约 112MB/s）。如果通过该网络传输 KV，对于 8,000 个 Token（对于每个 Token 占 114,688 字节的 1.7B 模型约为 917MB）大约需要 8 秒；对于每个 Token 256KiB 的 32B 模型（约 2.1GB）大约需要 19 秒（计算值）。由于同一 1.7B 模型在 8GB 级 GPU 上处理 8,000 个 Token 的输入大约需要 1 秒（8.2k tok/s，第 21 篇），因此 在此网络下，重新计算比传输 KV 更快（第 14 篇、第 21 篇的测量值与此计算结果的对比）。
2. TCP 套接字 NCCL。 在各有一张 GPU 的两台服务器（例如 hostA、hostB）上，直接在主机上使用 MPI=1 构建的 nccl-tests 进行 mpirun 。请先确认没有其他工作负载正在使用 GPU。

   mpirun -np 2 -H hostA:1,hostB:1 -x NCCL_IB_DISABLE=1 -x NCCL_SOCKET_IFNAME=<인터페이스> \
     -x NCCL_DEBUG=INFO ./build/all_reduce_perf -b 8 -e 256M -f 2 -g 1
   

   预期的现象是日志中能看到套接字传输，且大消息的 busbw 不会超过链路速度（1GbE 时为 0.125GB/s），这并非实测结果。单节点单张 GPU 因为没有通信对象而没有意义。
3. 通过软件 RoCE (rxe) 查看 verbs 流量。 根据 RHEL 文档，Soft-RoCE 是一项技术预览功能，计划在 RHEL 10 中移除。其性能受 CPU 左右，数值没有意义，仅用于确认设备枚举、端口状态、MTU 等概念。由于会创建内核模块和 RDMA 设备，请在一次性虚拟机而非生产运行中的节点上进行。

   sudo rdma link add rxe0 type rxe netdev <이더넷 인터페이스>
   rdma link show; ibv_devices; ibv_devinfo -d rxe0 | grep -E "state|active_mtu"
   ib_write_bw -d rxe0 -a          # VM 두 대에 rxe 를 만들고 서버/클라이언트로
   sudo rdma link delete rxe0      # 정리 (man rdma-link 로 확인)
   

实测：通过软件 RoCE (rxe) 重现 verbs 流量与故障这两种情况

环境。 在一台一次性虚拟机（4 vCPU、4GiB、Linux 6.8、虚拟 NIC 的 MTU 为 1500）内同时运行了服务端和客户端（通过自身地址访问）。安装了 rdma-core, ibverbs-utils, perftest(ib_write_bw, ib_write_lat), iperf3 。默认的云内核镜像中不包含 rdma_rxe 模块，导致 modprobe 找不到该模块，在安装了附加模块软件包（linux-modules-extra-<커널 버전>）后成功加载。性能数值由 CPU 决定，因此仅用于概念验证。

• “软件实现对数字没有意义”这一警告是正确的。 在同一台机器上，TCP 比 RDMA 写入快 8 倍。RDMA 的优势（绕过内核和 CPU）只有在硬件负责传输时才会体现，而在软件实现中，每个数据包都需要 CPU 工作，因此反而处于劣势。此测试用于直观了解 verbs 流程、GID、MTU 等概念。
• 复现了第 7 节表格中的“固定内存限制”故障。 以普通用户身份降低 ulimit -l 并写入 1MiB 消息时，在 64KiB 和 1,024KiB 下会以 Failed to create MR, Couldn't allocate MR 失败（服务器端为 failed to create mr），而在 8,192KiB 及以上时成功。在相同的 64KiB 限制下，4KiB 消息成功了，因此触发限制的是 要注册的内存大小。作为 root 用户时，在 64KiB 下也成功了，因为 Linux 内核源码（drivers/infiniband/core/umem.c）在注册用户内存时，如果超过 RLIMIT_MEMLOCK ，则仅在没有 CAP_IPC_LOCK 时才会 使其失败，这解释了其中的原因（本次测试并未直接检查 capability，而是通过源码描述确认的）。
• MTU 由设备决定。 在以太网 MTU 1500 下 active_mtu 变为 1024（rxe 源码会将以太网 MTU 减去 80 字节头部后的值向下取整到 256 到 4096 之间最接近的 2 的幂次方。1500 减去 80 等于 1420，因此是 1024。NVIDIA 文档中的 mlx5 设备示例也展示了以太网 MTU 为 1500 时 active_mtu 1024 ，所以这并非软件实现独有的现象），因此在排查节点间 MTU 不匹配的故障时，不仅要看以太网 MTU，还要看 ibv_devinfo 的 active_mtu 。
• 存在多个 GID 的原因在实际中显而易见。 由于同一个设备上同时加载了链路本地地址（Link-local）、IPv4 映射地址以及其他接口的地址，因此 show_gids 第 7 节中关于“必须通过选择 RoCE v2 项来指定”的说明变得非常容易具体理解。我们通过 ib_write_bw 分别测试了 GID 选择错误时的行为。当服务端和客户端使用相同时，三种类型（IPv4 映射、链路本地、覆盖地址）全部成功，吞吐量相近，分别为 1,266、1,322、1,299 MB/s（在单个虚拟机内访问自身地址）。当服务端和客户端使用不同的索引（1 对 0、1 对 3）或提供不存在的索引（9）时，测试以退出码 1 失败。如果省略索引，则默认选择第 1 个（IPv4 映射）。不过，该测试使用的是 perftest 而非 NCCL，且未能收集到错误提示信息，因此未能确认在相同情况下是否会出现 NCCL 文档中记录的 ibv_modify_qp ... Invalid argument （未实际测量）。

本测试的局限性在于：仅使用单台虚拟机、纯软件实现、且没有 GPU。我们未能测量两节点间的 RDMA、实际网卡（NIC）的吞吐量与延迟、PFC 与 ECN、 nccl-tests以及 GPUDirect RDMA（未实际测量）。

外部依据：通过论文与官方资料进行确认

我们通过第一手资料核实了未能直接测量的 RoCE 拥塞控制、NCCL 与 GPUDirect 相关描述，以及软件 RoCE 的性能。由于设备与条件存在差异，外部数值仅用于判定方向和架构的一致性。

由于访问限制而未能打开的资料（IEEE Network 2019 论文、内核 Bugzilla 190951、SoftRDMA）中的数值未被采用。

11. 面试常见问题

1. 为什么要用 RDMA 代替 TCP？ 因为网卡可以在没有内核拷贝和 CPU 介入的情况下直接读写固定内存，从而减少了延迟和 CPU 负担，而 GPUDirect RDMA 甚至省去了经过主机内存的步骤。
2. InfiniBand 与 RoCE v2 应该选择哪个？RoCE 的风险是什么？ IB 拥有专用网络和子网管理器（SM），配置简单；而 RoCE 使用现有的以太网和 L3 路由，代价是必须同时配置好 PFC、ECN、DSCP 和 MTU。如果配置错误，表现出来的将是长尾延迟或仅在节点间通信失败，需要通过交换机计数器来确认。
3. all_reduce_perf 如果的 busbw 仅为网卡线速的一半，应该从哪里开始排查？ ib_write_bw 应通过 nvidia-smi topo -m 检查网卡本身是否达到了线速，通过 NCCL_DEBUG=INFO 检查 GPU 与网卡的距离，并通过NET/IB确认所选的传输方式（
4. 、是否使用 GDRDMA）以及 rail 拓扑配置。 如果多节点训练突然变慢，排查顺序是什么？ibstat 依次检查：链路降级（ibdiagnetRate）、端口错误计数器、特定 rail 倾斜（
5. ），如果是 RoCE 则检查 PFC·ECN 计数器。只有在硬件完全正常的情况下，再去调整 NCCL 环境变量。 在 Kubernetes 中，Pod 若要使用 RDMA 需要哪些条件？ rdma/... 需要 MOFED 与设备插件（Network Operator）、Pod 的 nvidia_peermem资源请求、

、memlock 限制，如有必要还需 Multus 辅助接口或 SR-IOV，以及分配到靠近 GPU 的网卡的调度策略。

• 12. 常见误解 "RDMA 就是 InfiniBand。"
• RoCE 和 AWS 的 EFA 也提供 RDMA（Dynamo RDMA 文档）。 "NCCL 环境变量适用于所有 GPU 通信。"
• 对于走 NIXL/UCX 的 KV 传输并不适用。 "busbw 就是传输时间耗时的倒数。"
• 它是 algbw 乘以校正系数后的值，是用于与硬件极限进行对比的指标。 "既然有了 NVLink，服务器之间也会很快。"
• 在普通的 8 GPU 服务器中，NVLink 仅用于服务器内部连接，NVL72 则是例外。 "调优变量设置得越多越好。"

NCCL 文档并不建议常态化开启这些设置。

• 参考资料（实际查阅过的内容）
• NCCL 2.32.3 文档 (overview, usage/collectives, env, troubleshooting 的 networking·performance_and_tuning·gpu_troubleshooting): https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/
• https://github.com/NVIDIA/nccl , https://github.com/NVIDIA/nccl-tests (README, doc/PERFORMANCE.md) , https://github.com/linux-rdma/perftest
• NCCL 2.4 博客: https://developer.nvidia.com/blog/massively-scale-deep-learning-training-nccl-2-4/
• https://github.com/Mellanox/network-operator , https://github.com/Mellanox/k8s-rdma-shared-dev-plugin , https://github.com/k8snetworkplumbingwg/multus-cni , https://github.com/k8snetworkplumbingwg/sriov-network-device-plugin docs/fern/pages/kubernetes/installation)
• Dynamo 安装与 RDMA 文档: https://github.com/ai-dynamo/dynamo (release/1.5.0
• vLLM: https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ , https://docs.vllm.ai/en/latest/usage/troubleshooting/
• RoCE: https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-44/Layer-1-and-Switch-Ports/Quality-of-Service/RDMA-over-Converged-Ethernet-RoCE/ , https://networking-docs.nvidia.com/onyxum/3.10.4800/rdma-over-converged-ethernet-roce , https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet , https://docs.min.io/memkv/operate/rocev2/ , https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_infiniband_and_rdma_networks/configuring-roce_configuring-infiniband-and-rdma-networks
• 规格: https://www.nvidia.com/en-us/data-center/nvlink/ , https://docs.nvidia.com/dgx/dgxh100-user-guide/introduction-to-dgxh100.html , https://docs.nvidia.com/dgx-superpod/reference-architecture/scalable-infrastructure-rubinx86/latest/network-fabrics.html , https://www.rambus.com/blogs/pci-express-5-vs-4/
• 论文: https://arxiv.org/abs/2412.19437 , https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p523.pdf (DCQCN，仅限搜索结果的摘要级别)

已确认的版本与日期，以及未确认的内容

确认日期为 2026-10-05。通过 GitHub Release API 确认了 NCCL v2.32.3-1(2026-09-17)、perftest 26.07.8(2026-09-28)、Network Operator v26.4.2(2026-09-16)、RDMA 共享设备插件 v1.5.4(2026-07-28)、Multus v4.3.1(2026-09-08)、SR-IOV 设备插件 v3.11.0(2025-12-16)，而 nccl-tests 未发布 Release，读取的是 master（2026-10-02 提交）。

未确认的内容：(1) DCQCN 论文正文现已直接阅读（见下方“外部依据”）。(2) Network Operator README 中的系统要求（ConnectX-5、Ubuntu 20.04）看起来已过时，当前支持矩阵未作确认。(3) 在 Kubernetes 中配对分配 GPU-NIC 的方法。(4) rdma link delete 与 nccl-tests 的预期输出未进行实际运行。(5) MTU 协商规则基于第三方运行手册。(6) 未涵盖 InfiniBand 链路层流控与 NVLink 第 6 代细节。(7) 第 10 节的三项练习均未实际执行。