CUDA-Verfügbarkeit
Bevor eine Grafikkarte für Berechnungen genutzt werden kann, muss das System prüfen, ob die passende Hardware vorhanden und korrekt eingerichtet ist. Diese Prüfung heißt CUDA-Verfügbarkeit.
CUDA-Verfügbarkeit beschreibt den Zustand, in dem ein System eine NVIDIA-GPU erkennt, die zugehörigen Treiber geladen sind und die CUDA-Laufzeitumgebung korrekt funktioniert. Erst wenn alle drei Bedingungen erfüllt sind, können Programme Berechnungen auf die GPU auslagern. Der Begriff ist im Kontext von Deep Learning und wissenschaftlichem Rechnen zentral, weil dort nahezu jede rechenintensive Operation von GPU-Beschleunigung profitiert.
Wie die Prüfung technisch abläuft
Die Prüfung der CUDA-Verfügbarkeit durchläuft mehrere Schichten. Auf der untersten Ebene kommuniziert der NVIDIA-Kerneltreiber mit der GPU-Hardware über den PCIe-Bus. Darüber liegt die CUDA-Runtime-Bibliothek, die eine einheitliche Programmierschnittstelle bereitstellt. Frameworks wie PyTorch rufen diese Bibliothek auf und melden das Ergebnis an den Anwender zurück.
Beispiel: In PyTorch gibt torch.cuda.is_available() den Wert True zurück, wenn Treiber, Runtime und GPU korrekt zusammenarbeiten. Der Aufruf torch.cuda.device_count() zeigt zusätzlich die Anzahl der erkannten GPUs.
Beispiel: Auf Systemebene liefert nvidia-smi eine Übersicht über erkannte GPUs, Treiberversion, VRAM-Belegung und laufende GPU-Prozesse. Dieses Werkzeug arbeitet unabhängig von Python-Frameworks direkt mit dem Treiber.
Fachliche Einordnung: Die Prüfung umfasst im Detail den Aufruf der Funktion cuInit() aus der CUDA Driver API. Diese initialisiert den Treiber-Kontext und gibt einen Fehlercode zurück, falls die Hardware nicht ansprechbar ist. Frameworks kapseln diesen Aufruf und übersetzen ihn in eine einfache boolesche Rückmeldung.
Die drei Schichten der CUDA-Verfügbarkeit
CUDA-Verfügbarkeit setzt sich aus drei Komponenten zusammen, die alle funktionieren müssen: Hardware, Treiber und Runtime. Fehlt eine dieser Schichten, schlägt die Prüfung fehl.
Beispiel: Ein Server verfügt über eine NVIDIA A100 und der Treiber ist installiert, aber die CUDA-Runtime fehlt. nvidia-smi zeigt die GPU korrekt an, doch torch.cuda.is_available() gibt False zurück. Die Hardware allein reicht nicht aus.
Beispiel: In einer Docker-Umgebung wird ein Container ohne GPU-Zugriff gestartet. Der Host hat Treiber und GPU, aber dem Container fehlt die Durchreichung (--gpus all wurde nicht gesetzt). Innerhalb des Containers meldet die CUDA-Prüfung: nicht verfügbar.
Häufige Ursachen für fehlende Verfügbarkeit
In der Praxis scheitert die CUDA-Verfügbarkeit an einer überschaubaren Zahl von Ursachen. Die meisten lassen sich systematisch eingrenzen.
Treiber nicht installiert oder veraltet
Ohne NVIDIA-Treiber erkennt das Betriebssystem die GPU nicht als CUDA-fähiges Gerät. Auch ein zu alter Treiber kann die Verfügbarkeit verhindern, wenn das installierte CUDA-Toolkit eine höhere Treiberversion voraussetzt.
Beispiel: CUDA 12.x erfordert mindestens Treiberversion 525.60.13 unter Linux. Ein System mit Treiber 470.x meldet bei der Initialisierung den Fehler CUDA driver version is insufficient for CUDA runtime version.
Inkompatible Versionen
Die CUDA-Laufzeitumgebung, der Treiber und das ML-Framework müssen zueinander passen. PyTorch-Versionen werden gegen bestimmte CUDA-Versionen kompiliert. Eine PyTorch-Installation für CUDA 11.8 funktioniert nicht mit einer CUDA 12.4 Runtime auf dem System.
Beispiel: pip install torch ohne zusätzliche Angabe installiert unter bestimmten Bedingungen die CPU-Variante von PyTorch. Diese enthält keine CUDA-Anbindung. torch.cuda.is_available() gibt dann False zurück, obwohl GPU und Treiber korrekt eingerichtet sind.
Fehlkonfiguration in Cloud- und Container-Umgebungen
In virtualisierten Umgebungen muss die GPU explizit der Instanz zugewiesen werden. Bei Cloud-Anbietern wie AWS, GCP oder Azure erfordert das die Wahl eines GPU-Instanztyps. Bei Docker erfordert es das NVIDIA Container Toolkit und den Parameter --gpus.
Beispiel: Ein Kubernetes-Cluster verfügt über GPU-Knoten, aber der Pod-Manifest fordert keine GPU-Ressource an (nvidia.com/gpu: 1 fehlt in den Resource-Limits). Der Scheduler weist dem Pod keinen GPU-Knoten zu.
Systematische Diagnose
Die Fehlersuche folgt dem Schichtmodell von unten nach oben: zuerst Hardware, dann Treiber, dann Runtime, dann Framework.
Beispiel: Schritt 1: lspci | grep -i nvidia prüft, ob das Betriebssystem die GPU auf dem PCIe-Bus erkennt. Liefert der Befehl keine Ausgabe, ist entweder keine NVIDIA-GPU verbaut oder die Hardware ist defekt. Schritt 2: nvidia-smi prüft den Treiberstatus. Schritt 3: python3 -c "import torch; print(torch.cuda.is_available())" testet die gesamte Kette bis zum Framework.
Eine erweiterte Diagnose umfasst zusätzlich die Prüfung der Umgebungsvariablen. CUDA_VISIBLE_DEVICES steuert, welche GPUs für ein Programm sichtbar sind. Ist diese Variable auf einen leeren String gesetzt, sieht das Programm keine GPU.
Beispiel: CUDA_VISIBLE_DEVICES="" in der Shell-Umgebung bewirkt, dass torch.cuda.is_available() den Wert False liefert. Setzt man die Variable auf 0, wird nur die erste GPU sichtbar. Setzt man sie auf 0,1, werden die ersten beiden GPUs sichtbar.
Compute Capability und Kompatibilität
Jede NVIDIA-GPU hat eine Compute Capability, die angibt, welche CUDA-Funktionen sie unterstützt. Neuere CUDA-Toolkits setzen eine Mindest-Compute-Capability voraus. Ältere GPUs können dadurch trotz korrekter Treiber und Runtime nicht mehr nutzbar sein.
Beispiel: Eine GeForce GTX 750 Ti hat Compute Capability 5.0. PyTorch ab Version 2.0 unterstützt standardmäßig nur noch Compute Capability 3.7 und höher. Ältere Karten mit Capability 3.0 (z.B. GeForce GTX 680) werden von aktuellen PyTorch-Builds nicht mehr erkannt.
Die Compute Capability bestimmt auch, welche Rechenoperationen die GPU nativ beschleunigt. GPUs mit Capability 7.0 und höher verfügen über Tensor Cores, die Matrixoperationen in gemischter Präzision (FP16/FP32) beschleunigen. Das wirkt sich direkt auf die Trainingsgeschwindigkeit von Transformer-Modellen aus.
Beispiel: Das Training eines Sprachmodells auf einer V100 (Compute Capability 7.0 mit Tensor Cores) dauert bei aktivierter Mixed Precision etwa halb so lang wie auf einer P100 (Capability 6.0, ohne Tensor Cores) bei vergleichbarem VRAM.
CUDA-Verfügbarkeit bei mehreren GPUs
Systeme mit mehreren GPUs stellen eigene Anforderungen an die CUDA-Verfügbarkeit. Jede GPU wird einzeln angesprochen. Es ist möglich, dass eine GPU verfügbar ist und eine andere nicht, etwa weil eine Karte überhitzt ist oder ein Hardwarefehler vorliegt.
Beispiel: Ein Trainingsserver mit vier A100-GPUs zeigt nach einem Hardwarefehler nur drei GPUs in nvidia-smi. torch.cuda.device_count() gibt 3 zurück. Code, der fest mit vier GPUs rechnet, bricht mit einem Indexfehler ab.
Die Verwaltung mehrerer GPUs erfolgt über CUDA_VISIBLE_DEVICES oder über Framework-eigene Mechanismen wie torch.cuda.set_device(). In Cluster-Umgebungen teilt der Scheduler (z.B. SLURM) jeder Aufgabe bestimmte GPUs zu. Die CUDA-Verfügbarkeit wird dann pro zugewiesener GPU geprüft.
Beispiel: Ein SLURM-Job erhält zwei von acht GPUs eines Knotens. SLURM setzt CUDA_VISIBLE_DEVICES=2,5. Das Programm sieht nur diese beiden GPUs als Device 0 und Device 1. Die anderen sechs GPUs sind für diesen Job unsichtbar.
Grenzen und Einordnung
CUDA-Verfügbarkeit ist eine notwendige, aber nicht hinreichende Bedingung für GPU-beschleunigtes Rechnen. Auch bei erfolgreicher Prüfung können Probleme auftreten: zu wenig VRAM für ein Modell, thermische Drosselung unter Last oder Speicherfehler (ECC-Fehler) bei längeren Berechnungen.
CUDA ist zudem an NVIDIA-Hardware gebunden. AMD-GPUs nutzen ROCm, Intel-GPUs nutzen oneAPI mit SYCL. Die Prüfung der GPU-Verfügbarkeit funktioniert dort analog, aber mit anderen Werkzeugen und Bibliotheken. Portabilität zwischen diesen Ökosystemen ist begrenzt.
Fachliche Einordnung: CUDA-Verfügbarkeit betrifft ausschließlich den Zugriff auf GPU-Rechenressourcen, nicht deren Qualität. Ein System kann CUDA-verfügbar sein und trotzdem für einen bestimmten Workload ungeeignet, weil der verfügbare VRAM nicht ausreicht oder die Rechenleistung zu gering ist. Die Verfügbarkeitsprüfung ersetzt keine Kapazitätsplanung.