Wenn die DGX Spark plötzlich so lahm ist

Comicstil-Illustration eines Detektiv-Roboters mit Deerstalker-Mütze und Lupe, der ein rot ausschlagendes Taktmessgerät untersucht, im Hintergrund eine schwach glimmende DGX-Spark-artige Superchip-Workstation.
Der Fall der lahmen DGX Spark – Illustration im Comic-Stil. KI-generiert (GPT Image 2).

Ihre DGX Spark fühlt sich seit ein paar Tagen komisch träge an, aber Sie können nicht sagen, woran es liegt? Willkommen im Klub — denn genau dieses Gefühl hat uns auf die Spur eines Bugs gebracht, den NVIDIA bisher lieber verschweigt als behebt.

Der Tatort: unser eigener Spark-Cluster. Der Verdacht fiel zunächst auf niemanden — bis eine der Maschinen plötzlich nur noch halb so schnell rechnete wie ihre Nachbarn. Kein Fehlercode, kein Log-Eintrag, keine Warnung. Nur eine Spark, die sich anfühlte, als hätte sie über Nacht die Hälfte ihres Grace-Blackwell-Gehirns verloren.

Die Ermittlung führte zu einem seit Monaten bekannten, aber unbehobenen BIOS-Bug in der DGX Spark (GB10): Unter bestimmten, bislang nicht reproduzierbaren Umständen bleibt der Chip in einem Low-Power-Zustand hängen — der SM-Takt dümpelt bei rund 1000–1200 MHz statt der üblichen ~2400 MHz. Mehr als die Hälfte der Rechenleistung verschwindet spurlos, ohne dass ein normaler Reboot etwas daran ändert. Einziges Gegenmittel: ein Cold Boot — Strom ziehen, mindestens 30 Sekunden warten, neu starten.

Das eigentliche Verbrechen dieses Bugs ist seine Tarnung. Auf einem Einzelsystem bleibt es ein vages Bauchgefühl. Im Cluster fällt es nur im Vergleich auf. Und auf einem unbeaufsichtigten Server merkt es niemand — bis jemand sich fragt, warum das Training ewig dauert, und die Inferenz im Schneckentempo schleicht.

Deshalb haben wir check-gpu-clock gebaut, ein schlankes Python-Tool, das genau diese Frage objektiv beantwortet: Erreicht die GPU unter Last wirklich ihren maximalen Takt? Das Skript jagt kurze, gepulste Lastspitzen über die GPU, misst per nvidia-smi den SM-Takt dazwischen und fällt ein klares Urteil — OK, wenn der gemessene Höchstwert über 1800 MHz liegt, ALERT, wenn nicht. Für Automatisierung gedacht: Exit-Codes nach Nagios/Icinga-Konvention, damit auch ein kaputter Check (UNKNOWN) nicht mit einem echten Alarm verwechselt wird. Läuft am besten alle 30 Minuten aus dem Cron heraus, unauffällig im Hintergrund.

Was das Tool bewusst nicht mitbringt: eine fertige Benachrichtigung. Das ist Absicht — jeder überwacht anders. Wer aber, wie wir, den Alarm per Mail haben möchte, findet dafür bereits ein passendes Werkzeug aus unserem Open-Source-Regal: climb, unser Kommandozeilen-Mail-Bot. Damit haben wir die Überwachung unserer eigenen Sparks automatisiert — ein simpler Cron-Einzeiler prüft den Takt, und bei ALERT verschickt climb sofort eine Mail. Kein Dienst, kein Abo, keine Abhängigkeiten außer der Python-Standardbibliothek.

Den Code, die Konfiguration und alle Details gibt’s wie immer auf GitHub: check-gpu-clock. Apache 2.0, wie gewohnt kostenlos und frei einsetzbar. Cold Case gelöst — bis NVIDIA den Bug fixt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert