CUDA, Compute Capability und Treiber: Warum neue NVIDIA-GPUs plötzlich nicht mehr laufen

Wer mit CUDA, PyTorch oder eigenen GPU-Kernels arbeitet, stolpert früher oder später über dieselbe Frage: Warum läuft der Code auf der einen NVIDIA-GPU sofort — und auf der nächsten plötzlich gar nicht mehr? Die Antwort liegt fast immer im Zusammenspiel von CUDA Toolkit, Compute Capability, Treiber und Framework-Builds.

Die Fehlermeldungen sehen dabei unterschiedlich aus, meinen aber oft dasselbe: no kernel image is available for execution on the device oder NVIDIA GeForce RTX 5090 with CUDA capability sm_120 is not compatible with the current PyTorch installation. In vielen Teams beginnt an dieser Stelle die falsche Fehlersuche — Treiber werden aktualisiert, CUDA neu installiert, PyTorch mehrfach ersetzt, und das eigentliche Problem bleibt trotzdem bestehen. Dieser Beitrag sortiert die Ebenen, auf denen Kompatibilität entschieden wird, und zeigt, warum sich viele dieser Fehler auf dieselben drei Konzepte reduzieren lassen.

CUDA Toolkit, Compute Capability, Treiber: Was ist was?

Viele verwechseln drei Dinge, die zwar zusammenhängen, aber nicht dasselbe sind: CUDA Toolkit, Compute Capability und NVIDIA-Treiber. Wer diese Ebenen nicht sauber trennt, verliert bei neuen GPU-Generationen wie Ada, Hopper oder Blackwell schnell den Überblick.

Das CUDA Toolkit ist die Entwicklungsbasis

Das CUDA Toolkit ist NVIDIAs Software-Stack für GPU-Entwicklung. Dazu gehören der Compiler nvcc, die Runtime, Entwicklerwerkzeuge wie Nsight oder Compute Sanitizer sowie Bibliotheken wie cuBLAS, cuDNN, cuFFT oder cuSolver [1]. Wenn Entwickler von „CUDA 12.8" oder „CUDA 13.2" sprechen, meinen sie in der Regel genau diese Toolkit-Version — auch jene Nummer, die bei nvcc --version auftaucht. Aktueller Stand zum Zeitpunkt dieses Beitrags ist CUDA 13.2 [3].

Die Compute Capability beschreibt die GPU-Hardware

Die Compute Capability ist keine Software-Version, sondern eine Eigenschaft der GPU-Architektur. Sie definiert, welche Hardware-Funktionen und Instruktionen eine NVIDIA-GPU unterstützt [2]. Typische Beispiele: CC 7.5 für Turing, CC 8.6 für Ampere-Consumer-GPUs, CC 8.9 für Ada Lovelace, CC 9.0 für Hopper, CC 10.0 für Blackwell im Datacenter und CC 12.0 für Blackwell im Consumer-Bereich [2, 8]. In Build-Logs oder Compilern taucht diese Ebene meist als sm_75, sm_89 oder sm_120 auf [7]. Genau diese Kürzel entscheiden später darüber, ob ein Binary auf einer bestimmten GPU nativ läuft oder nicht.

Der NVIDIA-Treiber verbindet Toolkit und Hardware

Der Treiber ist die Schicht zwischen Software und GPU. Er entscheidet mit darüber, ob ein CUDA-Build auf dem System überhaupt ausgeführt werden kann. Für jede Toolkit-Version gibt es eine Mindesttreiberversion; ein neuerer Treiber kann ältere Toolkits in der Regel weiter bedienen, umgekehrt funktioniert das nicht beliebig [6].

Der Denkfehler, der ständig passiert

Besonders oft führt PyTorch in die Irre. Ein Paket wie torch==2.6.0+cu128 sieht technisch aus, wird aber regelmäßig falsch gelesen. Das cu128 bezeichnet nicht die Compute Capability, sondern die CUDA-Version 12.8, gegen die dieses Wheel gebaut wurde. Das klingt banal, ist in der Praxis aber eine der häufigsten Ursachen für falsche Diagnosen. Wer cu128 mit einer GPU-Architektur verwechselt, sucht an der falschen Stelle.

Warum manche CUDA-Binaries auf neuen GPUs laufen — und andere nicht

Der eigentliche Schlüssel zur Kompatibilität liegt in der Unterscheidung zwischen SASS und PTX. Wer diesen Unterschied verstanden hat, versteht fast alle typischen CUDA-Fehler deutlich schneller [5, 7].

SASS ist fertiger Maschinencode für genau eine Architektur

SASS ist der native GPU-Maschinencode. Er ist direkt für eine konkrete Architektur kompiliert. Ein Binary, das nur SASS für sm_89 enthält, ist auf Ada ausgelegt. Auf einer Blackwell-GPU hilft das nicht weiter — dann landet man schnell bei Fehlermeldungen wie no kernel image is available for execution on the device [5].

PTX ist der flexible Zwischencode

PTX ist eine virtuelle Zwischensprache. Der NVIDIA-Treiber kann diesen Code beim ersten Kernel-Start just in time in nativen Code für die vorhandene GPU übersetzen — vorausgesetzt, die GPU ist architektonisch kompatibel und nicht älter als die PTX-Basis [5].

Darum enthalten gute CUDA-Binaries meist beides

Produktive CUDA-Binaries enthalten häufig SASS für mehrere bekannte Architekturen und PTX als Fallback für neuere GPUs. Genau das ist der Grund, warum eine Bibliothek, die vor einer neuen GPU-Generation gebaut wurde, trotzdem noch starten kann: Der Treiber kompiliert das mitgelieferte PTX dann beim ersten Aufruf in einen passenden nativen Pfad [5]. Der Preis dafür ist ein möglicher JIT-Overhead, der gerade bei großen Bibliotheken spürbar sein kann.

Wenn man die gesamte Thematik auf einen Satz reduzieren will, dann auf diesen: Neue GPUs können alten PTX-Code oft noch ausführen. Alten SASS-Code dagegen nicht. Und ein alter Treiber kann eine neue GPU grundsätzlich nicht sauber bedienen [5, 6].

Was sm_120 wirklich bedeutet — und warum Blackwell nicht gleich Blackwell ist

Mit Blackwell ist die Namenslogik nicht einfacher geworden, im Gegenteil. Im Alltag wird oft so gesprochen, als sei „Blackwell" eine einzige Architektur. Technisch ist das zu grob.

Es gibt nicht die eine Blackwell-Plattform

Tatsächlich existieren zwei getrennte Familien: die 10.x-Familie im Datacenter mit sm_100 und sm_103 sowie die 12.x-Familie im Consumer- und Workstation-Bereich mit sm_120 und sm_121 [2, 8]. Das klingt nach einem Detail, ist aber folgenreich: Code für sm_100 läuft nicht automatisch auf einer RTX 5090 mit sm_120, obwohl beide Produkte unter dem Label Blackwell firmieren [8]. Genau hier entstehen in der Praxis viele Fehlannahmen.

Was die Suffixe a und f bedeuten

Zusätzlich zur SM-Nummer kommen inzwischen Suffixe ins Spiel: sm_120 steht für das Standardziel, sm_120a für architekturspezifische Features (nicht vorwärtskompatibel) und sm_100f für family-spezifische Kompatibilität innerhalb einer Familie [3, 7]. Gerade das a-Suffix ist in der Praxis heikel: Es aktiviert spezielle Hardware-Funktionen, opfert dafür aber Portabilität. Wer maximale Performance auf einer einzelnen Architektur will, greift manchmal genau dazu — muss dann aber mit engerer Kompatibilität leben.

Warum neue GPUs in älteren Projekten oft falsch eingeschätzt werden

Eine typische Praxisfalle sind interne Tabellen in Bibliotheken, die neue GPUs noch nicht kennen. Dann werden Architekturparameter wie Kerne pro SM falsch zugeordnet, was dazu führen kann, dass eine neue GPU zwar grundsätzlich läuft, aber deutlich schlechter performt als erwartet [11]. Wenn eine neue NVIDIA-GPU ungewöhnlich schwache Ergebnisse liefert, ist das oft kein Hardwareproblem, sondern schlicht ein Software-Stack, der die Architektur noch nicht sauber kennt.

CUDA-Versionen im Überblick: Welche Releases wirklich relevant waren

Nicht jedes CUDA-Release verändert die Praxis gleich stark. Einige Versionen markieren aber klare Brüche:

Version	Jahr	Wichtigster Punkt
6.0	2014	Unified Memory
7.5	2015	FP16-Support
8.0	2016	Pascal, NVLink
9.0	2017	Volta, Tensor Cores
10.0	2018	Turing, CUDA Graphs, RT Cores
11.0	2020	Ampere, BF16/TF32, Minor Version Compatibility
12.0	2022	Hopper, FP8
12.8	2025	Blackwell-Support mit sm_100 und sm_120
13.0	2025	Ende des Toolkit-Supports für Maxwell, Pascal, Volta
13.1	2025	Änderungen am Windows-Treiberpaket, Tile-IR
13.2	2026	Erweiterte Grouped-GEMM-API in cuBLASLt

Besonders wichtig ist hier CUDA 13.0. Dieses Release war kein normales Wartungsupdate, sondern ein Schnitt: Maxwell, Pascal und Volta wurden aus dem Toolkit entfernt [1, 3]. Wer solche GPUs noch produktiv nutzt, bleibt faktisch auf der 12.x-Linie. Für Legacy-Infrastruktur ist das keine Randnotiz, sondern eine strategische Toolchain-Entscheidung.

Warum die RTX 5090 mit PyTorch trotzdem Probleme macht

Theoretisch kann das CUDA-Toolkit eine neue Architektur längst unterstützen — praktisch heißt das noch nicht, dass jedes Framework sofort sauber nachzieht. Genau das zeigt der Fall der RTX 5090: Die GPU bringt sm_120 mit, aber viele verbreitete PyTorch-Builds enthalten diese Architektur zunächst nicht. Dann meldet PyTorch zwar die GPU, kann aber keine passenden Binaries ausführen [9, 10]. Das Ergebnis sind Inkompatibilitätsmeldungen, obwohl CUDA auf dem Papier längst bereit ist.

Was man bei neuen NVIDIA-GPUs immer prüfen sollte

Wenn ein Framework eine neue GPU nicht korrekt unterstützt, führt in der Praxis kaum ein Weg an diesen vier Prüfungen vorbei: Welche CUDA-Version steckt im Wheel? Welche sm_XX-Architekturen enthält das Build tatsächlich? Gibt es bereits Nightly-Builds mit Support? Muss das Framework aus dem Quellcode gebaut werden? Für PyTorch ist dabei besonders wichtig, vor einem Source-Build TORCH_CUDA_ARCH_LIST zu setzen — sonst kompiliert das Framework unnötig breit und die Build-Zeit explodiert [9].

CUDA-Kompatibilität in der Praxis: typische Fälle aus dem Alltag

Die eigentliche Stärke der SASS/PTX-Logik zeigt sich erst in einer Kompatibilitätsmatrix über typische Konstellationen:

Szenario	Ergebnis	Warum
CUDA 13.2 für sm_89	Läuft optimal auf RTX 4090	Native Ada-SASS
CUDA 13.2 für sm_120	Läuft optimal auf RTX 5090	Native Blackwell-SASS
CUDA 12.4 für sm_89 auf RTX 5090	Läuft via PTX-JIT	Kein nativer Blackwell-Pfad
CUDA 13.2 für sm_100 auf RTX 5090	Läuft nicht	Datacenter-Blackwell ≠ Consumer-Blackwell
Toolkit 8.0 für sm_89	Kompiliert nicht	Die Architektur war damals unbekannt
sm_89-SASS-only-Binary auf RTX 5090	Läuft nicht	Kein PTX-Fallback
sm_89-Binary mit PTX auf RTX 5090	Läuft via JIT	Erster Aufruf kann verzögert sein

Gerade die letzte Zeile ist in der Praxis entscheidend: Viele alte CUDA-Binaries sind nicht „kaputt", sondern nur darauf angewiesen, dass PTX enthalten ist. Fehlt dieses Fallback, endet die Geschichte direkt mit einem Runtime-Fehler [5].

Die sm_90a-Falle bei spezialisierten Libraries

Ein wichtiger Spezialfall sind Builds wie sm_90a, wie sie etwa in Hopper-optimierten Performance-Bibliotheken vorkommen. Diese Targets sind bewusst auf spezielle Hardware-Funktionen zugeschnitten und deshalb nicht vorwärtskompatibel [3, 7]. Wer so kompiliert, bekommt maximale Spezialisierung — aber keine automatische Zukunftssicherheit.

Checkliste: So findet man CUDA-Probleme schneller

Wenn CUDA-Code nicht startet oder eine GPU nicht sauber erkannt wird, hilft eine nüchterne Reihenfolge mehr als hektisches Neuinstallieren. Zuerst nvidia-smi prüfen: welche Treiberversion ist installiert, welche CUDA-Unterstützung meldet das System? Dann nvcc --version ausführen, um die lokale Toolkit-Version zu sehen. Danach den Framework-Status prüfen: Erkennt PyTorch die GPU, welche Compute Capability meldet es, welche Architekturen enthält das Build? Anschließend kontrollieren, dass nicht versehentlich eine CPU-Version installiert wurde. Und zuletzt die Umgebung selbst im Blick behalten — gerade bei Node-basierten Tools, ComfyUI-Setups oder experimentellen Requirements-Dateien wird ein GPU-Build oft stillschweigend überschrieben. Diese Checks klingen simpel, sparen in der Praxis aber regelmäßig Stunden.

Warum Minor Version Compatibility wichtig ist

Ein Punkt, den viele im Alltag unterschätzen: Seit CUDA 11.0 gibt es Minor Version Compatibility. Innerhalb derselben Major-Version können Binaries oft auf leicht älteren Treibern laufen, ohne dass sofort ein Upgrade nötig wird [5, 6]. Das reduziert den Druck in produktiven Umgebungen erheblich. Zwischen Major-Versionen gilt diese Erleichterung aber nicht — der Sprung von 12.x auf 13.x ist eben kein Minor-Update.

Wohin sich CUDA und die NVIDIA-Toolchain entwickeln

Für die nächsten Jahre zeichnen sich vier klare Entwicklungen ab. Erstens rückt Python in CUDA weiter in den Mittelpunkt, was vor allem für AI- und Inferenz-Workloads relevant ist und das klassische C++-Narrativ zunehmend ergänzt. Zweitens werden FP4 und NVFP4 mit Blackwell strategisch wichtig — wer an modernen AI-Kernels arbeitet, wird an diesen Formaten kaum vorbeikommen [3]. Drittens werden Family-Targets wichtiger: Die klassische Build-Logik „eine Architektur, eine SM-Zahl" wird zunehmend durch Familienlogiken ergänzt, was besonders für Blackwell relevant ist [3, 7]. Und viertens wird Legacy-Support weiter schrumpfen — nach Maxwell, Pascal und Volta ist absehbar, dass auch spätere Generationen irgendwann aus dem aktiven Toolkit-Support herausfallen [1]. Wer langfristige Hardwareflotten betreibt, muss das früh in seine Planung einrechnen.

Fazit: Die drei Regeln, die fast alle CUDA-Fehler erklären

Am Ende lässt sich die gesamte Kompatibilitätsfrage auf drei einfache Prinzipien verdichten. Neue Hardware ist meist toleranter gegenüber älterem Code als umgekehrt. SASS ist starr, PTX bringt Vorwärtskompatibilität. Compute Capability ist nicht dasselbe wie die CUDA-Version. Wer diese drei Regeln sauber auseinanderhalten kann, diagnostiziert NVIDIA-GPU-Probleme schneller, baut robustere Toolchains und spart sich viel unnötige Fehlersuche bei neuen CUDA- und Framework-Releases.

Quellen

[1] NVIDIA Developer. CUDA Toolkit Archive. https://developer.nvidia.com/cuda-toolkit-archive

[2] NVIDIA Developer. CUDA GPUs — Compute Capability. https://developer.nvidia.com/cuda/gpus

[3] NVIDIA. CUDA Toolkit 13.2 Release Notes. https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html

[4] NVIDIA. CUDA Toolkit 13.1 Release Notes. https://docs.nvidia.com/cuda/archive/13.1.0/cuda-toolkit-release-notes/index.html

[5] NVIDIA. CUDA Compatibility Guide. https://docs.nvidia.com/deploy/cuda-compatibility/index.html

[6] NVIDIA. Supported Drivers and CUDA Toolkit Versions. https://docs.nvidia.com/datacenter/tesla/drivers/supported-drivers-and-cuda-toolkit-versions.html

[7] Arnon Shimoni. Matching CUDA arch and CUDA gencode for various NVIDIA cards. https://arnon.dk/matching-sm-architectures-arch-and-gencode-for-various-nvidia-cards/

[8] NVIDIA Developer Forums. CUDA Toolkit 12.8 — what GPU is sm_120? https://forums.developer.nvidia.com/t/cuda-toolkit-12-8-what-gpu-is-sm-120/322128

[9] PyTorch GitHub. Issue #159207 — sm_120 Support. https://github.com/pytorch/pytorch/issues/159207

[10] PyTorch Forums. Is there a PyTorch build that supports NVIDIA RTX 5090 (compute capability 12.0, sm_120)? https://discuss.pytorch.org/t/is-there-a-pytorch-build-that-supports-nvidia-rtx-5090-compute-capability-12-0-sm-120/223536

[11] OpenMVS GitHub. Issue #1248 — SM 12.0 MapSMtoCores. https://github.com/cdcseacave/openMVS/issues/1248

[12] Wikipedia. CUDA. https://en.wikipedia.org/wiki/CUDA