面向 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 之上。
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 完成其交换时,该步骤才结束。
集合通信局部性
xCCL 调度占主导的 AllReduce 于单个 rail 内. Because a rail is one leaf, that traffic stays on the leaf and never contends for spine capacity.
最低跳数
同 rank 的 GPU 共享一台 leaf,因此梯度同步交换以最少的跳数完成。spine 只承载跨 rail 的剩余流量。
更低的尾延迟
一个同步步骤在最慢的那次交换结束时才结束。让热点集合通信避开 spine,可削减拖慢整个作业的长尾。
rail 优化 fabric 的布局展开
每台 GPU 服务器配有 8 块 NIC,每个 rail 一块,且每个 rail 都是各自专用的 leaf,因此一台服务器上的 8 块 NIC 分别落到不同的 leaf 上。rail-N 上的 AllReduce 始终留在 leaf-N 内,绝不触及 spine;一层 1:1 无阻塞 spine 只承载跨 rail 的剩余流量。此图为示意图:它绘制了经过简化的服务器与 spine 数量,以保持 rail 对齐关系的可读性。

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)。
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 和通用机架。 |
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。
两级,1:1 无阻塞
每个 GPU 一个 800G fabric 端口的 rail 优化 leaf-spine。标准的单 pod 可扩展单元。
带 800G 拆分的两级
同样的两级设计,将 800G 端口拆分给多块 GPU NIC,以提高每台交换机的 GPU 密度。
3 级 Clos
在 rail 优化 pod 之上增加一层 super-spine。每个 pod 保持 1:1 无阻塞;由 super-spine 设定跨 pod 收敛比。
fat-tree 极限
在此基数下三级 fat-tree 的理论上限。跨 pod 收敛比按工作负载调节。
正在为自己的集群做容量规划? The AI Fabric Design Suite 按每个 GPU 一块 fabric NIC 为无阻塞两级 leaf-spine pod 设定规格,并在您跨入三级规模时给出提示。要了解完整的拓扑全貌,请参见 AI fabric 拓扑 reference.
OcNOS-DC 如何构建 rail 优化 fabric
OcNOS-DC 通过路由式 underlay、无损 RoCEv2 底座、自适应负载均衡和流式遥测,把 HCL 收录的 Tomahawk 5 交换机变成一张 rail 优化 fabric。它是一个整体系统:经过验证的硬件、OcNOS-DC 网络操作系统,以及一份配有一个 TAC 和一个 SLA 的单一支持合同。
BGP-unnumbered L3
采用 BGP unnumbered 的路由式 underlay 免去了逐链路地址规划,并通过 ECMP 把流量分散到每条 rail 到 spine 的路径上。
带 PFC + ECN 的 RoCEv2
OcNOS-DC 提供 RoCEv2 所需的无损以太网底座:PFC 让优先级保持无损,ECN 标记拥塞。RoCEv2 本身则是运行在该底座之上的 NIC 传输。
动态负载均衡
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 硬件兼容性列表中。
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.
获取 AI Fabric 参考设计
简短表单:提交后 PDF 将立即开始下载。
✓ 正在新标签页中打开您的 PDF……
如果未能自动打开,请使用下方链接。
rail 优化网络常见问题解答
什么是 rail 优化网络?
rail 优化与 rail-only 有何区别?
Rail 与 ToR:AI fabric 应采用哪种布局?
rail 优化 fabric 能扩展到多少个 GPU?
rail 优化网络需要 InfiniBand 吗?
OcNOS-DC 如何实现 rail 优化 fabric?
深入了解,随身带走。
产品数据手册,以及内容比本页更为深入的简明技术下载资料。
OcNOS-DC 数据手册
表单简短。提交后您的 PDF 将立即在新标签页中打开。
✓ 正在新标签页中打开您的 PDF……
如果未能自动打开,请使用下方链接。
OcNOS 800G 无损 AI Fabric
表单简短。提交后您的 PDF 将立即在新标签页中打开。
✓ 正在新标签页中打开您的 PDF……
如果未能自动打开,请使用下方链接。
EVPN-VXLAN 数据中心网络
表单简短。提交后您的 PDF 将立即在新标签页中打开。
✓ 正在新标签页中打开您的 PDF……
如果未能自动打开,请使用下方链接。
在规划 rail 优化 GPU fabric?我们将与您一起做端口数量测算。
告诉我们 GPU 规模和 rail 数量,IP Infusion 的工程师将与您一起为 leaf-spine pod 设定规格,或先在 AI Fabric Design Suite 中生成一版初步布局。
用 OcNOS 设计整张 AI fabric
从商业论证到端口数量测算,无论您进行到哪一步,都可从此接续。