{"id":"scaleup-scaleout-boundaries","level":"infrastructure","name":"Scale-up, scale-out and management fabrics","shortName":"Scale-up, scale-out and management fabrics","role":"Assigns each traffic class to its actual interconnect and resource boundary.","description":"Scale-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.","specs":[{"label":"Traffic roles","value":"Tensor exchange, storage and management","context":"Roles may share equipment but require separate accounting."},{"label":"Bandwidth boundary","value":"Port, link, cut or fabric aggregate","context":"A sum of ports is not a single flow’s achievable rate."}],"interfaces":[{"name":"Accelerator communication","direction":"in","signal":"Partial tensors, gradients or routed activations"},{"name":"Local and remote fabric","direction":"out","signal":"Messages crossing the required topology boundaries"}],"tradeoff":"Tightly connected local domains can accelerate frequent exchanges; spreading a job across domains may add capacity while exposing slower or contended cuts.","whyAI":"Model parallelism depends on where communication occurs, making topology placement as consequential as the number of accelerators allocated.","related":["nvlink-port","leaf-switch","spine-switch","fabric-collective-traffic"],"sources":[{"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"}],"scale":"Package to rack and cluster; named reference geometry","kind":"architecture","branch":"Chip-to-hall integration","subbranch":"Rack anatomy and network fabrics","mechanism":["Identify endpoints and the traffic’s purpose before choosing its route.","Mark the local acceleration domain and the links that leave it.","Trace every switch or network boundary required by the communication.","Keep storage and management dependencies visible even if they are not on the main tensor path.","Compare useful flow rates and congestion at the relevant cut rather than adding every advertised port rate."],"misconception":"Scale-up and scale-out are roles in a system topology; neither label alone establishes coherence, latency or unlimited scaling.","check":{"question":"What best predicts the limit for traffic moving between two rack groups?","options":["The sum of all ports inside both groups","The count of management controllers","The useful capacity of the cut those messages cross"],"answer":2,"explanation":"Every required cross-group byte must traverse the connecting cut, regardless of unused local links."},"science":[{"title":"Topology cut bound","equation":"T ≥ Qcut / Bcut","explanation":"Qcut is bytes crossing a defined cut and Bcut sustainable bytes/s across it.","assumptions":"A traffic bound before synchronization and queueing; parallel links count only if the routing can use them."}],"prerequisites":["leaf-switch","nvlink-switch"],"learningObjective":"Distinguish traffic roles and bandwidth aggregation boundaries in a cluster.","workstream":"W09","visualFamily":"rack-system","engineeringExample":"Synthetic 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.","evidenceNotes":"The example is synthetic. Protocol choice and placement depend on the actual system; no universal NVLink-versus-Ethernet performance ordering is implied.","labId":"library","scope":"Use the execution investigation for the shared tensor-to-memory-to-result thread; no current standalone calculator models this lesson’s full mechanism.","investigationId":"execution","labScope":"Use the execution investigation for the shared tensor-to-memory-to-result thread; no current standalone calculator models this lesson’s full mechanism."}