Monitoring für HGX B300 und HGX B200
Acht GPUs je Knoten, jede einzeln: Auslastung, Speicher, Temperatur, Leistungsaufnahme und Takt. Dazu das, was einen Knoten wirklich lahmlegt: eine Karte, die fehlt, ein Treiber, der nicht mehr antwortet, Drosselung durch Hitze oder Power Cap. Alles aus nvidia-smi und dem Kernel, ohne Schätzwerte.
Ein HGX B300 wird in PeakNode als ein Server-Monitor angelegt. Der Agent auf dem Knoten liest alle acht GPUs über nvidia-smi und sendet die Werte je Karte. Das Portal zeigt den Knoten unter „GPU-Nodes" mit Aggregaten (mittlere Auslastung, Gesamtspeicher, heißeste Karte, Gesamtleistung, Karten im Leerlauf) und darunter jede GPU einzeln. Meldet der Knoten weniger Karten als erwartet oder gar nicht mehr, gibt es Alarm.
- Verifiziert am 8. Oktober 2026 auf einem 8-GPU-HGX-Knoten (H100 SXM, NVLink) und auf einer B300 SXM6 AC mit MIG, jeweils gegen nvidia-smi im selben Moment.
- Bei MIG erscheinen die Instanzen mit Profil (zum Beispiel 1g.34gb), Speicher und SM-Anzahl unter der Karte. Die Gesundheitsfelder je Karte beschreibt die Seite GPU-Server-Monitoring.
- Ein Knoten gilt nach drei ausgefallenen Messintervallen als offline, die Entwarnung kommt automatisch.
| System | Auslastung | Speicher | Temperatur | Leistung | Takt |
|---|---|---|---|---|---|
| HGX-Knoten 8× H100 80GB HBM3, Aggregat (Last auf 3 von 8 Karten) | Ø 37,5 % | 11.123 MiB / 637,2 GiB | heißeste Karte 56 °C | 2.442,1 / 5.600 W | - |
| Dieselbe Maschine, eine Karte unter Last | 100 % | 3.701 MiB / 79,6 GiB | 55 bis 56 °C | 697 bis 699 / 700 W | 1.905 bis 1.965 MHz |
| Dieselbe Maschine, eine Karte im Leerlauf | 0 % | 4 MiB / 79,6 GiB | 20 bis 26 °C | 67 bis 71 / 700 W | 345 MHz |
| NVIDIA B300 SXM6 AC mit MIG (1× 1g.34gb, 18 SM) | - (MIG liefert keine Auslastung je Instanz) | 123 / 31.232 MiB | 29 °C | 250,5 / 1.100 W | 2.032 MHz |
Was PeakNode für HGX-Betreiber löst
Bei acht Karten je Knoten zählt nicht der Mittelwert, sondern die eine Karte, die abweicht. Deshalb steht jede GPU einzeln im Portal.
Acht Karten, acht Zeilen
Auslastung, Speicher, Temperatur, Leistung, Takt je GPU, dazu die Aggregate des Knotens. Im Verlauf acht Linien in eigenen Farben, mit Datumsauswahl und Export.
Fehlende Karte, hängender Treiber
Sie hinterlegen die erwartete GPU-Anzahl. Meldet der Agent weniger, ist das ein kritisches Ereignis. Antwortet nvidia-smi nicht innerhalb des Timeouts, meldet der Agent genau das, statt zu hängen.
Xid-Ereignisse nach Schweregrad
Xid-Meldungen des Treibers aus dem Kernel-Log werden der Karte zugeordnet und nach Code eingestuft. Kritisch sind unter anderem 79 (Karte vom Bus gefallen), 48 (Double-Bit-ECC), 63 und 64 (Row Remapping), 74 (NVLink), 44 und 45 betreffen Kernel-Abbrüche und Benutzerprogramme.
Drosselgrund
Ob eine Karte wegen Hitze, Power Cap oder Hardware-Slowdown drosselt, steht als Ereignis im Portal, nach drei aufeinanderfolgenden Meldungen, damit ein kurzer Peak keinen Alarm auslöst.
Leerlauf je Karte
Jede GPU unter 5 % Auslastung zählt als Leerlauf, mit Dauer. Ein Alarm „länger als 120 Minuten im Leerlauf" zeigt gebuchte, aber ungenutzte Kapazität.
Energie in kWh und Euro
Die gemessene Boardleistung wird über die Zeit integriert: heute, dieser Monat, seit Einrichtung. Mit Ihrem Strompreis je kWh ergibt das die Energiekosten des Knotens. Bei 8 Karten mit je bis zu 1.100 W Limit, wie auf der getesteten B300, sind das bis zu 8,8 kW allein für die GPUs.
Was gemessen wird
Der Agent ist ein Shell-Skript, das per Cron läuft. Es liest nvidia-smi und den Linux-Kernel und sendet die Werte als JSON. Was eine Quelle nicht liefert, erscheint als „-", nie als Null.
| Messwert | Quelle auf dem Knoten | Takt |
|---|---|---|
| Je GPU: Auslastung, Speicher belegt und gesamt, Temperatur, Leistung und Limit, SM- und Speichertakt, Treiberversion | nvidia-smi --query-gpu, je Karte | im gewählten Intervall, ab 1 Minute |
| MIG-Instanzen: Profil, GPU-Instanz, SM-Anzahl, Speicher belegt und gesamt | nvidia-smi -q und nvidia-smi -L | im gewählten Intervall |
| Gesundheit je GPU: ECC-Fehler, Row Remapping, PCIe-Link, Drosselgründe, Prozesse mit Speicher | nvidia-smi -q und erweiterte Abfragen, sofern die Karte die Felder liefert | im gewählten Intervall |
| Xid-Ereignisse mit Code, Karte und Zeitpunkt | Kernel-Log (journalctl oder dmesg), Zuordnung über die PCI-Adresse | im gewählten Intervall, nur neue Einträge |
| Knoten: CPU-Auslastung, Lastdurchschnitt, Arbeitsspeicher, Festplatte, Netzwerk | /proc/stat, /proc/meminfo, df, /proc/net/dev, in Containern die cgroup-Grenzen | im gewählten Intervall |
| Energie: Wattstunden je Knoten aus der Boardleistung | Integration der gemessenen Leistung im Portal | fortlaufend |
Intervalle: 1, 5, 10, 15 oder 30 Minuten. Basiswerte je GPU und Aggregate sind auf H100 (8-GPU-HGX mit NVLink), B300 SXM6 AC mit MIG und RTX PRO 6000 Blackwell gegen nvidia-smi verifiziert. ECC, Row Remapping, HBM-Temperatur und Drosselgründe liefern Datacenter-GPUs, Consumer-Karten melden „N/A", das Portal zeigt dann „-".
HGX B300, HGX B200 und DGX: Was für das Monitoring gleich ist
Für den Agenten ist ein 8-GPU-Knoten ein Linux-System mit NVIDIA-Treiber. Die Unterschiede liegen in den Werten, nicht in der Einrichtung.
| System | Für das Monitoring | Hinweis |
|---|---|---|
| HGX B300 (8× B300 SXM6) | Ein Server-Monitor, acht GPU-Zeilen, MIG-Instanzen falls aktiviert | Leistungslimit der getesteten B300 SXM6 AC laut nvidia-smi: 1.100 W je Karte |
| HGX B200 (8× B200 SXM) | Ein Server-Monitor, acht GPU-Zeilen | Derselbe Treiberweg wie B300, noch nicht auf eigener Hardware gemessen |
| HGX H100 / H200 (8× SXM) | Ein Server-Monitor, acht GPU-Zeilen | H100 am 8. Oktober 2026 auf einem 8-GPU-Knoten verifiziert |
| DGX B300 / DGX B200 | Wie HGX, der Agent läuft auf DGX OS (Ubuntu-basiert) mit vorinstalliertem Treiber | Keine Besonderheit für den Agenten, siehe auch DGX Spark Monitoring |
| PCIe-Server mit 4 oder 8 Karten | Ein Server-Monitor, eine Zeile je Karte, zusätzlich Lüfterdrehzahl bei aktiv gekühlten Karten | RTX PRO 6000 Blackwell Server Edition verifiziert |
Angaben zu Speicher oder TDP der einzelnen Modelle finden Sie in den NVIDIA-Datenblättern. Hier stehen nur Werte, die der Agent selbst gemessen hat.
Einrichtung in drei Schritten
Kein Dienst, kein offener Port. Der Knoten sendet, das Portal empfängt.
Server-Monitor anlegen
Registrieren, „Server-Monitoring" öffnen, einen Monitor für den Knoten anlegen, Messintervall wählen und die erwartete GPU-Anzahl 8 eintragen.
Eine Zeile auf dem Knoten ausführen
Der Install-Befehl aus dem Portal lädt das Agent-Skript mit dem Token dieses Knotens und trägt es in die Crontab ein. Als root, damit Kernel-Log und Prozesse aller Nutzer lesbar sind.
curl -fsSL "https://peaknode.de/server-monitor-code// ?os=linux" -o peaknode.sh chmod 700 peaknode.sh && (crontab -l; echo "* * * * * /bin/bash $PWD/peaknode.sh") | crontab -
Alarme und Kanäle festlegen
Ab der ersten Meldung sehen Sie alle acht Karten. Legen Sie Schwellwerte fest (Temperatur, Speicher, Leerlauf), hinterlegen Sie den Strompreis und wählen Sie die Kanäle.
Häufige Fragen
Was es kostet
Ein HGX-Knoten ist ein Server-Monitor, egal ob mit vier oder acht GPUs. Uptime-Monitore, Heartbeats, Statusseiten und Kanäle sind in allen Tarifen enthalten.
- Server-Monitore (Knoten)3
- Uptime-Monitore5
- Heartbeats5
- Statusseiten1
- Eigene Domains für Statusseiten0
- Teammitglieder0
- Vorhaltezeit der Messwerte14 Tage
- API-Zugangnein
- Server-Monitore (Knoten)10
- Uptime-Monitore50
- Heartbeats50
- Statusseiten5
- Eigene Domains für Statusseiten1
- Teammitglieder5
- Vorhaltezeit der Messwerte365 Tage
- API-Zugangja
- Server-Monitore (Knoten)50
- Uptime-Monitore250
- Heartbeats250
- Statusseiten25
- Eigene Domains für Statusseiten5
- Teammitgliederunbegrenzt
- Vorhaltezeit der Messwerte365 Tage
- API-Zugangja
Alle Details, Zahlungsintervalle und der On-Premise-Betrieb stehen unter Tarife.
PeakNode für Ihren Anwendungsfall
Den ersten HGX-Knoten in fünf Minuten im Portal
Konto anlegen, Monitor erstellen, eine Zeile auf dem Knoten ausführen.
Jetzt starten