Collectives and cluster topology
Ring and tree all-reduce one step at a time, the α–β time model with the ring/tree crossover and SHARP, the scale-up vs scale-out bandwidth cliff, how an NVL72 rack's 72 GPUs and 18 NVSwitch chips are wired, fat-tree and rail-optimised switch counts, and on-chip ring, mesh and torus hop counts and bisection.
Added
How to use it
How to use it
⛶ Full screen (or F) gives the tool the whole screen — the browser’s full screen where it is
allowed, otherwise a full-window layer (iPhone). The ring or tree in the step view and the NVL72
wiring diagram grow to fill it and follow the window; on a wide screen the NVL72 figures sit in a
column beside the wiring, and ◫ Panels hides them. Escape leaves.
Ring & tree, step by step — pick 2 to 16 GPUs and step through an all-reduce. In the ring, every GPU’s tensor is cut into n chunks (a, b, c, …); the grid shows which GPUs' contributions each chunk already holds (a0+a1+a2), shading darker as it fills and outlined green when it is fully reduced. Reduce-scatter takes n − 1 steps, all-gather another n − 1, and every ring link is busy on every step. Chunk indexing runs either the book’s Python exactly as printed (rank r ends reduce-scatter holding chunk (r + 1) mod n) or the shifted version where rank r owns chunk r. The tree reduces up a binomial tree in ⌈log₂ n⌉ steps and broadcasts back down in as many again, with most links idle.
Time model — the α–β model: each step costs a fixed α (launch, synchronisation, first byte) plus bytes ÷ β (one link’s bandwidth, one way). Ring: 2(n − 1)·α + 2(n − 1)/n · S/β; tree: 2⌈log₂ n⌉ · (α + S/β). The plot shows both against message size with the crossover marked; the tree wins small messages, the ring large ones. Tick SHARP to add in-network reduction: each GPU sends its tensor once and the switch returns the sum, 2α + S/β, about half the ring’s bytes. Bus bandwidth is NCCL’s convention (algorithm bandwidth × 2(n − 1)/n).
Scale-up vs scale-out — a hierarchical all-reduce over several NVLink domains: reduce-scatter inside each rack, an all-reduce of each 1/n shard across racks on its rail, then all-gather inside the rack, against a flat ring that runs at the network’s speed. Below it, the per-GPU bandwidth ladder from HBM to a 400 Gb/s NIC shows the cliff.
NVL72 wiring — the GB200 NVL72 rack drawn to its real counts: 18 compute trays (4 Blackwell GPUs and 2 Grace CPUs each) and 9 switch trays (2 NVSwitch chips each). Click a GPU to see its 18 links, one to every switch chip, or a switch chip to see its 72 ports, one to every GPU.
Fat tree & rails — switch counts for a given number of hosts and switch radix k, two tiers while they fit (k²/2 hosts) and three beyond (k³/4), with oversubscription, bisection, and the optical transceivers the switch-to-switch links need. The rail-optimised view wires GPU r of every node to rail r’s leaf.
On-chip networks — a ring, 2D mesh, 2D torus, crossbar or bus of rows × columns tiles: diameter, average hops, bisection in links and GB/s, and a hop-count map from any tile (click one). The plot shows bisection per tile shrinking as √N/N for a mesh as the chip grows.
Limits
-
The step view draws up to 16 GPUs; the time model takes any n.
-
The time model is the textbook α–β model: no congestion, no pipelining of the tree (NCCL’s double binary tree pipelines, bringing its bandwidth term near the ring’s), a single α per step.
-
The tree shown is binomial; the book describes a binary tree. Both take 2⌈log₂ n⌉ steps.
-
Hierarchical all-reduce assumes one NIC per GPU (rail-aligned) and equal domains.
-
NVL72 numbers are for the GB200/GB300 generation (NVLink 5); Rubin’s NVLink 6 doubles the per-link rate.
-
Fat-tree counts use the k-ary construction with ceiling rounding for partly filled tiers; real designs also round to whole pods and leave spare ports.
-
On-chip hop maps are drawn up to 400 tiles; the figures are exact up to 4 million.
Related: links, optics and energy per bit (bandwidth and pJ/bit for every link named here), AI hardware calculator, graph algorithms (BFS hop counts), latency numbers.
Companion to Network topologies for multi-GPU clusters, the switch silicon, rail-optimized fat-tree topology, ring vs. tree all-reduce, the collective fabric and on-chip networks of _AI Acceleration: From Transistors to Trillion-Parameter Models.
Sources
-
NVIDIA, GB200 NVL72 and NVLink and NVLink Switch (18 links × 100 GB/s per Blackwell GPU, 72-port NVSwitch); NVL72 reference architecture (18 compute trays, 9 switch trays). As of October 2026.
-
Patarasuk & Yuan, Bandwidth optimal all-reduce algorithms for clusters of workstations (2009) — the ring’s 2(n − 1)/n.
-
Thakur, Rabenseifner & Gropp, Optimization of collective communication operations in MPICH (2005) — the α–β cost model.
-
Graham et al., "Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction", COMHPC 2016.
-
Al-Fares, Loukissas & Vahdat, "A scalable, commodity data center network architecture", SIGCOMM 2008 — k-ary fat trees.
-
Dally & Towles, Principles and Practices of Interconnection Networks (2004) — ring, mesh and torus figures.
Linking to an example
Every setting can be written into a link by hand. Put the tab after : ring, time, cliff,
nvl72, fattree or noc; with example= and no , the example’s own tab opens. Sizes take
SI units (25MB = 25 × 106 bytes, 1GiB = 230); 1e9 works too — in a URL write ` as `%2B`
(`1e%2B9`), although a ` typed into the address bar (read back as a space) is understood.
| Parameter | Meaning | Example |
|---|---|---|
|
one of the presets below; parameters written beside it override it |
|
|
GPUs (step view 2–16; time model any) |
|
|
step view: |
|
|
step view: frame to show, 0 = start |
|
|
ring chunk indexing: |
|
|
message size (time model, scale-up vs scale-out) |
|
|
time model: α in µs, β in GB/s one way |
|
|
time model: |
|
|
GPUs per scale-up domain, number of domains |
|
|
scale-up and scale-out GB/s per GPU, one way |
|
|
α in µs inside and between domains |
|
|
NVL72: highlight GPU |
|
|
fat tree: switch radix, hosts, oversubscription (down:up) |
|
|
GPUs per node (rails); watts per optical transceiver |
|
|
on-chip: |
|
|
on-chip: rows, columns, source tile (row-major), GB/s per link |
|
Presets:
example= |
Shows |
|---|---|
|
Figure 17a: ring all-reduce on 4 GPUs from the start (open) |
|
The book’s Python reduce-scatter after its 3 steps: rank r holds chunk (r + 1) mod n (open) |
|
Ring all-reduce on 8 GPUs: 14 steps (open) |
|
Tree all-reduce on 8 GPUs: 6 steps, most links idle (open) |
|
14 ring steps against 6 tree steps, and the crossover size (open) |
|
2(n − 1)/n = 1.75 × the tensor per GPU at n = 8 (open) |
|
SHARP: the tensor sent once, about double the throughput (open) |
|
900 GB/s inside the rack against 100 GB/s between racks (open) |
|
The NVL72 rack, one GPU’s 18 links highlighted (open) |
|
One NVSwitch chip’s 72 ports: 3.6 TB/s each way, 7.2 TB/s total (open) |
|
2,048 hosts on 96 64-port switches (open) |
|
65,536 hosts on 5,120 switches (open) |
|
3:1 oversubscription: 54 switches instead of 96 (open) |
|
Rail-optimised wiring, 32 nodes × 8 GPUs (open) |
|
On 64 GPUs the tree wins small messages, the ring large ones (open) |
|
A 25 MB gradient bucket over 1,024 GPUs (open) |
|
140 GB of gradients inside one rack and across 16 (open) |
|
A 64-tile ring: diameter 32, bisection 2 (open) |
|
An 8 × 8 mesh: diameter 14, bisection 8 (open) |
|
An 8 × 8 torus: diameter 8, bisection 16 (open) |
|
Tenstorrent Wormhole’s 10 × 12 grid as a torus (open) |
|
~900,000 elements on a 950 × 950 mesh (open) |
Feedback is a gift. Something to improve, a feature to add, or a bug? Tell me.
Runs entirely in your browser; nothing you type leaves this page.