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.
A 16-GPU illustration: four servers, with four GPUs in each.
Network layout
Traffic or failure scenario
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.
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 →
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