Vår GB10-maskin slo seg av av seg selv. Loggen pekte på minnet; det var varmen
Drift
Én av våre tre NVIDIA GB10-maskiner gikk svart tre ganger på fire dager i september: 10. september, 12. september (den var av i 17 timer) og 13. september, tolv minutter etter at den ble slått på igjen. Hver gang trengtes det en person til å trykke på strømknappen.
Slik ser en varmeavstengning ut
Systemjournalen stoppet rett og slett midt i aktivitet, uten noen avstengning i seg: en hard strømavstengning gir ikke journald tid til å skrive bufferen sin. I juli, etter en lignende avstengning, kom klokken til og med tilbake med en gammel dato. Og maskinvareovervåkeren, som starter en hengende maskin på nytt, gjorde ingenting, fordi maskinen ikke hadde hengt seg: strømmen var borte.
Ledetråden som var feil
De siste kjernelinjene før hver død var GPU-minnefeil (NV_ERR_NO_MEMORY), så minnet så skyldig ut. Det var det ikke. Disse linjene var rett og slett det vanligste kjernen skrev: 440 580 av dem i én enkelt oppstart som hadde vart i 19 dager før den tok slutt. Når en linje dukker opp så ofte, vil den være den siste linjen før hva som helst. Før du skylder på en logglinje, tell hvor ofte den dukker opp når ingenting går galt.
Ledetråden som var riktig
Fordi journalen mister de siste minuttene ved en strømavstengning, hadde vi lagt til en liten sampler som skriver temperatur, last og minne til en fil hvert minutt og tømmer den til disk. Den fanget opp alle fem dødsfallene siden juli. Hvert av dem kom ved full GPU-last (96 %), med CPU-en på 85 til 97 °C.
Tidsinnstillingen forklarte resten. Rundt starten av september hadde vi flyttet videorendering over på denne maskinen. GPU-effekten under full last gikk fra omtrent 24 W til 46 W, median GPU-temperatur fra 68 til 86 °C, og minutter per uke med CPU på 95 °C eller mer fra ingen til 4 283. Våre to andre GB10-maskiner, som kjører språkmodellen ved samme 96 % last, holdt seg på 65 til 81 °C. Denne kjølte rett og slett dårligere.
Den første fiksen: en GPU-klokkegrense
På GB10 kan nvidia-smi ikke sette en effektgrense, men den kan sette en grense for GPU-klokken: nvidia-smi -lgc 0,2000. I juli tok dette den varmeste sonen fra 91 °C til 77 til 83 °C innen sekunder. To detaljer betyr noe:
- Bruk den før de tunge tjenestene starter. Vår grensetjeneste kjørte først omtrent 15 sekunder etter oppstart, når modellserveren allerede hadde begynt å laste ved full effekt, som var øyeblikket som hadde krasjet maskinen. Nå kjører den før Docker starter.
- Test det under belastning. Med grensen aktivert viser den rapporterte GPU-klokken fortsatt om lag 2 400 MHz når GPU-en er inaktiv. Under belastning holder den seg på 1 976 MHz.
Den andre fiksen: en varmesikring i trinn
Grensen var ikke nok da renderingen kom inn, så en sikring leser nå alle sensorer ett sekund om gangen og griper inn i trinn: lavere GPU-klokke fra 89 °C og enda lavere fra 92 °C; fra 94 °C settes rendereren på pause (SIGSTOP) og CPU-en bremset ned; fra 96 °C settes alle GPU-jobber på pause i de sekundene det tar å kjøle ned. Den trapper ned først etter at maskinen har vært kjøligere en stund. Ved 97 °C i 20 sekunder stopper en siste-utvei-bremse videotjenesten helt.
I de første ni minuttene under rendering nådde den varmeste sonen en topp på 94 °C med en median på 89 °C, mot platåer på 97 °C tidligere. Det har en pris: på én dag i midten av september var rendereren på pause i 17 % av tiden, og GPU-en gikk på 900 MHz eller mindre mesteparten av dagen. Og det er ingen kur: maskinen slo seg av én gang til, den 11. oktober, ved 97 til 98 °C. Den har kjørt uten avbrekk siden da, 20 dager så langt vi skriver dette.
Fire feil vi gjorde underveis
- Å sette én jobb på pause kjølte ikke maskinen. Bremsen slo inn mens rendereren allerede var på pause, fordi en bildemodell fortsatt tegnet og et dusin timere startet i samme minutt. Det øverste trinnet setter nå alle tunge GPU-jobber på pause, ikke bare rendereren.
- Sikringen setter jobber på pause etter navn, og navnene endret seg. To ganger ville en ny motor ha unnslippet pausen: en bildemodell med et nytt prosessnavn i september, og i oktober en renderer som kjører i en container i stedet for som en underprosess til render-tjenesten. Hver endring av motor innebærer nå en sjekk av sikringens liste.
- Bremseholdet ble aldri opphevet. Den stoppet videotjenesten og la igjen en holdfil slik at ingenting startet den på nytt. Ingen varslet heller noen, og produksjonen stoppet i tre dager før vi merket det. Holdet opphever seg nå selv: fem minutter etter den siste bremsen, uten ny brems, minst 30 GB ledig minne og et gjennomsnitt over ti minutter på 93 °C eller mindre. Å vente på at maskinen skulle kjøle seg ned ville aldri fungert: den hadde et gjennomsnitt på 88 °C med og uten rendering.
- Alarmen ringte ved maskinens normale temperatur. Advarselsterskelen var 88 °C, som var denne maskinens gjennomsnitt. Over én dag tilbrakte den 32 % av tiden på 90 °C eller mer, 8 % på 93 °C eller mer og 3 % på 95 °C eller mer, og nådde aldri 97 °C. Vi flyttet alarmen til 97 °C, platået der den faktisk døde, og alarm-e-postene stoppet.
Konklusjonen
Programvaren holdt denne maskinen i live, men årsaken var fysisk: kjølingen var to til tre ganger dårligere enn søsknenes. Hvis en GB10-maskin slår seg av under belastning, sjekk luftstrømmen først. Begrens deretter GPU-klokken før tjenestene dine starter, pause de tunge jobbene før maskinen når grensen, og sett opp alarmer basert på temperaturene den faktisk kjører på.
Factory Floor inkluderer en slik varmesikring: den leser den høyeste av GPU- og termisone-sensorene, pauser de tunge jobbene du angir ved en bestemt temperatur (92 °C som standard) og gjenopptar dem kun under en lavere (84 °C), med minne- og disksikringer ved siden av.