Grace Blackwell heeft een nieuwe scheduler nodig: 27% meer bruikbare GPU's uit dezelfde racks

Door Rohan Sonecha (Member of Technical Staff), 29 oktober 2026

Niet alle high-speed interconnects zijn gelijk, en het gebruik van de verkeerde kan kostbaar zijn: het uitvoeren van dezelfde gedistribueerde trainingsjob over InfiniBand in plaats van NVLink kan de prestaties met 43% verslechteren.

Historisch gezien was NVLink beperkt tot communicatie binnen een enkele node, wat betekende dat multi-node AI-workloads gedwongen waren om te communiceren via InfiniBand of een cloud-equivalent (zoals EFA op AWS of GPUDirect-TCPX op GCP). De NVL72-systemen van NVIDIA nemen deze beperking weg door alle 72 GPU's in een rack te verbinden met een uniforme NVLink-fabric. Hierdoor kunnen GPU's op verschillende nodes gegevens uitwisselen met een bandbreedte die een orde van grootte hoger ligt.

Het maximaliseren van de voordelen van NVL72-systemen is echter sterk afhankelijk van de plaatsing van de workload: een multi-node job die over meerdere racks is verspreid, wordt nog steeds beperkt door InfiniBand. Het behouden van rack-lokaliteit wordt moeilijker wanneer hardwarefouten nodes offline halen en wanneer jobs op verschillende tijdstippen eindigen, waardoor vrije capaciteit verspreid raakt over de racks.

Dit artikel behandelt de communicatiebottleneck bij grootschalige training en inferentie, de NVL72 rack-scale fabric, de optimalisatie van slice-groottes voor veerkracht tegen GPU-fouten, en hoe het SkyPilot-platform multi-node jobs rack-lokaal houdt via topologiebewuste plaatsing, in-place herstel van hardwarefouten en automatische defragmentatie van gedeelde clusters.

Training op grote schaal is een communicatieprobleem

Frontier-trainingsjobs draaien over duizenden GPU's. Om dit te realiseren moeten twee vragen worden beantwoord:

1. Hoe verdeel je (shard) je model over GPU's om ervoor te zorgen dat het daadwerkelijk kan draaien?
2. Gegeven je compute-budget, hoeveel kopieën van het gescharde model kun je draaien om de trainingsdoorvoer te maximaliseren?

De eerste vraag wordt doorgaans beantwoord met een combinatie van:

• Tensor Parallelism (TP): het splitsen van de gewichtsmatrices van een laag over GPU's.
• Expert Parallelism (EP): het plaatsen van de experts van een mixture-of-experts (MoE) laag op verschillende GPU's.
• Pipeline Parallelism (PP): het laag-gewijs splitsen van een model over GPU's.

Het antwoord op de tweede vraag bepaalt de graad van Data Parallelism (DP): het aantal kopieën van het gescharde model dat parallel traint, waarbij elke kopie een ander deel van de trainingsdata gebruikt.

Van deze parallellismestrategieën liggen de all-reduce patronen van tensorparallelisme en de all-to-all communicatie van expertparallelisme op het kritieke pad tijdens de training. Het is daarom essentieel om deze op NVLink te houden.

Tensorparallelisme

Tensorparallelisme splitst de gewichtsmatrices binnen elke laag over GPU's, zodat elke GPU slechts een deel van elke laag opslaat en berekent.

Transformer-lagen bestaan uit twee blokken: self-attention en een multi-layer perceptron (MLP). In essentie bestaat elk blok uit twee matrixvermenigvuldigingen (GEMMs) na elkaar. Megatron-LM heeft aangetoond dat door de eerste GEMM van een blok kolomgewijs en de tweede GEMM rijgewijs te partitioneren, GPU's slechts één keer per blok via all-reduce hoeven te synchroniseren (na de tweede GEMM), in plaats van na elke bewerking.

(Referentie: Figuur 1 illustreert tensorparallelisme over twee GPU's. A is kolomgewijs gesplitst, zodat elke GPU zijn eigen deel van y berekent zonder communicatie. B is rijgewijs gesplitst, zodat elke GPU een partieel resultaat z produceert, waarna één all-reduce de resultaten optelt.)

Zelfs met deze optimalisatie vereist tensorparallelisme nog steeds twee all-reduces per transformer-laag tijdens de forward pass. Deze stappen liggen op het kritieke pad omdat ze niet volledig kunnen worden overlapt met berekeningen. Daarom wordt tensorparallelisme doorgaans op NVLink gehouden; Hugging Face maten een daling van 43% in trainingsdoorvoer toen dit werd verplaatst van NVLink naar InfiniBand.

Expertparallelisme

In een mixture-of-experts (MoE) laag wordt het MLP-blok vervangen door vele kleinere MLP's, genaamd experts, en een router die elk token naar een klein subset van experts stuurt. Expertparallelisme splitst MoE-lagen zodanig dat deze kleine, onafhankelijke experts op verschillende GPU's worden geplaatst.

Bij expertparallelisme vereist elke MoE-laag twee all-to-all communicatiestappen tijdens de forward pass: dispatch en combine. Een router selecteert de top-k experts voor elk token en stuurt de tokens naar de GPU's die die experts in het geheugen hebben. Elke GPU berekent vervolgens de lokale experts voor de ontvangen tokens via een enkele grouped matrix multiplication. Ten slotte worden de expert-outputs teruggestuurd naar de oorspronkelijke GPU van het token en gecombineerd.

(Referentie: Figuur 2 toont hoe expertparallelisme experts over GPU's verdeelt. De all-to-all communicatie stuurt tokens naar hun toegewezen experts en combineert de resultaten.)

Naarmate modellen meer MoE-lagen toevoegen en elk token naar meer experts routeren, groeit het volume van het all-to-all verkeer, wat een communicatiebottleneck veroorzaakt.

Het trainen van een MoE-model met 64-way expertparallelisme verspreidt de experts van elke MoE-laag over 64 GPU's. Op standaard 8-GPU servers verplaatst dit het all-to-all verkeer van de high-bandwidth NVLink naar veel smallere InfiniBand-interconnects, waar ongeoptimaliseerde communicatie tot 60% van de trainingstijd in beslag kan nemen. Op NVL72-systemen blijven alle 64 GPU's binnen één NVLink-domein, waardoor de communicatiebottleneck effectief wordt geëlimineerd.

Ook inferentie heeft snel inter-node netwerken nodig

De bovengenoemde parallellisme-technieken zijn niet uniek voor training. Naast het mogelijk maken van inferentie-engines voor modellen die te groot zijn voor één GPU, kan modelparallelisme ook de doorvoer (throughput) verbeteren. Door de gewichten van een model over meer GPU's te splitsen, komt er geheugen vrij voor de KV-cache, waardoor de engine meer gelijktijdige verzoeken kan verwerken of grotere context-windows kan ondersteunen.

In sommige gevallen groeit het vrijgekomen geheugen sneller dan het aantal GPU's: in een vLLM-benchmark zorgde het tensor-parallel splitsen van een model over twee GPU's voor een toename van 13,9x in het aantal KV-cache blokken en 3,9x meer doorvoer.

(Referentie: Figuur 3 toont de GPU-geheugenverdeling voor Llama-3.1-70B op één versus twee H100's.)

Expertparallelisme volgt dezelfde logica. Bij een lage graad van expertparallelisme houdt elke GPU veel experts vast, waardoor er minder ruimte overblijft voor de KV-cache. WideEP (expert-parallel configuraties over meerdere nodes) vermindert het aantal experts per GPU aanzienlijk. De trade-off is het netwerkverkeer: elke all-to-all beslaat nu meer GPU's. Op standaard 8-GPU servers kan een expert-parallel groep maximaal acht GPU's beslaan voordat communicatie via InfiniBand moet plaatsvinden, waar de bandbreedte per GPU met factor 18 daalt. NVL72 heft deze limiet op door alle 72 GPU's in een rack op NVLink te houden. Bij het serveren van DeepSeek-R1 op interactieve snelheden levert GB200 NVL72 met 32-way expertparallelisme tot 4,4x hogere doorvoer per GPU dan 8-GPU B200 servers, die beperkt zijn tot 8-way.

Het rack is de nieuwe server

NVL72 breidt NVLink uit van een enkele node naar het gehele rack, waardoor het volledige rack functioneert als één gigantische accelerator met gedeeld geheugen.

(Referentie: Figuur 4 toont de NVLink-hiërarchie binnen een NVL72-rack.)

Elke GPU in het NVL72-rack heeft 18 NVLink-poorten die elk een bidirectionele bandbreedte van 100 GB/s leveren, wat neerkomt op een totaal van 1,8 TB/s per GPU. Elke NVLink-poort op een GPU is gekoppeld aan een van de 18 NVSwitch-chips die de fabric-backplane van het rack aansturen. Omdat elke NVSwitch-chip 72 NVLink-lijnen accepteert (één van elke GPU), is de geaggregeerde interne bandbreedte binnen het rack 130 TB/s.

(Referentie: Figuur 5 illustreert dat elke GPU één NVLink-poort verbindt met elk van de 18 NVSwitch-chips van het rack.)

Deze netwerktopologie zorgt ervoor dat de fabric volledig non-blocking is. Dit betekent dat elke GPU in het rack gegevens naar elke andere GPU kan verzenden met een uniforme latentie, wat ideaal is voor grootschalige gedistribueerde AI-workloads.

(Referentie: Figuur 6 bevestigt dat de NVSwitch-fabric non-blocking is; elke GPU kan communiceren met elke andere GPU in het rack met volledige bandbreedte en dezelfde latentie.)

Soms is minder meer: minder nodes per rack verbetert de betrouwbaarheid

Bij NVL72-systemen is het verleidelijk om volledige racks van 18 nodes toe te wijzen aan workloads om de clusterbenutting te maximaliseren. In de praktijk halen teams echter meer bruikbare capaciteit uit hun cluster door een paar reserve-nodes per rack vrij te houden.

GPU's zijn onbetrouwbaar. Op zijn gigawatt-schaal supercluster mat Meta een mean time between interruptions (MTBI) van ongeveer 490 dagen per 4-GPU node, na aanzienlijke inspanningen om de betrouwbaarheid te verbeteren. NVL72-clusters maken het 72-GPU rack de atomaire eenheid van compute, wat de fault blast radius met factor 18 vergroot vergeleken met de 4-GPU nodes waaruit het rack bestaat. De MTBI voor het rack wordt berekend als:

MTBI(rack) = MTBI(node) / (aantal nodes in rack)

Op basis van deze formule zou een rack ongeveer elke $490 / 18 \approx 27$ dagen onderbroken worden. Als jobs volledige racks van 18 nodes krijgen toegewezen, maakt elke onderbreking het hele rack onbruikbaar tot de defecte node is gerepareerd. In een cluster van 128 racks betekent dit dat er ongeveer elke 5 uur een rack onbruikbaar wordt voor full-rack jobs.

Door twee nodes per rack als reserve te reserveren, verandert dit. Wanneer een node uitvalt, vervangt een reserve-node in hetzelfde rack deze, zodat een enkele node-fout niet het hele rack uitschakelt. De kosten hiervan zijn dat twee nodes per rack ongebruikt blijven wanneer alles correct functioneert.

NVIDIA heeft gemodelleerd hoe verschillende slice-groottes de bruikbare capaciteit beïnvloeden op een cluster van 128 racks (2.304 nodes) naarmate het aandeel onbeschikbare nodes groeit.

(Referentie: Figuur 7 toont de bruikbare capaciteit van een 128-rack cluster voor verschillende slice-groottes bij toenemende node-onbeschikbaarheid.)

Bij SkyPilot beheren we tienduizenden GPU's voor onze klanten. Op productie-NVL72-clusters hebben we onbeschikbaarheidspercentages van rond de 2% gemeten. Bij dat percentage laat het model van NVIDIA zien dat 16-node slices 27% meer bruikbare capaciteit bieden dan 18-node slices (2.037 vs. 1.602 nodes). Ze presteren ook 4% beter dan 9-node slices, ondanks dat twee 9-node slices precies één rack vullen: bij 9-node slices kost elke fout de helft van een rack, terwijl bij 16-node slices de eerste twee fouten in een rack volledig worden geabsorbeerd. Vergeleken met 8-node slices bieden 16-node slices elke job twee keer zoveel GPU's per NVLink-domein, terwijl ze minder dan 1% van de bruikbare capaciteit inleveren tot de onbeschikbaarheid ongeveer 3,3% overschrijdt.

Zestien nodes is bovendien een natuurlijke grootte voor gedistribueerde AI-workloads: 64 GPU's is een macht van twee, wat overeenkomt met hoe parallellismegroepen gewoonlijk worden gedimensioneerd.

Hoe een moderne scheduler jobs op NVLink houdt

SkyPilot past deze inzichten toe door elke slice op een enkel rack te plaatsen, in-place te herstellen van hardwarefouten en volledige racks vrij te houden naarmate jobs komen en gaan.

Schedulers moeten de hardware begrijpen

Het kiezen van de juiste slice-grootte is slechts de eerste stap. Hoe zorgen onderzoekers ervoor dat elke slice van een multi-node trainingsrun daadwerkelijk op één rack landt?

Naïve schedulers splitsen multi-node jobs over verschillende racks, waardoor workers gedwongen worden om te communiceren via InfiniBand (400 Gb/s per richting) in plaats van NVLink (1,8 TB/s bidirectioneel).

(Referentie: Figuur 8 toont een naïve plaatsing die een multi-node job over racks splitst.)

De Topology-Aware Scheduler (TAS) van SkyPilot zorgt ervoor dat workers op hetzelfde rack worden geplaatst.

(Referentie: Figuur 9 toont hoe de Topology-Aware Scheduler de workers van een job op één rack houdt.)

Voor multi-rack workloads splitst TAS de job in slices van 16 nodes (configureerbaar) en plaatst deze elk op hun eigen rack met twee reservenodes. Wanneer de GPU Manager van SkyPilot vervolgens GPU-fouten detecteert, kan de SkyPilot Frontier Trainer de defecte node "hot swappen" met een van de gereserveerde gezonde nodes, terwijl de overige nodes zonder onderbreking doorgaan. Als er geen reserves meer over zijn in hetzelfde rack, zal Frontier Trainer de slice van het defecte rack verplaatsen naar een gezond rack.

(Referentie: Figuur 10 illustreert slice-based scheduling met twee reserve-nodes per rack en het proces van hot-swapping bij defecten.)

Om de impact van slice-based scheduling te kwantificeren, vergeleek het GR00T-team van NVIDIA twee verschillende scheduling-policies tijdens de pre-training van GR00T N1.7 (een multimodaal foundation model voor humanoïde robots) op 512 GB300 GPU's over 128 nodes. De eerste run gebruikte een naïve scheduler; de tweede run gebruikte een rack-bewuste, slice-based policy. Rack-bewuste plaatsing verhoogde de doorvoer met 14,4%, waarbij elke iteratie werd teruggebracht van 1,59 s naar 1,39 s.

Op een cluster van 10.000 GPU's bespaart dezelfde versnelling ongeveer $16.700 per trainingsuur. Dat is ongeveer $400.000 besparing per trainingsdag, enkel door betere scheduling-beslissingen.

Fragmentatie blokkeert rack-scale jobs

In de praktijk worden grote clusters gedeeld door heterogene workloads (zoals pre-training, RL rollouts en batch-inferentie). TAS plaatst workloads efficiënt binnen hetzelfde rack, maar omdat jobs op verschillende tijdstippen eindigen, raken vrije nodes verspreid over de racks. Dit is fragmentatie: het cluster heeft genoeg vrije GPU's om een rack-scale job te draaien, maar omdat ze verspreid zijn, kan de job niet worden gepland.

(Referentie: Figuur 11 toont hoe vrije nodes over racks verspreid raken, waardoor een 16-node "hero-run" moet wachten ondanks voldoende totale capaciteit.)

De Automatic Defragmentation (Auto Defrag) van SkyPilot is ontwikkeld om dit op te lossen. Wanneer een job wordt geblokkeerd door topologie in plaats van capaciteit, zoekt Auto Defrag de minst disruptieve set workloads om te preemten (onderbreken) om een volledig rack vrij te maken. Deze workloads worden vervolgens op andere racks herplaatst, waardoor de geblokkeerde job kan starten.

(Referentie: Figuur 12 toont hoe Auto Defrag een workload preempteert en herplaatst om een volledig rack vrij te maken voor een 16-node slice.)

Auto Defrag preempteert alleen workloads die veilig herstart kunnen worden, zoals managed jobs die kunnen hervatten vanaf een checkpoint. Interactieve ontwikkelomgevingen worden ongemoeid gelaten, tenzij een beheerder dit expliciet activeert.

Conclusie

Grootschalige AI-workloads zijn standaard gedistribueerd, en hun meest netwerkintensieve communicatiepatronen liggen op het kritieke pad. Rack-scale systemen zoals NVL72 proberen deze bottleneck in hardware op te lossen, maar hardware alleen garandeert geen snelheidswinst. Deze systemen vereisen rack-bewuste plaatsing, veerkracht tegen hardwarefouten en dynamische herbalancering.

Het SkyPilot-platform is specifiek gebouwd om dit gat te dichten: Topology-Aware Scheduling houdt multi-node jobs op NVLink, Frontier Trainer wisselt een defecte node in voor een gezonde reserve wanneer de GPU Manager fouten detecteert, en Automatic Defragmentation houdt gedeelde racks open voor grote jobs.