Een knooppunt met acht GPU kan wekenlang probleemloos functioneren en nog steeds te onbetrouwbaar zijn voor training op enorme schaal met duizenden machines tegelijk. De schijnbare tegenspraak ligt in het feit dat, wanneer een synchronisatieproces afhankelijk is van de beschikbaarheid van alle deelnemers, een kleine kans op individuele foutmeldingen zich snel vermenigvuldigt tot het punt waarop onderbrekingen onderdeel worden van de dagelijkse gang van zaken.
Een recent verspreide infographic vat het probleem samen met een opvallend cijfer: een dagelijkse foutkans van 1,5 % per knooppunt zou resulteren in een kans van 84,8 % dat minstens één incident optreedt in een systeem met 1.000 GPU’s. Deze berekening klopt onder bepaalde voorwaarden, maar andere uitspraken in de afbeelding vereisen meer context. De betrouwbaarheid van een cluster kan niet uitsluitend worden afgeleid uit een formule of het percentage dat voor elke server is gepubliceerd.
De kern van GPU-clusterbetrouwbaarheid in 20 seconden
- Distributed training synchroniseert doorgaans duizenden GPU’s bij elke stap.
- Een enkele defecte knooppunt kan alle anderen stilleggen of vertragen.
- Met 1.000 GPU’s verdeeld over 125 knooppunten, leidt een dagelijkse foutkans van 1,5 % per knooppunt tot een kans van 84,9 % dat minstens één incident plaatsvindt.
- De berekening gaat uit van onafhankelijke fouten en knooppunten met acht GPU’s.
- In de praktijk treden ook correlated noise op door netwerk-, stroom-, koelings-, firmware- en softwarefouten.
- Werkelijke betrouwbaarheid wordt gemeten in effectieve trainingsduur, niet alleen in individuele uptime.
- Snel detecteren en isoleren van een knooppunt is meestal waardevoller dan het lange tijd diagnosticeren voordat men actie onderneemt.
- Checkpoints verminderen het werk dat verloren gaat, maar kunnen de opslag belasten.
- Nieuwere systemen maken het mogelijk om een beschadigd exemplaar te verwijderen terwijl de rest doorgaat met trainen.
- Een fout elke 30 minuten in 100.000 GPU’s volgt niet direct uit het voorbeeld van 1,5 %.
Technische literatuur bevestigt dat onderbrekingen minder uitzonderlijk worden naarmate het cluster groter wordt. Bij Llama 3, dat op 16.384 H100 GPU’s trainde, werden 466 onderbrekingen genoteerd in 54 dagen. ByteDance documenteerde meer dan honderd fouten gedurende enkele weken met MegaScale, uitgerust met 12.288 GPU’s. Een studie naar gedistribueerde systemen beschrijft ook incidentele problemen elke één tot twee dagen in configuraties van ongeveer 1.000 accelerators.
Hoe wordt 1,5 % een kans van 84,9 %?
De formule gebruikt in de afbeelding luidt:
P(minstens één fout) = 1 − (1 − p)^N
Hierin staat p voor de dagelijkse foutkans van elk knooppunt, en N voor het aantal knooppunten dat aan de taak deelneemt.
Een systeem met 1.000 GPU’s betekent niet noodzakelijk 1.000 losse eenheden. Als elk server acht GPU’s bevat, bestaat de infrastructuur uit 125 knooppunten. Bij een dagelijkse foutkans van 1,5 % per knooppunt is de kans dat geen van de knooppunten faalt:
0,985^125 ≈ 15,1 %
De kans dat minstens één knooppunt faalt, is dus ongeveer 84,9 %. Dit cijfer in de infographic is correct, mits men uitgaat van een verdeling van acht GPU’s per knooppunt, een constante foutkans en onafhankelijke fouten.
Dit betekent niet dat 84,9 % van de trainingen volledig mislukken. Het houdt in dat, op een willekeurige dag, er een diepte van 84,9 % bestaat dat minstens één van de 125 knooppunten een fout ondervindt, zoals beschreven. De uiteindelijke impact hangt af van de architectuur van de training, de duur van de storing en de mogelijkheden om het knooppunt te vervangen of gecorrigeerd te herstellen.
Ook wat onder een fout wordt verstaan, speelt een rol. Het kan gaan om een GPU die niet meer reageert, een niet-herstelbare ECC-fout, problemen met HBM, een NVLink-verbinding die uitvalt, een degradeerde netwerkinterface, een geblokkeerd proces of een server die preventief wordt afgeschakeld vanwege afwijkende metrics.
Daarom betekent het opnemen van knooppunten in de lijst met defecten niet automatisch dat de hardware stuk is. Een apparaat kan worden uitgeschakeld vanwege een geverifieerde storing, intermitterende degradatie of gedrag dat andere versnellers in een collectieve operatie zou kunnen vertragen.
De studie van een productieknooppunt met 504 Nvidia B200 GPU’s illustreert deze complexiteit. Onderzoekers analyseerden 751 metrics uit Prometheus en identificeerden tien fouten via XID-codes. Ze vonden echter geen enkele metriek die consistent alle soorten fouten domineerde. Ook zagen ze dat drie van de 63 knooppunten meer dan de helft van de uitzonderingen veroorzaakten, wat aangeeft dat problemen niet altijd gelijkmatig verdeeld zijn.
Deze concentratie onderstreept één van de vereenvoudigingen in de originele berekening: de assumptie van onafhankelijkheid. Fouten kunnen zich groeperen door hardware-batches, firmwareversies, temperatuur, netwerk-topologie, configuratie of workload. Elektriciteitsstoringen of koelproblemen kunnen meerdere machines tegelijk treffen, terwijl een klein aantal knooppunten verantwoordelijk kan zijn voor een groot deel van de incidenten.
De foutmarge van 30 minuten vereist een ander model
De infographic stelt dat een systeem met 100.000 GPU’s ongeveer elke 30 minuten een storing zou ondervinden. Het algemene idee is plausibel: bij dergelijke schaal zijn incidenten continu aanwezig. Toch volgt die cijfer niet automatisch uit de extrapolatie met 1,5 % foutkans.
Met acht GPU’s per knooppunt, zouden ongeveer 12.500 systemen nodig zijn voor 100.000 accelerators. Als elk systeem een dagelijkse foutkans van 1,5 % heeft en elke fout onafhankelijk is, zou het verwachte aantal fouten per dag 187,5 bedragen. Dit betekent gemiddeld ongeveer elke 7,7 minuten een storing, niet elke 30 minuten.
Een fout elke 30 minuten komt overeen met ongeveer 48 incidenten per dag op 12.500 knooppunten. De individuele foutkans per knooppunt zou dan ongeveer 0,38 % per dag zijn. Alternatief kan de omvang van de fout, de architectuur of de gebruikte operational data anders worden geïnterpreteerd.
De in de afbeelding genoemde referentie voor deze schatting, het werk arXiv:2605.09370, analyseert niet een cluster van 100.000 GPU’s. Het onderzoekt 63 knooppunten met 504 B200 GPU’s gedurende 55 dagen met metrische data en 73 dagen met operationele logs. Het biedt waardevolle inzichten over detectie, checkpoints, uitsluiting van knooppunten en retries, maar onderbouwt de veronderstelling van een 30-minutinterval voor een cluster van 100.000 accelerators niet direct.
Er bestaat wel gerichte research over het trainen met ongeveer 100.000 GPU’s. De onderzoekers rapporteren een effectieve efficiëntie van slechts 44 % in een volledig synchronische benadering, vanwege de frequentie van incidenten en de tijd die nodig is voor herstel. Het voorgestelde systeem, FT-HSDP genoemd, verkort de pauze na elke herstelactie van tien naar drie minuten en verhoogt de effectieve trainingsduur tot 80 %. Het artikel hoeft geen fout elke 30 minuten te veronderstellen om de omvang van het probleem aan te tonen.
De belangrijke conclusie is niet het exacte interval tussen fouten, dat afhankelijk is van hardware en methodiek, maar dat een systeem dat geoptimaliseerd is om bij elke fout te stoppen, zijn nuttige capaciteit sterk verliest bij enorme aantallen componenten.
Betrouwbaarheid opbouwen boven hardware
Het aanschaffen van kwalitatief hogere servers helpt, maar lost het probleem niet vanzelf op. Bij synchronised training wisselen alle deelnemers tussengradients of tussenresultaten uit. Als één knooppunt uitvalt, te laat reageert of bandbreedte verliest, kunnen de anderen wachten blijven staan.
De infrastructuur heeft mechanismen nodig om te detecteren welk knooppunt de problemen veroorzaakt, dat te verwijderen en het werk te reorganiseren. De snelheid van deze beslissingen is vaak belangrijker dan de precisie van het initiële diagnosticeren.
Vaststellen dat een knooppunt defect is in enkele minuten, voordat men exact weet wat het probleem is, kan machines stilzetten die honderden duizenden euro’s per uur kosten. Eerst isoleren en daarna analyseren verkort de hersteltijd, vooral als er reserveknelpunten of architecturen zijn die operationeel kunnen blijven met minder deelnemers.
Deze aanpak verklaart het gebruik van monitoring, activiteitssignalen, Nvidia DCGM-metrics, NCCL-logs en periodieke netwerktests. Systemen zoeken zowel naar duidelijke fouten als naar trage knooppunten die blijven functioneren, maar hun prestatie verminderen.
Een netwerkverbinding met enige degradatie kan bijzonder schadelijk zijn. Sommige bibliotheken routeren verkeer via andere interfaces om volledige uitval te voorkomen, zelfs als de server nog onder de collectieve operatie valt en anderen kan vertragen. Recent onderzoek stelt algoritmes voor die AllReduce kunnen aanpassen om prestaties te behouden bij verlies van bandbreedte op één knooppunt.
Het operationele doel verschuift van het altijd operationeel houden van alle machines naar het voorkomen dat een defect apparaat anderen mee sleurt.
Checkpoints redden de training, maar kosten geld
De traditionele reactie op een fout is het periodiek opslaan van de staat van het model. Bij onderbreking wordt het laatste checkpoint geladen en wordt de berekening voortgezet vanaf dat punt.
Meer checkpoints opslaan vermindert dataverlies, maar vereist grote hoeveelheden data over te dragen van GPU’s naar servergeheugen en verder naar storage. Bij grote modellen kan het proces pieken veroorzaken die de netwerkbandbreedte of bestandsystemen overbelasten.
Uit de studie van 504 B200 GPU’s blijkt dat bij herstel slechts 21,5 % van de maximale bandbreedte werd gebruikt voor lezen, en 16 % voor schrijven. Ter vergelijking, kans op wachtrijen bij NFS, RPC en transport lagen op dat moment niet zelden. Dit benadrukt dat snel opslag niet automatisch zorgt voor sneller herstel wanneer honderden processen tegelijk data opvragen.
Projecten zoals DLRover proberen deze kosten te verminderen door gegevens in het geheugen te bewaren en asynchroon vast te leggen. Volgens het project verhoogde de combinatie van fault tolerance en snelle recovery de goodput van een training met 65 miljard parameters met duizenden GPU’s van 69 % naar 95 %. Het gaat hier om gerapporteerde cijfers, niet om onafhankelijke vergelijkingen, maar ze illustreren het fundamentele punt: welk percentage van de tijd wordt besteed aan het produceren van nieuwe, nuttige resultaten?
Een GPU kan ‘bezet’ lijken te zijn terwijl hij wacht op communicatie, verloren werk herhaalt, of een checkpoint laad, maar dat betekent niet automatisch dat hij productief is.
Van volledige herstart tot hersteldeling via replica’s
Nieuwere trainingssystemen proberen te voorkomen dat alle processen altijd afhankelijk zijn van elkaar.
FT-HSDP verdeelt het werk over parallelle dataprivés. Wanneer een GPU of server uitvalt, wordt alleen die replica verwijderd. De andere blijven doorgaan en de uitgevallen replica wordt hersteld, geladen en weer geïntegreerd via een protocol voor dynamische herintegratie.
Deze aanpak verandert de definitie van fouttolerantie. Het wordt niet meer één groot systeem van 100.000 GPU’s die altijd volledig operationeel moet zijn, maar een verzameling van meerdere groepen die tijdelijk een verlies kunnen verdragen.
Asynchroon herstel vermindert ook de behoefte aan grote reserves aan onbenutte hardware. Het blijft nodig om knooppunten te vervangen, maar reservecapaciteit kan worden geïntegreerd in het cluster zelf en niet als een apart kopieklone.
De ervaring met het 504-GPU-cluster toont dat geautomatiseerde retries een slaagpercentage van 33,3 % behalen, versus 12,5 % bij handmatige pogingen, met een mediane herhaalperiode van elf minuten. Dit onderstreept dat automatische, herhaalbare responsen effectiever kunnen zijn dan improvisatie.
Wat moet een AI-infrastructuurbeheerder meten?
De foutratio die voor een GPU of server wordt gepubliceerd, is slechts één aspect. Een operationele inzet moet meten hoeveel onderbrekingen er per duizend GPU’s en uur plaatsvinden, hoe snel ze worden gedetecteerd, hoeveel werk wordt verloren en hoeveel minuten nodig zijn om de vorige prestatie te herstellen.
Ook is het belangrijk om incidenten naar bron te classificeren: GPU, HBM, NVLink, netwerkinterfaces, switches, opslag, voeding, koeling, drivers en software. Zonder dergelijke indeling kan een schijnbare verbetering van hardware worden verhuld door een knelpunt dat zich heeft verplaatst naar een andere laag.
De claim dat HBM-geheugen in een systeem van 32.000 accelerators meer storingen veroorzaakt dan de GPU-berekeningen, is plausibel vanwege de complexiteit van gestapelde geheugenmodules, maar wordt niet bevestigd door de in de infographic genoemde bronnen. Totdat het originele rapport beschikbaar is, moet deze bewering als onverifiëerbaar worden beschouwd en niet als een bevestigde trend voor de hele industrie.
De betrouwbaarheid van een groot cluster wordt niet bepaald door de specificaties van één GPU, maar door een combinatie van observability, isolatie, reserve- en herstelmogelijkheden, snelle checkpoints en een trainingsmodel dat uitgaat van het feit dat hardware zal falen.
In een kleinschalige infrastructuur is een storing nog altijd een incident. In een systeem met tientallen duizenden GPU’s is het een normale bedrijfsvoorwaarde. Het verschil tussen een dure en een productieve cluster ligt in de manier waarop men de minuten direct daarna behandelt.
Veelgestelde vragen
Is de 84,8 % faalkans voor 1.000 GPU’s correct?
Ja, onder de aanname van 125 knooppunten met elk acht GPU’s, een onafhankelijke dagelijkse foutkans van 1,5 % en gelijke waarschijnlijkheid voor alle knooppunten. Het resultaat komt neer op ongeveer 84,9 %.
Verhindert een incident op een knooppunt altijd dat de hele training stopt?
Niet altijd. Bij zeer strak synchronische systemen kan dat het geval zijn, maar systemen met fouttolerante replica’s kunnen alleen dat onderdeel uitschakelen terwijl de rest doordraait.
Fhout een systeem met 100.000 GPU’s elke 30 minuten?
Het kan incidenteel heel vaak voorkomen, maar de daadwerkelijke interval hangt af van de foutkans en hoe ‘fout’ wordt gedefinieerd. 30 minuten is niet direct uit het eenvoudige voorbeeld van 1,5 % te halen.
Welke metriek geeft de beste indicatie voor clusterbetrouwbaarheid?
De goodput, oftewel het percentage tijd dat wordt besteed aan het produceren van nieuw bruikbaar werk, is doorgaans relevanter dan slechts de beschikbaarheid van individuele GPU’s.