AI Fabric Topology

Rail-optimized network topology for AI fabrics

A rail-optimized network aligns every GPU NIC to a dedicated network plane, so the collective traffic that dominates distributed training stays local instead of climbing the spine. This page explains what rail-optimized means, how it differs from rail-only and top-of-rack layouts, how far it scales on Broadcom Tomahawk 5, and how OcNOS-DC builds it on validated open hardware.

What is a rail-optimized network? A rail-optimized network is an AI fabric layout where each 8-NIC GPU server puts one NIC on each of 8 rails, and every rail is its own dedicated leaf. Because rail-N from every server lands on leaf-N, the dominant intra-rail AllReduce stays on one leaf and never hits the spine, which keeps hop count and tail latency low for GPU collectives.

What rail-optimized means, and how it differs from rail-only

Modern GPU servers ship with 8 NICs. A rail is one NIC position taken from every server: NIC-1 from every server forms rail-1, and so on to rail-8. Rail-optimized homes each rail to its own dedicated leaf, so every server has one link into each of the 8 rail leaves. The payoff is locality: xCCL libraries schedule the dominant AllReduce inside a single rail, and because that rail is one leaf, the traffic never leaves the leaf. Only the smaller cross-rail remainder reaches the spine.

  • Rail-only keeps the rail-aligned leaves but drops the spine tier, so cross-rail traffic leans on the in-server GPU scale-up domain rather than a network path. Cheaper for a handful of racks, but with no fabric route for cross-rail flows once the cluster outgrows one scale-up domain.
  • Rail-optimized adds a 1:1 non-blocking spine above the rail leaves, giving cross-rail flows a real network path. It is the standard single-pod scalable unit; rail-only is the entry point below it.

Why rail-optimized matters

Distributed training is dominated by collectives such as AllReduce for gradient synchronization, run through xCCL libraries (NCCL, RCCL, oneCCL). Rail alignment puts same-rank GPUs on a shared leaf, so those collectives complete with the lowest hop count and no spine transit for the common case. That holds down tail latency, and tail latency sets the pace of a synchronous step: it finishes only when the slowest GPU finishes its exchange.

Collective locality

xCCL schedules the dominant AllReduce inside one rail. Because a rail is one leaf, that traffic stays on the leaf and never contends for spine capacity.

Lowest hop count

Same-rank GPUs share a leaf, so gradient-sync exchanges complete in the fewest hops. The spine carries only the cross-rail remainder.

Lower tail latency

A synchronous step ends when the slowest exchange ends. Keeping the hot collective off the spine trims the long tail that stalls the whole job.

Even path use

For the cross-rail traffic that does reach the spine, Dynamic Load Balancing spreads elephant flows so no single uplink becomes the hot spot.

How far a rail-optimized fabric scales

Scale is set by the switch radix and by how each 800G port maps to GPUs. On radix-64 Broadcom Tomahawk 5 (51.2 Tbps, 64×800G), the designs run from a 2-tier leaf-spine up to a 3-stage Clos, shown below. Because most collective traffic stays rail-local, the super-spine plane is sized only to the cross-pod ratio you actually need. For context, Meta has publicly described a 24,000-GPU Ethernet-based AI training cluster, which shows Ethernet fabrics operating well beyond a single pod.

~2,048GPUs

2-tier, 1:1 non-blocking

Rail-optimized leaf-spine at one 800G fabric port per GPU. The standard single-pod scalable unit.

Tomahawk 5 · 64×800G
8,000+GPUs

2-tier with 800G breakout

Same 2-tier design with 800G ports broken out to multiple GPU NICs for higher GPU density per switch.

Tomahawk 5 · 800G breakout
16,000+GPUs

Clos a 3 stadi

Add a super-spine tier above rail-optimized pods. Each pod stays 1:1 non-blocking; the super-spine sets the cross-pod ratio.

Tomahawk 5 · super-spine plane
~65,535GPUs

Fat-tree limit

The theoretical ceiling of the 3-stage fat-tree on this radix. Cross-pod ratio is dialed to the workload.

Tomahawk 5 · fat-tree ceiling

State dimensionando il vostro cluster? The AI Fabric Design Suite sizes a non-blocking two-tier leaf-spine pod at one fabric NIC per GPU and flags when you cross into three-tier scale. For the full topology picture, see the Topologie AI fabric reference.

Reference Design

The rail-optimized fabric, laid out

Each GPU server carries 8 NICs, one per rail, and each rail is its own dedicated leaf, so all 8 NICs on a server land on different leaves. AllReduce across rail-N stays inside leaf-N and never touches the spine; a 1:1 non-blocking spine carries only the cross-rail remainder. The diagram is schematic: it draws a reduced server and spine count to keep the rail alignment readable.

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.
The full rail-optimized AI data center: two GPU pods with every NIC on its own rail leaf, a dedicated storage fabric, and an isolated out-of-band management plane, all on one NOS (OcNOS-DC).

Componenti OcNOS: BGP-unnumbered L3 underlay, RoCEv2 lossless (PFC + ECN) on every rail leaf, DLB at the spine tier, gNMI/OpenConfig telemetry throughout. Built on HCL-listed Tomahawk 5 hardware: the Edgecore AIS800-64D and UfiSpace S9321-64E (64×800G).

Rail vs ToR: aligning the fabric to GPU ranks

The rail-versus-ToR choice is about what the fabric aligns to. A rail layout aligns each GPU rank to a network plane, so same-rank GPUs across the cluster share a leaf and the collective completes with the lowest hop count. A ToR layout aligns to the server: every NIC in one server lands on its rack switch, which is simpler to cable but forces same-rank GPUs in different racks up to the spine and back. For GPU training fabrics, where AllReduce dominates, rail alignment is the standard; ToR stays a fine choice for storage and general-purpose racks where traffic is not rank-synchronous.

Property Rail-optimized Top-of-rack (ToR)
Alignment Each GPU rank aligned to a network plane; NIC-N from every server homes to leaf-N. Network aligned to the server; every NIC in a server homes to its own rack switch.
Collective hop count Lowest: same-rank peers share a leaf, so intra-rail AllReduce stays on one leaf. Higher: same-rank peers in different racks sit on different switches, so collectives cross the spine.
Spine pressure Low for the dominant collective; the spine carries only the cross-rail remainder. Higher: rank-synchronous collective traffic is pushed up to the spine.
Cabling More structured: eight rails fan out from each server to eight rail leaves. Simpler: a server's links stay within its own rack to one switch.
Scelta ottimale GPU training and inference fabrics where AllReduce dominates. Storage, CPU, and general-purpose racks where traffic is not rank-synchronous.

How OcNOS-DC builds a rail-optimized fabric

OcNOS-DC turns HCL-listed Tomahawk 5 switches into a rail-optimized fabric with a routed underlay, a lossless RoCEv2 substrate, adaptive load balancing, and streaming telemetry. It is one system: validated hardware, the OcNOS-DC network operating system, and a single support contract with one TAC and one SLA.

Underlay

BGP-unnumbered L3

A routed underlay with BGP unnumbered removes per-link address planning and spreads traffic across every rail-to-spine path with ECMP.

Lossless

RoCEv2 with PFC + ECN

OcNOS-DC provides the lossless Ethernet substrate that RoCEv2 requires: PFC keeps the priority lossless and ECN marks congestion. RoCEv2 itself is the NIC transport riding on that substrate.

Balancing

Dynamic Load Balancing

DLB spreads elephant flows by real-time path quality instead of a static hash, so cross-rail traffic does not pile onto one uplink. Broadcom has published that DLB lifts fabric utilization from about 55% to 90%+ on Tomahawk 4/5.

Telemetria

gNMI / OpenConfig

Per-path utilization and queue-depth counters stream over gNMI with OpenConfig models, so you tune the fabric with closed-loop data during cluster bring-up.

Hardware

HCL-listed Tomahawk 5

Runs on validated 64×800G switches: Edgecore AIS800-64D and UfiSpace S9321-64E. Every leaf and spine here is on the OcNOS Hardware Compatibility List.

Forward-looking

Ultra Ethernet ready

IP Infusion is a contributing member of the Ultra Ethernet Consortium, and OcNOS-DC tracks the UEC 1.0 fabric profile, so the fabric carries forward as UEC-capable NICs ship. Alignment with the profile is not a certification claim.

FAQ

Rail-optimized network FAQ

What is a rail-optimized network?
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.
What is the difference between rail-optimized and rail-only?
Both align GPU NICs to rails. Rail-only is the small-cluster case: a single row of rail-aligned leaves with no spine tier, so cross-rail traffic leans on the GPU scale-up domain. Rail-optimized adds a 1:1 non-blocking spine above those rail leaves, so cross-rail flows have a real network path. Rail-only is simpler and cheaper for a handful of racks; rail-optimized is the standard single-pod scalable unit once you need cross-rail bandwidth.
Rail vs ToR: which layout should an AI fabric use?
A rail layout aligns each GPU rank to a network plane, giving the lowest hop count for collectives because same-rail peers share a leaf. A top-of-rack (ToR) layout is server-aligned: every NIC in a server lands on the same rack switch, which is simpler to cable but pushes more collective traffic up to the spine, since same-rank GPUs in different racks are never on the same leaf. For GPU training fabrics, rail alignment is the standard because it keeps the AllReduce pattern local.
How many GPUs does a rail-optimized fabric scale to?
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,535 GPUs at the fat-tree limit.
Does a rail-optimized network need InfiniBand?
No. A rail-optimized fabric runs on standard Ethernet. OcNOS-DC provides the lossless Ethernet substrate that RoCEv2 requires using PFC and ECN, so RDMA runs without loss across the rails. IP Infusion is also a contributing member of the Ultra Ethernet Consortium, and OcNOS-DC tracks the UEC 1.0 fabric profile, so the same fabric carries forward as UEC-capable NICs ship. Alignment with the profile is not a certification claim.
How does OcNOS-DC implement a rail-optimized fabric?
OcNOS-DC builds the underlay with BGP-unnumbered L3 routing, makes every rail leaf lossless for RoCEv2 with PFC and ECN, spreads elephant flows with Dynamic Load Balancing (DLB), and streams gNMI/OpenConfig telemetry for closed-loop tuning. It runs on HCL-listed Tomahawk 5 hardware such as the Edgecore AIS800-64D and UfiSpace S9321-64E. One IP Infusion contract covers the OcNOS-DC software and the validated switch hardware, with one TAC and one SLA.

Planning a rail-optimized GPU fabric? We'll do the port-count maths with you.

Book an Architecture Review →