AI 超级计算机的高速公路:从 GB200/GB300 看懂 RDMA 网络

AI 超级计算机的高速公路:从 GB200/GB300 看懂 RDMA 网络

只要你大致知道“CPU、内存、网络”是什么,就能从头读到尾。我们会从“AI 为什么需要网络”讲起,一路深入到 NVIDIA GB200/GB300 机架内的三层网络架构,以及 RDMA 这项让十万颗 GPU 像一台计算机一样协同工作的关键技术。

一、AI 的瓶颈,很多时候不是算力,而是“堵车”

大家谈论 AI 芯片时,通常都在讨论 GPU 有多快、内存有多大。但有一个很反直觉的事实:在大型 AI 训练集群中,GPU 可能花大量时间“等待网络”,而不是计算。一项教材中的示例性测算显示:在其特定模型、消息规模、硬件拓扑和并行策略假设下,单节点配备 8 块 GPU 时,通信约占每步训练时间的 25%;扩展到数千块 GPU 时,通信与同步合计可能占到约八成。这两个比例不是适用于所有训练任务的固定常数;实际系统还会通过通信与计算重叠等技术降低等待比例,但网络仍是最关键的瓶颈之一。1

为什么?因为如今的大型语言模型(LLM)动辄拥有数千亿甚至上万亿个参数;训练时除参数本身外,还要保存梯度、优化器状态和激活值,完整训练状态往往远超单颗 GPU 的显存容量。因此,训练时必须拆分模型、训练状态和数据,交给成千上万颗 GPU 共同计算。这些 GPU 每完成一小步计算,就必须通过 AllReduce(全归约)等“集合通信”操作交换结果,对齐后才能继续下一步。

你可以把它想象成一场超大型的小组报告:

  • 每位组员(GPU)各自负责一部分工作。
  • 每隔几分钟,所有人都要停下来开会核对答案;任何一个人迟到,其他人都得等。
  • 开会(网络传输)越慢,大家“干等”的时间越长,再昂贵的人力(GPU)也都在浪费。

分布式训练的节奏:每完成一步计算,都要在 AllReduce 同步点等待所有 GPU——最慢的环节决定整体速度;集群越大,“干等”所占的比例越高

分布式训练的节奏:每完成一步计算,都要在 AllReduce 同步点等待所有 GPU——最慢的环节决定整体速度;集群越大,“干等”所占的比例越高

因此,网络就是 AI 超级计算机看不见的地基。而这座地基的核心技术,正是本文的主角:RDMA(Remote Direct Memory Access,远程直接内存访问)

二、什么是 RDMA?先从“传统网络为什么慢”说起

2.1 传统 TCP/IP:每个包裹都要经过好几道海关

我们平时上网使用的 TCP/IP 协议,其数据传输流程大致如下。这里描述的是便于理解的传统套接字简化路径:现代网卡卸载和经过调优的零拷贝 API 可以减少其中一部分工作,但主机网络协议栈仍处于数据路径之中。

  1. 应用程序把数据交给操作系统内核(kernel)
  2. 操作系统将数据复制到系统内存的缓冲区,拆分成数据包、添加包头并计算校验和。
  3. 网卡将数据包发送出去;对端收到后,再反向执行一次:触发 CPU 中断、解包,再将数据复制回应用程序内存。

这套流程非常可靠(互联网正是依靠它运行),但也有三个代价:

  • CPU 非常忙碌:协议处理、中断或轮询、缓冲区管理等工作,在高速传输时仍可能消耗大量主机 CPU 资源,即使已经启用网卡卸载也是如此。
  • 反复复制:数据不断在“应用程序内存 → 内核缓冲区 → 网卡”之间来回搬运。
  • 额外时延与抖动:具体时延取决于网卡、协议栈、负载和网络环境,但内存复制、系统调用、调度与排队都会增加端到端时延及其波动。

对于日常上网,这套方式完全够用;但对于需要持续交换大量梯度、激活值和模型状态的分布式 AI 训练而言,就像让 F1 赛车行驶在城市道路上。2

2.2 RDMA:让网卡直接“隔空取物”

RDMA 的核心概念只有一句话:

在预先注册的内存区域之间进行稳态数据传输时,让一台计算机的网卡直接读写另一台计算机的内存,使数据路径绕过两端的操作系统内核,并尽量减少 CPU 参与。

这里的“绕过”有明确边界:建立连接、注册和锁定内存、管理访问权限,以及处理完成通知和异常,仍然需要 CPU 与操作系统参与。RDMA 优化的是已注册内存之间的稳态数据路径,并不是让 CPU 和操作系统彻底消失。

它具体做了三件事:

  1. Kernel Bypass(绕过操作系统内核):完成初始化后,应用程序通过用户态 RDMA 接口向网卡提交工作请求;稳态数据路径无需反复进入内核网络协议栈。
  2. Zero Copy(零拷贝):数据直接从源内存传输到目标内存,不再通过中间缓冲区反复复制。
  3. 硬件卸载(Offload):数据面的分段、重组和可靠传输主要由网卡的专用硬件处理,显著降低 CPU 负载。

RDMA 不只有单边的 Read/Write 操作,也支持由两端分别提交缓冲区的双边 Send/Receive。无论采用哪种模型,网卡都只能访问预先注册并获得授权的内存区域;RDMA 并不会暴露任意系统内存。

打个比方:传统 TCP/IP 就像“你写信 → 交给邮局 → 对方邮局收信 → 送到收件人手中”;RDMA 则像是在两栋大楼之间直接架设一条气动传输管道。管道建好、收发区域登记完毕后,文件就能直达对方桌面,无需两端的前台人员(CPU)逐件转交。结果就是:稳态数据传输的时延可降至微秒级,CPU 开销也会大幅减少。2

传统 TCP/IP 与 RDMA 的数据路径对比:TCP/IP 每一站都要经过内核并复制数据;RDMA 的稳态数据路径绕过内核协议栈并减少 CPU 参与,由网卡直达远程内存

传统 TCP/IP 与 RDMA 的数据路径对比:TCP/IP 每一站都要经过内核并复制数据;RDMA 的稳态数据路径绕过内核协议栈并减少 CPU 参与,由网卡直达远程内存

2.3 GPUDirect RDMA:连主机内存都无需经过

在 AI 服务器中,NVIDIA 又将这种方式推进了一步。传统上,GPU 要把数据发送出去,必须先将其搬到主机系统内存(即所谓的 bounce buffer),再交给网卡。GPUDirect RDMA 让网卡通过 PCIe 直接读写 GPU 的显存(HBM),数据路径变为:

传统方式:GPU 显存 → 主机系统内存 → 网卡 → 网络 → 对端网卡 → 主机内存 → GPU 显存
GPUDirect RDMA:GPU 显存 → 网卡 → 网络 → 对端网卡 → GPU 显存

GPUDirect RDMA 与传统路径对比:数据直接在两端 GPU 显存(HBM)之间传输,完全绕过主机系统内存

GPUDirect RDMA 与传统路径对比:数据直接在两端 GPU 显存(HBM)之间传输,完全绕过主机系统内存

NVIDIA 官方数据显示,这种方式的传输性能最高可达传统路径的 10 倍3 这就是 RDMA 网卡在不同机架的 GPU 显存之间直接传输梯度的技术基础,可形成紧密耦合的分布式系统;但它不会让整座集群变成具有统一一致性或单设备编程模型的一颗 GPU。

三、认识主角:GB200 与 GB300 到底是什么?

3.1 GB200 是超级芯片,GB200 NVL72 才是机架级系统

这里需要先澄清命名:GB200 并不是一整座机架,也不只是单颗 GPU;它指的是 Grace Blackwell Superchip。本文讨论的完整机架级(rack-scale)超级计算机叫作 GB200 NVL72,GB300 与 GB300 NVL72 也有同样的层级区别:

  • GB200 超级芯片:1 颗 Grace CPU(Arm 架构)+ 2 颗 Blackwell GPU,通过 NVLink-C2C 直接封装互连。4
  • GB200 NVL72:一个机架中装有 36 颗 Grace CPU + 72 颗 Blackwell GPU(18 个计算托盘 + 9 个 NVLink 交换机托盘),每颗 GPU 配备 186 GB HBM3e(每颗 GB200 Superchip 合计 372 GB),整机架采用液冷,功耗约为 120 kW。5
  • GB300 NVL72:2025 年下半年推出的升级版本,采用 Blackwell Ultra GPU:单颗 GPU 的 HBM3e 显存从 186 GB 增至 288 GB,稠密 FP4 Tensor Core 吞吐量达到上一代的 1.5 倍,ConnectX-8 I/O 模块为每颗 GPU 提供总计 800 Gb/s 的横向扩展网络带宽,主要面向长上下文推理(inference)和复杂推理(reasoning)工作负载。5 6

3.2 三类概念性网络域

为了便于理解,可以先按功能把 GB200/GB300 NVL72 的互连概括为三类网络域。这是一种概念模型,并不表示每套部署恰好只有三套彼此固定的物理网络。7 8

网络 范围 技术 通俗比喻
NVLink(Scale-Up,纵向扩展) 机架内 72 颗 GPU 之间 NVLink 5 + NVSwitch,铜缆背板 同一座办公楼内的“内部电话”,快得就像在隔壁直接说话
RDMA 计算网络(Scale-Out,横向扩展) 机架之间,GPU 对 GPU InfiniBand 或 Spectrum-X 以太网 + ConnectX 网卡 城市之间的“高铁”,将成千上万颗 GPU 连接起来
前端/存储/带内管理网络(North-South,南北向) 对外提供服务、读取数据、系统管理 普通以太网 + BlueField-3 DPU 普通的对外道路:收发包裹、支持日常运维

在实际参考架构中,GPU 计算(东西向)、CPU 融合(南北向)、存储/客户接入网络和带外管理(OOB)可能采用独立物理网络,也可能按规模与需求进行汇聚;带外管理通常仍是单独的管理网络。概念上的三层网络相互补充,而非相互取代:NVLink 让一个机架内的 72 颗 GPU 形成统一的高速计算域;RDMA 网络将几十乃至几百个机架连接成一座“AI 工厂”;前端网络则负责处理其余任务。下面逐层解析。

四、第一层 NVLink:将 72 颗 GPU 焊成一颗

GB200/GB300 机架内部采用第五代 NVLink

  • 每颗 GPU 配备 18 条 NVLink 连接,双向带宽合计达到 1.8 TB/s,是 PCIe Gen5 的 14 倍以上。9
  • 72 颗 GPU 通过 9 个 NVSwitch 交换机托盘实现全互连(任意两颗 GPU 之间仅相隔一跳),整机架 NVLink 总带宽达到 130 TB/s5
  • 机架背板集成了超过 5,000 条铜缆。为什么使用铜缆而不是光纤?因为传输距离足够短,铜缆无需耗电的光电转换组件(如 DSP 和激光器)。据行业分析估算,每个机架可节省约 20 kW 电力,而且成本更低、可靠性更高。10
  • 第五代 NVLink 提供 GPU 间的加载/存储内存语义,让 72 颗 GPU 能够直接访问对端 HBM;NVLink-C2C 则在每颗 Grace Blackwell Superchip 内提供 CPU 与 GPU 的一致性访问。不过,这并不意味着把整座机架的 HBM 与 LPDDR5X 变成访问代价完全相同的平坦 UMA:本地与远程访问的路径、带宽和时延仍有差异,具体可见性和数据放置还取决于 CUDA/IMEX 与分区模型。整套系统的聚合容量为 13.4 TB HBM3e + 17 TB LPDDR5X(NVIDIA 官方规格)。4

NVLink Scale-Up:机架内 72 颗 GPU 通过 NVSwitch 全互连(每颗 GPU 1.8 TB/s、整机架 130 TB/s),形成统一的高速 GPU 计算域

NVLink Scale-Up:机架内 72 颗 GPU 通过 NVSwitch 全互连(每颗 GPU 1.8 TB/s、整机架 130 TB/s),形成统一的高速 GPU 计算域

一句话总结:在机架内部,NVLink 从通信层面将 72 颗 GPU 组织成一个高速计算域,但这并不代表所有内存访问都完全等价。 真正的挑战在机架之外,这时就该 RDMA 登场了。

五、第二层 RDMA Scale-Out 网络:AI 工厂的高速公路系统

当需要训练的模型大到一个机架(72 颗 GPU)都无法容纳时,就必须连接几十乃至几百个 NVL72 机架。这条“机架间 GPU 高速公路”有几个设计重点:

5.1 参考设计为每颗 GPU 提供一个逻辑网络端点(1:1)

在 NVIDIA 的 GB200/GB300 NVL72 参考设计中,横向扩展计算网络按每 GPU 一个 ConnectX 逻辑端点配置:GB200 通常使用 ConnectX-7 提供每 GPU 400 Gb/s,GB300 则使用 ConnectX-8 提供每 GPU 最高 800 Gb/s,避免多个 GPU 共享同一个受限出口。这里的 1:1 描述的是逻辑端点和带宽配比,并不一定表示每颗 GPU 都插有一张独立的 PCIe 扩展卡;实际系统会把 ConnectX 芯片集成到夹层网络板上,并可将端口拆分到双平面网络。GB300 的每个四 GPU 计算托盘对应四个 ConnectX-8 端点。ConnectX-8 还提供 48 条 PCIe Gen6 通道和集成式 PCIe 交换连接能力,成为计算托盘的 I/O 枢纽。7 11

NVL72 参考设计按每 GPU 一个逻辑 RDMA 网络端点配置:1:1 的端点与带宽配比避免共享出口瓶颈,但不代表每颗 GPU 都使用一张独立的 PCIe 扩展卡

NVL72 参考设计按每 GPU 一个逻辑 RDMA 网络端点配置:1:1 的端点与带宽配比避免共享出口瓶颈,但不代表每颗 GPU 都使用一张独立的 PCIe 扩展卡

5.2 Rail-Optimized 拓扑:同一托盘位置的 GPU 使用同一条轨道

机架之间采用 Leaf-Spine(叶脊)架构+轨道优化(rail-optimized)拓扑:它把每个计算托盘或节点内的本地 GPU 位置映射到固定 rail,例如各托盘的“1 号 GPU”端点进入同一条 rail,各托盘的“2 号 GPU”进入另一条 rail;跨机架时也保持这种位置映射。这里的编号是托盘内的本地位置,并不是把整座 NVL72 机架的 72 颗 GPU 编成 1~72 号。这样有助于通信库把集合通信映射到带宽均衡、跳数较少的路径。不过,实际跳数取决于网络规模与层级:小型配置可能停留在同一叶交换机,大型跨机架流量通常还会经过 spine,超大规模部署甚至会增加 super-spine,因此 rail 优化并不保证所有流量都只经过一层交换机。7

RDMA Scale-Out:轨道优化的 Leaf-Spine 拓扑——各计算托盘中相同本地位置的 GPU 映射到同一条 rail;实际跳数取决于 leaf、spine 与 super-spine 层级

RDMA Scale-Out:轨道优化的 Leaf-Spine 拓扑——各计算托盘中相同本地位置的 GPU 映射到同一条 rail;实际跳数取决于 leaf、spine 与 super-spine 层级

5.3 两条技术路线:InfiniBand 与 Spectrum-X 以太网

这是当前 AI 网络领域最重要的“路线之争”,NVIDIA 同时押注两条路线:

路线一:InfiniBand,为 HPC 而生的专业赛车

InfiniBand 是专为超级计算机设计、原生支持 RDMA 的网络。它采用基于信用的链路级流量控制:在正确配置且正常运行时,发送端不会向没有可用接收缓冲区的链路继续发送,从而避免因接收端缓冲区溢出而丢包;这并不等于在故障、误配置或其他异常条件下绝对不会丢包。

  • Quantum-2(NDR):400 Gb/s,是 GB200 时代的主力产品。
  • Quantum-X800(XDR):800 Gb/s,拥有 144 个端口,与 GB300 和 ConnectX-8 配套,是新一代 AI 工厂的旗舰产品。
  • SHARP 网内计算(In-Network Computing):InfiniBand 的重要优势。SHARP 可将其支持的数据类型与集合操作中的部分聚合、归约阶段卸载到交换机,减少端点之间重复传输和 GPU/CPU 参与;它并不是让交换机执行任意计算,也不意味着整个 AllReduce 必然由单台交换机一次完成。Quantum-X800 的 SHARP v4 提供最高 14.4 TFLOPS 的网内计算能力。12 这就像把原本需要另行办理的一部分汇总工作交给沿途设施完成。
  • Quantum 交换机提供极低的端口到端口转发时延;但 GPU 到 GPU 的端到端时延还包括 GPU、PCIe、网卡、线缆、排队和软件等环节,不能直接等同于交换机时延。结合 NCCL/MPI 使用时,应用通常无需大幅修改即可受益,但网络拓扑和通信库仍需正确配置。

代价在于:虽然 InfiniBand 是开放标准(IBTA),但当前高端商用交换机、网卡和软件生态的供应高度集中于 NVIDIA,部署通常也依赖专门的运维技能;具体成本则取决于拓扑、光模块、支持服务和采购规模。

路线二:Spectrum-X,将普通高速公路升级为赛道的以太网

以太网标准开放,相关人才、工具和既有运维体系也很普及;具体成本仍取决于网络设计。但传统以太网通过 RoCEv2(RDMA over Converged Ethernet)承载 RDMA 时,在大规模 AI 场景中容易出现热点:AI 流量通常是少数几条超大流(elephant flows),传统 ECMP 路由可能让它们集中在同一条路径上,引发严重拥塞。在 NVIDIA 公布的特定对比测试中,部分传统 ECMP 配置的有效吞吐率约为 60%;这一数字会随拓扑、负载和调优方式变化。13

对于 GB200/GB300 时代的数据路径,NVIDIA 的 Spectrum-X 平台将 Spectrum-4/SN5600 交换机与兼容的 BlueField-3 或 ConnectX SuperNIC 端到端组合,主要采用三项机制:

  1. 自适应路由+数据包喷洒(Adaptive Routing / Packet Spraying):交换机根据实时拥塞情况,逐包选择最空闲的路径,将大流分散到所有可用路径上。
  2. 直接数据放置(Direct Data Placement):数据包通过不同路径后可能乱序到达,目标端 SuperNIC 根据数据包元数据,将每段有效载荷直接写入已注册内存中的正确目标偏移。这样无需先按到达顺序拼回整条数据流,应用程序最终仍能看到布局正确的缓冲区。
  3. 硬件级拥塞控制:交换机通过带内遥测(in-band telemetry)报告网络状态,网卡根据反馈快速调整发送速率,以减少热点拥塞,并改善多租户环境中的性能可预测性与隔离效果。

结果是:在 NVIDIA 公布的相应测试条件下,Spectrum-X 的有效吞吐率可达到约 95%,同时继续使用以太网生态、工具和运维技能。13

两条 RDMA 路线:InfiniBand 通过基于信用的流量控制和 SHARP 网内计算提高效率;Spectrum-X 通过自适应路由、数据包喷洒和按目标偏移直接放置数据,将以太网有效吞吐率提升到约 95%

两条 RDMA 路线:InfiniBand 通过基于信用的流量控制和 SHARP 网内计算提高效率;Spectrum-X 通过自适应路由、数据包喷洒和按目标偏移直接放置数据,将以太网有效吞吐率提升到约 95%

应该选择哪条路线?

维度 InfiniBand(Quantum) Spectrum-X 以太网
性能 以极低时延和稳定高吞吐为目标,并支持 SHARP 网内计算 NVIDIA 测试中的有效吞吐率可达约 95%;这一代产品侧重路由与拥塞控制,不提供与 InfiniBand SHARP 完全对应的归约卸载能力
生态 采用开放标准,但供应集中于 NVIDIA,且需要专业人才 采用开放以太网标准,网络运维人才充足
成本 可能较高,具体取决于拓扑、光模块、支持服务与采购规模 可沿用部分以太网技能与工具;总成本仍取决于拓扑、收发器、冗余和超售设计
典型用户 顶尖研究实验室、追求极致性能的训练集群 云服务商、多租户 AI 云、企业

目前行业的现状是“双轨并行”:例如,CoreWeave 的 GB300 实例同时提供 Quantum-X800 InfiniBand 版本和 Spectrum-X RoCE 版本;Oracle OCI 的 GB200/GB300 也同时支持两种 RDMA 网络。14 15

六、GB200 → GB300:网络究竟升级了什么?

项目 GB200 NVL72 GB300 NVL72
GPU Blackwell(186 GB HBM3e) Blackwell Ultra(288 GB HBM3e)
每颗 GPU 的逻辑网络端点 ConnectX-7,400 Gb/s ConnectX-8,总计 800 Gb/s(带宽翻倍)
网卡接口 PCIe Gen5 PCIe Gen6 x48,内置 PCIe 交换机
配套交换机 Quantum-2(NDR 400G)/Spectrum-4 Quantum-X800(XDR 800G)/Spectrum-X 800G
NVLink NVLink 5,每颗 GPU 1.8 TB/s、整机架 130 TB/s 同属 NVLink 5 代

SemiAnalysis 对 GB200 硬件架构的分析认为,GB200 首发时新一代 224G SerDes 网络芯片尚未就绪,因此早期系统沿用了 H100 时代的 ConnectX-7 与 Quantum-2;按这一分析,端到端 800G 网络要到 GB300 时代才更完整地到位10 11 这也说明了一点:在 AI 基础设施领域,网络的代际演进与 GPU 同样关键,甚至可能影响产品交付节奏。

七、真实案例

xAI Colossus:10 万颗 GPU 的以太网豪赌

马斯克旗下的 xAI 在孟菲斯建造了 Colossus 超级计算机,使用 Spectrum-X 以太网连接 10 万颗 NVIDIA Hopper GPU;NVIDIA 发布相关资料时,扩展至 20 万颗 GPU 的工作仍在进行。从开工到开始训练仅用了 122 天。NVIDIA 公布的数据显示:整个集群维持了 95% 的数据吞吐率,并且没有因流量碰撞造成数据包丢失。这些厂商数据展示了以太网路线在超大规模环境中的可行性,也是“AI 工厂”理念最具代表性的实际案例之一。16

云计算巨头的选择

  • Oracle OCI:为 GB200/GB300 NVL72 开发了专用 API,将整个机架作为“一台超级计算机”进行配置,并自动优化 NVLink + InfiniBand 或 Spectrum-X RoCE。15
  • CoreWeave:为 GB300 提供 InfiniBand 与 Spectrum-X 两个版本,每颗 GPU 的网络带宽均为 800 Gb/s。14
  • Meta 与 Oracle 已宣布在其 AI 数据中心网络中采用 Spectrum-X 交换机;微软、CoreWeave 和 OCI 也已陆续部署 GB300 NVL72。13
  • Google Cloud:没有采购 Spectrum-X,而是将 NVIDIA 网卡接入自有网络体系。从 A3 Ultra(H200)开始,Google 改用 Titanium ML 网卡+标准 RoCE(取代早期深度定制 TCP 的 GPUDirect-TCPX)17 18;A4X(GB200 NVL72)每机架带宽为 28.8 Tb/s,A4X Max(GB300)则再次翻倍至每颗 GPU 800 Gb/s。外层由自研的 Jupiter 网络结构连接成包含数万颗 GPU 的无阻塞集群。Google 还设计了硬件辅助传输层 Falcon,并将其规范与设计贡献给 OCP 社区公开协作。TPU 则属于另一个平行世界:其加速器 pod 的芯片互连不使用以太网或 InfiniBand,而是采用专用的 ICI 芯片互连+ OCS 光路交换;这并不代表主机、存储和管理网络也采用相同方案。Ironwood 的单个 superpod 可直接连接 9,216 颗芯片。TPU v4 论文称,这套加速器互连方案比论文对比的同期 InfiniBand 设计成本更低、能耗更少、速度更快。19 20 21 22 23
  • AWS:甚至连网卡与传输协议也自行研发。EFA(Nitro 芯片)+ SRD 会将数据包逐个喷洒到最多 64 条路径,能够容忍乱序到达并实现微秒级重传(与 Spectrum-X 的“自适应路由+按目标偏移直接放置数据”思路相似,但早在 2019 年就已上线)。对外则采用自研的 10p10u 网络结构(吞吐率达数十 Pb/s,往返时延低于 10 微秒)。24 25 26 P6e-GB200 UltraServers 在机架内仍使用 NVL72,机架间则采用 EFAv4(每机架 28.8 Tb/s + GPUDirect RDMA);就连 NVIDIA 自己的 Project Ceiba(20,736 颗 B200)和为 Anthropic 打造的 Project Rainier(近 50 万颗 Trainium2)使用的也是 EFA,而非 InfiniBand;Rainier 在每个 64 芯片 Trainium2 UltraServer 内使用 NeuronLink,在 UltraServer 之间使用 EFA。27 28 29

将 GCP、AWS 与前文的 InfiniBand/Spectrum-X 进行对比,会发现设计思路正在明显趋同:多路径数据包喷洒、乱序容忍,以及将拥塞控制卸载到硬件。但它们并不共享同一种协议语义:InfiniBand 与 RoCE 提供 RDMA;AWS EFA 通过 libfabric 暴露基于 SRD 的高性能传输;Falcon 是可以承载 RDMA 等上层语义的硬件传输层;TPU ICI 则是 Google 的专用芯片互连。共同终点是低时延、高带宽和低 CPU 开销的数据移动,而不是所有方案都采用 RDMA。

八、下一步:当一座数据中心也不够用

随着 AI 集群持续扩张,单个站点的供电与容量正成为重要的扩展约束。NVIDIA 给出的答案,是在 scale-up(机架内纵向扩展)和 scale-out(机架间横向扩展)之后增加第三个维度:scale-across(跨数据中心扩展)

  • Spectrum-XGS Ethernet(2025 年发布):利用距离感知的拥塞控制算法,将分布在不同地点的多座数据中心连接成一座 Giga-scale(超大规模)AI 超级工厂。NVIDIA 报告称,其跨站点测试中的 NCCL 集合通信性能最高可提升至约 1.9 倍;CoreWeave 是首批宣布部署的客户之一。30
  • 硅光子(Silicon Photonics)/共封装光学(CPO):把光引擎与交换机 ASIC 共封装,而不是把光学元件直接做进交换芯片的硅片中。截至 2026 年 8 月,NVIDIA 表示 Spectrum-X Ethernet Photonics 已进入量产;其中 SN6800 的标称总交换带宽最高为 409.6 Tb/s。具体出货与部署状态仍取决于系统、合作伙伴和地区。31 32
  • Rubin 代产品正在落地:Vera Rubin NVL72 设计为每颗 GPU 提供 1.6 Tb/s 的 ConnectX-9 横向扩展带宽;NVLink 6 则提供每颗 GPU 3.6 TB/s、整机架 260 TB/s。NVIDIA 表示该平台正推进全面量产,量产系统计划于 2026 年秋季开始出货。32

九、总结

回顾全文:AI 竞赛早已不只是芯片竞赛,更是网络竞赛。 当模型大到单颗 GPU、单个机架甚至单座数据中心都无法容纳时,“让上万颗 GPU 高效协作”的网络能力,就会直接决定训练的成本与速度。在配置完成后的稳态数据路径上,RDMA 可绕过操作系统内核,并避免数据经由内核缓冲区反复复制;GPUDirect RDMA 进一步把这条直接路径延伸到 GPU 显存。两者结合,可将时延降至微秒级并显著降低 CPU 负载。

在 GB200/GB300 中,这套能力具体体现为三层网络架构:机架内使用 NVLink 将 72 颗 GPU 组织成高速计算域;机架之间使用 InfiniBand 或 Spectrum-X 以太网(后者通过 RoCE 承载 RDMA)将几十乃至几百个机架连接成一座 AI 工厂;再通过 Spectrum-XGS 将多座工厂连接成跨数据中心的超级工厂。下次看到 AI 超级计算机的新闻时,除了 GPU 的算力数据,也别忘了那条看不见的高速公路。它才是决定这座 AI 工厂能够运行多快的隐形地基。

术语表

术语 通俗解释
RDMA 远程直接内存访问。完成配置后,网卡可通过单边 Read/Write 或双边 Send/Receive,在已注册且获授权的内存区域之间传输数据,使稳态数据路径绕过内核并显著减少 CPU 参与;连接建立和内存注册等控制操作仍需要软件处理。
GPUDirect RDMA 网卡直接读写 GPU 显存,并绕过主机系统内存中的中转缓冲区。
RoCE 在以太网上承载 RDMA 的协议(RDMA over Converged Ethernet)。
NVLink / NVSwitch 机架内 GPU 之间的超高速互连(scale-up)。
InfiniBand 专为超级计算设计、原生支持 RDMA 的网络(使用 Quantum 系列交换机)。
Spectrum-X NVIDIA 面向 AI 优化的以太网平台(交换机与 SuperNIC 的端到端组合)。
SHARP 将受支持的集合操作中的部分聚合与归约阶段卸载到交换机执行的“网内计算”技术。
EFA/SRD EFA 通过 libfabric 向应用提供绕过操作系统的数据路径,SRD 则是由 AWS Nitro 硬件实现的传输协议;较新的受支持实例还提供 RDMA 读写能力。EFA/SRD 不是 RoCE 或 InfiniBand。
Falcon Google 设计的硬件辅助传输层;其规范与设计已贡献给 OCP 社区公开协作,可在普通以太网上承载 RDMA 等上层语义。
ICI/OCS Google TPU pod 使用的专用芯片互连与光路交换技术,不属于 InfiniBand 或 RoCE/RDMA 协议。
AllReduce 分布式训练中“所有参与者交换并汇总梯度”的集合通信操作。
Scale-up / Scale-out / Scale-across 机架内纵向扩展/跨机架横向扩展/跨数据中心扩展。

参考资料

  1. MLSysBook:集合通信 

  2. FS.com:快速了解 RDMA 与 TCP/IP 的区别  2

  3. NVIDIA GPUDirect 官方页面 

  4. NVIDIA GB200 NVL72 技术博客:万亿参数 LLM 训练  2

  5. NVIDIA GB200 NVL72 官方页面与规格  2 3

  6. NVIDIA GB300 NVL72 官方页面 

  7. NVIDIA NVL72 AI Factory 企业参考架构:网络逻辑架构  2 3

  8. NVIDIA DGX GB200 用户指南:网络 

  9. SemiAnalysis:GB200 硬件架构  2

  10. ServeTheHome:ConnectX-8 SuperNIC PCIe Gen6 800G 详解  2

  11. NVIDIA Quantum-X800 InfiniBand 平台 

  12. NVIDIA Spectrum-X 平台与白皮书  2 3

  13. CoreWeave:GB200/GB300 NVL72 实例文档  2

  14. Oracle:GB200 NVL72 专用 API 背后的设计  2

  15. NVIDIA Newsroom:Spectrum-X 加速 xAI Colossus 

  16. Google Cloud 文档:GPU 机型网络带宽与 GPUDirect 技术对比 

  17. Google Cloud:A3 Ultra(H200)正式发布及 Titanium ML 网卡 

  18. Google Cloud:A4X(GB200 NVL72)虚拟机发布 

  19. Google Cloud:A4X Max(GB300 NVL72)交付公告 

  20. Google Cloud:Falcon 硬件传输层(通过 OCP 公开规范与设计) 

  21. Google Cloud:Ironwood TPU 发布 

  22. TPU v4 论文:An Optically Reconfigurable Supercomputer for ML 

  23. AWS:Elastic Fabric Adapter 官方文档 

  24. Amazon Science:A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC 

  25. AWS:10p10u/UltraCluster 2.0 网络 

  26. AWS:P6e-GB200 UltraServers 发布 

  27. DCD:Project Ceiba 升级至 20,736 颗 Blackwell 并采用第四代 EFA 

  28. AWS:Project Rainier(近 50 万颗 Trainium2 的集群) 

  29. NVIDIA Newsroom:Spectrum-XGS 跨数据中心扩展 

  30. NVIDIA 技术博客:Spectrum-X Ethernet Photonics 如何提升 AI 工厂能效 

  31. NVIDIA 技术博客:Vera Rubin 平台架构NVIDIA Newsroom:Vera Rubin 推进全面量产  2

Eason Cao
Eason Cao Eason is an engineer working at FANNG and living in Europe. He was accredited as AWS Professional Solution Architect, AWS Professional DevOps Engineer and CNCF Certified Kubernetes Administrator. He started his Kubernetes journey in 2017 and enjoys solving real-world business problems.
comments powered by Disqus