Clockwork laat GPU-clusters doorwerken bij storingen

Wie GPU-infrastructuur ontwerpt, levert of beheert, heeft te maken met zeer dure clusters die door storingen regelmatig stilstaan. Software die dat verlies beperkt, raakt de businesscase van die clusters en dus ook de diensten eromheen. Clockwork vertrekt vanuit een bekend probleem: ‘Bij training werken duizenden GPU's synchroon samen, en zodra één GPU of één link vertraagt of uitvalt, wachten alle andere.’ Volgens het bedrijf is het netwerk daarmee een essentieel onderdeel van de rekeninfrastructuur geworden.

Clockwork onderbouwt dit met studies van derden. Een onderzoek van Meta laat volgens hen zien dat een cluster van 1.000 GPU's gemiddeld ongeveer drie verstoringen per dag heeft, met 45 minuten tot anderhalf uur verlies per verstoring. Een studie van ByteDance zou aantonen dat ruim twee op de vijf jobs minstens 10 procent trager liepen door een gedegradeerde component. Bij handmatige detectie ging volgens een Microsoft-studie ongeveer twee uur verloren aan het opsporen van de oorzaak.

Tenslotte: herstel verloopt traag. Na een uitval moet de job opnieuw starten, het laatste checkpoint worden geladen en al het werk sinds dat checkpoint opnieuw worden berekend.

Van tijdsynchronisatie naar fouttolerantie

De voorgestelde technologie komt uit een ander vakgebied. Clockwork begon met het synchroniseren van klokken over grote aantallen machines, volgens het bedrijf tot tientallen nanoseconden nauwkeurig en helemaal in software. Eerste klanten kwamen uit de financiële sector, waar transacties nauwkeurig getimestampt moeten worden.

Met zulke klokken kan de één-richtingsvertraging van pakketten worden gemeten, in plaats van de gebruikelijke schatting op basis van de roundtrip-tijd. Clockwork stuurt daarvoor elke tien milliseconden lichtgewicht probes tussen alle NIC-paren. Met die metingen kan het probleem 'getrianguleerd' worden tot een specifieke switch, link of poort. Dat moet vooral de grijze storingen zichtbaar maken, waarbij dashboards groen tonen terwijl de workload toch vertraagt. Het bedrijf positioneert dit nadrukkelijk niet als vervanger van brede observability-tools als Datadog of Splunk.

Op deze basis bouwde Clockwork het platform FleetIQ, met twee onderdelen, zijnde Observability met Fleet Lens voor detectie tijdens runtime en Fleet Audit voor tests voordat een cluster in productie gaat. De fouttolerantie is geregeld met Link Pass, Torch Pass en sinds kort Torch Pass-snapshots.

Drie lagen fouttolerantie

Link Pass vangt linkstoringen op laag niveau af. Verkeer van een uitgevallen NIC wordt herverdeeld over de overige NIC's van dezelfde node, en teruggezet als de link herstelt. Zonder zo'n ingreep leidt een linkflap volgens Clockwork tot een time-out in NCCL, na ongeveer een minuut, of in PyTorch, standaard na tien minuten. Het bedrijf zegt binnen een tot twee seconden te reageren. Link Pass draait volgens Clockwork al ruim een jaar in productie.

Torch Pass verhuist bij een defecte of op te ruimen node de toestand van die node live naar een andere node. Bij een plotselinge uitval wordt de toestand gereconstrueerd vanuit een data-parallel replica. Daarvoor is dus replicatie in de trainingsopzet nodig, plus een beschikbare vervangende node. Volgens Clockwork hanteren neoclouds een norm van 5 tot 8 procent reserve capaciteit, die meestal lagere-prioriteitsjobs draait en bij nood wordt ingezet op geoprioteriseerde opdrachten. In de demo, met twee nodes van vier GPU's, lag de training ongeveer een minuut stil en ging daarna verder op dezelfde stap.

Snapshots vormen de vangnetlaag. Het platform legt de toestand van GPU- en CPU-geheugen vast, zonder aanpassing van de modelcode. Dat kost volgens Clockwork minder dan twintig seconden (of minder dan vijf seconden via de checkpointfunctie van het model zelf). Bij één snapshot per twintig minuten zou de overhead rond de 1% liggen. Het restoretraject is nog niet volledig gebenchmarkt, gaf het bedrijf zelf toe. Omdat snapshots per GPU ongeveer 100 tot 200 gigabyte omvatten, is een grote opslagcapaciteit nodig.