NVIDIA-Treiberzweige und CUDA-Versionen für GPU-Server: welcher Treiber laufen sollte und warum

Drei Arten von Treiberzweigen

Seit 2019 organisiert NVIDIA seinen Treiber für Rechenzentrums-GPUs nach einem Enterprise-Lebenszyklus mit drei Arten von Zweigen, und die Wahl zwischen ihnen entscheidet, wie oft ein Server einen neuen Treiber braucht. Ein New Feature Branch ist nach NVIDIAs Worten „für Early Adopters gedacht, die neue Funktionen evaluieren wollen (zum Beispiel neue CUDA-APIs)“: Mindestens alle drei Monate erscheint ein neuer, und NVIDIAs Lebenszyklustabelle sagt ihm keinen festen Supportzeitraum zu. Ein Production Branch ist „für den Produktionseinsatz mit Enterprise-/Rechenzentrums-GPUs qualifiziert“: Jedes Jahr erscheinen zwei, und jeder erhält ein Jahr lang vierteljährlich oder nach Bedarf Bugfix- und Sicherheits-Releases. Ein Long Term Support Branch ist ein Production Branch, der drei Jahre lang gepflegt wird, und NVIDIA legt mindestens einmal je Hardwarearchitektur einen solchen auf.

Das sind nicht die Softwarezweige von NVIDIA AI Enterprise, die einem eigenen Kalender mit eigenen Enddaten folgen; diese behandelt unser Leitfaden zur Lizenzierung.

Welche Zweige aktuell sind

NVIDIAs Tabelle der unterstützten Treiber und CUDA-Versionen (aktualisiert am 9. September 2026), seine Liste releases.json und die Release Notes der einzelnen Treiber. R535 reicht nur bis CUDA 12; die übrigen gelisteten Zweige erreichen CUDA 13 ohne Kompatibilitätspaket.

R535 hat im Juni 2026 sein Supportende erreicht, bei Hosts, die noch darauf laufen, ist also ein Wechsel fällig, und dieselbe Tabelle zeigt für R610 das Supportende im August 2026. Für einen Produktionsserver besteht die Wahl zwischen R580 mit der längsten veröffentlichten Laufzeit und R595, der neuer ist und bis März 2027 unterstützt wird. Die Release Notes beider führen die RTX PRO 6000 in allen drei Editionen, die RTX PRO 5000 mit 48 und 72 GB, die RTX PRO 4500, 4000, 4000 SFF und 2000, die L40S, die L4 und die H200 NVL; die RTX PRO 5500 steht noch in keiner der beiden Listen. Einen Unterschied haben wir gefunden: Die RTX PRO 4500 Blackwell Server Edition erscheint in der Produktliste von R595 und nicht in der von R580. Beide Zweige liegen über Treiber 575.51.03, der Untergrenze, die NVIDIAs MIG-Leitfaden für MIG auf der RTX PRO 6000 und 5000 setzt.

Ein New Feature Branch gehört auf eine Testmaschine, die eine CUDA-Funktion braucht, bevor diese einen Production Branch erreicht. NVIDIA veröffentlicht für ihn keinen Supportzeitraum, und er ist kein unterstütztes Ziel für die Vorwärtskompatibilität von CUDA.

Wie die CUDA-Kompatibilität funktioniert

Zur Laufzeit treffen zwei Teile aufeinander. Das Treiberpaket enthält die Kernelmodule und den CUDA-Treiber für den User-Mode, libcuda.so; die CUDA-Runtime und die Bibliotheken kommen mit dem Toolkit und damit mit der Anwendung oder ihrem Container. Nach NVIDIAs Worten funktionieren neue Treiber „immer mit (Anwendungen, kompiliert mit) einem älteren CUDA-Toolkit“, sofern die Anwendung Code mitbringt, den die GPU ausführen kann. Die CUDA-Nummer, die nvidia-smi ausgibt, gehört zum Treiber: NVIDIAs Dokumentation nennt sie inzwischen CUDA UMD Version, „die neueste vom Treiber unterstützte CUDA-Version“, meist, aber nicht immer dieselbe wie beim installierten Toolkit. Jedes Minor-Release von CUDA gehört zu einem Treiberzweig: 13.0 zu R580, 13.1 zu R590, 13.2 zu R595, 13.3 zu R610 und 13.4 zu R615. Seit CUDA 13.4 liegt der Linux-Treiber dem Toolkit nicht mehr bei.

Die Minor-Version-Kompatibilität lässt eine Anwendung, die mit einem beliebigen 13.x-Toolkit gebaut wurde, auf Treiber 580 oder neuer laufen und eine 12.x-Anwendung auf Treibern von 525 bis unter 580, „mit eingeschränktem Funktionsumfang“; wo der Treiber neuer ist als das Toolkit, gilt die gewöhnliche Abwärtskompatibilität, und diese Einschränkungen gelten nicht. NVIDIA benennt die Einschränkungen: Anwendungen, die Gerätecode zu PTX kompilieren, „funktionieren nicht mit älteren Treibern“, Funktionen, die den neueren Treiber brauchen, liefern cudaErrorCallRequiresNewerDriver zurück, und der Build muss die reale Architektur angeben, zum Beispiel mit nvcc -arch=sm_xx. Eine Anwendung für CUDA 13.4 kann also auf einem Host mit R580 laufen, wenn sie kompilierten Code für die GPU mitbringt und Funktionen meidet, die den neueren Treiber brauchen.

Die Vorwärtskompatibilität geht weiter. Das Paket, zum Beispiel per apt install cuda-compat-13-4, legt die neueren Treiberbibliotheken in ein versioniertes Verzeichnis, /usr/local/cuda-13.4/compat, das Anwendungen über LD_LIBRARY_PATH finden. NVIDIA dokumentiert die Vorwärtskompatibilität nur für „NVIDIA Data Center GPUs“, „Select NGC Server Ready SKUs of RTX cards“ und Jetson-Boards, stellt fest, dass New Feature Branches keine unterstützten Ziele sind, und auf Hardware, die sie nicht nutzen kann, liefert CUDA den Fehler 804. Die H200 NVL, die L40S und die L4 erfüllen die Voraussetzungen. Für die RTX-PRO-Workstation-Karten nennt der Leitfaden keine infrage kommende SKU, planen Sie also ohne Vorwärtskompatibilität.

Compute Capability und das erste CUDA-Release dafür

NVIDIAs Liste der CUDA-GPUs und seine Matrix aus CUDA-Toolkit, Treiber und Architektur; Release Notes von CUDA 11.8 (Ada und Hopper), 12.8 (SM_120) und 12.9 (sm_121); Product Briefs von NVIDIA; das MIG-Benutzerhandbuch; Release Notes des DGX Spark, Release vom Juli 2026. NVIDIA hat kein Toolkit für CUDA 12.7 veröffentlicht: Sein Archiv springt von 12.6 auf 12.8, und sein Xid-Katalog ordnet CUDA 12.7 dem Treiber R565 zu. Für Hopper nennt die Architekturmatrix zwei Einträge, CUDA 11.8 und CUDA 12.0.

CUDA 13.0 hat die Offline-Kompilierung und die Bibliotheksunterstützung für Maxwell, Pascal und Volta entfernt und unterstützt nach NVIDIAs Worten „alle NVIDIA-Architekturen von Turing bis Grace Blackwell“. Keine der oben genannten Karten ist betroffen; eine Flotte, in der noch Volta-Karten laufen, behält für sie ein 12.x-Toolkit, und NVIDIAs Architekturmatrix nennt R580 als letzten Treiberzweig für Maxwell, Pascal und Volta. In der Praxis wichtiger ist die Blackwell-Regel. NVIDIAs Kompatibilitätsleitfaden sagt, Binaries mit PTX „sollten unverändert auf den Blackwell-GPUs funktionieren“, während Binaries, die nur Cubins für ältere Architekturen mitbringen, „neu gebaut werden müssen“; PTX, das für ein architekturspezifisches Ziel wie compute_90a gebaut wurde, wird auf Blackwell ebenfalls nicht unterstützt. Der vom Leitfaden beschriebene Test besteht darin, die Anwendung mit CUDA_FORCE_PTX_JIT=1 auszuführen, was den eingebetteten Binärcode ignoriert und stattdessen das PTX kompiliert: Läuft die Anwendung so einwandfrei, ist sie Blackwell-kompatibel. Entfernen Sie die Variable danach wieder.

Offene Kernelmodule und Pinning des Zweigs

NVIDIA formuliert es seit Juli 2024 unmissverständlich: „Für hochmoderne Plattformen wie NVIDIA Grace Hopper oder NVIDIA Blackwell müssen Sie die Open-Source-GPU-Kernelmodule verwenden. Die proprietären Treiber werden auf diesen Plattformen nicht unterstützt.“ Die offenen Module funktionieren auf jeder GPU ab Turing, NVIDIA hat sie zur selben Zeit für Ada und Hopper empfohlen, und ab R560 installieren NVIDIAs Installationsmethoden sie im Allgemeinen standardmäßig. R615 hat den Umstieg für Paketinstallationen abgeschlossen. In seinen Release Notes heißt es: „Die Paketinstallation der proprietären Kernelmodul-Variante ist veraltet und wird ab 615 nicht mehr bereitgestellt“, und der Installationsleitfaden vom 23. September 2026 nennt die offenen Module „die einzige bereitgestellte Kernelmodul-Variante“.

Unter Ubuntu mit NVIDIAs Repository wird der Treiber mit apt install nvidia-open installiert. Zweig 590 hat die Paketierung geändert: Die Paketnamen tragen den Zweig nicht mehr, und nach NVIDIAs Worten wird „das Standardverhalten sein, das System auf die neuesten Treiber zu aktualisieren“, wobei die Bindung an einen Zweig ein Opt-in ist. Ein Server ohne Pinning auf den umbenannten Paketen wechselt daher beim nächsten Upgrade auf den neuesten Zweig in NVIDIAs Repository, und im September 2026 ist der neueste Treiber, den NVIDIA listet, 615.71.09 aus einem New Feature Branch. Installieren Sie, wie NVIDIA vorschlägt, vor dem Treiber das Pinning-Paket für den Zweig, zum Beispiel nvidia-driver-pinning-580 für R580. NVIDIA ergänzt, dass unter Ubuntu bis einschließlich Zweig 580 die Pakete „den Verweis auf den Zweig noch im Paketnamen tragen“ und dass ein Wechsel des Zweigs durch Installieren, Upgrade oder Downgrade von Treiberpaketen nur ab 590 unterstützt wird.

Container, vGPU und der DGX Spark

Container. Der Treiber liegt auf dem Host, die CUDA-Runtime im Image. Das NVIDIA Container Toolkit erwartet den NVIDIA-Treiber auf dem Host, sein Runtime-Hook bindet die GPU-Geräte in jeden Container ein, und NVIDIAs eigener Test führt nvidia-smi in einem einfachen Ubuntu-Image aus. Über die CUDA-Version entscheidet also das Image. NVIDIAs PyTorch-Container in der Version 26.08 basiert auf CUDA 13.4.1, neuer als die 13.0 und 13.2, zu denen R580 und R595 gehören, und ist auf diesen Hosts daher auf die oben beschriebenen Kompatibilitätsmechanismen angewiesen; laut NVIDIAs Kompatibilitäts-FAQ funktionieren beide mit seinen Framework-Containern und mit Images, die auf seinen offiziellen CUDA-Basis-Images aufbauen.

vGPU. Auf einem Virtualisierungshost kommt der Treiber stattdessen aus dem Release der vGPU-Software, und jedes Release kombiniert einen vGPU Manager für den Host mit Gasttreibern: vGPU 19.6 auf R580 kombiniert Manager 580.178.05 mit dem Linux-Gasttreiber 580.178.04 und dem Windows-Treiber 582.78; vGPU 20.2 auf R595 kombiniert 595.91.04 mit 595.91.07 und 596.86. Ein Manager aus einem späteren Zweig akzeptiert Gasttreiber aus dem vorherigen Zweig, aber mit einem Gasttreiber aus einem späteren Zweig als seinem eigenen „schlägt das Laden der NVIDIA vGPU fehl“, der Host kommt also zuerst. Das Release entscheidet auch über die Karten: Die vGPU-Unterstützung beginnt mit 19.0 für die RTX PRO 6000 Server Edition, mit 20.0 für die RTX PRO 4500 Server Edition und mit 20.2 für die RTX PRO 5000 mit 72 GB, die NVIDIA nur unter Red Hat Enterprise Linux mit KVM 9.6 unterstützt.

DGX Spark. In den Release Notes der Rechenzentrumstreiber, die wir gelesen haben, taucht der Spark nicht auf. DGX OS bringt einen eigenen Stack mit, im Release vom Juli 2026 Treiber 580.159.03 mit CUDA 13.0.2, und NVIDIA nennt das DGX Dashboard „den primären und empfohlenen Weg, System-Updates durchzuführen“. Unser Leitfaden zum ersten Tag mit dem DGX Spark zeigt, wo es zu finden ist.

Checkliste für das nächste Treiber-Update

Lesen Sie die Release Notes genau dieser Version. Vergewissern Sie sich, dass jede Karte im Server in ihrer Produktliste steht, und lesen Sie die bekannten Probleme.

Prüfen Sie die Images gegen den Treiber. Listen Sie die CUDA-Version jedes Container-Images auf und vergleichen Sie sie mit der CUDA UMD Version, die der neue Treiber meldet. Ein Image, das neuer ist als der Treiber, ist auf die Minor-Version-Kompatibilität angewiesen oder, auf Rechenzentrums-GPUs, auf die Vorwärtskompatibilität.

Erst pinnen, dann installieren. Installieren Sie unter Ubuntu das Pinning-Paket für den Zweig vor dem Treiber, damit ein routinemäßiges Upgrade den Server nicht auf einen anderen Zweig bringen kann.

Bleiben Sie bei den offenen Modulen. Auf Blackwell sind sie die einzige unterstützte Wahl, und ab R615 sind sie die einzige Variante, die NVIDIA paketiert.

Aktualisieren Sie vGPU-Hosts zuerst. Nehmen Sie vGPU Manager und Gasttreiber aus demselben vGPU-Release und installieren Sie den Host vor den Gästen.

Setzen Sie neu, was ein Neuladen des Treibers löscht. Laut NVIDIAs Product Brief zur H200 NVL muss eine mit nvidia-smi gesetzte Leistungsgrenze „nach jedem erneuten Laden des Treibers neu gesetzt werden“; nur die Out-of-Band-Einstellung über SMBPBI bleibt erhalten. Prüfen Sie auf RTX-PRO-Karten im MIG-Modus das Instanz-Layout, bevor die GPUs wieder in Betrieb gehen, wie unser MIG-Leitfaden beschreibt.

Beobachten Sie die ersten Tage. Vergewissern Sie sich, dass DCGM weiterhin jede GPU sieht und keine neuen XID-Meldungen im Kernel-Log erscheinen; unser Monitoring-Leitfaden listet die, auf die es ankommt.

Was wir liefern

Eurokommerz liefert RTX-PRO-Blackwell-Karten von der RTX PRO 2000 bis zur RTX PRO 6000 Workstation Edition und Max-Q sowie die L4, L40S und H200 NVL, EU-weit mit Herstellergarantie. Nach Auftrag gebaute KI-Server können auf Wunsch mit dem Betriebssystem, dem Treiberzweig, CUDA und der Container-Runtime Ihrer Wahl vorinstalliert geliefert werden. Nennen Sie uns die Karten und die Container, und wir nennen Ihnen den Zweig vor der Bestellung.

FAQ