8 个 Rail · RoCEv2 · Tomahawk 5

面向 AI fabric 的 rail 优化网络拓扑

rail 优化网络把每台 8-NIC GPU 服务器的一块 NIC 分别放到 8 个 rail 上,并让每个 rail 成为各自专用的 leaf,因此占主导的 rail 内 AllReduce 始终留在一台 leaf 上,绝不触及 spine。 这是一种关于布线和流量局部性的规范,而非减少 spine 数量的手段:spine 保持 1:1 无阻塞,只承载跨 rail 的剩余流量。构建于基于 Broadcom Tomahawk 5 无损 RoCEv2 的 OcNOS-DC 之上。

8 rails每台服务器每个 rail 一块 NIC
~2,048GPU 两级 1:1 上限
TH4 & TH5Broadcom 芯片
1 NOS运行于开放硬件上的 OcNOS-DC
布线规范

rail 优化意味着什么,以及它与 rail-only 有何不同

现代 GPU 服务器出厂配有 8 块 NIC。一个 rail 是从每台服务器取出的一个 NIC 位置:每台服务器的 NIC-1 构成 rail-1,依此类推直到 rail-8。rail 优化把每个 rail 归属到各自专用的 leaf,因此每台服务器都有一条链路接入这 8 台 rail leaf 中的每一台。

回报在于局部性:xCCL 库把占主导的 AllReduce 调度在单个 rail 内,而由于该 rail 就是一台 leaf,流量从不离开这台 leaf。只有较小的跨 rail 剩余流量才会到达 spine。rail 优化是一种关于布线和流量局部性的规范,而非缩减 spine 的手段——spine 始终保持 1:1 无阻塞。

  • Rail-only 保留 rail 对齐的 leaf,但去掉 spine 层,因此跨 rail 流量依赖服务器内的 GPU scale-up 域,而非网络路径。对寥寥几个机架而言更便宜,但一旦集群超出单个 scale-up 域,跨 rail 流量便没有 fabric 路由可走。
  • Rail-optimized 在 rail leaf 之上增加一层 1:1 无阻塞 spine,为跨 rail 流量提供真正的网络路径。它是标准的单 pod 可扩展单元;rail-only 则是其下方的入门起点。
为何重要

rail 对齐让热点集合通信保持本地化

分布式训练由 AllReduce 等用于梯度同步的集合通信主导,这些操作通过 xCCL 库(NCCL、RCCL、oneCCL)运行。rail 对齐把同 rank 的 GPU 放到共享的一台 leaf 上,因此在常见情形下这些集合通信以最低跳数完成,且无需经过 spine。这抑制了尾延迟,而尾延迟决定着同步步骤的节奏:只有当最慢的 GPU 完成其交换时,该步骤才结束。

Locality

集合通信局部性

xCCL 调度占主导的 AllReduce 于单个 rail 内. Because a rail is one leaf, that traffic stays on the leaf and never contends for spine capacity.

Hop count

最低跳数

同 rank 的 GPU 共享一台 leaf,因此梯度同步交换以最少的跳数完成。spine 只承载跨 rail 的剩余流量。

尾延迟

更低的尾延迟

一个同步步骤在最慢的那次交换结束时才结束。让热点集合通信避开 spine,可削减拖慢整个作业的长尾。

Path use

均匀的路径使用

对于确实到达 spine 的跨 rail 流量, 动态负载均衡 分散大象流,使任何单条上行链路都不成为热点。

参考设计

rail 优化 fabric 的布局展开

每台 GPU 服务器配有 8 块 NIC,每个 rail 一块,且每个 rail 都是各自专用的 leaf,因此一台服务器上的 8 块 NIC 分别落到不同的 leaf 上。rail-N 上的 AllReduce 始终留在 leaf-N 内,绝不触及 spine;一层 1:1 无阻塞 spine 只承载跨 rail 的剩余流量。此图为示意图:它绘制了经过简化的服务器与 spine 数量,以保持 rail 对齐关系的可读性。

Rail-optimized AI data center on OcNOS-DC: a shared 800G Tomahawk 5 spine tier over two GPU pods where every server maps its eight NICs one per rail to eight color-coded rail leaves, plus a separate storage fabric (leaf-spine Clos, NVMe-oF and NFS) and an isolated out-of-band management plane that reaches every switch.
完整的 rail 优化 AI 数据中心:两个 GPU pod,每块 NIC 都接入各自的 rail leaf,配以专用的存储 fabric 和一个隔离的带外管理平面,全部运行在一套 NOS(OcNOS-DC)上。

OcNOS 组件: BGP-unnumbered L3 underlay,每台 rail leaf 上运行无损 RoCEv2(PFC + ECN),spine 层采用 DLB,全程 gNMI/OpenConfig 遥测。构建于 HCL 收录的 Tomahawk 5 硬件之上:Edgecore AIS800-64D 和 UfiSpace S9321-64E(64×800G)。

对齐 fabric

rail 优化、rail-only 与 ToR,并排对比

选择的关键在于 fabric 对齐到什么。rail 布局把每个 GPU rank 对齐到一个网络平面,因此集群中同 rank 的 GPU 共享一台 leaf,集合通信以最低跳数完成。ToR 布局则对齐到服务器:一台服务器中的每块 NIC 都落到其机架交换机上,布线更简单,但会迫使不同机架中的同 rank GPU 上到 spine 再返回。对以 AllReduce 为主的 GPU 训练 fabric 而言,rail 对齐是标准;而对流量并非 rank 同步的存储和通用机架,ToR 仍是不错的选择。

Property Rail-optimized单 pod 标准 Rail-only小规模集群入门 机架顶(ToR)server-aligned
Alignment 每个 GPU rank 对齐到一个网络平面;每台服务器的 NIC-N 归属到 leaf-N。 同样的 rail 对齐:NIC-N 归属到 rail leaf-N,但仅有单排 leaf。 网络对齐到服务器;服务器中的每块 NIC 都归属到其所在机架的交换机。
Spine tier rail leaf 之上有 1:1 无阻塞 spine。 没有 spine 层;rail leaf 独立存在。 机架交换机之上有标准 spine。
跨 rail 路径 一条经由无阻塞 spine 的真正网络路径。 依赖服务器内的 GPU scale-up 域;一旦超出单个域便没有 fabric 路由。 rank 同步流量被推向 spine。
集合通信跳数 最低:同 rank 的对端共享一台 leaf,因此 rail 内 AllReduce 留在一台 leaf 上。 rail 内同样很低,因为该 rail 仍是一台 leaf。 较高:不同机架中的同 rank 对端位于不同交换机上,因此集合通信要穿越 spine。
最佳匹配 面向 GPU 训练与推理 fabric 的标准单 pod 可扩展单元。 单个 scale-up 域之下的寥寥几个机架;入门起点。 流量并非 rank 同步的存储、CPU 和通用机架。
Scale

rail 优化 fabric 能扩展到多远

规模由交换机基数以及每个 800G 端口如何映射到 GPU 决定。在基数为 64 的 Broadcom Tomahawk 5(51.2 Tbps,64×800G)上,这些设计可从两级 leaf-spine 一直扩展到三级 Clos。由于多数集合通信流量留在 rail 本地,super-spine 平面只需按您实际所需的跨 pod 收敛比来设定规格。作为参考,Meta 曾公开描述过一个基于以太网的 24,000-GPU AI 训练集群,这表明以太网 fabric 的运行规模可远超单个 pod。

~2,048 Tomahawk 5 · 64×800G

两级,1:1 无阻塞

每个 GPU 一个 800G fabric 端口的 rail 优化 leaf-spine。标准的单 pod 可扩展单元。

8,000+ Tomahawk 5 · 800G 拆分

带 800G 拆分的两级

同样的两级设计,将 800G 端口拆分给多块 GPU NIC,以提高每台交换机的 GPU 密度。

16,000+ Tomahawk 5 · super-spine 平面

3 级 Clos

在 rail 优化 pod 之上增加一层 super-spine。每个 pod 保持 1:1 无阻塞;由 super-spine 设定跨 pod 收敛比。

~65,536 Tomahawk 5 · fat-tree 上限

fat-tree 极限

在此基数下三级 fat-tree 的理论上限。跨 pod 收敛比按工作负载调节。

正在为自己的集群做容量规划? The AI Fabric Design Suite 按每个 GPU 一块 fabric NIC 为无阻塞两级 leaf-spine pod 设定规格,并在您跨入三级规模时给出提示。要了解完整的拓扑全貌,请参见 AI fabric 拓扑 reference.

IP Infusion 的构建方式

OcNOS-DC 如何构建 rail 优化 fabric

OcNOS-DC 通过路由式 underlay、无损 RoCEv2 底座、自适应负载均衡和流式遥测,把 HCL 收录的 Tomahawk 5 交换机变成一张 rail 优化 fabric。它是一个整体系统:经过验证的硬件、OcNOS-DC 网络操作系统,以及一份配有一个 TAC 和一个 SLA 的单一支持合同。

Underlay

BGP-unnumbered L3

采用 BGP unnumbered 的路由式 underlay 免去了逐链路地址规划,并通过 ECMP 把流量分散到每条 rail 到 spine 的路径上。

Lossless

带 PFC + ECN 的 RoCEv2

OcNOS-DC 提供 RoCEv2 所需的无损以太网底座:PFC 让优先级保持无损,ECN 标记拥塞。RoCEv2 本身则是运行在该底座之上的 NIC 传输。

Balancing

动态负载均衡

DLB 依据实时路径质量而非静态哈希来分散大象流,因此跨 rail 流量不会堆积到一条上行链路上,运维良好的 fabric 在 Tomahawk 4/5 上可将目标利用率设定在 90% 以上。

遥测

gNMI / OpenConfig

按路径的利用率和队列深度计数器通过 gNMI 以 OpenConfig 模型流式输出,因此您可在集群上线调试期间用闭环数据来调优 fabric。

硬件

HCL 收录的 Tomahawk 5

运行在经过验证的 64×800G 交换机上:Edgecore AIS800-64D 和 UfiSpace S9321-64E。这里的每台 leaf 和 spine 都在 OcNOS 硬件兼容性列表中。

Forward-looking

Ultra Ethernet 就绪

IP Infusion 是 Ultra Ethernet 联盟的贡献成员,OcNOS-DC 跟踪 UEC 1.0 fabric profile,因此随着 UEC 能力 NIC 上市,fabric 得以延续。与该 profile 对齐并不构成认证声明。

资源

获取 AI Fabric 参考设计

The full PDF: rail-optimized topology, switch and transceiver counts, validated platforms, and a RoCEv2 lossless starting profile on OcNOS-DC.

下载 PDF
常见问题

rail 优化网络常见问题解答

什么是 rail 优化网络?
A rail-optimized network is an AI fabric wiring pattern for GPU servers. Each server carries 8 NICs, one per "rail", and every rail is homed to its own dedicated leaf. Because rail-N from every server lands on leaf-N, the dominant same-rail AllReduce traffic stays inside one leaf and never traverses the spine. That keeps hop count and tail latency low for the collective patterns that dominate distributed training.
rail 优化与 rail-only 有何区别?
两者都把 GPU NIC 对齐到 rail。 Rail-only 是小规模集群的情形:单排 rail 对齐的 leaf,没有 spine 层,因此跨 rail 流量依赖 GPU 的 scale-up 域。 Rail-optimized 在那些 rail leaf 之上增加一层 1:1 无阻塞 spine,因此跨 rail 流量拥有真正的网络路径。对寥寥几个机架而言,rail-only 更简单也更便宜;而一旦需要跨 rail 带宽,rail 优化便是标准的单 pod 可扩展单元。
Rail 与 ToR:AI fabric 应采用哪种布局?
rail 布局把每个 GPU rank 对齐到一个网络平面,由于同 rail 的对端共享一台 leaf,为集合通信提供最低的跳数。机架顶(ToR)布局则以服务器为中心对齐:一台服务器中的每块 NIC 都落到同一台机架交换机上,布线更简单,但会把更多集合通信流量推向 spine,因为不同机架中的同 rank GPU 从不在同一台 leaf 上。对 GPU 训练 fabric 而言,rail 对齐是标准,因为它让 AllReduce 模式保持本地化。
rail 优化 fabric 能扩展到多少个 GPU?
On radix-64 Broadcom Tomahawk 5 switches (51.2 Tbps, 64×800G), a 2-tier rail-optimized leaf-spine reaches about 2,048 GPUs at one 800G fabric port per GPU (1:1 non-blocking), and scales toward 8,000+ GPUs when 800G ports break out to multiple GPU NICs. Extending to a 3-stage Clos with a super-spine tier reaches 16,000+ GPUs in the reference designs, and up to about 65,536 GPUs at the fat-tree limit.
rail 优化网络需要 InfiniBand 吗?
不需要。rail 优化 fabric 运行在标准以太网上。OcNOS-DC 使用 PFC 和 ECN 提供 RoCEv2 所需的无损以太网底座,因此 RDMA 可在各 rail 上无损运行。IP Infusion 同时也是 Ultra Ethernet 联盟的贡献成员,OcNOS-DC 跟踪 UEC 1.0 fabric profile,因此随着 UEC 能力 NIC 上市,同一张 fabric 得以延续。与该 profile 对齐并不构成认证声明。
OcNOS-DC 如何实现 rail 优化 fabric?
OcNOS-DC 用 BGP-unnumbered L3 路由构建 underlay,通过 PFC 和 ECN 让每台 rail leaf 对 RoCEv2 无损,用动态负载均衡(DLB)分散大象流,并流式输出 gNMI/OpenConfig 遥测以支持闭环调优。它运行在 HCL 收录的 Tomahawk 5 硬件上,例如 Edgecore AIS800-64D 和 UfiSpace S9321-64E。一份 IP Infusion 合同即涵盖 OcNOS-DC 软件和经过验证的交换机硬件,并配以一个 TAC 和一个 SLA。

在规划 rail 优化 GPU fabric?我们将与您一起做端口数量测算。

告诉我们 GPU 规模和 rail 数量,IP Infusion 的工程师将与您一起为 leaf-spine pod 设定规格,或先在 AI Fabric Design Suite 中生成一版初步布局。