{
  "schemaVersion": 1,
  "id": "atlas-lesson-scaleup-scaleout-boundaries",
  "title": "Scale-up, scale-out and management fabrics",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Assigns each traffic class to its actual interconnect and resource boundary.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/scaleup-scaleout-boundaries/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Chip-to-hall integration",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "The example is synthetic. Protocol choice and placement depend on the actual system; no universal NVLink-versus-Ethernet performance ordering is implied.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/scaleup-scaleout-boundaries-bdd85897c5539126.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#scaleup-scaleout-boundaries",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "ecdf2e4c3532ccbeedf14fe8e9a587e7a0e77267be50260e64c880441f464564",
  "contentLength": 4986,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-scaleup-scaleout-boundaries.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-scaleup-scaleout-boundaries.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Scale-up, scale-out and management fabrics",
      "start": 41,
      "end": 399
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 399,
      "end": 1584
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1584,
      "end": 1612
    },
    {
      "id": "section-4",
      "title": "Topology cut bound",
      "start": 1612,
      "end": 2175
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2175,
      "end": 2348
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 2348,
      "end": 2807
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 2807,
      "end": 3070
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 3070,
      "end": 3253
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 3253,
      "end": 3282
    },
    {
      "id": "section-10",
      "title": "What best predicts the limit for traffic moving between two rack groups?",
      "start": 3282,
      "end": 3677
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 3677,
      "end": 4008
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 4008,
      "end": 4455
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 4455,
      "end": 4478
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 4478,
      "end": 4686
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 4686,
      "end": 4986
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#scaleup-scaleout-boundaries"
    },
    {
      "title": "NVIDIA DGX GB Rack Scale Systems: Networking",
      "url": "https://docs.nvidia.com/dgx/dgxgb200-user-guide/networking.html"
    },
    {
      "title": "NVIDIA DGX GB Rack Scale Systems: Hardware",
      "url": "https://docs.nvidia.com/dgx/dgxgb200-user-guide/hardware.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/scaleup-scaleout-boundaries-bdd85897c5539126.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": "NVLink switch tray and scale-up fabric",
      "url": "https://semiaifoundry.com/learn/atlas/nvlink-switch/"
    },
    {
      "title": "NVLink GPU interface",
      "url": "https://semiaifoundry.com/learn/atlas/nvlink-port/"
    },
    {
      "title": "Spine switching and fabric topology",
      "url": "https://semiaifoundry.com/learn/atlas/spine-switch/"
    },
    {
      "title": "Collective traffic and congestion",
      "url": "https://semiaifoundry.com/learn/atlas/fabric-collective-traffic/"
    }
  ],
  "recordHash": "e608287a0ac883a5520f2a9cf0fa373034a43484c7be5afb9905c6df51ea808c",
  "contentFormat": "text/markdown",
  "content": "Chip-to-hall integration · Atlas v1.3.0\n\n# Scale-up, scale-out and management fabrics\n\nAssigns each traffic class to its actual interconnect and resource boundary.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#scaleup-scaleout-boundaries)Package to rack and cluster; named reference geometry\n\nLearning objectiveDistinguish traffic roles and bandwidth aggregation boundaries in a cluster.\n\n## The mechanism\n\nScale-up links connect tightly coupled accelerators within a selected domain, while scale-out networks join nodes or domains into larger clusters. Storage and management traffic may use separate fabrics even when cables or switches look similar. The distinction describes roles and locality, not a universal distance threshold or protocol monopoly. A collective can cross both domains, encountering different bandwidth, latency and contention. The NVIDIA rack documentation separates acceleration, cluster and management paths in a concrete implementation. A correct visualization follows the selected message across those boundaries and states whether any displayed bandwidth is one-way, bidirectional or an aggregate over many ports.\n\n1.  Identify endpoints and the traffic’s purpose before choosing its route.\n2.  Mark the local acceleration domain and the links that leave it.\n3.  Trace every switch or network boundary required by the communication.\n4.  Keep storage and management dependencies visible even if they are not on the main tensor path.\n5.  Compare useful flow rates and congestion at the relevant cut rather than adding every advertised port rate.\n\n## Science and assumptions\n\n### Topology cut bound\n\n$$\nT\\ge\\frac{Q_{\\mathrm{cut}}}{B_{\\mathrm{cut}}}\n$$\n\nCut-crossing traffic requires at least its byte count divided by usable cut bandwidth.\n\nSymbols and units\n\nT\n\nTime lower bound associated with the topology cut\n\ns\n\nQ\\_cut\n\nBytes crossing the defined cut\n\nbytes\n\nB\\_cut\n\nSustainable aggregate bandwidth actually usable across it\n\nbytes/s\n\nQcut is bytes crossing a defined cut and Bcut sustainable bytes/s across it.\n\nAssumptions A traffic bound before synchronization and queueing; parallel links count only if the routing can use them.\n\n## Engineering example\n\nSynthetic topology: abundant rack-local bandwidth cannot hide a 10 GB transfer across a 100 GB/s inter-rack cut, which alone takes at least 100 ms.\n\n## Distinctions and tradeoffs\n\nScale-up and scale-out are roles in a system topology; neither label alone establishes coherence, latency or unlimited scaling.\n\nTightly connected local domains can accelerate frequent exchanges; spreading a job across domains may add capacity while exposing slower or contended cuts.\n\nModel parallelism depends on where communication occurs, making topology placement as consequential as the number of accelerators allocated.\n\n## Specifications and interfaces\n\nTraffic roles\n\nTensor exchange, storage and management\n\nRoles may share equipment but require separate accounting.\n\nBandwidth boundary\n\nPort, link, cut or fabric aggregate\n\nA sum of ports is not a single flow’s achievable rate.\n\n### Interfaces\n\nAccelerator communication Input\n\nPartial tensors, gradients or routed activations\n\nLocal and remote fabric Output\n\nMessages crossing the required topology boundaries\n\n## Check your understanding\n\n### What best predicts the limit for traffic moving between two rack groups?\n\n1.  The sum of all ports inside both groups\n2.  The count of management controllers\n3.  The useful capacity of the cut those messages cross\n\nAnswer and reasoning\n\nThe useful capacity of the cut those messages cross\n\nEvery required cross-group byte must traverse the connecting cut, regardless of unused local links.\n\n## Evidence and scope\n\nThe example is synthetic. Protocol choice and placement depend on the actual system; no universal NVLink-versus-Ethernet performance ordering is implied.\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 DGX GB Rack Scale Systems: Networking](https://docs.nvidia.com/dgx/dgxgb200-user-guide/networking.html)\n-   [NVIDIA DGX GB Rack Scale Systems: Hardware](https://docs.nvidia.com/dgx/dgxgb200-user-guide/hardware.html)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/scaleup-scaleout-boundaries-bdd85897c5539126.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-   [NVLink switch tray and scale-up fabric](https://semiaifoundry.com/learn/atlas/nvlink-switch/)\n\n### Related lessons\n\n-   [NVLink GPU interface](https://semiaifoundry.com/learn/atlas/nvlink-port/)\n-   [Spine switching and fabric topology](https://semiaifoundry.com/learn/atlas/spine-switch/)\n-   [Collective traffic and congestion](https://semiaifoundry.com/learn/atlas/fabric-collective-traffic/)"
}