Vår GB10-maskin stängde av sig själv. Loggen pekade på minnet; det var värmen

Drift2026-10-31

En av våra tre NVIDIA GB10-maskiner slocknade tre gånger på fyra dagar i september: den 10 september, den 12 september (den var avstängd i 17 timmar) och den 13 september, tolv minuter efter att den hade startats om igen. Varje gång behövde en person trycka på strömknappen.

Så ser ett värmestopp ut

Systemloggen slutade helt enkelt, mitt i aktivitet, utan något stopp i den: ett hårt strömavbrott ger inte journald tid att skriva sin buffert. I juli, efter ett liknande stopp, kom klockan till och med tillbaka med ett gammalt datum. Och hårdvarubevakningsprocessen, som startar om en maskin som hänger sig, gjorde ingenting, eftersom maskinen inte hade hängt sig: strömmen var borta.

Ledtråden som var fel

De sista kärnraderna före varje avstängning var GPU-minnesfel (NV_ERR_NO_MEMORY), så minnet såg skyldigt ut. Det var det inte. De raderna var helt enkelt det vanligaste kärnan skrev: 440 580 av dem under en enda start som hade pågått i 19 dagar innan den avslutades. När en rad förekommer så ofta kommer den att vara den sista raden före vad som helst. Innan du anklagar en loggrad, räkna hur ofta den förekommer när ingenting går fel.

Ledtråden som var rätt

Eftersom loggen förlorar sina sista minuter vid ett strömavbrott hade vi lagt till en liten provtagare som skriver temperatur, belastning och minne till en fil varje minut och tvingar ut den till disk. Den fångade alla fem avstängningar sedan juli. Varje gång skedde det vid full GPU-belastning (96 %), med CPU:n på 85 till 97 °C.

Tidsaspekten förklarade resten. Runt början av september hade vi flyttat videorendering till denna maskin. Dess GPU-effekt vid full belastning gick från cirka 24 W till 46 W, dess mediantemperatur för GPU:n från 68 till 86 °C, och minuterna per vecka med CPU:n på 95 °C eller mer från noll till 4 283. Våra två andra GB10-maskiner, som kör språkmodellen vid samma 96 % belastning, låg kvar på 65 till 81 °C. Denna svalde helt enkelt sämre.

Den första åtgärden: en GPU-klockbegränsning

På GB10 kan nvidia-smi inte sätta en effektbegränsning, men det kan begränsa GPU-klockan: nvidia-smi -lgc 0,2000. I juli sänkte det den hetaste zonen från 91 °C till 77 till 83 °C inom sekunder. Två detaljer spelar roll:

• Tillämpa den innan de tunga tjänsterna startar. Vår begränsningstjänst körde först cirka 15 sekunder efter start, när modellservern redan hade börjat ladda vid full effekt, vilket var det ögonblick som hade kraschat maskinen. Nu körs den innan Docker startar.
• Kontrollera det under belastning. Med begränsningen aktiverad visar den rapporterade GPU-klockan fortfarande cirka 2 400 MHz när GPU:n är inaktiv. Under belastning ligger den kvar på 1 976 MHz.

Den andra åtgärden: en värmesäkerhetskontroll i steg

Begränsningen räckte inte när renderingen flyttade in, så en säkerhetskontroll läser nu varje sensor en gång per sekund och agerar i steg: en lägre GPU-klocka från 89 °C och en ytterligare sänkning från 92 °C; från 94 °C pausas renderaren (SIGSTOP) och processorn saktas ner; från 96 °C pausas alla GPU-jobb under den tid det tar att svalna. Den återgår bara efter att maskinen har hållit sig svalare ett tag. Vid 97 °C i 20 sekunder stoppar en sista utväg videonätverket helt.

Under de första nio minuterna med rendering nådde den hetaste zonen en topp på 94 °C med ett medianvärde på 89 °C, jämfört med tidigare platåer på 97 °C. Det har ett pris: en dag i mitten av september pausades renderaren 17 % av tiden, och GPU:n körde på 900 MHz eller mindre under större delen av dagen. Och det är ingen bot: maskinen stängde av sig själv en gång till, den 11 oktober, vid 97 till 98 °C. Den har kört utan avbrott sedan dess, 20 dagar när vi skriver detta.

Fyra misstag vi gjorde längs vägen

• Att pausa ett jobb svalnade inte maskinen. Bromsen utlöstes när renderaren redan var pausad, eftersom en bildmodell fortfarande ritade och ett dussin timers startade samma minut. Det högsta steget pausar nu alla tunga GPU-jobb, inte bara renderaren.
• Säkerhetskontrollen pausar jobb efter namn, och namnen ändrades. Två gånger hade en ny motor kunnat undkomma pausen: en bildmodell med ett nytt processnamn i september, och i oktober en renderare som körs i en container istället för som ett barn till render-tjänsten. Varje byte av motor inkluderar nu en kontroll av säkerhetskontrollens lista.
• Bromsens lås hävdes aldrig. Den stoppade videonätverket och lämnade en låsfil så att inget startade om det. Ingen larmade heller någon, och produktionen stannade i tre dagar innan vi märkte det. Låset häver sig nu själv: fem minuter efter den sista bromsningen, utan ny bromsning, minst 30 GB ledigt minne och ett tio-minutersmedelvärde på 93 °C eller lägre. Att vänta på att maskinen skulle svalna skulle aldrig fungera: den låg i snitt på 88 °C med och utan rendering.
• Larmet löste ut vid maskinens normala temperatur. Larmtröskeln var 88 °C, vilket var denna maskins medelvärde. Under en dag låg den 32 % av tiden på 90 °C eller mer, 8 % på 93 °C eller mer och 3 % på 95 °C eller mer, och nådde aldrig 97 °C. Vi flyttade larmet till 97 °C, den platå där den faktiskt dog, och larmmejluppsendningarna upphörde.

Slutsatsen

Mjukvaran höll denna maskin vid liv, men orsaken var fysisk: dess kylning var två till tre gånger sämre än syskonmaskinernas. Om en GB10-maskin stänger av sig själv under belastning, kontrollera luftflödet först. Begränsa sedan GPU-klockfrekvensen innan dina tjänster startar, pausa de tunga jobben innan maskinen når sin gräns, och ställ in larm utifrån de temperaturer den faktiskt kör vid.

Factory Floor innehåller en sådan värmebevakning: den läser av den högsta av GPU- och termzon-sensorerna, pausar de tunga jobb du anger vid en inställd temperatur (92 °C som standard) och återupptar dem endast under en lägre (84 °C), med minnes- och diskbevakning vid sidan av.