torch.cuda.is_available() ist False, obwohl die GPU steckt
PyTorch findet die Grafikkarte nicht, obwohl sie im Rechner steckt? Vier Stellen, an denen die Kette zwischen Karte und Python reißen kann.
Aufwand:
ca. 25 Min.
Voraussetzung:
Python, Terminal, nvidia-smi
Gilt für:
PyTorch 2.13, Nvidia-Grafikkarte, Linux
Das Symptom
Die Karte ist eingebaut, der Lüfter dreht, Spiele laufen – und trotzdem
antwortet Python auf torch.cuda.is_available() mit False. Das Modell landet
brav auf der CPU, ein Durchlauf dauert statt Minuten Stunden, und beim Versuch,
etwas mit .cuda() zu erzwingen, kommt AssertionError: Torch not compiled with CUDA enabled oder RuntimeError: Found no NVIDIA driver on your system. Am
Vortag hat dasselbe Skript noch funktioniert. Vermutlich.
Die „Layer 8“-Wahrheit
is_available() ist keine Hardwareerkennung, sondern die Schlussprüfung einer
Kette mit vier Gliedern: Die Karte muss am Bus aufgezählt werden, das
Kernelmodul des Treibers muss geladen sein, das installierte PyTorch-Paket muss
überhaupt CUDA mitbringen, und das Gerät muss für genau diesen Prozess sichtbar
sein. Reißt eines davon, meldet die Funktion False – und zwar mit derselben
lakonischen Ausgabe, ganz gleich, welches Glied es war. Das ist der eigentliche
Grund, warum dieser Fehler so lange dauert: Die Meldung ist ehrlich, aber
maximal wortkarg.
Zwei Verwechslungen halten sich besonders hartnäckig. Die erste: Bild anzeigen
und rechnen sind nicht dasselbe. Eine Karte kann tadellos ein Spiel darstellen
und für CUDA trotzdem nicht bereitstehen, weil das Kernelmodul nach einem Update
nicht mehr passt oder schlicht ein Neustart fehlt. Die zweite: Nicht jede
PyTorch-Installation kann überhaupt mit einer Grafikkarte reden. Wird ein Paket
ohne CUDA-Unterstützung installiert, ist die Antwort dauerhaft False, und kein
Treiber der Welt ändert daran etwas – dann hilft nur, das passende Paket zu
installieren.
Bleibt der Fall, in dem alles stimmt und es trotzdem nicht geht. Dann steht mit
hoher Wahrscheinlichkeit CUDA_VISIBLE_DEVICES irgendwo im Weg, gesetzt in
einer Shell-Startdatei, einer Dienstdefinition oder einem Container und seit
Monaten vergessen. Die Variable versteckt Karten prozessweise; nvidia-smi
zeigt sie weiterhin an, weil es sie nicht auswertet. Deshalb die Reihenfolge von
unten nach oben – Bus, Treiber, Paket, Sichtbarkeit. Wer stattdessen oben
anfängt und PyTorch dreimal neu installiert, hat am Ende drei Installationen und
denselben Wahrheitswert.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob das System die Karte überhaupt sieht
Zuerst die unterste Ebene: Steckt die Karte am Bus und wird sie aufgezählt? Der Installationsleitfaden von Nvidia nennt dafür genau diesen Befehl. Kommt hier keine Zeile zurück, ist das kein Softwareproblem, sondern ein Steckplatz-, Strom- oder Durchreichungsproblem. Ob das Modell CUDA beherrscht, klärt laut Nvidia der Abgleich mit der Liste der CUDA-fähigen Grafikkarten.
lspci | grep -i nvidia
2.
Prüfen, ob der Treiber geladen ist
nvidia-smi ist laut Nvidia das Werkzeug zur Überwachung und Verwaltung der eigenen Geräte. Zeigt es eine Tabelle mit der Karte, läuft das Kernelmodul. Meldet es dagegen, dass keine Geräte gefunden wurden oder dass die Kommunikation mit dem Treiber scheitert, ist die Suche hier zu Ende: Ohne geladenen Treiber kann kein Programm die Karte zum Rechnen benutzen. Nach einem Treiber- oder Kernelupdate ohne Neustart ist genau das der Normalfall.
nvidia-smi
3.
PyTorch selbst befragen, statt zu vermuten
Diese vier Zeilen trennen die Fälle sauber. Zeigt die dritte Ausgabe keine CUDA-Version an, wurde eine PyTorch-Variante ohne CUDA installiert – dann ist alles andere egal, und es hilft nur eine Neuinstallation des passenden Pakets. device_count() gibt laut Dokumentation die Anzahl der verfügbaren Grafikkarten zurück; eine 0 bei laufendem Treiber deutet auf den nächsten Schritt hin.
Sicherstellen, dass das gemeinte Python auch das benutzte ist
Ein häufiger und ärgerlich banaler Fall: Es gibt zwei Installationen, und die Shell erwischt die falsche – etwa weil die virtuelle Umgebung nicht aktiviert ist oder das Notebook einen anderen Kernel benutzt. Die Ausgabe zeigt, aus welchem Verzeichnis PyTorch tatsächlich geladen wird. Steht dort ein anderer Pfad als erwartet, wurde die Suche bisher am falschen Objekt geführt.
which python3
python3 -c "import torch; print(torch.__file__)"
5.
Nachsehen, ob eine Umgebungsvariable die Karte ausblendet
CUDA_VISIBLE_DEVICES steuert laut PyTorch-Dokumentation, welche Grafikkarten für PyTorch verfügbar sind. Ist die Variable gesetzt, muss ihr Wert zu den vorhandenen Kartennummern passen. Ein leerer Wert blendet alles aus. Zum Gegentest lässt sie sich für einen einzelnen Aufruf überschreiben, ohne irgendetwas dauerhaft zu ändern.
Den Code so schreiben, dass der Fall nicht mehr überrascht
Ein hart verdrahtetes .cuda() bricht auf jedem Rechner ohne Karte ab. Die Dokumentation empfiehlt stattdessen geräteunabhängigen Code: einmal abfragen, ein torch.device festhalten, überall damit arbeiten. Dann läuft dasselbe Skript auf der Karte und auf der CPU, und ein False ist eine Information statt eines Absturzes.
import torch
geraet = torch.device('cuda' if torch.cuda.is_available() else 'cpu')
print('Es wird gerechnet auf:', geraet)
Die Dokumentation formuliert es knapp: Die Funktion gibt einen Wahrheitswert zurück, der anzeigt, ob CUDA gerade verfügbar ist. Das ist keine Aussage darüber, ob eine Grafikkarte im Rechner steckt, sondern darüber, ob die gesamte Kette bis zu diesem Python-Prozess steht – Karte, Kernelmodul des Treibers, die CUDA-Unterstützung im installierten PyTorch-Paket und die Sichtbarkeit des Geräts für genau diesen Prozess. Das Paket wird laut Dokumentation verzögert initialisiert, lässt sich also immer importieren; erst diese Abfrage sagt, ob es auch etwas zu tun gibt. Ein False heißt deshalb nicht defekt, sondern: irgendwo in der Kette fehlt ein Glied.
?Die Karte funktioniert doch, ich spiele damit. Warum sieht PyTorch sie trotzdem nicht?
Weil Bilder anzeigen und Rechenaufträge annehmen zwei verschiedene Fähigkeiten sind. Für die Bildausgabe genügt ein Anzeigetreiber; für CUDA braucht es zusätzlich das passende Kernelmodul und die Laufzeitumgebung, gegen die das PyTorch-Paket gebaut wurde. Deshalb kann ein Spiel flüssig laufen, während nvidia-smi nichts meldet oder is_available() False liefert. Und selbst wenn beides steht, entscheidet noch die installierte PyTorch-Variante: Ein Paket ohne CUDA-Unterstützung rechnet ausschließlich auf der CPU, ganz gleich, was in der Karte steckt.
?Kann eine Umgebungsvariable die Karte vor PyTorch verstecken?
Ja, und das ist der Fehler, den man am längsten sucht, weil er systemweit unsichtbar ist. Die PyTorch-Dokumentation nennt CUDA_VISIBLE_DEVICES als die Stellschraube, mit der sich steuern lässt, welche Grafikkarten für PyTorch überhaupt verfügbar sind. Steht die Variable auf einem leeren Wert oder auf einer Nummer, die es nicht gibt, sieht der Prozess kein Gerät – nvidia-smi dagegen zeigt die Karte weiterhin an, weil es die Variable nicht auswertet. Gesetzt wird so etwas gern in einer Startdatei der Shell, in einer Dienstdefinition oder in einem Container und dann jahrelang vergessen.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Nach der Installation von akmod-nvidia startet Fedora ohne Nvidia-Treiber? Oft ist das Kernelmodul beim Neustart noch nicht fertig gebaut. akmods baut es.
Windows hat ein Gerät gestoppt, weil es Probleme meldete? Code 43 ist kein Urteil über einen Defekt — oft hilft Treiber, Strom oder ein sauberer Neustart.
Nach dem Treiber- oder Kernel-Update bleibt der Bildschirm schwarz? Oft passt das Nvidia-Modul nicht mehr zum Kernel — die Textkonsole rettet die Lage.