{
  "schemaVersion": 1,
  "id": "atlas-lesson-spine-switch",
  "title": "Spine switching and fabric topology",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Provides multiple high-capacity paths between leaf switches.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/spine-switch/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Data-center fabric",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "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.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/spine-switch-0357d7f8641e771e.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#spine-switch",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "34a5d9b130374044a663ba7797f2205e2bdd8ad095b783b3f1bfd1a43b342d1c",
  "contentLength": 4921,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-spine-switch.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-spine-switch.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Spine switching and fabric topology",
      "start": 35,
      "end": 348
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 348,
      "end": 1283
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1283,
      "end": 1311
    },
    {
      "id": "section-4",
      "title": "Cut capacity",
      "start": 1311,
      "end": 2118
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2118,
      "end": 2428
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 2428,
      "end": 2807
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 2807,
      "end": 3142
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 3142,
      "end": 3282
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 3282,
      "end": 3311
    },
    {
      "id": "section-10",
      "title": "What is necessary to assess a nonblocking claim?",
      "start": 3311,
      "end": 3712
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 3712,
      "end": 4104
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 4104,
      "end": 4493
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 4493,
      "end": 4516
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 4516,
      "end": 4625
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 4625,
      "end": 4921
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#spine-switch"
    },
    {
      "title": "NVIDIA — HGX AI Factory Spine-Leaf Architecture",
      "url": "https://docs.nvidia.com/enterprise-reference-architectures/hgx-ai-factory-h100-h200-b200/latest/network-logical-architecture.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/spine-switch-0357d7f8641e771e.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Leaf switch and endpoint network",
      "url": "https://semiaifoundry.com/learn/atlas/leaf-switch/"
    },
    {
      "title": "Optical transceiver and fiber link",
      "url": "https://semiaifoundry.com/learn/atlas/optics/"
    },
    {
      "title": "Data, tensor, pipeline, and state parallelism",
      "url": "https://semiaifoundry.com/learn/atlas/parallelism/"
    },
    {
      "title": "Collective communication library",
      "url": "https://semiaifoundry.com/learn/atlas/nccl/"
    }
  ],
  "recordHash": "135eeb131bb98b3a4120ecc1046dd5a214f95f7693d39a73389c00a2078dc8ee",
  "contentFormat": "text/markdown",
  "content": "Data-center fabric · Atlas v1.3.0\n\n# Spine switching and fabric topology\n\nProvides multiple high-capacity paths between leaf switches.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#spine-switch)Row-to-data-center network fabric; topology not a floor plan\n\nLearning objectiveUse a network cut to bound traffic between groups of machines.\n\n## The mechanism\n\nThe 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.\n\n1.  Connect each leaf to the intended set of spine paths.\n2.  Route cross-leaf traffic through available fabric capacity.\n3.  Balance flows and preserve communication when supported alternate paths are needed.\n\n## Science and assumptions\n\n### Cut capacity\n\n$$\nT_{\\mathrm{cross\\ cut}}\\le\\sum_{\\ell\\in\\mathcal C}B_\\ell\n$$\n\nThroughput across a network cut cannot exceed the sum of usable capacities of links crossing it.\n\nT denotes throughput here, not time.\n\nSymbols and units\n\nT\\_cross cut\n\nTraffic throughput crossing the defined cut\n\nbytes/s\n\nB\\_ℓ\n\nUsable directional capacity of crossing link ℓ\n\nbytes/s\n\n𝒞\n\nSet of links crossing the selected cut\n\nset of links\n\nℓ\n\nCrossing-link index\n\nindex\n\nAny 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.\n\nAssumptions Network-flow upper-bound intuition; routing, shared traffic, protocol overhead, and failures can reduce attainable throughput.\n\n## Engineering example\n\nSynthetic 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.\n\n## Distinctions and tradeoffs\n\nA leaf–spine drawing does not prove a fabric is nonblocking; port capacity and oversubscription must be checked.\n\nExtra paths improve capacity and resilience. More ports, optics, and stages add cost and complexity.\n\nLarge model jobs synchronize many workers. Fabric capacity influences how much time they spend communicating instead of computing.\n\n## Specifications and interfaces\n\nTopology role\n\nConnects leaf switches\n\nSpines normally form the transit layer in this teaching topology.\n\nPath diversity\n\nMultiple spine choices\n\nRouting and congestion policies determine path use.\n\nNonblocking claim\n\nConfiguration-dependent\n\nRequires sufficient capacity across the complete fabric.\n\n### Interfaces\n\nLeaf uplinks Input\n\nPackets crossing between endpoint groups\n\nDestination leaf Output\n\nTransit traffic over selected paths\n\n## Check your understanding\n\n### What is necessary to assess a nonblocking claim?\n\n1.  The number of LEDs on a switch\n2.  The actual port counts, rates, and interconnection design\n3.  Only the presence of the word spine\n\nAnswer and reasoning\n\nThe actual port counts, rates, and interconnection design\n\nThe capacity of the complete topology determines whether it can carry the assumed traffic without structural oversubscription.\n\n## Evidence and scope\n\nThe 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.\n\nUse the execution investigation for the shared tensor-to-memory-to-result thread; no current standalone calculator models this lesson’s full mechanism.\n\n## Sources\n\n-   [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)\n\n[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)\n\n## Continue exploring\n\n### Foundations\n\n-   [Leaf switch and endpoint network](https://semiaifoundry.com/learn/atlas/leaf-switch/)\n\n### Related lessons\n\n-   [Optical transceiver and fiber link](https://semiaifoundry.com/learn/atlas/optics/)\n-   [Data, tensor, pipeline, and state parallelism](https://semiaifoundry.com/learn/atlas/parallelism/)\n-   [Collective communication library](https://semiaifoundry.com/learn/atlas/nccl/)"
}