为什么大模型训练需要高速网络

大模型从单机扩展到多节点训练后，GPU之间需要频繁交换梯度、参数和中间结果。单机环境中，这些数据通常可以通过NVLink、NVSwitch等高速互联完成交换；当GPU数量扩展到多个节点后，跨节点通信就需要依赖网络。

以数据并行（Data Parallel，DP）为例，每个节点完成本地计算后，需要通过Collective通信交换梯度：

如果网络通信时间占比较高，即使GPU具有很高的计算能力，也需要等待其他节点完成通信。因此，训练效率并不只取决于GPU的计算能力，还受到通信效率和资源利用率的共同影响，可以粗略理解为：训练效率 ≈ 计算效率 × 通信效率 × 资源利用率。

网络问题通常不会直接表现为GPU报错，更常见的是GPU利用率周期性下降、Collective通信时间变长、节点之间出现明显性能差异，以及训练吞吐随节点数量增加没有同步提升。在同步训练场景中，整体性能还可能受到最慢节点或最慢通信路径的限制。

因此，GPU集群网络不能只作为独立的网络基础设施来理解，而应当作为整个计算系统的一部分进行设计和排障。真正需要关注的不是“网络有没有问题”，而是GPU产生的数据能否沿着合理、稳定且高效的路径完成跨节点交换。

IB、RoCE与RDMA三个概念

在GPU集群网络中，经常同时出现IB、RoCE和RDMA三个术语，但它们并不属于同一个层级。

RDMA（Remote Direct Memory Access）是一种允许主机直接访问远端内存的通信技术，InfiniBand（IB）与RoCEv2则是承载它的网络技术。

在GPU集群中，RDMA可结合GPUDirect RDMA等机制减少数据在CPU内存中的额外拷贝，让GPU与远端设备之间的数据交换更高效。因此，RDMA关注的是数据如何在节点之间高效传输，而非某一种具体的设备或协议。

常见的RDMA网络主要包括InfiniBand和RoCE。

三者的关系可以简单理解为：

后续文档中统一使用以下术语：

• RDMA：描述通信能力；
• InfiniBand（IB）：描述InfiniBand网络；
• RoCEv2：描述基于以太网的RDMA网络；
• RDMA网卡：泛指支持RDMA的网卡；涉及具体硬件时，根据实际设备使用HCA或NIC。

明确RDMA、IB和RoCEv2之间的关系后，还需要进一步理解一条完整的GPU通信路径。

跨节点Collective通信的数据路径

在典型的多节点GPU集群中，一次跨节点Collective通信并不是简单的“GPU连接GPU”，而是需要经过GPU、PCIe、RDMA网卡和交换网络等多个层次。

• 源节点内（①–②）：GPU把数据交给本节点PCIe交换机，再由PCIe交换机送到本次通信使用的RDMA网卡；启用GPUDirect RDMA时，这一跳不经过CPU内存。
• 交换网络内（③–⑤）：网卡把数据封装成RDMA报文上联Leaf，由Leaf交给Spine，再转发到目标节点所在的Leaf。
• 目标节点内（⑥–⑧）：目标Leaf下行到本节点RDMA网卡，网卡再经PCIe交换机把数据交给目标GPU。

因此，GPU之间的通信性能取决于整条数据路径：PCIe拓扑、NUMA亲和性、网卡速率、交换网络拥塞、链路状态以及节点间配置一致性等因素，都可能成为通信性能瓶颈。分析时不应只关注RDMA网卡的标称带宽，而应沿着上面这条路径逐层检查。

后续的PCIe Affinity、GPUDirect RDMA和Rail-aligned，分别关注这条路径上的不同环节：

• PCIe Affinity：关注GPU与RDMA NIC之间的PCIe/NUMA拓扑关系，尽量减少不必要的跨PCIe或跨NUMA数据传输。
• GPUDirect RDMA：减少GPU数据在主机内存与CPU之间的额外搬运，缩短GPU到NIC的数据传输路径。
• Rail-aligned：关注多GPU、多NIC与网络Rail之间的对应关系，使GPU、NIC和网络路径保持合理映射。

因此，这三个概念可以分别理解为对GPU-NIC拓扑、GPU数据传输路径以及多Rail通信映射的优化，共同影响跨节点Collective通信的实际性能。

随着GPU算力持续提升，GPU集群网络也经历了多代速率演进。InfiniBand经历了EDR、HDR、NDR到XDR等多个代际，单端口典型速率不断提升：

更高的端口速率意味着更高的理论通信能力，但端口速率并不等于训练任务能够获得的实际通信性能。

例如，一台GPU服务器可能配置多块RDMA网卡，每块网卡分别连接到不同的Leaf交换机。因此，从硬件规格来看，一台服务器的理论网络能力可以近似表示为：理论聚合带宽 ≈ 单端口速率 × RDMA端口数量。

但这个数字只能代表理论带宽。实际训练性能还受到GPU与NIC之间的PCIe拓扑、NIC与Leaf交换机之间的连接关系、节点间网络路径、Collective通信模式、网络拥塞、RDMA配置以及NCCL的GPU-NIC选择策略等因素影响。

因此，不能简单使用“网卡总带宽”判断一台GPU服务器的实际训练网络性能。

PCIe Affinity：数据首先要走对GPU到NIC的路径

网络性能问题有时并不是交换机造成的，而是数据还没有高效地离开GPU。GPU和RDMA网卡通常通过PCIe连接：GPU —— PCIe —— RDMA NIC —— Network。

如果GPU与NIC之间存在跨CPU Socket、跨NUMA或者较长的PCIe路径，数据传输可能增加额外开销。因此，在多GPU、多NIC服务器中，首先需要确认GPU和NIC之间的物理拓扑关系。可以使用以下命令查看GPU、NIC和PCIe设备之间的拓扑关系：

nvidia-smi topo -m

常见拓扑标识包括：

通常情况下，应优先选择距离GPU更近的NIC路径。但这里需要避免将拓扑标识直接等同于性能结论。例如：SYS并不等于GDR一定不可用，也不能简单认为性能一定下降一半。

实际性能取决于GPU型号、GPU互联能力、NIC型号及带宽、PCIe Root Complex拓扑、NUMA关系、RDMA配置以及NCCL拓扑感知和通信策略等多个因素。因此，nvidia-smi topo -m更适合作为排障和优化的依据，而不是单独用于判断最终性能。

GPUDirect RDMA：减少GPU数据传输中的中间拷贝

在传统的数据传输路径中，GPU数据需要先经过CPU内存，再由NIC发送到网络；在需要频繁交换大量数据的训练场景中，这会带来额外的拷贝开销。

GPUDirect RDMA可以让支持的网络设备更加直接地访问GPU内存，从而减少不必要的数据搬运。典型的数据路径可以表示为：GPU → PCIe → RDMA NIC → Network → RDMA NIC → PCIe → GPU

因此，GPUDirect RDMA关注的是GPU数据如何更高效地进入网络以及从网络返回GPU，而PCIe Affinity关注的是GPU与NIC之间的路径是否合理。二者相互关联，但解决的问题并不完全相同。在Linux环境中，可以结合以下命令检查相关环境：

nvidia-smi
lsmod | grep nvidia_peermem

nvidia_peermem是GPUDirect RDMA环境中的重要组件，但是否加载以及实际使用方式取决于GPU驱动、RDMA驱动和软件栈配置，因此不能仅根据模块是否加载判断整个GPUDirect RDMA链路是否正常。

Rail-aligned：让GPU、NIC和网络路径对应起来

当一台服务器包含多块GPU和多块RDMA网卡时，仅仅确认“GPU和NIC能够通信”还不够，还需要进一步考虑多块GPU、NIC以及交换机端口之间的整体映射关系。

如果GPU、NIC和交换机之间的连接关系没有经过合理设计，就可能出现多个GPU共享某条链路、跨PCIe路径访问NIC，或者多个GPU集中使用同一个网络出口的情况，从而产生局部资源竞争。

Rail

可以把一组相互对应的GPU、NIC和Leaf交换机理解为一个Rail：

这里的Rail并不是一个独立的网络协议，而是一种描述GPU、NIC和网络连接关系的拓扑概念。

Rail-aligned

Rail-aligned的核心并不是简单地让“GPU0连接Leaf0、GPU1连接Leaf1”。真正的目标是：让GPU、NIC、交换机和通信模式形成稳定、可预测的路径，使Collective通信能够尽可能利用对应的网络资源。 具体映射关系需要结合服务器PCIe拓扑、NUMA结构、交换机连接方式以及NCCL通信模式进行设计。

下面用两组服务器对比两种映射方式：左侧Rail对齐时，GPU、NIC与Leaf一一对应，同Rail直连；右侧为非对齐示例，Leaf之间不再直连，需要经Spine跨Rail转发并共享上联，而目标节点未用到的Leaf↔GPU·NIC链路则会闲置。

为什么Rail-aligned会影响训练

大模型训练中的AllReduce、AllGather、ReduceScatter等Collective通信会产生大量跨节点流量。如果网络路径设计合理，一次通信就可以沿着稳定的路径完成，让多个GPU尽可能利用各自对应的网络资源。相反，如果多个GPU集中访问同一个NIC或同一条网络路径，如下图所示，就可能形成局部瓶颈。

因此，Rail-aligned主要解决的是多GPU、多NIC和网络Fabric之间的资源映射问题，有助于减少不必要的跨路径通信、降低局部资源竞争，并提高Collective通信的可预测性。

需要注意的是，Rail-aligned并不是一个脱离实际拓扑的固定规则。

假设一个训练任务需要反复执行 计算 → AllReduce → 计算 → AllReduce → 计算，如果某一次AllReduce需要等待最慢的通信路径，其他GPU即使已经完成计算，也可能进入等待状态。

例如：

Node 0 ── 10 ms
Node 1 ── 10 ms
Node 2 ── 10 ms
Node 3 ── 15 ms

在同步训练场景中，需要关注整体Collective完成时间，而不是节点平均通信时间。只要Rail映射不合理、链路降速或发生拥塞，训练吞吐就会被最慢的路径拖住，这也是网络问题经常表现为“GPU利用率下降”的原因之一：GPU不是算不动，而是在等待其他GPU完成通信。

排障与验收：从GPU一路检查到NCCL

实际排障建议遵循“先拓扑、再链路、再RDMA、最后NCCL与业务”的顺序，逐层确认通信路径。GPU / PCIe → RDMA网卡 → IB / RoCEv2链路 → 点到点RDMA → 多节点通信 → NCCL Collective → 实际训练。

1. 先确认GPU和RDMA网卡是否正常识别。 可通过nvidia-smi、nvidia-smi topo -m和ibdev2netdev -v查看GPU、NIC及其拓扑关系，重点检查如下条目，如果发现GPU-NIC实际连接路径与服务器设计不一致，应优先排查并修正硬件拓扑问题。

   • GPU-NIC映射；
   • PCIe路径；
   • GPU与NIC的NUMA亲和性；
   • 多NIC节点的Rail映射；
   • PCIe链路速率和宽度。

2. 再检查RDMA链路，如下所示。 目标是确认RDMA链路状态正常、通信稳定，并符合集群网络设计要求。

   • InfiniBand：可通过 ibstat 和 ibstatus 查看端口状态、Link Layer、链路速率及错误统计；
   • RoCEv2：还需要进一步检查NIC链路状态、MTU、QoS、PFC、ECN，以及拥塞、丢包和链路错误。

3. 链路状态正常后，验证点到点RDMA的带宽和时延。 可使用ib_write_bw和ib_write_lat测试，并与同型号节点的基线进行对比。如果性能异常，建议按“链路速率→PCIe拓扑→NIC绑定→测试参数→交换网络→链路错误”的顺序逐层排查。

   在确认底层链路和RDMA性能正常之前，不建议直接调整NCCL参数，以避免混淆底层网络与通信库本身的问题。

4. 单机RDMA通信正常，并不代表多节点集群通信正常。 还需要进一步验证不同消息规模、多GPU并发、连续多次运行以及不同节点组合下的通信性能，重点观察是否存在如下现象：

   • 特定节点持续偏慢；
   • 特定节点组合异常；
   • 性能明显抖动。

5. 基础网络和RDMA性能确认正常后，再验证NCCL Collective。 可通过NCCL-tests覆盖AllReduce、AllGather、ReduceScatter和Broadcast，并尽量采用接近实际训练的GPU数量和消息规模（Collective性能会受到GPU数量、消息规模、通信模式及网络拓扑的影响）。如果出现“RDMA带宽正常但NCCL性能异常”的情况，应重点检查如下信息：

   • GPU-NIC亲和性；
   • Rail映射；
   • NCCL实际使用的NIC；
   • 多NIC并发；
   • 节点间网络路径；
   • Collective通信模式。

排查过程中，常见现象与优先检查方向对应如下：

验收无需建立独立流程，可直接按照通信链路逐层检查：

验收的核心不是单个命令的测试结果，而是整条通信路径是否都满足设计要求和性能基线。

总结：从“高速网卡”走向“完整通信路径”

GPU集群网络性能需要从完整的数据路径来理解：GPU → PCIe / NUMA → RDMA NIC → Leaf / Spine → RDMA NIC → PCIe / NUMA → GPU，这条路径由RDMA通信、GPU-NIC PCIe拓扑、GPUDirect RDMA与Rail映射共同决定，优化顺序为 网络技术 → RDMA通信 → GPU-NIC PCIe拓扑 → GPUDirect RDMA → Rail映射 → IB / RoCEv2 Fabric → Collective通信 → 实际训练吞吐

只有每一环都符合设计预期，这些能力才能转化为训练性能——排障的核心不是寻找某一块“最快的网卡”，而是确认从GPU到GPU的整条通信路径是否合理、稳定且可预测。