05 / NETWORK DESIGN

How a cluster is connected

Network layout determines which routes data can take, how much equipment is needed, and which machines are affected when a switch fails.

A shared switching fabric

A fat-tree routes messages through local leaf switches and shared spine switches. It supports communication between different GPU positions through the network.

Separate rails

A rail layout groups matching GPU positions across servers. It can use fewer switches for that pattern; a message to a different position may need an extra hop inside a server.

FIGURE 1

A 16-GPU illustration: four servers, with four GPUs in each.

Network layout

Traffic or failure scenario

Selected path Route with internal hop Unavailable path

The diagram shows routes and failure scope, not measured bandwidth. It stays at 16 GPUs so the connections remain readable.

WORKED EXAMPLE

Sizing a 512-GPU network

Estimated switches

—

Estimated optical links

—

Estimated optics budget

—

Cross-group messages

—

One switch can affect

—

These are planning counts for the inputs below, separate from the 16-GPU figure. An optical-link allowance covers a complete link; it is not a price per cable or transceiver. The model does not verify vendor port maps.

Change the planning inputs

Design assumptions & what to measure
Decision supported
Which fabric assumptions belong in the quote and design review?
Primary output
Planning BOM, traffic tradeoff, and failure domain
Model boundary
Illustrative two-tier designs; vendor port allocation may differ

Counts are planning estimates under the displayed endpoint, radix, rail, oversubscription, and fabric-plane assumptions—not a vendor design or cabling schedule.

Topology diligence

Training traffic has a shape, and rails can be wired to it. In the illustrated mapping, collective channels keep corresponding GPU ranks on dedicated rails and use the high-bandwidth NVLink domain for intra-node movement. Actual NCCL algorithms and channel mappings are topology-, message-, and workload-dependent; NCCL can select rings, trees, NVLS, and other algorithms.

The cost gap is countable only after the design assumptions are explicit. The calculator uses a simple two-tier Clos planning rule for fat-tree and groups servers under each rail switch. When a rail needs more than one switch group, connections between those groups are not counted. It is intended to expose quote assumptions, not replace the supplier's port map.

Rails trade generality for an expected traffic pattern. Cross-rank traffic such as mixture-of-experts all-to-all routing, embedding lookups, parameter-server flows, storage, and data loading may need an intra-node hop before crossing the appropriate rail. That path can consume NVLink capacity shared with collective traffic. Measure all-to-all as well as all-reduce when the cluster will serve mixture-of-experts or other communication-heavy inference workloads.

Ask the supplierIf it's rails: is the scheduler rail-aware, what's the NCCL configuration, and what are your measured numbers for all-to-all — not just all-reduce — at my job size?

Failure modes are shaped by the wiring and its redundancy. In the single-plane toy case, a fat-tree leaf failure removes its attached endpoints while a rail-switch failure removes one rail across many nodes. Whether jobs stall or reroute depends on redundant planes, routing, scheduler placement, and collective configuration. Both examples are mapped onto one physical row on the pod page — see the failure stripe on the pod page →

Ask the supplierFull fat-tree or rail-optimized — show me the topology diagram. And when one switch fails, what exactly keeps running: which nodes, which rails, which of my jobs?

The toy cluster shows one channel and one cross-rank pair so the wiring stays readable. Use the controls for a planning estimate, then ask the supplier for the actual logical topology, physical port map, redundancy behavior, and measured collective results.

model · two-tier planning estimate · NCCL algorithm selection · methods & limitations · model version 2026.08