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

Arten von Treiberzweigen: New Feature, Production und Long Term Support

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.

Aktuelle Treiberzweige und ihr Supportende

NVIDIAs Tabelle der unterstützten Treiber und CUDA-Versionen (aktualisiert am 4. November 2026; die Zeile R535 aus ihrer Fassung vom 9. September 2026), seine Liste releases.json, abgerufen am 23. Oktober 2026, und die Release Notes der einzelnen Treiber, darunter die von 620.70.06 vom 4. November 2026. R535 reicht nur bis CUDA 12; die übrigen gelisteten Zweige erreichen CUDA 13 ohne Kompatibilitätspaket.

R535 hat im Juni 2026 sein Supportende erreicht. Seit ihrer Aktualisierung vom 4. November 2026 führt NVIDIAs Tabelle nur noch Long Term Support und Production Branches, weil „New Feature Branches are short-lived and do not have an end-of-life date“ (eigene Übersetzung: „New Feature Branches sind kurzlebig und haben kein Supportende“); R610 und R615 stehen deshalb nicht mehr darin. NVIDIAs Sicherheitsbulletin vom 30. September 2026 nennt als korrigierte Versionen 580.178.04 für R580 und 595.91.07 für R595, außerdem 610.57.04 für R610 und 615.71.09 für R615 aus den New Feature Branches, aber keinen Treiber für R535; bei Hosts, die noch auf R535 laufen, ist also ein Wechsel fällig. Die vom 19. bis 22. Oktober 2026 veröffentlichten Treiber sind spätere Versionen dieser Zweige, und ihre Release Notes enthalten keinen Sicherheitsabschnitt. Für einen Produktionsserver besteht die Wahl jetzt zwischen drei Zweigen: R620, dem neuesten Long Term Support Branch und dem mit der längsten veröffentlichten Laufzeit, bis September 2029; R580 mit Support bis Juni 2028; und R595, dem Production Branch mit Support bis März 2027. Die Release Notes von R580 und R595 vom Oktober 2026 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 in keiner der beiden Listen. Der einzige Unterschied bei diesen Karten, den wir gefunden haben, betrifft die RTX PRO 4500 Blackwell Server Edition, die in der Produktliste von R595 erscheint, aber nicht in der von R580. Die Release Notes von 620.70.06 führen alle hier genannten Karten, auch die RTX PRO 4500 Blackwell Server Edition, und sie sind die ersten Release Notes eines Rechenzentrumstreibers, die die RTX PRO 5500 Blackwell Workstation Edition nennen; für die RTX PRO 4500 Server Edition ist R620 damit auf Bare Metal eine Alternative zu R595, unter vGPU braucht die Karte weiterhin vGPU 20 auf R595. Alle drei Zweige liegen über den Untergrenzen, die NVIDIAs MIG-Leitfaden (aktualisiert am 4. November 2026) für MIG setzt: 575.51.03 auf der RTX PRO 6000, 575.57.08 auf der RTX PRO 5000 und 575.64 auf der RTX PRO 4500.

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.

KI-Server, die wir nach Auftrag bauen, liefern wir auf Wunsch mit bereits installiertem Treiberzweig R580 oder R595. Nennen Sie uns den Zweig Ihrer Produktionshosts, und der neue Server kommt mit demselben Zweig.

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, 13.4 zu R615 und 13.5 zu R620. Das neueste Toolkit ist CUDA 13.5 (November 2026, Treiberzweig R620; Anwendungen für 13.x laufen über die Minor-Version-Kompatibilität auf R580 oder neuer); seine Release Notes markieren Debian 12 und openSUSE Leap 15.6 als veraltet, das nächste Release streicht beide. 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. Der Leitfaden nennt keine infrage kommende RTX-SKU; planen Sie die RTX-PRO-Workstation-Karten also ohne Vorwärtskompatibilität, und testen Sie die Vorwärtskompatibilität auf dem gelieferten Server, bevor Sie sich bei der RTX PRO 6000 Server Edition darauf verlassen.

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 (aktualisiert am 4. November 2026); Release Notes des DGX Spark, Release vom Oktober 2026 (aktualisiert am 21. Oktober 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. Für die Karten in diesem Artikel ist die Blackwell-Regel wichtiger. 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 am 5. November 2026 ist der neueste Zweig, den NVIDIA listet, der Long Term Support Branch R620 mit Treiber 620.70.06 vom 4. November 2026. 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 ist auf dem Host installiert, die CUDA-Runtime kommt mit dem 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 den Versionen 26.08 und 26.09 basieren auf CUDA 13.4.1, neuer als die 13.0 und 13.2, zu denen R580 und R595 gehören, und sind auf diesen Hosts daher auf die oben beschriebenen Kompatibilitätsmechanismen angewiesen. Laut NVIDIAs Kompatibilitäts-FAQ funktionieren beide Mechanismen 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 Manager 595.91.04 mit dem Linux-Gasttreiber 595.91.07 und dem Windows-Treiber 596.86. Beide Releases beheben CVE-2026-47489 aus NVIDIAs Sicherheitsbulletin vom 30. September 2026. 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 vGPU-Release bestimmt auch, welche Karten unterstützt werden. 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. Für R620 hat NVIDIA noch kein vGPU-Release (Stand 5. November 2026), ein vGPU-Host bleibt also auf R580 oder R595.

Wenn Sie die Karten über vGPU betreiben, liefern wir die Lizenzen für vGPU und NVIDIA AI Enterprise auf derselben Rechnung wie die Hardware. Beschreiben Sie Hypervisor und vGPU-Profile im Formular unten, und wir sagen Ihnen, welche Lizenzen das Setup braucht.

DGX Spark. In den Release Notes der Rechenzentrumstreiber, die wir gelesen haben, taucht der Spark nicht auf. DGX OS bringt einen eigenen Stack mit. Sein Release vom Oktober 2026 (Release Notes aktualisiert am 21. Oktober 2026) bringt DGX OS 7.6.0 mit Treiber 580.178.04, der R580-Version aus NVIDIAs Sicherheitsbulletin vom 30. September 2026, CUDA 13.0.3 und den Linux-Kernel 7.0 und unterstützt Systeme mit 64 GB und 128 GB. NVIDIA nennt diese Versionen für die Founders Edition und weist darauf hin, dass Partnersysteme später aktualisiert werden können. NVIDIA nennt das DGX Dashboard „den primären und empfohlenen Weg, System-Updates durchzuführen“, und 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 und NVIDIAs neuestes Sicherheitsbulletin. NVIDIA veröffentlicht seine Sicherheitsbulletins seit dem 1. Oktober 2026 auf GitHub (NVIDIA/product-security); Stand 5. November 2026 ist das neueste Bulletin zum GPU-Anzeigetreiber das vom 30. September 2026, aktualisiert am 13. Oktober. 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. Die Treiber vom 21. und 22. Oktober 2026, 580.196.07 und 595.112.07, beheben einen seltenen treiberseitigen Auslöser von XID 79 auf Hosts, die nvidia-smi -q in kurzen Abständen aufrufen, sowie eine GPU-Auslastung, die nach mit SIGINT beendeten CUDA-Jobs bei 100 Prozent stehen bleibt; ein Monitoring, das nvidia-smi abfragt, ist ein Grund, sie zu installieren.

Was wir liefern

Wir liefern die L4, L40S und H200 NVL, die RTX-PRO-Blackwell-Workstation-Karten ab der RTX PRO 2000 und die RTX PRO 6000 in allen drei Editionen (Workstation, Max-Q und Server Edition), EU-weit mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Auf nach Auftrag gebauten KI-Servern installieren wir auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime, sodass der Server einsatzbereit für Ihr Team ankommt.

FAQ