GPU Out-of-Band Monitoring: was BMC und Redfish zeigen und was nur DCGM in-band sieht

GPU Out-of-Band Monitoring: was der BMC sieht und was nicht

GPU Out-of-Band Monitoring liest die GPUs über den Baseboard Management Controller (BMC) des Servers an dessen eigenem Management-Port aus statt über das Betriebssystem. Bei Rechenzentrumskarten erreicht der BMC die GPU über den SMBus, über NVIDIAs SMBus Post-Box Interface (SMBPBI), wo der Serverhersteller es implementiert, und die Hersteller dokumentieren Temperatur, Leistungsaufnahme der Karte und Zustandsdaten in Redfish und in ihren Webkonsolen. Vom Treiber ist dieser Pfad allerdings nicht völlig unabhängig: NVIDIAs Product Brief zur RTX PRO 6000 Server Edition sagt, dass ihr SMBPBI-Kanal für die Leistungsgrenze „außerdem voraussetzt, dass der NVIDIA-Treiber für die volle Funktionalität geladen ist“. Die Details, die einen langsamen oder abgebrochenen Job erklären, vor allem Xid-Fehler, kommen in-band vom Treiber, über nvidia-smi und NVIDIAs Data Center GPU Manager (DCGM), und sie enden, wenn der Host oder der Treiber stoppt.

Wie viel der BMC über Temperatur und Leistungsaufnahme hinaus zeigt, hängt vom Serverhersteller ab. Dells iDRAC-Telemetrie führt 40 GPU-Metriken, darunter SM-Aktivität und NVLink-Fehlerflags, während andere Hersteller für PCIe-GPUs wenig mehr als Inventar und Leistungsaufnahme dokumentieren. Ein Standort mit 2 bis 4 GPU-Servern braucht deshalb beide Pfade in einem Monitoring-System: den BMC für die Werte, die einen hängenden Host überstehen müssen, und DCGM für die Zähler, die nur der Treiber hat. Die zitierten Dokumente haben den Stand Oktober 2026.

Wie der BMC eine PCIe-GPU ausliest: SMBus und SMBPBI

Eine Rechenzentrums-GPU hat eine eigene Managementschnittstelle am SMBus. NVIDIAs Product Brief zur H200 NVL, PB-12128-001_v01 vom 11. April 2025, nennt die SMBus-Adressen 0x9E für Schreib- und 0x9F für Lesezugriffe, „SMBus direct access Supported“ und „SMBPBI (SMBus Post-Box Interface) Supported“. Von den NVIDIA-Briefs, die wir gelesen haben, nennt nur der zur RTX PRO 6000 Server Edition einen SMBPBI-Befehl, die Anforderung, die gesamte Leistungsgrenze der GPU zu setzen. Keiner nennt die Telemetriewerte, die SMBPBI zurückgibt; welche Werte die BMC-Firmware ausliest und wie sie sie darstellt, entscheidet also jeder Serverhersteller selbst.

An der Leistungsgrenze zeigt sich der Unterschied zwischen beiden Pfaden. Im Product Brief zur H200 NVL bleibt eine out-of-band über SMBPBI gesetzte Grenze „über das Laden des Treibers und Systemstarts hinweg in Kraft“, während eine in-band mit nvidia-smi gesetzte „nach jedem neuen Laden des Treibers neu festgelegt werden muss“. NVIDIA spezifiziert die H200 NVL mit mindestens 200 W und höchstens 600 W, dem Standardwert. Bei vier H200 NVL an einer begrenzten Rack-Zuleitung übersteht eine über den BMC gesetzte Grenze Treiber-Updates, während eine Grenze per nvidia-smi einen Dienst braucht, der sie bei jedem Systemstart setzt.

Der Product Brief zur L4, PB-11316-001_v01 vom 9. März 2023, nennt SMBus direct access und SMBPBI als unterstützt. Der Product Brief zur RTX PRO 6000 Server Edition, SP-12355-001_v02 vom 27. Juni 2025, nennt SMBPBI als unterstützt und sagt, die Karte „unterstützt GPU-Out-of-Band-Telemetrie und Firmware-Updates über SMBus und USB 2.0“. Er wiederholt die Formulierung zur Leistungsgrenze aus dem Brief der H200 NVL, mit einem Minimum von 300 W. Prüfen Sie für die L40S deren eigenen Brief und für jede Karte die Liste der unterstützten GPUs des Serverherstellers, bevor Sie sich auf BMC-Werte verlassen.

GPU-Daten in Redfish: Processor, EnvironmentMetrics und ProcessorMetrics

Redfish ist die REST-Schnittstelle der DMTF für das Servermanagement, und ihr Schema-Bundle 2026.2 erschien am 14. September 2026. Eine GPU erscheint als Processor-Ressource, deren ProcessorType den Wert GPU hat; das Schema bietet auch Accelerator an. Der Processor trägt Status, „den Status und Zustand der Ressource“, Throttled und ThrottleCauses sowie eine Speicherzusammenfassung mit ECCModeEnabled. Er verweist auf zwei Metrik-Ressourcen.

EnvironmentMetrics, „die Umgebungsmetriken eines Geräts“, enthält TemperatureCelsius, PowerWatts, PowerLimitWatts und EnergykWh. ProcessorMetrics, „Nutzungs- und Zustandsstatistiken eines Prozessors“, enthält BandwidthPercent, OperatingSpeedMHz, korrigierbare und nicht korrigierbare Fehlerzähler, PCIe-Fehler sowie PowerLimitThrottleDuration und ThermalLimitThrottleDuration, die Zeit, die seit dem letzten Reset gedrosselt wurde. Welche dieser Eigenschaften die BMC-Firmware füllt, entscheidet sie selbst; lesen Sie also die Processor-Ressourcen eines gelieferten Servers, bevor Sie Alarmregeln schreiben.

Redfish-Schemas Processor v1_24_0, EnvironmentMetrics v1_7_0 und ProcessorMetrics v1_7_0 (DMTF); Dell iDRAC Telemetry Reference Guide; Lenovo XCC2 REST API; Supermicro-BMC-Handbuch X14/H14 Rev. 1.1; NVIDIA Product Briefs zur H200 NVL und zur RTX PRO 6000 Server Edition; Dokumentation zu NVIDIA DCGM 4.6 und zu Xid, alle abgerufen am 10. Oktober 2026.

Was Dell, HPE, Lenovo und Supermicro für GPUs dokumentieren

Die vier Hersteller dokumentieren für PCIe-GPUs sehr unterschiedlich viel. Die Tabelle nennt nur, was das jeweilige Dokument angibt; eine Eigenschaft, die darin fehlt, kann es auf Ihrem Modell und Ihrer Firmware trotzdem geben.

Dell iDRAC Telemetry Reference Guide (GPU Metrics, GPU Statistics) und README zu Dells iDRAC-Telemetry-Reference-Tools; HPE-iLO-6-Redfish-Changelog bis v1.79; Lenovo XCC2 REST API, GET GPU PowerLimit properties; Supermicro-BMC-Handbuch X14/H14, Revision 1.1, 22. Dezember 2025. Abgerufen am 10. Oktober 2026.

Dells Referenz nennt weit mehr GPU-Werte als die Dokumente der anderen drei. Sein Bericht GPU Metrics enthält GPUResetRecommendedState, beschrieben als „Ein Flag, das anzeigt, ob ein GPU-Reset empfohlen wird“, PowerBrakeState, ThermalAlertState, Zähler für korrigierbare PCIe-Fehler und NVLink-Fehlerbits je Link. GPU Statistics zählt Einzelbit- und Doppelbitfehler je Speicherbereich und die deswegen stillgelegten Speicherseiten. Telemetrie, gestreamt oder abgefragt, braucht die iDRAC-Lizenz „Datacenter“; nehmen Sie sie also in die Bestellung auf. Dells Leitfaden sagt nicht, wie iDRAC diese Werte erfasst.

Lenovos XCC2 dokumentiert die GPU-Leistung als Redfish-Control: GPU{N}_PowerLimit liest den Sensor GPU{N}_Power und nimmt einen Sollwert in Watt an, ohne die Platinum-Lizenz ausgeblendet. Der Changelog von HPEs iLO 6 fügt in v1.61 EnvironmentMetrics und ProcessorMetrics für Prozessoren hinzu. Seine Einträge zu GPUs nennen einen NVLink-Status zwischen CPU und GPU und die Werte GPU1 und GPU2 in zwei Leistungsschemas, aber keine GPU-Modelle; fragen Sie HPE also bei einer PCIe-Karte, welche Eigenschaften Ihr Modell füllt. Supermicros Handbuch zu X14/H14 dokumentiert einen Inventar-Reiter für GPUs mit Firmware-Versionen, nützlich, wenn ein Update nur einen Teil der Karten erreicht.

Wir bauen KI-Server nach Auftrag mit Out-of-Band-Management über IPMI und den BMC. Nennen Sie uns den bevorzugten Serverhersteller und das Monitoring-System, das den BMC auslesen soll.

Xid-Fehler, ECC-Details und NVLink: der In-Band-Pfad

NVIDIA definiert die Xid-Meldung in seiner Xid-Dokumentation, aktualisiert am 9. September 2026, als „einen Fehlerbericht des NVIDIA-Treibers, der in das Kernel-Log oder Ereignisprotokoll des Betriebssystems geschrieben wird“. Einen Xid gibt es nur dort, wo der Treiber läuft; er gelangt also über das Kernel-Log oder DCGM ins Monitoring-System. DCGM selbst arbeitet über NVML, die Managementbibliothek des Treibers: Seine Dokumentation zu 4.6 beschreibt, wie dcgmDetachDriver „NVML von DCGM trennt“. Stoppt der Treiber, stoppt auch der In-Band-Pfad.

In-band liefern nvidia-smi und DCGM die vollen Details hinter einem GPU-Reset, einem geleerten Knoten oder einem Garantiefall: Xid-Codes, flüchtige und aggregierte ECC-Zählerstände, Row Remapping, Clock Event Reasons je Abtastung sowie NVLink-Replay- und CRC-Zähler. Dells Telemetrie meldet einen Teil davon out-of-band, mit Zählern für Einzelbit- und Doppelbitfehler alle 600 Sekunden, Bits für Clock Event Reasons und NVLink-Fehlerbits, aber keines der BMC-Dokumente, die wir gelesen haben, nennt Row Remapping oder Xid-Codes. Unser Leitfaden zu DCGM-Metriken und XID-Fehlern behandelt die Felder und die Standardwerte von dcgm-exporter, und die Referenz der NVIDIA-Xid-Fehlercodes listet die Codes mit NVIDIAs Maßnahmen. Für eine Karte, die der Treiber nicht mehr erreicht, lesen Sie unseren Artikel zu Xid 79, einer GPU, die vom Bus gefallen ist, und bewahren Sie die BMC-Werte für diesen Steckplatz als zweiten Nachweis für den Garantiefall auf.

Die beiden Pfade unterscheiden sich auch darin, was während einer Wartung weiterläuft. Ein Treiber-Update entlädt das Modul, und dcgm-exporter meldet nichts, bis es wieder geladen ist. Der BMC läuft weiter, aber keines der Dokumente oben sagt, welche GPU-Werte er ohne Treiber noch ausliest; prüfen Sie das also beim ersten Treiber-Update. Inferenz-Latenz, Warteschlangenlänge und KV-Cache-Nutzung liegen noch eine Ebene höher, in der Serving-Engine, wie unser Leitfaden zum LLM-Monitoring erklärt.

BMC-Alarme an das Monitoring-System weiterleiten

Redfish bietet zwei Wege, Daten aus dem BMC zu holen, ohne jede Ressource abzufragen. Der EventService „enthält Eigenschaften zur Verwaltung von Ereignisabonnements und erzeugt die Ereignisse, die an Abonnenten gesendet werden“; jedes Abonnement ist ein Ereignisziel, und der Dienst kann auch einen Server-Sent-Events-Stream und die Zustellung per SMTP anbieten. Der TelemetryService „dient dem Erfassen und Melden von Metrikdaten innerhalb des Redfish-Dienstes“, mit Definitionen von Metrikberichten und Metrikberichten; Dells GPU Metrics und GPU Statistics sind solche Berichte. Ältere Schnittstellen bleiben bestehen, und Supermicros Handbuch zu X14/H14 führt Alarme, SNMP, Syslog und SMTP unter seinen Benachrichtigungseinstellungen.

Für wenige Server genügt ein Collector je Standort, der die Ereignisse jedes BMC abonniert und die Ressourcen für GPU-Temperatur und Leistungsaufnahme abfragt. Versehen Sie jede Zeitreihe mit Server, Steckplatz und Seriennummer der Karte, damit ein BMC-Alarm und ein DCGM-Alarm zur selben Karte in einem Vorfall zusammenlaufen. Der BMC gehört in ein isoliertes Verwaltungsnetz, das nur der Collector und ein Jump-Host erreichen; unser Leitfaden zum Absichern eines GPU-Servers behandelt dieses Netz und die BMC-Firmware.

Beide Pfade auf 2 bis 4 GPU-Servern einrichten

Als Beispiel dienen drei Server mit je acht Karten der RTX PRO 6000 Server Edition und einer mit vier H200 NVL, zusammen 28 GPUs. Wären das Dell-Modelle mit der Lizenz „Datacenter“, würde allein der Bericht GPU Metrics nach unserer Rechnung 40 Werte je GPU liefern, 1.120 für den Standort, die meisten davon alle 5 Sekunden. Die folgende Reihenfolge richtet beide Pfade ein und prüft, was jeder meldet.

1. Schließen Sie jeden BMC an das Verwaltungsnetz an, aktualisieren Sie seine Firmware auf das aktuelle Release des Herstellers und gleichen Sie das angezeigte GPU-Inventar mit nvidia-smi -q ab.
2. Lesen Sie auf einem Server die Processor-Ressourcen vom Typ GPU und notieren Sie, welche Eigenschaften von EnvironmentMetrics und ProcessorMetrics er füllt.
3. Lassen Sie den Collector die Redfish-Ereignisse jedes BMC abonnieren, oder richten Sie SNMP oder Syslog ein, wo Redfish-Ereignisse nicht verfügbar sind.
4. Fragen Sie GPU-Temperatur und Leistungsaufnahme out-of-band ab und setzen Sie die Schwellwerte nach der Slowdown-Temperatur und der Leistungsgrenze jeder Karte.
5. Installieren Sie dcgm-exporter in-band, leiten Sie das Kernel-Log für Xid-Zeilen weiter und ergänzen Sie die Felder für ECC, Row Remapping und NVLink, die Ihre Karten unterstützen.
6. Entladen Sie in einem Wartungsfenster auf einem Server den NVIDIA-Treiber, notieren Sie, welche GPU-Werte der BMC noch meldet, und prüfen Sie, dass ein Test-Temperaturalarm von ihm ankommt; laden Sie dann den Treiber und prüfen Sie, dass auch ein In-Band-Testalarm ankommt.
7. Halten Sie schriftlich fest, welcher Pfad für welchen Alarm zuständig ist, damit jeder, der einen Alarm bearbeitet, weiß, wo er zuerst nachsehen muss.

Unsere KI-Server werden vor dem Versand montiert und im Burn-in getestet, mit Testbericht auf Wunsch. Schicken Sie uns die geplanten Karten und die Zahl der Server über das Formular unten, und wir antworten innerhalb eines Werktages mit einer Konfiguration und einem Angebot.

Was wir liefern

Wir bauen KI-Server nach Auftrag mit Out-of-Band-Management über IPMI und den BMC, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung. Die Karten in diesem Artikel stammen aus unserem GPU-Sortiment: die H200 NVL mit NVLink-Brücken, die RTX PRO 6000 Server Edition, die L40S und die L4. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch, und den Support für die Karten übernimmt das Serviceteam unseres Engineering-Partners. Wenn Ihr Monitoring eine BMC-Funktion nutzt, die eine Lizenz braucht, etwa Dells iDRAC-Lizenz „Datacenter“ für die Telemetrie, nennen Sie sie in Ihrer Anfrage.

FAQ