CUDA-Kompatibilität
Wer eine Grafikkarte für Berechnungen nutzt, braucht ein Zusammenspiel aus Treiber, Softwarebibliothek und Hardware-Generation. Stimmt eine Komponente nicht, läuft die Berechnung nicht. Dieses Zusammenspiel heißt CUDA-Kompatibilität.
CUDA ist die Programmierschnittstelle von NVIDIA, die es ermöglicht, allgemeine Berechnungen auf Grafikkarten auszuführen. CUDA-Kompatibilität bezeichnet die Anforderung, dass vier Schichten aufeinander abgestimmt sein müssen: die GPU-Hardware, der installierte NVIDIA-Treiber, die CUDA-Laufzeitbibliothek und das darauf aufbauende ML-Framework wie PyTorch. Fehlt die Abstimmung an einer Stelle, schlägt die GPU-beschleunigte Berechnung fehl.
Wie Treiber und CUDA-Version zusammenhängen
Jede CUDA-Version setzt eine bestimmte Mindesttreiberversion voraus. CUDA 12.0 erfordert mindestens Treiberversion 525.60.13 unter Linux. Ein älterer Treiber kann eine neuere CUDA-Version nicht bedienen. In umgekehrter Richtung funktioniert es: Ein aktueller Treiber unterstützt in der Regel alle älteren CUDA-Versionen. NVIDIA nennt das Vorwärtskompatibilität.
Beispiel: Ein Server hat Treiberversion 510.47 installiert. Ein Team will CUDA 12.2 nutzen, das Treiberversion 535.54 verlangt. Der Versuch, ein CUDA-12.2-Programm zu starten, erzeugt die Fehlermeldung CUDA driver version is insufficient for CUDA runtime version. Erst nach dem Treiber-Update auf 535.x startet das Programm.
Beispiel: Ein Rechenzentrum aktualisiert den Treiber auf Version 550. Alle bestehenden Anwendungen, die mit CUDA 11.7, 11.8 und 12.0 kompiliert wurden, laufen weiter. Der neue Treiber ist abwärtskompatibel zu diesen älteren CUDA-Versionen.
Der Befehl nvidia-smi zeigt in der rechten oberen Ecke die höchste CUDA-Version an, die der installierte Treiber unterstützt. Das ist nicht die aktuell installierte CUDA-Toolkit-Version, sondern die Obergrenze. Der Befehl nvcc --version zeigt die tatsächlich installierte Toolkit-Version.
Fachliche Einordnung: Die Unterscheidung zwischen Treiber-CUDA-Version (Driver API) und Toolkit-CUDA-Version (Runtime API) ist eine häufige Fehlerquelle. nvidia-smi zeigt die Driver API Version. nvcc --version zeigt die Runtime API Version. Beide können sich unterscheiden, solange die Driver API Version größer oder gleich der Runtime API Version ist.
Hardware-Generationen und Compute Capability
Jede NVIDIA-GPU-Generation besitzt eine Kennung, die beschreibt, welche Rechenoperationen die Hardware unterstützt. NVIDIA nennt diese Kennung Compute Capability. Sie besteht aus einer Haupt- und einer Nebenversionsnummer. Die Hauptversion steht für die Architektur-Generation, die Nebenversion für Erweiterungen innerhalb dieser Generation.
Beispiel: Eine NVIDIA A100 hat Compute Capability 8.0 (Ampere-Architektur). Eine H100 hat Compute Capability 9.0 (Hopper-Architektur). Die A100 unterstützt Features wie FP16 Tensor-Core-Operationen. Die H100 kann zusätzlich FP8-Operationen in Hardware ausführen.
Beispiel: CUDA 12.0 hat den Support für GPUs mit Compute Capability 3.5 (Kepler-Architektur, ca. 2013) eingestellt. Wer eine GeForce GTX 780 besitzt, muss bei CUDA 11.x bleiben oder die Karte ersetzen.
Die Compute Capability bestimmt auch, welche Optimierungen ein Compiler anwenden kann. Code, der für Compute Capability 8.0 kompiliert wurde, nutzt Ampere-spezifische Instruktionen und läuft nicht auf einer Volta-GPU mit Compute Capability 7.0. Der CUDA-Compiler nvcc kann Code gleichzeitig für mehrere Compute Capabilities kompilieren. Das Ergebnis ist eine sogenannte Fat Binary, die Maschinencode für jede Zielarchitektur enthält.
Frameworks und ihre CUDA-Abhängigkeiten
ML-Frameworks wie PyTorch werden in vorkompilierten Varianten für bestimmte CUDA-Versionen ausgeliefert. Die Wahl der richtigen Variante ist entscheidend. Eine PyTorch-Installation, die gegen CUDA 11.8 kompiliert wurde, funktioniert nicht mit einer CUDA-12.1-Laufzeitumgebung.
Beispiel: Die offizielle PyTorch-Installationsseite bietet ein Auswahlmenü, in dem die CUDA-Version angegeben wird. Für CUDA 12.1 lautet der Installationsbefehl pip install torch --index-url https://download.pytorch.org/whl/cu121. Für CUDA 11.8 lautet er pip install torch --index-url https://download.pytorch.org/whl/cu118. Wählt man die falsche Variante, startet das Training nicht.
Beispiel: Ein Deep-Learning-Projekt verwendet PyTorch 2.1 mit CUDA 11.8. Das Team will auf PyTorch 2.3 mit CUDA 12.4 wechseln. Dafür muss zuerst der Treiber auf mindestens Version 550 aktualisiert werden. Dann wird das neue CUDA-Toolkit installiert. Erst danach wird PyTorch in der passenden Variante installiert. Die Reihenfolge ist zwingend: Treiber, dann CUDA-Toolkit, dann Framework.
Neben PyTorch benötigen auch Bibliotheken wie cuDNN (CUDA Deep Neural Network Library) eine zur CUDA-Version passende Fassung. cuDNN beschleunigt Standardoperationen wie Faltungen und Matrixmultiplikationen auf der GPU. Eine Versionsabweichung zwischen CUDA und cuDNN führt zu Laufzeitfehlern oder stillen Leistungseinbußen.
Die Kompatibilitätskette als Gesamtbild
CUDA-Kompatibilität betrifft nie eine einzelne Schicht, sondern eine vollständige Kette. Jede Schicht hängt von der darunterliegenden ab. Wenn eine Schicht aktualisiert wird, müssen alle darüberliegenden Schichten auf Verträglichkeit geprüft werden.
Die Pfeile zeigen die Abhängigkeitsrichtung: Das Framework hängt von cuDNN ab, cuDNN vom Toolkit, das Toolkit vom Treiber, der Treiber von der Hardware. Ein Update an der untersten Schicht (z.B. neue GPU) kann alle darüberliegenden Schichten beeinflussen.
Beispiel: Ein Unternehmen tauscht Tesla V100 (Compute Capability 7.0) gegen A100 (Compute Capability 8.0) aus. Der bestehende Treiber 450.x unterstützt die A100 nicht. Also wird der Treiber auf 525.x aktualisiert. Damit steigt die maximal unterstützte CUDA-Version von 11.0 auf 12.0. Das Team kann nun entscheiden, ob es bei CUDA 11.8 bleibt (läuft weiterhin) oder auf 12.x wechselt.
CUDA-Kompatibilität in Containern
In containerisierten Umgebungen wird die CUDA-Kompatibilität auf besondere Weise gehandhabt. Der NVIDIA-Treiber läuft auf dem Host-System. Der Container enthält das CUDA-Toolkit und die Anwendung. Die Containerisierung entkoppelt die Toolkit-Version von der Host-Installation, aber der Treiber auf dem Host muss weiterhin zur CUDA-Version im Container passen.
Beispiel: Ein Docker-Container basiert auf dem Image nvidia/cuda:12.2.0-runtime-ubuntu22.04. Der Host hat Treiberversion 535. Der Container startet und nutzt CUDA 12.2, obwohl auf dem Host kein CUDA-Toolkit installiert ist. Der Treiber des Hosts reicht aus. Ein zweiter Container auf demselben Host nutzt nvidia/cuda:11.8.0-runtime-ubuntu22.04 und läuft ebenfalls, weil Treiber 535 abwärtskompatibel zu CUDA 11.8 ist.
Beispiel: Ein Cluster betreibt zehn Nodes mit unterschiedlichen Treiberversionen. Node 1 bis 5 haben Treiber 525, Node 6 bis 10 haben Treiber 550. Ein Container mit CUDA 12.4 läuft nur auf Node 6 bis 10 (Treiber 550 unterstützt CUDA 12.4). Node 1 bis 5 mit Treiber 525 unterstützen maximal CUDA 12.0. Das Scheduling-System muss diese Einschränkung kennen.
Das NVIDIA Container Toolkit (früher nvidia-docker) stellt sicher, dass Container auf die GPU-Ressourcen des Hosts zugreifen können. Es injiziert die Treiberbibliotheken des Hosts in den Container. Ohne dieses Toolkit sieht ein Container keine GPU.
Typische Fehlerbilder und Diagnose
Kompatibilitätsprobleme äußern sich in verschiedenen Fehlermeldungen. Die häufigsten lassen sich systematisch eingrenzen.
Beispiel: RuntimeError: CUDA error: no kernel image is available for execution on the device. Diese Meldung bedeutet, dass der kompilierte Code keine Maschinencode-Variante für die vorhandene GPU-Architektur enthält. Die Lösung: PyTorch in einer Version installieren, die für die betreffende Compute Capability kompiliert wurde, oder den Code selbst mit der passenden -gencode-Option neu kompilieren.
Beispiel: torch.cuda.is_available() gibt False zurück. Mögliche Ursachen: Kein NVIDIA-Treiber installiert, Treiber-Kernel-Modul nicht geladen (lsmod | grep nvidia zeigt nichts), PyTorch ohne CUDA-Support installiert (CPU-only-Variante), oder CUDA_VISIBLE_DEVICES auf einen leeren Wert gesetzt.
Beispiel: CUBLAS_STATUS_NOT_INITIALIZED. Diese Meldung tritt auf, wenn die cuBLAS-Bibliotheksversion nicht zur CUDA-Runtime-Version passt. Ein typischer Auslöser: Zwei verschiedene CUDA-Toolkit-Versionen sind installiert, und die Umgebungsvariable LD_LIBRARY_PATH zeigt auf die falsche Version.
Die Diagnose folgt einem festen Schema: Zuerst nvidia-smi prüfen (Treiber vorhanden, GPU sichtbar). Dann nvcc --version prüfen (Toolkit installiert, Version bekannt). Dann die Framework-Version prüfen (python3 -c "import torch; print(torch.version.cuda)"). Wenn alle drei Werte bekannt sind, lässt sich die Kompatibilität anhand der NVIDIA-Kompatibilitätstabelle prüfen.
Strategien für stabile Umgebungen
In produktiven Systemen wird die CUDA-Umgebung bewusst eingefroren. Jede Komponente wird mit exakter Versionsnummer dokumentiert. Updates werden isoliert getestet, bevor sie in die Produktion übernommen werden.
Beispiel: Ein Team dokumentiert seine Umgebung als requirements.txt und Dockerfile. Der Dockerfile-Header lautet FROM nvidia/cuda:11.8.0-cudnn8-devel-ubuntu22.04. Damit ist die CUDA-Version, die cuDNN-Version und das Betriebssystem fixiert. Die PyTorch-Version wird in requirements.txt mit torch==2.1.0+cu118 festgelegt. Diese Kombination wird getestet und als stabil freigegeben.
Der Wechsel auf eine neue CUDA-Version geschieht in produktiven Systemen schrittweise. Zuerst wird die neue Version in einer Testumgebung installiert. Dann werden alle abhängigen Bibliotheken auf Kompatibilität geprüft. Erst wenn das Training und die GPU-Beschleunigung unter der neuen Version identische Ergebnisse liefern, wird die Produktion umgestellt.
Fachliche Einordnung: In großen Clustern mit hunderten GPUs ist die CUDA-Kompatibilitätsverwaltung ein eigenes Infrastrukturproblem. Tools wie Conda-Umgebungen, Docker-Images und Modul-Systeme (Environment Modules) adressieren verschiedene Aspekte davon. Kein einzelnes Tool löst alle Kompatibilitätsfragen gleichzeitig. Die Kombination aus fixiertem Docker-Image und gesteuertem Treiber-Rollout auf Host-Ebene hat sich als gängige Praxis etabliert.
Grenzen und Einordnung
CUDA-Kompatibilität betrifft ausschließlich NVIDIA-Hardware. AMD-GPUs verwenden ROCm, Intel-GPUs verwenden oneAPI. Beide Systeme haben eigene Kompatibilitätsmatrizen. Code, der für CUDA geschrieben wurde, läuft ohne Portierung nicht auf AMD- oder Intel-Hardware.
Die Vorwärtskompatibilität von NVIDIA-Treibern hat Grenzen. In seltenen Fällen kann ein Treiberupdate bestehende Anwendungen beeinträchtigen, etwa wenn deprecated APIs entfernt werden. NVIDIA dokumentiert solche Breaking Changes in den Release Notes, aber nicht jedes Team prüft diese vor dem Update.
Beispiel: CUDA 12 hat die Unterstützung für Kepler-GPUs (Compute Capability 3.x) entfernt. Organisationen, die noch Tesla K80-Karten betreiben, können nicht über CUDA 11.x hinaus aktualisieren. Das betrifft ältere Cloud-Instanzen (z.B. AWS p2-Instanzen) und On-Premise-Hardware aus den Jahren 2013 bis 2016.
Die zunehmende Komplexität der Kompatibilitätskette hat Konsequenzen für die Reproduzierbarkeit von ML-Experimenten. Unterschiedliche CUDA-Versionen können zu numerisch leicht abweichenden Ergebnissen führen, weil sich die Implementierung von GPU-Kernels zwischen Versionen ändert. Für exakte Reproduzierbarkeit müssen nicht nur Modellgewichte und Daten, sondern auch die vollständige CUDA-Toolchain identisch sein.
Fachliche Einordnung: NVIDIA pflegt eine offizielle Kompatibilitätsmatrix (CUDA Compatibility Guide), die Treiber, Toolkit und Compute Capability zueinander in Beziehung setzt. In der Praxis reicht diese Matrix allein nicht aus, weil Drittanbieter-Bibliotheken (cuDNN, NCCL, TensorRT) eigene Versionsanforderungen haben. Die tatsächliche Kompatibilitätsprüfung erfordert eine vollständige Auflistung aller beteiligten Komponenten mit ihren exakten Versionsnummern.