# Spine switching and fabric topology

Canonical: https://semiaifoundry.com/learn/atlas/spine-switch/
Revision: 2026-10-07
Rights: https://semiaifoundry.com/ai-atlas/licenses.html

Data-center fabric · Atlas v1.3.0

# Spine switching and fabric topology

Provides multiple high-capacity paths between leaf switches.

[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#spine-switch)Row-to-data-center network fabric; topology not a floor plan

Learning objectiveUse a network cut to bound traffic between groups of machines.

## The mechanism

The spine layer interconnects leaves so traffic can cross a cluster through a regular set of paths. In a common leaf–spine design, each leaf has links to multiple spines, giving route diversity and scalable connectivity. The topology can be provisioned without oversubscription at a chosen scale, but that property depends on port counts, link rates, and the complete design. It is not guaranteed by drawing two rows of switches. The atlas lets viewers trace two flows that share a link and then compare alternate paths. This makes contention and path diversity visible. Larger fabrics may add stages or planes, and their performance still depends on traffic patterns and software communication behavior.

1.  Connect each leaf to the intended set of spine paths.
2.  Route cross-leaf traffic through available fabric capacity.
3.  Balance flows and preserve communication when supported alternate paths are needed.

## Science and assumptions

### Cut capacity

$$
T_{\mathrm{cross\ cut}}\le\sum_{\ell\in\mathcal C}B_\ell
$$

Throughput across a network cut cannot exceed the sum of usable capacities of links crossing it.

T denotes throughput here, not time.

Symbols and units

T\_cross cut

Traffic throughput crossing the defined cut

bytes/s

B\_ℓ

Usable directional capacity of crossing link ℓ

bytes/s

𝒞

Set of links crossing the selected cut

set of links

ℓ

Crossing-link index

index

Any communication between two groups of endpoints must pass through links that separate them. Their combined capacity limits the rate across that partition, regardless of how many GPUs exist behind each side.

Assumptions Network-flow upper-bound intuition; routing, shared traffic, protocol overhead, and failures can reduce attainable throughput.

## Engineering example

Synthetic cut between two groups contains four usable 100 GB/s links, for 400 GB/s aggregate directional capacity. Moving 800 GB across that cut takes at least 2 s if the whole capacity is available. Losing one link lowers the ceiling to 300 GB/s and raises the bound to about 2.67 s.

## Distinctions and tradeoffs

A leaf–spine drawing does not prove a fabric is nonblocking; port capacity and oversubscription must be checked.

Extra paths improve capacity and resilience. More ports, optics, and stages add cost and complexity.

Large model jobs synchronize many workers. Fabric capacity influences how much time they spend communicating instead of computing.

## Specifications and interfaces

Topology role

Connects leaf switches

Spines normally form the transit layer in this teaching topology.

Path diversity

Multiple spine choices

Routing and congestion policies determine path use.

Nonblocking claim

Configuration-dependent

Requires sufficient capacity across the complete fabric.

### Interfaces

Leaf uplinks Input

Packets crossing between endpoint groups

Destination leaf Output

Transit traffic over selected paths

## Check your understanding

### What is necessary to assess a nonblocking claim?

1.  The number of LEDs on a switch
2.  The actual port counts, rates, and interconnection design
3.  Only the presence of the word spine

Answer and reasoning

The actual port counts, rates, and interconnection design

The capacity of the complete topology determines whether it can carry the assumed traffic without structural oversubscription.

## Evidence and scope

The cut-capacity argument is a bound on the specified topology and traffic direction. Synthetic values assume usable independent links; other traffic, routing and protocol overhead can reduce attainable throughput.

Use the execution investigation for the shared tensor-to-memory-to-result thread; no current standalone calculator models this lesson’s full mechanism.

## Sources

-   [NVIDIA — HGX AI Factory Spine-Leaf Architecture](https://docs.nvidia.com/enterprise-reference-architectures/hgx-ai-factory-h100-h200-b200/latest/network-logical-architecture.html)

[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/spine-switch-0357d7f8641e771e.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)

## Continue exploring

### Foundations

-   [Leaf switch and endpoint network](https://semiaifoundry.com/learn/atlas/leaf-switch/)

### Related lessons

-   [Optical transceiver and fiber link](https://semiaifoundry.com/learn/atlas/optics/)
-   [Data, tensor, pipeline, and state parallelism](https://semiaifoundry.com/learn/atlas/parallelism/)
-   [Collective communication library](https://semiaifoundry.com/learn/atlas/nccl/)