„No kernel image is available“ auf RTX PRO Blackwell (sm_120): Ursachen und Lösungen

Was die Fehlermeldung bedeutet

Die Meldung „CUDA error: no kernel image is available for execution on the device“ sagt, dass die CUDA-Laufzeit im Programm keinen Code gefunden hat, den diese GPU ausführen kann. Auf einer NVIDIA-RTX-PRO-Blackwell-Karte, Compute Capability 12.0 oder sm_120 in der Sprache des Compilers, ist die Ursache fast immer Software, die vor CUDA 12.8 oder ohne 12.0 in der Zielliste gebaut wurde: ein älteres PyTorch-Wheel, eine eigene CUDA-Erweiterung, übersetzt für die Karten, die der Entwickler damals hatte, oder ein Container-Image aus der Hopper- oder Ada-Zeit. Die Lösung ist ein Build mit sm_120-Code, und die folgenden Prüfungen zeigen, welcher Komponente er fehlt.

Der Fehler erscheint beim ersten Kernel-Start, oft tief im Modell: Ein Tensor wandert ohne Fehlermeldung auf die GPU, und erst der erste Attention- oder Matrix-Kernel scheitert. PyTorch gibt häufig schon beim Import eine Warnung aus, die diese Seite ebenfalls behandelt. Jede RTX-PRO-Blackwell-Karte, die wir liefern, meldet 12.0, von der RTX PRO 6000 in Server, Max-Q und Workstation Edition bis zu RTX PRO 5000, 4500, 4000 und 2000; eine Lösung gilt also für alle. Die Unterstützung dieser Karten in vLLM, SGLang und TensorRT-LLM Release für Release behandelt unser Leitfaden zu Software für RTX PRO Blackwell (SM120); hier geht es um den Fehler selbst und um Code, den Sie selbst bauen.

Wie CUDA den Code für eine GPU auswählt

Eine CUDA-Binärdatei kann zwei Arten von GPU-Code enthalten, und der Blackwell-Kompatibilitätsleitfaden von NVIDIA (Dokumentation CUDA 13.4, zuletzt aktualisiert am 12. Oktober 2026) nennt die Regeln für beide. Ein Cubin ist Maschinencode und „supported to run on any GPU with the same major revision and same or higher minor revision“ der Compute Capability. PTX ist eine Zwischenform, „supported to run on any GPU with compute capability higher than the compute capability assumed“ bei der Erzeugung, und der Treiber übersetzt es beim Laden. Beim Start nimmt die Laufzeit ein passendes Cubin, falls vorhanden, sonst übersetzt sie das PTX; in den Worten des Leitfadens: „If neither compatible cubin nor PTX is available, kernel launch results in a failure.“ Dieser Fehlschlag ist die Meldung dieser Seite.

Compute Capabilities aus der CUDA-GPU-Liste von NVIDIA, wie in unserem Leitfaden zu Treiberzweigen angegeben; Cubin-Regel aus dem Blackwell-Kompatibilitätsleitfaden von NVIDIA vom 12. Oktober 2026, von uns angewandt. Gelesen am 25. Oktober 2026.

Aus der Regel ergeben sich drei Folgen. Kernel, die nur für die H200 NVL (9.0) oder die L40S (8.9) übersetzt sind, laufen nicht auf einer RTX PRO 6000, weil die Hauptversion abweicht. Ein Cubin für die B200 (10.0) läuft dort ebenfalls nicht, obwohl beide Chips Blackwell heißen. Und nach derselben Regel läuft ein Cubin für 12.0 auf DGX Spark (12.1), aber nicht umgekehrt. Der Leitfaden ergänzt, dass architekturspezifisches PTX mit dem Suffix a, etwa compute_90a, weder vorwärts- noch rückwärtskompatibel ist: Das compute_90a-PTX von Hopper läuft nicht auf Blackwell, und so gebaute Kernel brauchen einen eigenen sm_120-Build.

Die Komponente ohne sm_120 finden

Beginnen Sie mit PyTorch, weil es zu fast jedem Stack gehört. Zwei Aufrufe beantworten die Frage: torch.cuda.get_device_capability() liefert auf einer RTX-PRO-Blackwell-Karte (12, 0), und torch.cuda.get_arch_list() listet die Ziele, die der installierte Build enthält. Ein funktionierender Build listet sm_120; ein Beitrag im PyTorch-Forum vom Januar 2026 zeigt eine Liste, die mit 'sm_90', 'sm_100', 'sm_120' endet. Fehlt das Ziel, meldet PyTorch es beim ersten CUDA-Aufruf mit der Vorlage aus seinem Quellcode: „{} with CUDA capability sm_{} is not compatible with the current PyTorch installation.“, gefolgt von „The current PyTorch install supports CUDA capabilities {}.“

Ist PyTorch in Ordnung, liegt der fehlerhafte Kernel in einer anderen Binärdatei. cuobjdump von NVIDIA zeigt, was eine CUDA-Anwendung, Bibliothek oder ein Python-Erweiterungsmodul enthält: cuobjdump -lelf listet „all the ELF files available in the fatbin“, also die Cubins, mit Dateinamen wie add_new.sm_120.cubin, und cuobjdump -lptx listet das PTX. Wenden Sie es auf die .so-Dateien der Pakete im Traceback an, typischerweise ein FlashAttention-Build, eine Quantisierungsbibliothek oder eine hauseigene Erweiterung. Eine Bibliothek, die nur sm_80- und sm_90-Cubins und kein PTX zeigt, muss neu gebaut werden.

NVIDIA beschreibt außerdem einen Test, den Sie vor dem Eintreffen der neuen Karten ausführen können. Setzen Sie auf einer vorhandenen Maschine CUDA_FORCE_PTX_JIT=1 und starten Sie die Anwendung: Eingebettete Cubins werden ignoriert, das PTX wird beim Laden übersetzt, und „An application fails to execute if it does not include PTX.“ Eine Anwendung, die den Test besteht, enthält PTX, das die RTX-PRO-Karten übersetzen können, sofern der Treiber mindestens so neu ist wie das Toolkit, das es erzeugt hat. Entfernen Sie die Variable danach wieder.

Wir liefern die RTX PRO 6000 in allen drei Editionen und bauen Server damit, auf Wunsch mit installiertem Treiber, CUDA und Container-Laufzeit; senden Sie uns die Frameworks und Erweiterungen, die Ihr Code braucht, und wir antworten mit einer Kombination aus Treiber und CUDA, die sie ausführt.

Ursache 1: ein PyTorch-Wheel ohne sm_120

Die Release Notes von PyTorch 2.7.0, veröffentlicht am 23. April 2025, nennen „NVIDIA Blackwell Architecture Support“ unter den Neuerungen, dazu „Blackwell support added across native kernels, CUDA math libraries, and torch.compile“ und CUDA 12.8 in der Build-Pipeline. Eine Antwort im PyTorch-Forum vom März 2026 fasst die Regel zusammen: „Release 2.7.0 built with CUDA 12.8 supports sm_120.“ Wheels, die mit CUDA 12.6 gebaut sind, enthalten es nicht; ein Nutzer im selben Thread berichtete, eine cu126-Installation warne, sie „supports sm_50 - sm_90“.

Die CUDA-Variante eines installierten Wheels steht in seiner Versionsangabe, etwa 2.10.0+cu128. Die Lösung: aus dem Index für CUDA 12.8 oder neuer neu installieren, dessen Adresse auf die CUDA-Version endet, etwa download.pytorch.org/whl/cu128, und die Version in der Requirements-Datei festschreiben, damit eine spätere Installation nicht auf eine andere Variante zurückfällt. Die stabile Dokumentation von PyTorch verwies am 25. Oktober 2026 auf Release 2.14; jedes Release ab 2.7.0 läuft auf RTX PRO Blackwell, wenn es mit CUDA 12.8 oder neuer gebaut ist. Ältere, festgeschriebene Umgebungen, wie sie in Forschungsteams häufig sind, sind die übliche Quelle des Fehlers.

Ursache 2: eine eigene Erweiterung oder ein FlashAttention-Build ohne 12.0

Erweiterungen, die mit CUDAExtension von PyTorch gebaut werden, erhalten ihre Ziele aus TORCH_CUDA_ARCH_LIST. Die Dokumentation von PyTorch 2.14 beschreibt den Standard: „By default the extension will be compiled to run on all archs of the cards visible during the building process of the extension, plus PTX.“ Sie warnt: „If down the road a new card is installed the extension may need to be recompiled.“ Viele Projekte setzen die Liste ausdrücklich, und eine Liste wie „8.0 8.6 8.9 9.0“ ohne +PTX liefert Cubins für Ampere, Ada und Hopper und nichts, was eine RTX-PRO-Karte nutzen kann. Genau dieser Build erzeugt den Fehler.

Die Dokumentation nennt Syntax und Empfehlung. TORCH_CUDA_ARCH_LIST="6.1 8.6" baut zwei Ziele; das Suffix +PTX fügt PTX hinzu, das „can runtime-compile for any CC >= the specified CC“. Sie rät: „If you know exact CC(s) of the GPUs you want to target, you're always better off specifying them individually“, weil älteres PTX „can modestly reduce performance on those newer CCs“. Jedes Ziel verlängert die Build-Zeit, wie die Dokumentation ebenfalls vermerkt. Für einen Server mit RTX PRO 6000 Server Edition bauen Sie mit „12.0“, für einen Bestand, der auch H200 NVL und L40S enthält, mit „8.9 9.0 12.0“. Mit der Standardliste führt eine sichtbare Karte, die neuer ist als das Build-Toolkit, dazu, dass PyTorch auf das neueste PTX ausweicht, das nvcc erzeugen kann, und das läuft erst nach JIT-Übersetzung; bauen Sie mit CUDA 12.8 oder neuer, um nativen sm_120-Code zu erhalten.

Zu zwei verbreiteten Projekten ein Hinweis. vLLM baut eigene Kernel und schreibt in seiner Installationsanleitung, „Global +PTX requests in TORCH_CUDA_ARCH_LIST are ignored for general extension targets“; ein Maintainer schrieb im Juni 2025 im GitHub-Issue 16901, die SM120-Unterstützung sei im veröffentlichten Wheel und Docker-Image angekommen. Das README von FlashAttention nennt FlashAttention-2 für Ampere-, Ada- und Hopper-GPUs, FlashAttention-3 für Hopper und FlashAttention-4 für „Hopper and Blackwell GPUs (e.g. H100, B200)“, ohne sm_120 zu nennen. Prüfen Sie ein solches Paket mit cuobjdump, bevor Sie sich auf RTX-PRO-Karten darauf verlassen; Inferenz-Engines bringen eigene Attention-Kernel für SM120 mit, wie unser Software-Leitfaden auflistet.

Ursache 3: ein altes Container-Image oder ein Treiber älter als das Toolkit

CUDA-Laufzeit und Bibliotheken kommen mit dem Container-Image, der Treiber mit dem Host, wie unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt. Ein Image auf Basis einer CUDA-Version vor 12.8 kann keine sm_120-Cubins enthalten, weil CUDA 12.8 das erste Toolkit war, das sie erzeugt; bestenfalls enthält es PTX für ein älteres Ziel und läuft nach JIT-Übersetzung. Bauen Sie solche Images auf einer Basis mit CUDA 12.8 oder neuer neu, und die Erweiterungen darin mit 12.0 in der Zielliste. TensorRT-Engines sind ein strengerer Fall: Eine Engine wird für einen GPU-Typ gebaut, und unsere Seite zum Bereitstellen von Bildmodellen mit Triton, ONNX und TensorRT erklärt, warum eine auf einer L4 gebaute Engine auf einer RTX-PRO-Karte nicht lädt.

Die umgekehrte Abweichung erzeugt einen anderen Fehler. Ist ein Image neuer als der Treiber des Hosts, kann der ältere Treiber PTX aus dem neueren Toolkit nicht übersetzen. Die Troubleshooting-Seite von vLLM nennt dafür „RuntimeError: CUDA error: the provided PTX was compiled with an unsupported toolchain“ und „The NVIDIA driver on your system is too old“. Sie bietet ein Kompatibilitätspaket als Umweg an, das nach ihren Angaben nur auf ausgewählten Profi- und Rechenzentrums-GPUs funktioniert; die dauerhafte Lösung ist ein Treiber aus einem Zweig, der zur CUDA-Version des Images passt. CUDA 13.0 gehört zu R580, und sowohl R580 als auch R595 führen jede Edition der RTX PRO 6000.

JIT-Übersetzung ist eine Notlösung

Software, die auf einer RTX-PRO-Karte nur über PTX läuft, funktioniert, aber nicht ohne Nachteile. MathWorks beschreibt einen ähnlichen Mechanismus für MATLAB auf Blackwell, mit einer kurzen einmaligen Verzögerung („a brief one-time delay“), während der Byte-Code übersetzt und zwischengespeichert wird, und der Leitfaden von NVIDIA vermerkt, dass der Treiber die übersetzten Cubins zwischenspeichert, „so this is often a one-time cost“. Die Dokumentation von PyTorch ergänzt die oben zitierte Leistungseinbuße durch älteres PTX. Bauen Sie für einen Server im Betrieb nativen sm_120-Code und behalten Sie PTX nur als Reserve für die nächste Generation, etwa mit „12.0+PTX“ als letztem Eintrag der Liste.

Gemischte Bestände: ein Build für jeden Kartentyp

Ein Unternehmen, das H200-NVL-Server neben Knoten mit RTX PRO 6000 Server Edition betreibt oder L40S-Karten weiter nutzt, braucht Code für jede Capability in jedem Image, das auf beiden läuft. Die Tabelle nennt die Zielliste je Bestand; unsere Leitfäden zum Mischen von Ada- und Blackwell-GPUs und zu H200 NVL und RTX PRO 6000 in einer Plattform behandeln Treiber, Scheduling und Knoten-Labels.

unsere Empfehlung auf Basis der CUDAExtension-Dokumentation von PyTorch (2.14) und des Blackwell-Kompatibilitätsleitfadens von NVIDIA (12. Oktober 2026). Builds, die architekturspezifische a-Funktionen brauchen, benötigen ein eigenes Image je Ziel.

In Kubernetes versehen Sie die Knoten mit ihrer Compute Capability und halten Images, die nur für 12.0 gebaut sind, von Hopper- und Ada-Knoten fern; GPU Feature Discovery veröffentlicht dafür das Label nvidia.com/gpu.compute.major, 12 auf RTX PRO Blackwell und 8 auf Ada, wie der Leitfaden zum Mischen zeigt, und nach ihrer Compute Capability 9 auf der H200 NVL.

Wir bauen Server mit RTX PRO 6000 Server Edition und H200 NVL für gemischte Bestände und installieren auf Wunsch den Treiberzweig, den Ihre Images brauchen; nennen Sie uns die Karten, die Sie heute betreiben, und die geplanten, und wir antworten mit einer Konfiguration für beide.

FAQ