ReelOS.AI 禅定｜一句话看懂本文
InfiniBand 和 RoCE 不是在比“谁更快”，而是在回答：如何让昂贵的 GPU 集群少等待、少空转。
- GPU 很贵。
- 但 GPU 集群真正怕的不是算不动，而是等通信。
- 训练和推理会产生大量 GPU 间数据交换。
- 数据交换慢，GPU 就等待；GPU 等待，就是算力浪费。
- RDMA 让数据少经过 CPU、内核和多次内存拷贝。
- GPUDirect RDMA 让 GPU 和网卡之间的数据路径更直接。
- InfiniBand 用专用网络体系，把低延迟、低抖动和确定性交付产品化。
- RoCE 在以太网上实现 RDMA，用开放生态和工程调优获得规模化能力。
- InfiniBand 买的是确定性。
- RoCE 考验的是工程能力。
- AI Compute Fabric 的核心，不是连接服务器，而是把网络变成 GPU 有效算力的一部分。
很多人看 AI 集群，第一反应是看 GPU。
有多少张 H100？有多少张 H200？未来有没有 B200、B300？
但真正进入大规模训练和分布式推理之后，你会发现：
GPU 本身很强，不代表 GPU 集群就强。
单张 GPU 是算力资产。
一组 GPU 能不能被组织成稳定、高效、可扩展的计算系统，取决于另一件更底层的东西：
网络。
更准确地说，是 AI Compute Fabric。
一、先抓住主杆：AI 集群网络不是普通网络
GPU 集群需要的不是一张普通网络，而是一张 AI Compute Fabric。
它既要提供高带宽，也要控制尾延迟；既要支持 RDMA 和 GPUDirect，也要处理拥塞、队列、路由、遥测和故障恢复；既要让单个节点跑得快，也要让成百上千张 GPU 在同一个训练节奏里稳定前进。
InfiniBand 的优势，是把这种确定性做成了成熟的一体化系统；RoCE 的优势，是把 RDMA 带进了开放的以太网生态，但需要更强的网络工程、运维和软件协同能力。
所以，AI 集群的竞争，不能只看 GPU 数量，也不能只看端口速率。真正要看的，是 NCCL 有效带宽、集合通信耗时、拥塞恢复能力、故障隔离能力，以及网络能否随着 GPU 数量持续扩展。
当 AI 计算从单机走向大规模集群，网络已经不是服务器的附属品，而是算力系统本身。
这就是理解 InfiniBand、RoCE、RDMA、GPUDirect、NCCL、AI Ethernet 的主线。
后面所有概念，都围绕这条主线展开。
二、学习这件事，要先建立一张地图
理解 GPU 集群网络，不要一上来就陷入各种名词。
先看这张学习地图：
| 层级 | 解决什么问题 | 关键技术 |
|---|---|---|
| GPU 内部计算 | 单卡怎么更快计算 | CUDA / Tensor Core / HBM |
| 节点内互连 | 一台服务器内多张 GPU 怎么通信 | NVLink / NVSwitch / PCIe |
| 节点间互连 | 多台 GPU 服务器怎么组成集群 | InfiniBand / RoCE / Ethernet Fabric |
| 数据传输路径 | 数据怎么少经过 CPU 和内核 | RDMA / GPUDirect RDMA |
| 集合通信组织 | 梯度、参数、激活值怎么同步 | NCCL / MPI / DeepEP |
| 网络工程治理 | 拥塞、丢包、抖动、故障怎么处理 | PFC / ECN / DCQCN / Telemetry |
| 集群效率判断 | GPU 到底有没有被用满 | NCCL busbw / algbw / 尾延迟 / 利用率 |
这张表最重要的地方在于：
网络不是单独的一层，而是贯穿 GPU、网卡、交换机、通信库和训练框架的一整套系统。
所以 AI Compute Fabric 不是“买几台高速交换机”。
它是一个系统工程。
三、为什么 GPU 集群最怕“等”？
普通网络的目标，是把数据从 A 点送到 B 点。
AI 集群网络的目标，是让大量 GPU 在同一个节奏里一起前进。
这两件事不是一个难度。
在普通业务系统里，一个请求慢一点，通常只是某个用户慢一点，或者某个服务重试一下。
但在大模型训练中，GPU 不是各算各的。
它们每一轮训练都要交换大量数据，例如：
- 梯度；
- 参数；
- 激活值；
- 专家路由信息；
- 分布式并行中的中间结果。
这些数据交换通常通过集合通信完成。NVIDIA NCCL 官方文档列出的核心集合通信包括 AllReduce、AllGather、ReduceScatter、AllToAll 等。
问题在于，集合通信会被最慢的一部分拖住。
假设 1024 张 GPU 一起训练，其中 1000 张 GPU 已经完成计算，但还有一部分 GPU 的数据没有同步回来，那么前面那些 GPU 也不能随意进入下一轮。
它们只能等。
所以，GPU 集群真正昂贵的浪费，不只是机器慢。
而是：
GPU 已经买了，电已经用了，机房已经建了，但大量时间消耗在通信等待上。
这就是 AI 集群网络的本质问题：
能不能让昂贵的 GPU 尽量少等。
四、为什么普通以太网不够？
严格说，不是“以太网不够”。
而是传统数据中心以太网，不能直接满足大规模同步训练的要求。
普通以太网很强。它开放、成熟、供应链丰富，适合承载网页访问、API 请求、数据库访问、对象存储、文件传输、虚拟机和容器网络。
但 AI 训练流量有几个特殊点。
第一，同步性强。
一批 GPU 算完之后，往往会在接近同一时间发起通信。
第二，单次通信量大。
梯度、参数、激活值不是普通业务请求里的小包。
第三，通信模式集中。
AllReduce、AllGather、AllToAll 这类通信，会在大量节点之间形成结构化的数据交换。
第四，对尾延迟敏感。
平均延迟好看不够，最慢那部分通信才可能拖住整个训练任务。
第五，局部拥塞会被放大。
一条链路拥塞，一个交换机队列堆积，一个节点慢速接收，都可能影响整个训练迭代。
所以，GPU 集群需要的不是“更快的普通网络”。
它需要的是为计算同步优化的网络。
这就是 InfiniBand 和 RoCE 的位置。
五、RDMA：理解 InfiniBand 和 RoCE 的第一块积木
要理解 InfiniBand 和 RoCE，必须先理解 RDMA。
RDMA，全称是 Remote Direct Memory Access，远程直接内存访问。
它解决的是一个底层问题：
数据在机器之间传输时，能不能少经过 CPU、少经过内核、少做拷贝？
传统网络传输中，数据通常要经过应用程序、操作系统内核、TCP/IP 协议栈、内核缓冲区、网卡等多个环节。
这个过程会带来数据拷贝、CPU 占用、内核路径、延迟、抖动和内存带宽消耗。
RDMA 改变了这条路径。
在完成内存注册和权限配置后，网卡可以直接访问远端服务器的指定内存区域，从而减少 CPU 和操作系统内核的参与。
对于 GPU 集群来说，更关键的是 GPUDirect RDMA。NVIDIA 官方文档说明，GPUDirect RDMA 可以让 GPU 和第三方 PCIe 设备建立直接数据交换路径，例如网络接口卡或存储适配器。
这意味着，数据可以尽量避免在 GPU 显存、主机内存、CPU、网卡之间反复搬运。
可以这样理解：
RDMA 让网络从普通 I/O，变成计算系统里的直接数据通道。
这也是为什么 AI 集群里的高速网卡不只是“收包发包”。
它还要处理 RDMA 队列、内存访问权限、可靠传输、拥塞反馈、速率控制、GPUDirect 数据路径、多路径流量调度、网络遥测，以及与 NCCL 等通信库协同。
所以，在 AI 集群里，网卡不再只是服务器外设。
它越来越像异构计算系统里的专用数据处理器。
六、InfiniBand：把确定性做成一体化系统
InfiniBand 从设计之初，就不是为普通互联网访问准备的。
它面向的是高性能计算、超级计算、服务器互连和存储互连。
它的核心特点是：
从协议、网卡、交换机、管理系统、流量控制、服务质量、拥塞控制到网络遥测，都围绕高性能计算设计。
这和普通以太网的逻辑不同。
普通以太网首先追求开放、通用、兼容。
InfiniBand 首先追求低延迟、高吞吐、低抖动和端到端确定性。
在 GPU 集群里，确定性非常重要。
因为训练任务最怕的不是平均性能稍微低一点，而是某些链路突然拥塞、某些路径突然抖动、某些节点突然拖尾。
InfiniBand 的优势，就是尽量把这些不确定性压下去。
以 NVIDIA Quantum-X800 InfiniBand 为例，官方资料显示，它提供 800Gb/s 端口，并支持 SHARP 网络内计算、自适应路由、基于遥测的拥塞控制和性能隔离等能力。
其中，SHARP 值得特别理解。
普通集合通信中，归约操作通常要在服务器之间来回传输数据。
而 SHARP 的思路是：
能不能把一部分归约操作下沉到交换网络里完成？
NVIDIA 文档说明，RDMA 和 SHARP collectives 可以通过 NCCL-SHARP plugin 与 NCCL 集成。
所以，InfiniBand 的价值不是“比以太网快一点”。
更准确地说：
InfiniBand 是把高性能计算网络做成了一套端到端系统。
它适合超大规模模型训练、HPC 高性能计算、集合通信密集型任务、对尾延迟敏感的训练，以及对交付确定性要求高的 AI 集群。
但 InfiniBand 也有代价。
它通常需要独立的 HCA、交换机、线缆、管理系统和运维体系。
所以，它的优势是确定性强、端到端验证充分。
它的代价是成本、供应链、生态弹性和运维体系相对集中。
一句话：
InfiniBand 买的不是单点速度，而是系统确定性。
七、RoCE：把 RDMA 带进以太网生态
RoCE，全称是 RDMA over Converged Ethernet。
也就是：
让 RDMA 跑在以太网上。
目前数据中心里更常见的是 RoCE v2。NVIDIA Networking 文档明确说明，RoCEv2 通过 IP header 支持三层路由，并使用 UDP header 作为 RDMA transport over IP 的封装层。
这件事的意义很大。
因为以太网是数据中心最成熟、最开放、供应链最丰富的网络生态。
大量云厂商已经拥有以太网交换机、IP 网络、光模块供应链、自动化运维、网络监控系统，以及云网络和存储网络经验。
如果能在以太网上获得 RDMA 能力，那么 RoCE 就有很强的吸引力。
RoCE 的优势主要有四个：
第一，供应链更开放。
以太网设备、交换机、光模块、网络操作系统和运维工具选择更多。
第二，更容易复用已有基础设施。
很多数据中心本来就是围绕以太网建设的。
第三，更容易和 IP 网络体系融合。
RoCE v2 可以运行在 UDP/IP 上，具备更好的三层网络规划能力。
第四，更适合云厂商长期演进。
云厂商天然希望基础设施标准化、规模化、自动化、开放化。
但这里有一个重要误区：
RoCE 不是普通以太网加一个 RDMA 功能。
RoCE 真正难的，不是跑通。
而是大规模下稳定、可控、可观测地跑快。
八、RoCE 真正难在什么地方？
RoCE 最大的工程难点，是拥塞控制。
GPU 训练流量很容易形成大量同步大流。
如果多个大流同时进入同一条链路，就会出现队列堆积、延迟上升、抖动变大、丢包风险、集合通信等待和训练效率下降。
而 RDMA 对丢包和延迟抖动非常敏感。
所以 RoCE 网络必须精细处理一整套问题：
- PFC；
- ECN；
- DCQCN；
- CNP 拥塞通知；
- 队列优先级；
- buffer 水线；
- 多路径调度；
- ECMP 哈希；
- 自适应路由；
- 端侧速率控制；
- 网络遥测和故障定位。
这里有三个关键词最关键。
1. PFC：最后保险丝
PFC，全称 Priority Flow Control，优先级流控。
它的作用是，当交换机队列快满时，让上游设备暂停发送对应优先级的流量，从而减少丢包。
早期很多 RoCE 网络强调“无损以太网”，PFC 是关键机制之一。
但 PFC 不是万能药。
Microsoft 在大规模 RoCE 实践论文中明确讨论了 PFC-induced deadlock、RDMA transport livelock、NIC PFC pause frame storm 等问题，并指出需要监控和管理系统来保证 RDMA 按预期工作。
所以，PFC 更像最后保险丝。
它不能成为日常刹车系统。
2. ECN：提前告诉发送端，前面开始堵了
ECN，全称 Explicit Congestion Notification，显式拥塞通知。
它的逻辑是：
当交换机发现队列开始拥塞时，不是等到丢包，而是提前对报文做拥塞标记。
这样系统可以在丢包之前感知拥塞。
3. DCQCN：让发送端根据拥塞反馈调整速度
DCQCN 是面向 RoCEv2 的端到端拥塞控制协议。
SIGCOMM 2015 的 DCQCN 论文说明，它依赖交换机 RED/ECN 支持，其余协议功能主要由端侧 NIC 实现，用于在大规模 IP-routed 数据中心网络中部署 RoCEv2。
可以这样理解：
PFC 是防止网络炸掉。
ECN 是提前发现拥塞。
DCQCN 是让发送端根据拥塞反馈调整速度。
真正的大规模 RoCE，不是靠某一个机制。
而是靠这些机制协同工作。
所以，RoCE 的本质不是“以太网也能跑 RDMA”。
而是：
在以太网生态里，通过复杂工程能力，把计算网络需要的确定性调出来。
一句话：
InfiniBand 是把确定性产品化；RoCE 是把确定性工程化。
九、AI Ethernet：以太网正在变成计算网络
过去很多人会简单认为：
“训练大集群用 InfiniBand，以太网不够。”
这个判断在很多历史场景里成立，但现在需要更精确。
更准确的说法是：
传统以太网不适合直接承载大规模同步训练，但经过 RoCE、拥塞控制、自适应路由、遥测、集合通信优化之后，以太网正在演进成 AI Ethernet。
Meta 在 SIGCOMM 2024 论文中公开了面向分布式 AI 训练的大规模 RoCE 网络设计，重点讨论了拓扑、路由、训练流量模式、拥塞管理和运维系统。
NVIDIA Spectrum-X 也是这个方向的代表。NVIDIA 将 Spectrum-X 定位为面向 AI networking 的 Ethernet 平台，并强调其面向 AI workloads 的高有效带宽、性能隔离和大规模扩展能力。
Ultra Ethernet Consortium 也在推动面向 AI 和 HPC 的以太网通信架构，其官方目标是优化 Ethernet，使其适配高性能 AI 和 HPC networking，并改善带宽、延迟、尾延迟和规模能力。
这些变化说明一个趋势：
以太网不是停留在传统数据中心网络里，而是在向 AI Compute Fabric 演进。
未来的竞争，不只是 InfiniBand 和 RoCE 两个协议名字的竞争。
而是：
谁能把网卡、交换机、光互连、拥塞控制、网络遥测和集合通信软件整合成一套稳定的 AI 网络。
十、InfiniBand 与 RoCE 的本质区别
InfiniBand 和 RoCE 都可以支持 RDMA。
但它们的路线不同。
| 维度 | InfiniBand | RoCE |
|---|---|---|
| 网络底座 | 专用计算网络 | 高速以太网 |
| RDMA 支持 | 原生 RDMA | RDMA over Ethernet |
| 核心价值 | 性能确定性 | 生态开放性 |
| 交付逻辑 | 端到端专用体系 | 在以太网体系上工程化调优 |
| 运维特点 | 专用网络运维体系 | 需要强以太网和 RDMA 调优能力 |
| 供应链 | 相对集中 | 更开放、更丰富 |
| 典型优势 | 低延迟、低抖动、成熟交付 | 开放生态、云网络融合、长期规模化 |
| 主要挑战 | 成本、供应链、体系独立 | 拥塞控制、队列、buffer、遥测、调优复杂 |
所以，这不是“谁一定更快”的问题。
真正的问题是：
你更需要确定性，还是更需要开放性？
如果要快速交付一个高确定性的训练集群，InfiniBand 往往更省心。
如果已经有强大的以太网基础设施、网络工程团队和自动化运维能力，RoCE / AI Ethernet 的长期吸引力会越来越强。
可以这样概括：
InfiniBand 是用专用系统买确定性。
RoCE 是用开放生态换工程复杂度。
十一、NVLink、InfiniBand、RoCE、NCCL 怎么分工？
很多人会把这些概念混在一起。
其实它们解决的是不同层级的问题。
1. NVLink / NVSwitch：解决节点内部通信
NVLink 和 NVSwitch 主要解决 Scale-Up。
也就是在一台服务器内部，或者一个紧密计算域内部，让多颗 GPU 高速交换数据。
它关心的是：
一台机器内部的 GPU 如何像一个整体一样协同。
2. InfiniBand / RoCE：解决节点之间通信
InfiniBand 和 RoCE 主要解决 Scale-Out。
也就是把更多服务器、更多机架、更多 GPU 节点连接起来。
它关心的是：
多台服务器之间的 GPU 如何组成更大的计算集群。
3. NCCL：解决通信如何组织
有了网络，不代表数据会自动以最高效率流动。
NCCL 负责组织集合通信。
它要决定数据怎么切分、哪些 GPU 先发、数据走哪条链路、多张网卡如何并行、通信和计算如何重叠、AllReduce 使用什么通信策略，以及遇到慢路径时如何处理。
所以完整的 GPU 集群通信路径可以这样理解：
节点内：NVLink / NVSwitch
节点间：InfiniBand / RoCE / AI Ethernet
数据通道：RDMA / GPUDirect RDMA
通信组织：NCCL
训练框架：PyTorch / Megatron / DeepSpeed 等
网络只是路。
NCCL 决定车怎么走。
训练框架决定什么时候需要走。
十二、为什么 AI 集群通常要分多张网络？
真实 AI 集群里，通常不会把所有流量混在一张网络里。
因为不同流量的目标不同、风险不同、调优方式不同。
一个比较清晰的划分是四张网络。
1. 管理网络
用于 BMC、PXE、设备管理、监控、部署、故障处理。
它追求稳定、安全、可控。
不追求极致带宽。
2. 业务 / 前端网络
用于登录、API、调度系统、用户访问、控制面通信。
它要和云平台、业务系统、用户入口连接。
3. 存储网络
用于数据集读取、checkpoint 保存、对象存储、并行文件系统。
它关心吞吐、稳定性和数据可靠性。
4. 计算后端网络
也就是 AI Compute Fabric。
用于 GPU 节点之间的 RDMA / NCCL 通信。
它最关心低延迟、高带宽、低抖动、拥塞控制、通信效率、故障隔离和训练任务稳定性。
所以，“融合网络”不等于所有流量混跑。
更准确地说：
融合的是生态、设备和运维能力；隔离的是流量、风险和调优目标。
这也是网络分层的意义：
- 更清晰；
- 更安全；
- 更容易调优；
- 更容易定位故障；
- 更容易控制不同流量之间的互相影响。
十三、真正做 RoCE Fabric，要调什么？
如果只是科普，讲到 RoCE over Ethernet 就够了。
但如果要真正做工程交付，必须知道 RoCE 难在哪里。
一个 RoCE Fabric 至少要关注七层问题。
1. 拓扑
常见是 Clos / Fat-tree / Leaf-Spine / 多平面设计。
要考虑是否无阻塞、是否超售、每个 GPU 节点几张网卡、多 rail 如何设计、流量是否均衡，以及故障时是否有替代路径。
2. 队列与优先级
RoCE 流量通常需要独立优先级。
要设计 Priority、Traffic Class、DSCP、QoS 映射，以及 RDMA 流量和普通流量是否隔离。
3. PFC
要决定哪些 priority 开 PFC、buffer headroom 怎么算、pause 阈值怎么设、是否会引发 pause storm，以及是否存在 deadlock 风险。
4. ECN / DCQCN
要决定 ECN 标记阈值、CNP 是否正常、NIC 端侧降速是否生效、速率恢复是否过慢，以及是否存在吞吐和公平性的冲突。
5. 多路径
要关注 ECMP 哈希是否均衡、flowlet / adaptive routing 是否可用、大流是否集中在少数链路、多网卡是否真正并行，以及 NCCL 是否正确使用多 rail。
6. GPUDirect
要确认 GPUDirect RDMA 是否启用、PCIe 拓扑是否合理、NIC 和 GPU 的 NUMA / PCIe 路径是否匹配，以及是否出现绕路到 CPU / 主机内存的情况。
7. 可观测性
要能看到 PFC pause counters、ECN marked packets、CNP packets、端口丢包、链路误码、光模块异常、NCCL algbw / busbw、单节点慢速、单链路拥塞，以及某个任务是否影响其他任务。
RoCE 的核心工程能力，不是“配置一个开关”。
而是建立一整套：
设计、压测、调参、观测、定位、恢复、复盘的闭环。
十四、判断一张 AI Compute Fabric，不能只看端口速率
很多人喜欢问：
这个网络是 400G 还是 800G？
这个问题重要，但不够。
端口速率只是理论上限。
真正决定训练效率的，是有效性能。
判断一张 AI Compute Fabric，至少要看八个指标。
- NCCL 有效带宽：AllReduce、AllGather、AllToAll 在真实拓扑下的 algbw / busbw 能跑到多少。
- 集合通信耗时：每一轮训练里，有多少时间花在通信等待上。
- 尾延迟：平均延迟没那么关键，最慢那部分通信才可能拖住整个训练迭代。
- 抖动：网络是否稳定，有没有周期性抖动、突发抖动、局部链路异常。
- 拥塞恢复能力：出现拥塞后，是快速收敛，还是长时间震荡。
- 故障隔离能力：链路、端口、光模块、节点异常，能否快速定位和隔离。
- 多租户隔离能力：多个训练任务同时运行，是否互相干扰。
- 扩展性：从几十张 GPU 到几百张、几千张、上万张 GPU，性能是否能持续扩展。
所以，一张好的 AI Compute Fabric，不只是“带宽大”。
它要做到：
高有效带宽、低尾延迟、低抖动、可恢复、可观测、可扩展。
十五、常见误区
误区一：GPU 多，集群就强
不一定。
GPU 多只是资产规模大。
如果网络拖后腿，GPU 会大量等待。
真正强的是：
GPU 利用率高、训练吞吐稳定、故障恢复快、通信效率高。
误区二：端口带宽高，训练就快
不一定。
400G、800G 是端口能力。
训练看到的是 NCCL 有效带宽。
中间还隔着拓扑、拥塞、队列、路由、GPUDirect、通信算法。
误区三：RoCE 就是便宜版 InfiniBand
不准确。
RoCE 的价值不是便宜，而是以太网生态。
它的优势是开放、规模化、云基础设施融合。
但它需要更强工程能力。
误区四：PFC 开了，RoCE 就稳定了
不准确。
PFC 只是最后保险丝。
真正的大规模 RoCE 还要依赖 ECN、DCQCN、队列、buffer、多路径、遥测和端侧速率控制。
误区五：网络团队调好就行，软件不用管
不准确。
NCCL、训练框架、并行策略都会影响网络流量。
网络和软件必须一起优化。
十六、怎么选择 InfiniBand 还是 RoCE？
可以从五个问题判断。
1. 更在意确定性交付，还是开放生态？
确定性交付优先，InfiniBand 更直接。
开放生态、长期规模化、云基础设施融合优先，RoCE 更值得投入。
2. 有没有强网络工程团队？
RoCE 对网络工程、自动化、压测、调优和观测能力要求更高。
如果团队经验不足，RoCE 的隐藏成本可能很高。
3. 集群规模有多大？
小规模集群，很多问题不明显。
规模越大，拥塞、尾延迟、故障、调优复杂度越明显。
4. 业务是训练为主，还是推理为主？
训练更依赖同步集合通信，对 Fabric 要求更高。
推理也越来越依赖高速网络，尤其是分布式推理、长上下文、KV cache、PD 分离等场景，但通信模式和训练不同。
5. 是否需要多租户云化？
如果是自用训练集群，网络可以更专用。
如果是云平台，需要多租户隔离、计费、调度、SLA 和资源池化，RoCE / AI Ethernet 的开放生态会更有吸引力。
最终选择可以这样理解：
InfiniBand 适合先追求确定性。
RoCE 适合有工程能力后追求开放性和规模化。
十七、AI 算力基础设施的真正竞争
AI 算力竞争，正在从“谁有 GPU”，进入“谁能把 GPU 组织成稳定算力系统”。
这个系统至少由四层组成。
第一层：GPU 算力层
包括 GPU 型号、显存容量、算力、功耗、散热、节点设计。
第二层：节点内互连层
包括 NVLink、NVSwitch、PCIe 拓扑。
它决定一台服务器内部的 GPU 如何协同。
第三层：节点间 Fabric 层
包括 InfiniBand、RoCE、AI Ethernet。
它决定多台服务器如何组成大规模集群。
第四层：通信软件层
包括 NCCL、MPI、DeepEP、训练框架里的并行策略。
它决定数据如何切分、同步、路由和与计算重叠。
这四层任何一层短板，都会变成 GPU 等待时间。
所以，AI 基础设施的核心能力，不是简单采购 GPU。
而是构建一套完整的 AI Compute Fabric。
结语：网络正在成为算力系统本身
GPU 集群需要的不是一张普通网络。
它需要的是一张 AI Compute Fabric。
它既要提供高带宽，也要控制尾延迟。
既要支持 RDMA 和 GPUDirect，也要处理拥塞、队列、路由、遥测和故障恢复。
既要让单个节点跑得快，也要让成百上千张 GPU 在同一个训练节奏里稳定前进。
InfiniBand 的优势，是把这种确定性做成成熟的一体化系统。
RoCE 的优势，是把 RDMA 带进开放的以太网生态，但需要更强的网络工程、运维和软件协同能力。
所以，判断一个 GPU 集群，不能只看 GPU 数量，也不能只看网口标称带宽。
真正要看的，是：
- NCCL 有效带宽；
- 集合通信耗时；
- 尾延迟和抖动；
- 拥塞恢复能力；
- 故障隔离能力；
- 网络可观测性；
- 多租户隔离能力；
- 集群能否随 GPU 数量持续扩展。
当 AI 计算从单机走向大规模集群，网络已经不再只是服务器之间的连接。
它正在成为算力系统本身的一部分。
真正的算力基础设施竞争，不是 GPU 数量的竞争。
而是：
谁能让更多 GPU 更稳定地一起工作。
权威扩展参考资料
下面这些资料建议按学习顺序看，不要一上来就全部读论文。
-
NVIDIA NCCL Collective Operations：支撑 AllReduce、AllGather、ReduceScatter、AllToAll 等集合通信。
https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html -
NVIDIA GPUDirect RDMA：支撑 GPU 与网卡 / PCIe peer device 直接数据交换。
https://developer.nvidia.com/gpudirect -
NVIDIA Quantum-X800 InfiniBand：支撑 InfiniBand 的 SHARP、自适应路由、遥测拥塞控制、性能隔离等能力。
https://www.nvidia.com/en-us/networking/products/infiniband/quantum-x800/ -
NVIDIA SHARP with NCCL：支撑 SHARP 与 NCCL-SHARP plugin 集成。
https://docs.nvidia.com/networking/display/sharpv300/using%2Bnvidia%2Bsharp%2Bwith%2Bnvidia%2Bnccl -
NVIDIA RoCE 文档 / IETF RoCEv2 draft：支撑 RoCEv2 运行在 UDP/IP 之上、可进行三层路由。
https://networking-docs.nvidia.com/mlnxofedswum/24.10-5.1.6.1lts/rdma-over-converged-ethernet-roce -
DCQCN: Congestion Control for Large-Scale RDMA Deployments：支撑 RoCEv2 的 ECN、CNP、端侧 NIC 拥塞控制。
https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p523.pdf -
Microsoft: RDMA over Commodity Ethernet at Scale：支撑 PFC deadlock、livelock、pause storm 等 RoCE 工程风险。
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/rdma_sigcomm2016.pdf -
Meta: RoCE Networks for Distributed AI Training at Scale：支撑大规模 AI 训练中 RoCE backend network 的真实工程实践。
https://engineering.fb.com/2024/08/05/data-center-engineering/roce-network-distributed-ai-training-at-scale/ -
NVIDIA Spectrum-X / AI Ethernet 方向：支撑 AI Ethernet / Ethernet for AI networking 的产品化方向。
https://www.nvidia.com/en-us/networking/products/ethernet/spectrum-x/ -
Ultra Ethernet Consortium Specification 1.0：支撑以太网生态正在面向 AI / HPC 重构。
https://ultraethernet.org/ultra-ethernet-consortium-uec-launches-specification-1-0-transforming-ethernet-for-ai-and-hpc-at-scale/