Wie können Unternehmen GPU-Zustand, ECC-Fehler, Temperatur, Stromverbrauch und degradierte Beschleunigerkarten überwachen?

Unternehmen sollten den GPU-Zustand auf Ebene der einzelnen Karte überwachen und dann Hardware-Fehler, Temperatur, Stromverbrauch, Takte, Auslastung, Reset-Historie und Workload-Verhalten zu einem klaren Zustandsbild kombinieren. Das Ziel ist, einen degradierten Beschleuniger zu erkennen, bevor er einen verteilten Trainingsjob verlangsamt, wiederholte Fehlschläge verursacht oder einer anderen Workload zugewiesen wird.

Ein grüner Server beweist nicht, dass jeder Beschleuniger darin gesund ist. Ein Acht-GPU-Node kann online bleiben, während eine Karte wiederkehrende ECC-Fehler oder thermische Probleme entwickelt. Für KI-Infrastruktur muss sich die operative Einheit deshalb unterhalb des Servers bis zum Beschleuniger selbst erstrecken.

Welche GPU-Zustandsmetriken sollten Unternehmen überwachen?

Unternehmen sollten die Signale überwachen, die drei Fragen beantworten: Ist die Karte physisch gesund, arbeitet sie innerhalb der erwarteten Grenzen, und liefert sie stabile Leistung?

Für die physische Gesundheit beginnen Sie mit ECC-Ereignissen, PCIe- oder Link-Fehlern, sofern verfügbar, Reset-Ereignissen, Hardware-Fehlercodes sowie Firmware- oder Treiberstatus.

Erfassen Sie für die Betriebsbedingungen Temperatur, Stromverbrauch, Taktzustand, Speichernutzung und Throttling-Indikatoren.

Verfolgen Sie für die Leistung GPU-Auslastung, Speicherauslastung, Workload-Durchsatz und auffällige Leistungsänderungen über die Zeit.

Der NVIDIA Data Center GPU Manager bietet Zustandsüberwachung, Diagnostik, Feldgruppen und Telemetrie für NVIDIA-Rechenzentrums-GPUs. Seine dokumentierten Felder umfassen Gerätestrom, temperaturbezogene Werte, Takte, Auslastung, ECC-bezogene Zähler und weitere Geräteinformationen, abhängig von GPU-Generation und Software-Unterstützung.

Die genauen Metriken unterscheiden sich zwischen Beschleuniger-Herstellern. Eine Multi-Vendor-Flotte braucht deshalb ein normalisiertes Zustandsmodell, das die rohen Herstellerfelder darunter erhält.

Für das umfassendere Ressourcenmodell erklärt wie man GPUs und NPUs mehrerer Hersteller verwaltet, wie man den Zustand standardisiert, ohne so zu tun, als würde jeder Beschleuniger identische Telemetrie liefern.

Was sind ECC-Fehler, und warum sind sie wichtig?

ECC-Fehler sind Speicherfehlerereignisse, die von Error-Correcting-Code-Mechanismen auf unterstützter Hardware erkannt werden.

Die operative Unterscheidung liegt zwischen Fehlern, die die Hardware korrigieren kann, und Fehlern, die darauf hindeuten, dass Daten nicht zuverlässig korrigiert werden konnten.

Ein korrigiertes Ereignis bedeutet nicht automatisch, dass eine Karte entfernt werden sollte. Ein einzelnes isoliertes korrigiertes Ereignis kann eine ganz andere Bedeutung haben als eine rasch steigende Fehleranzahl auf demselben Gerät.

Das Muster zählt.

Erfassen Sie Fehlertyp, Anzahl, Änderungsrate, betroffene Karte, die Workload zum Zeitpunkt des Ereignisses und ob sich das Ereignis nach einem Reset oder Validierungstest wiederholt.

Nicht korrigierbare Fehler verdienen eine stärkere Behandlung, weil sie je nach Hardware- und Softwareverhalten zu Workload-Fehlschlägen, fehlerhaften Berechnungen oder einem Geräte-Reset führen können.

Das Monitoring-System sollte den ECC-Zustand niemals auf einen einzelnen roten oder grünen Indikator reduzieren, ohne die zugrunde liegenden Zähler und die Ereignishistorie zu behalten.

Ein Operator, der einen Trainingsfehlschlag untersucht, muss wissen, ob die Karte vor Monaten ein historisches Ereignis oder eine Häufung frischer Ereignisse während des fehlgeschlagenen Jobs verzeichnet hat.

Wie sollte die GPU-Temperatur überwacht werden?

Die GPU-Temperatur sollte als Zeitreihe überwacht und gegen gerätespezifische Betriebsgrenzen bewertet werden, statt gegen einen einzigen universellen Schwellenwert.

Unterschiedliche Beschleuniger haben unterschiedliche thermische Eigenschaften. Die Plattform sollte deshalb Hersteller- und Modellkontext zusammen mit der Metrik speichern.

Beobachten Sie sowohl die absolute Temperatur als auch das Verhalten rund um Workload-Änderungen.

Wenn die Temperatur mit steigender Last ansteigt und danach wieder normal wird, kann das erwartbar sein.

Wenn die Temperatur nach Abschluss der Workload erhöht bleibt, schneller steigt als bei vergleichbaren Karten oder wiederholt einen Drosselungs-Schwellenwert erreicht, untersuchen Sie Kühlung, Luftstrom, Flüssigkeitsfluss, Kühlkörperkontakt, Lüfterleistung oder die Karte selbst.

Der beste Vergleich basiert oft auf vergleichbaren Geräten.

Vergleichen Sie Karten desselben Modells im selben Chassis unter ähnlicher Last. Eine Karte, die durchgängig heißer läuft als die anderen sieben, ist aussagekräftiger als ein generischer Flottendurchschnitt.

Die Temperatur sollte außerdem mit Takten und Leistung korreliert werden.

Eine Karte kann online bleiben, während die Temperatursteuerung ihre Takte reduziert. Der Nutzer sieht einen langsamen Job. Das Hardware-Monitoring sieht ein thermisches Problem. Diese beiden Beobachtungen zu verbinden ist es, was das Monitoring operativ nützlich macht.

Wie sollte der GPU-Stromverbrauch überwacht werden?

Der GPU-Stromverbrauch sollte auf Kartenebene überwacht und mit Zuweisung, Auslastung, Taktverhalten und Workload-Status verglichen werden.

Der aktuelle Stromverbrauch zeigt Ihnen, was die Karte gerade zieht.

Energie ist Leistung, akkumuliert über die Zeit. Wenn Sie Projektkosten oder Karten-Stunden-Energie ermitteln wollen, integrieren Sie die Leistungswerte über das Workload-Intervall.

Eine Karte, die erheblich Strom zieht, während sie wenig nützliche Arbeit leistet, ist ein Effizienzproblem.

Eine Karte, die während einer Workload unerwartet wenig Strom zieht, kann darauf hindeuten, dass sie auf Storage, Netzwerkkommunikation, CPU-seitiges Daten-Laden oder ein Scheduler-Problem wartet.

Eine Karte, die wiederholt an ihr Leistungslimit herankommt, kann sich anders verhalten als eine andere Karte, die dieselbe Workload ausführt.

Der Stromverbrauch sollte deshalb sowohl den Zustand als auch die Ökonomie unterstützen.

Die Zustandssicht fragt, ob das Stromverhalten auffällig ist.

Die Betriebssicht fragt, wie viel Energie die Workload verbraucht hat und ob teure zugewiesene Hardware Zeit im Leerlauf verbracht hat.

Für die Diagnoseseite erklärt warum die GPU-Auslastung niedrig sein kann, wie man Beschleuniger-Stromverbrauch und -Auslastung mit Netzwerk, Storage und Daten-Laden korreliert.

Was ist eine degradierte Beschleunigerkarte?

Eine degradierte Beschleunigerkarte ist ein Gerät, das weiterhin erkennbar ist, aber genug auffällige Hinweise aufweist, dass die Zuweisung neuer Produktions-Workloads unnötiges Risiko schafft.

Das ist eine operative Kategorie, kein universeller Hardware-Standard.

Ein degradierter Zustand kann durch ein einzelnes schwerwiegendes Ereignis oder eine Kombination schwächerer Signale ausgelöst werden.

Beispiele sind wiederholte ECC-Fehler, wiederkehrende Resets, anhaltendes thermisches Throttling, auffälliges Taktverhalten, instabiler Link-Zustand, wiederholte Treiber-Recovery-Ereignisse oder ein messbarer Leistungsabfall gegenüber vergleichbaren Karten.

Der Schwellenwert sollte auf Hardware-Modell, Workload-Empfindlichkeit und operativer Erfahrung basieren.

Markieren Sie eine Karte nicht als degradiert, nur weil eine Metrik einmal einen generischen Schwellenwert überschritten hat.

Warten Sie gleichzeitig nicht auf den vollständigen Ausfall, wenn sich die Hinweise häufen.

Der Zweck des degradierten Zustands ist es, einen kontrollierten Mittelweg zwischen gesund und ausgefallen zu schaffen.

Dieser Zustand lässt den Scheduler aufhören, neue Arbeit zuzuweisen, während Operatoren die Karte validieren.

Wie sollten Unternehmen einen GPU-Health-Score erstellen?

Ein GPU-Health-Score sollte mehrere Signale kombinieren, aber die rohen Belege müssen sichtbar bleiben.

Ein praxistaugliches Modell verwendet drei Stufen.

Gesund bedeutet keine signifikanten Hardware-Warnungen, Betriebsbedingungen innerhalb des genehmigten Bereichs und Leistung im Einklang mit vergleichbaren Geräten.

Degradiert bedeutet, das Gerät ist online, hat aber wiederkehrende oder bedeutsame Warnungen, die es rechtfertigen, neue Workload-Zuweisungen zu vermeiden.

Ausgefallen bedeutet, dem Gerät kann für die Produktion nicht vertraut werden, und es sollte isoliert werden, bis es repariert oder ersetzt ist.

Sie können hinter diesen Zuständen einen internen Score berechnen, aber vermeiden Sie es, Nutzern eine mysteriöse Zahl wie „72 von 100" ohne Erklärung zu präsentieren.

Jeder degradierte Zustand sollte erklären, warum.

Zum Beispiel:

Degradiert, weil korrigierte ECC-Fehler in den letzten 30 Minuten rasch zugenommen haben.

Degradiert, weil die Karte während zweier Trainingsjobs dreimal zurückgesetzt wurde.

Degradiert, weil die Temperatur wiederholt den Drosselungs-Schwellenwert erreichte, während vergleichbare Karten normal blieben.

Die Erklärung zählt mehr als der Score.

Wie sollten In-Band- und Out-of-Band-Monitoring zusammenarbeiten?

Verwenden Sie In-Band-Monitoring für Laufzeitdetails des Beschleunigers und Out-of-Band-Monitoring für den physischen Server und den Recovery-Pfad.

GPU-Laufzeitbibliotheken und Hersteller-Management-Tools liefern oft die reichhaltigste Telemetrie auf Kartenebene.

Der BMC liefert Server-Zustand, Stromstatus, Lüfter, Netzteile, Firmware und andere physische Signale unabhängig vom Host-Betriebssystem.

Zusammen ergeben sie eine stärkere Diagnose.

Angenommen, eine GPU zeigt hohe Temperatur.

In-Band-Telemetrie bestätigt die Beschleuniger-Temperatur und die Taktreduzierung.

Out-of-Band-Telemetrie zeigt eine Chassis-Lüfter-Warnung.

Die Beziehung zwischen beiden deutet eher auf ein Kühlungsproblem auf Serverebene hin als auf eine schlechte Trainingskonfiguration.

Dasselbe Prinzip gilt, wenn das Betriebssystem abstürzt. Die GPU-Laufzeitdaten können aussetzen, aber der BMC-Pfad kann erreichbar bleiben.

Eine sinnvolle Architektur hält beide Quellen an dieselbe Server- und Kartenidentität gekoppelt.

Wie sollten Zustandsdaten das GPU-Scheduling beeinflussen?

Der Kartenzustand sollte ein Eingabewert für Scheduling-Entscheidungen sein.

Wenn eine Karte degradiert, sollte der Scheduler aufhören, ihr neue Arbeit zuzuweisen, sobald die genehmigte Policy ausgelöst wird.

Bei einem milden Zustand könnte die Plattform die Scheduling-Priorität senken.

Bei einem stärkeren Zustand kann sie das Gerät oder den Node als nicht einplanbar markieren.

Bei einem bestätigten Ausfall kann der Workload-Recovery-Prozess einen Checkpoint verwenden, den Job auf gesunde Kapazität verschieben und eine Reparaturaufgabe anlegen.

Das schließt den Kreis zwischen Monitoring und Betrieb.

Ohne diese Verbindung kann das Monitoring-Team wissen, dass eine Karte ungesund ist, während der Scheduler ihr weiterhin Jobs zuweist.

Das ist eine der teuersten Formen operativer Entkopplung in einem KI-Cluster.

Wie vermeidet man False Positives?

Vermeiden Sie False Positives, indem Sie Schwellenwerte, Persistenz, Vergleich mit ähnlichen Geräten und Workload-Kontext kombinieren.

Eine Temperaturspitze, die zwei Sekunden dauert, rechtfertigt möglicherweise keine Isolation.

Eine wiederkehrende Spitze bei jedem Job mit hoher Last möglicherweise schon.

Ein einzelnes korrigiertes ECC-Ereignis rechtfertigt möglicherweise keine Reparatur.

Ein rasch wachsender Zähler möglicherweise schon.

Ein Auslastungsabfall kann durch Storage verursacht sein statt durch die Karte.

Deshalb sollten Zustandsregeln nicht aus einer isolierten Metrik gebaut werden.

Verwenden Sie Zeitfenster.

Verwenden Sie die Änderungsrate.

Vergleichen Sie mit Karten desselben Modells.

Prüfen Sie, ob die Karte unter Last stand.

Prüfen Sie, ob gleichzeitig ein anderes Infrastruktur-Ereignis stattfand.

Stimmen Sie die Regeln dann anhand tatsächlicher Vorfälle ab.

Das Quell-Betriebsmodell behandelt Schwellenwerte für degradierte Karten ausdrücklich als etwas, das fortlaufend anhand von echtem Trainingsverhalten abgestimmt werden muss.

Was sollte geschehen, nachdem eine Karte als degradiert markiert wurde?

Eine degradierte Karte sollte in einen kontrollierten Workflow eintreten: Workloads schützen, neue Zuweisung stoppen, Belege sammeln, das Gerät validieren und entscheiden, ob es wieder in Betrieb gehen kann.

Identifizieren Sie zunächst die aktuelle Workload.

Wenn der Job sicher einen Checkpoint setzen kann, schützen Sie den Trainingszustand, bevor Sie ihn verschieben.

Blockieren Sie zweitens neue Zuweisungen.

Sammeln Sie drittens Diagnosedaten, einschließlich der Fehler-Zeitachse, Temperatur, Stromverbrauch, Takte, Firmware, Treiberstatus und relevanter Server-Ereignisse.

Führen Sie viertens gegebenenfalls Hersteller-Diagnostik oder einen genehmigten Burn-in-Test durch.

Vergleichen Sie fünftens das Ergebnis mit der Return-to-Service-Policy.

Heben Sie den degradierten Zustand nicht nur deshalb auf, weil die Karte fünf Minuten später normal aussieht.

Ein wiederkehrendes Hardware-Problem kann nach einem Reset vorübergehend verschwinden.

Die Karte sollte erst dann in den Pool zurückkehren, wenn die Validierung genug Vertrauen liefert.

Ein Plattformbeispiel, das Kartenzustand, Scheduling und operative Workflows verbindet, ist Sensaka.

Der praktische Standard ist einfach: Jeder teure Beschleuniger sollte eine bekannte Identität, einen aktuellen Zustand, eine Historie auffälliger Ereignisse und eine an diesen Zustand gekoppelte Scheduling-Policy haben. Wenn Sie eine verdächtige Karte nicht aus der Produktion nehmen können, bevor sie vollständig ausfällt, überwachen Sie GPUs, betreiben sie aber noch nicht als verwaltete Ressource.