Firmware-Updates am GPU-Server: vBIOS, BMC und BIOS, Herkunft und Reihenfolge

Firmware-Schichten in einem GPU-Server

Die Firmware eines GPU-Servers wird Schicht für Schicht aktualisiert: BMC, System-BIOS, vBIOS der GPUs und die Firmware von Netzwerkkarten, Laufwerken und Netzteilen. Die Serverhersteller veröffentlichen die Releases für BMC und BIOS, Dells Support-Seite führt GPU-Firmware je GPU-Modell, und NVIDIAs MIG-Leitfaden verweist bei vBIOS-Fragen an „your reseller or system provider“. Aktualisieren Sie einen Knoten nach dem anderen, ohne Last, den BMC zuerst, und stoppen Sie jede GPU-Aktivität vor einem vBIOS-Update.

Die Schichten unterscheiden sich darin, was sie steuern und wer das Release baut, das Sie einspielen.

Unsere Zusammenfassung der Quellen in den folgenden Abschnitten, gelesen am 24. Oktober 2026. NVIDIAs DGX-OS-Handbuch ordnet die ConnectX-Firmware nach Version, OPN und PSID des Adapters zu.

Es sind mehr Komponenten, als die meisten Inventarlisten zeigen. NVIDIAs Redfish-Dokumentation für die eigene DGX B300 nennt allein auf dem Mainboard-Tray den BMC, das BIOS, zwei externe Vertrauensanker (Root of Trust) dafür, zwei CPLDs, zwölf Netzteile und zwei PCIe-Switches der Generation 5 als eigene Update-Ziele. Ein PCIe-Server eines anderen Herstellers hat eine eigene Liste, die dieser Hersteller festlegt, nach demselben Prinzip: Jede Komponente hat ihre eigene Version, und das Paket des Herstellers legt fest, welche Versionen zusammengehören.

Woher jedes Update kommt

Für BMC und System-BIOS ist die Quelle der Serverhersteller. Die BMC-Firmware kann auf einer kommerziellen Basis wie AMIs MegaRAC aufbauen und das BIOS auf AMIs Aptio, aber das Release, das Sie einspielen, ist der Build des Herstellers für diese Platine. Veröffentlicht AMI einen Sicherheitshinweis, lautet die Frage an den Serverhersteller, welches seiner eigenen Releases die Korrektur enthält, wie unser Leitfaden zur Absicherung eines GPU-Servers beschreibt.

Bei PCIe-GPUs ist der Weg weniger offensichtlich, weil die Karte von NVIDIA kommt und der Server von einem anderen Hersteller. NVIDIAs MIG-Benutzerhandbuch, aktualisiert am 13. Oktober 2026, beantwortet das für vBIOS-Updates: „If a vBIOS update is needed, contact your reseller or system provider for assistance.“ Dells Support-Artikel „PowerEdge: GPU firmware update considerations“, geändert am 2. September 2026, zeigt die Seite des Serverherstellers: GPU-Firmware findet sich auf Dells Support-Seite unter dem GPU-Modell, und „For some models, the firmware update instructions are a separate download“. Das Update-Paket nennt dann seine eigenen Schritte, Neustarts und Voraussetzungen.

Die Karte selbst hat ebenfalls einen Weg außerhalb des Betriebssystems. NVIDIAs Product Brief zur RTX PRO 6000 Blackwell Server Edition, SP-12355-001_v02, sagt, die Karte „supports GPU out-of-band telemetry and firmware updates through SMBus and USB 2.0“, wie unser Beitrag zur Out-of-Band-Überwachung von GPUs über den BMC zitiert. Ob ein bestimmter BMC diesen Weg für ein Firmware-Update nutzt, steht in der Dokumentation des Serverherstellers zum Modell, nicht in NVIDIAs Brief.

Bei NVIDIAs eigenen Systemen veröffentlicht NVIDIA alles. Für die DGX B300 kommt die Firmware als Pakete für den Mainboard-Tray und den GPU-Tray und wird mit NVIDIAs Werkzeug nvfwupd aus dem NVIDIA Enterprise Support Portal eingespielt; unser Leitfaden zu DGX OS 8 auf der DGX B300 nennt die aktuellen Versionen.

Wir bauen KI-Server nach Auftrag auf Serverplattformen mit Herstellergarantie auf jede Komponente, vor der Lieferung montiert und getestet; nennen Sie uns die Server und Karten, die Sie betreiben oder planen, und unser Team antwortet innerhalb eines Werktages mit einer Konfiguration.

Versionen auslesen, bevor sich etwas ändert

Jedes Update beginnt mit einem Inventar, damit sich das Ergebnis danach vergleichen lässt und eine Karte mit abweichender Version auffällt. NVIDIAs MIG-Leitfaden liest das vBIOS mit nvidia-smi --query-gpu=vbios_version und --format=csv. Die vollständige Abfrage, nvidia-smi -q, zeigt weitere Felder; NVIDIAs Dokumentation zu nvidia-smi definiert sie.

NVIDIA-Dokumentation zu nvidia-smi (GPU-Attribute), NVIDIA MIG User Guide „Getting Started with MIG“ (aktualisiert am 13. Oktober 2026) und DMTF-Redfish-Schema UpdateService v1.17.1 (Release 2025.3), gelesen am 24. Oktober 2026.

nvidia-smi braucht den Treiber, der BMC nicht. Unter /redfish/v1/ führt das FirmwareInventory des UpdateService die Firmware, die der BMC kennt; NVIDIAs Dokumentation zur DGX B300 liest dort die Versionen ihrer Komponenten. Bei PCIe-Servern ist die Tiefe unterschiedlich: Supermicros Handbuch zum BMC der Generation X14/H14 beschreibt einen GPU-Reiter mit Modell, Seriennummer und Firmware-Version, hilfreich, wenn ein Update nur einen Teil der Karten erreicht hat. Speichern Sie beide Ansichten mit Servername und Datum. Unser Leitfaden zur Abnahmeprüfung von GPU-Servern erfasst sie bei der Lieferung und erwartet von gleichen, gemeinsam gekauften Karten gleiche Versionen, und eine defekte GPU über Bus-ID, Slot und Seriennummer finden ordnet jede Zeile einer physischen Karte zu.

Warum das vBIOS zählt: MIG, signierte Firmware, gleiche Karten

Der häufigste Anlass, das vBIOS einer GPU anzufassen, ist eine Funktion. NVIDIAs MIG-Leitfaden nennt Mindestversionen des vBIOS für drei RTX-PRO-Blackwell-Karten, zusätzlich zur Treiber-Untergrenze 575.51.03 für die RTX PRO 6000 in allen Editionen und die RTX PRO 5000.

NVIDIA MIG User Guide, „Getting Started with MIG“, aktualisiert am 13. Oktober 2026, gelesen am 24. Oktober 2026. Der Display-Modus wird mit DisplayModeSelector 1.72.0 oder neuer umgeschaltet.

Für die Server Edition und die RTX PRO 4500 nennt der Leitfaden kein Mindest-vBIOS; dort ist der Treiber die dokumentierte Voraussetzung. Bei der Workstation Edition und der Max-Q prüfen Sie das vBIOS, bevor Sie MIG darauf planen. Unsere MIG-Profile der RTX PRO 6000 zeigen, was in jede Instanzgröße passt.

Der zweite Anlass ist die Integrität. Laut NVIDIAs Product Brief zur H200 NVL prüft der CEC-Baustein der Karte den Inhalt des Firmware-ROMs, bevor die GPU davon startet („authenticates the contents of the GPU firmware ROM before permitting the GPU to boot from its ROM“), mit Schutz vor Rollback und Widerruf von Schlüsseln. Bei der DGX B300 gilt: „Secure Flash is implemented … to prevent unsigned and unverified firmware images from being flashed onto the system.“ Beziehen Sie GPU-Firmware nur vom Serverhersteller oder von NVIDIA; auf einer Karte mit diesem Schutz wird ein ROM, das die Prüfung nicht besteht, nicht gestartet.

Der dritte Anlass ist Einheitlichkeit. Ein Server, dessen acht Karten nach einem unvollständigen Update drei vBIOS-Versionen melden, erfüllt das Abnahmekriterium gleicher Versionen auf gleichen Karten nicht mehr, und der Unterschied muss vor dem nächsten Update geklärt werden.

BMC- und BIOS-Releases sind Sicherheitsupdates

CVE-2024-54085 zeigt, warum. Der NVD-Eintrag beschreibt die Lücke so: „AMI's SPx contains a vulnerability in the BMC where an Attacker may bypass authentication remotely through the Redfish Host Interface“. AMI bewertet sie mit 10,0 nach CVSS 4.0, NIST mit 9,8 nach CVSS 3.1. CISA hat sie am 25. Juni 2025 in den Known Exploited Vulnerabilities Catalog aufgenommen, mit Frist 16. Juli 2025 für US-Bundesbehörden und der Maßnahme „Apply mitigations per vendor instructions“. AMIs Sicherheitshinweise vom 8. September und 13. Oktober 2026 nennen weitere Lücken in seinem BIOS Aptio V, darunter CVE-2026-33197 mit 8,7 Punkten nach AMI.

Ein BMC in einem getrennten Managementnetz begrenzt, wer ihn erreicht, aber der Patch muss trotzdem eingespielt werden. NVIDIAs Konfigurations­leitfaden für NVIDIA-Certified Systems, aktualisiert am 30. September 2026, nennt Redfish 1.0 oder neuer und ein TPM 2.0 mit Secure Boot unter den Anforderungen; diese Server werden also ohnehin über den BMC verwaltet. Vergleichen Sie die BIOS-Konfiguration vor und nach jedem Update, wie es der Ablauf unten vorsieht; ändern sich Einstellungen zu Secure Boot, erklärt unser Leitfaden zum NVIDIA-Treiber mit Secure Boot, wie der Signaturschlüssel des Treibers vertrauenswürdig wird.

Der Redfish UpdateService

Redfish, der Management-Standard der DMTF, definiert eine standardisierte Update-Schnittstelle für BMCs. Im Schema UpdateService, Version 1.17.1 aus Release 2025.3, aktualisiert die Aktion SimpleUpdate Softwarekomponenten („updates software components“) aus einem Image, das der BMC abholt; MultipartHttpPushUri ist die URI für „a Redfish Specification-defined multipart HTTP or HTTPS push update“; die ältere HttpPushUri „has been deprecated in favor of the MultipartHttpPushUri property“. Targets ist „An array of URIs that indicate where to apply the update image“, und ForceUpdate legt fest, ob der Dienst Update-Richtlinien umgehen soll („bypass update policies“).

Die Hersteller füllen diesen Standard unterschiedlich aus. Bei der DGX B300 schickt NVIDIAs Dokumentation die Firmware-Datei an einen Upload-Endpunkt, mit einer JSON-Datei, die das Ziel nennt, und hält fest: „The DGX B300 system component firmware is only updated if the incoming firmware version is newer than the existing version.“ Um dasselbe Release erneut einzuspielen oder zurückzugehen, muss also zuerst ForceUpdate gesetzt werden. Andere Hersteller dokumentieren ihre eigenen Update-Wege je BMC-Generation; lesen Sie sie für das Servermodell, da Ziele und Paketformate abweichen.

Eine Update-Reihenfolge, bei der der Dienst weiterläuft

NVIDIA veröffentlicht für seine DGX B300 eine vollständige Abfolge, aktualisiert am 22. September 2026. Sie zeigt, wie die Schichten voneinander abhängen:

1. Die installierte Firmware mit show_version mit dem Paket vergleichen.
2. Die BMC-Konfiguration sichern, dann den BMC aktualisieren und zurücksetzen.
3. Die Komponenten des Mainboard-Trays aktualisieren; was schon auf dem Stand des Pakets ist, wird übersprungen.
4. Den GPU-Tray aktualisieren, VBIOS, NVSwitch, ERoT und FPGA parallel, nachdem jede GPU-Aktivität gestoppt ist.
5. Einen AC-Power-Cycle ausführen und die Versionen erneut auslesen.

Zwei Warnungen daraus lohnen sich auch für andere GPU-Server. GPU-Aktivität, nvidia-smi eingeschlossen, kann das VBIOS-Update blockieren, und „A high workload can disrupt the firmware update process and result in an unusable component.“ Bei einem BMC älter als 01.00.00 braucht der AC-Power-Cycle die Option zum Zurücksetzen auf Werkseinstellungen; sie setzt die BMC-Einstellungen und die Zugangsdaten auf admin/admin zurück, Adresse und Passwort des BMC müssen also sofort neu gesetzt werden.

Für einen PCIe-Server ergibt dieselbe Logik einen Ablauf je Knoten:

1. Die Release Notes des Herstellerpakets und des eingesetzten NVIDIA-Treibers lesen und gegenseitige Mindestversionen notieren.
2. Den Knoten leeren: Modelle oder Jobs auf einen anderen Knoten verlagern, wie unser Leitfaden zu hochverfügbarer LLM-Inferenz auf zwei Knoten beschreibt.
3. GPU-Workloads stoppen und alles, was die GPUs abfragt, auch dcgm-exporter und Skripte, die nvidia-smi aufrufen.
4. BMC- und BIOS-Konfiguration sowie das Inventar sichern.
5. Zuerst den BMC aktualisieren, dann BIOS und Platinenkomponenten, dann die GPUs, mit den Neustarts oder Power-Cycles, die der Hersteller nennt.
6. Das Inventar erneut auslesen, die Versionen gleicher Karten vergleichen und die BIOS-Einstellungen prüfen.
7. Den GPU-Stack zurückholen: Treiber, Leistungsgrenzen und MIG-Aufteilung, dann den Knoten wieder in Betrieb nehmen.

Schritt 7 ist nötig, weil manche Einstellungen nicht erhalten bleiben. Laut NVIDIAs Product Briefs muss eine mit nvidia-smi gesetzte Leistungsgrenze nach jedem Laden des Treibers neu gesetzt werden („must be reestablished after each new driver load“), und auf Hopper und neueren GPUs bleibt der MIG-Modus laut MIG-Leitfaden nur erhalten, „as long as the driver is resident in the system“; beides wird nach dem Neustart neu eingerichtet. Ändert sich im selben Fenster auch der Treiber, gelten die Regeln aus unserem Leitfaden zu NVIDIA-Treiberzweigen, mit dem vGPU Manager auf einem Host vor den Gasttreibern.

Eine allgemeine NVIDIA-Regel, ob auf einem PCIe-Server zuerst die Firmware oder der Treiber kommt, haben wir nicht gefunden. Bei DGX-Systemen steht die Antwort in den Release Notes des Betriebssystems, die zu jedem System ein Firmware-Release nennen; bei anderen Servern in den Hinweisen zum Herstellerpaket.

Wie oft aktualisieren

Eine Richtlinie braucht zwei Geschwindigkeiten. Sicherheitsreleases für BMC und BIOS und GPU-Firmware, die ein Hersteller als Korrektur kennzeichnet, folgen dem Sicherheitshinweis: Eine Lücke in CISAs Katalog oder eine hohe Bewertung durch AMI oder NVIDIA ist ein Grund für das nächste Wartungsfenster. Funktionsreleases, ein neueres vBIOS für MIG oder ein BIOS für eine neue Karte, kommen, wenn die Funktion gebraucht wird, und zuerst auf einen Knoten zum Test.

NVIDIAs Release Guidance zu DGX OS nennt aktuelle Software und Firmware „the most important task for protecting your DGX systems“. Der Firmware-Leitfaden zur DGX B300 führt acht Releases von 25.11.1 bis 26.09.1, was zeigt, wie oft sich eine GPU-Plattform ändert. Über eine Nutzungsdauer von fünf Jahren, wie sie unser Leitfaden zum Lebenszyklus eines GPU-Servers plant, sind das viele Wartungsfenster; wer nach jedem die Versionen je Server erfasst, hält die Flotte vergleichbar.

Was wir liefern

Sie können GPU-Server bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server nach Auftrag mit zwei bis acht GPUs, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente, und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime. Schicken Sie uns die Servermodelle und die GPU-Firmware-Versionen, die Sie sehen, und wir antworten mit einer Konfiguration für Ihre nächsten Server.

FAQ