Fix 'CUDA error: no kernel image is available for execution on the device'

The error no kernel image is available for execution on the device means the CUDA code you ran has no kernels for your GPU's architecture, and on a Blackwell card such as the RTX PRO 6000, B200 or B300 the usual cause is a PyTorch build that is older than the card. A PyTorch wheel carries a fixed list of architectures, so the fix is a build whose list includes yours, or for your own CUDA code a rebuild for your GPU. The PyTorch, NVIDIA and vLLM facts below were checked on 12 November 2026.

CUDA error: no kernel image is available for execution on the device
Search for `cudaErrorNoKernelImageForDevice' in https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TYPES.html for more information.

PyTorch 2.15.0 builds that text in its C++ error code and raises it as torch.AcceleratorError. The first line is what users paste into PyTorch's tracker, as in issue 174284, where the replies were that the CUDA 12.6 wheel has no Blackwell support and that Blackwell needs the 12.8 or 13.0 builds. PyTorch often prints a warning first, when CUDA starts. This is its template in torch/cuda/__init__.py for 2.15.0:

{} with CUDA capability sm_{} is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities {}.
If you want to use the {} GPU with PyTorch, please check the instructions at https://pytorch.org/get-started/locally/

The braces are the GPU name, its capability written as sm_120, the capabilities the build supports and the GPU name again. Versions 2.14.1 and 2.15.0 print a second warning that starts with Found GPU0 and, when a published CUDA build includes the GPU, ends with a ready pip install torch line for it.

What no kernel image is available for execution on the device means

NVIDIA's runtime API reference lists this as error 209, cudaErrorNoKernelImageForDevice: no kernel image suits the device, which can happen when the code generation options leave out the device's configuration. The Blackwell compatibility guide gives the rule. Compiled code for one compute capability runs on a GPU with the same major number and the same or a higher minor number. PTX, the intermediate form, is compiled at run time for any higher capability. If neither is present, the kernel launch fails. PyTorch's CUDA support matrix says its 2.15 release wheels ship compiled code only, with no PTX, so a missing architecture has no fallback.

Check the GPU against the build

python3 -c "import torch; print(torch.__version__, torch.version.cuda); print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0)); print(torch.cuda.get_arch_list())"

PyTorch's docs say get_device_capability returns the major and minor capability of the device and get_arch_list returns the architectures the library was compiled for. This table lists the capabilities of the GPUs DeployGPU rents, from NVIDIA's CUDA GPU page:

The same page lists the GeForce RTX 5090 at 12.0, so sm_120 covers both cards. A build runs on a GPU when its list has an entry with the same major number and a minor number at or below the GPU's. PyTorch applies that rule in its own table in torch/cuda/__init__.py, so an sm_86 entry serves the 8.9 cards and an sm_100 entry serves the B300, although the 2.15 wheels list no sm_103.

Install a PyTorch build that includes your GPU

The architecture lists come from PyTorch's 2.15.0 build script for Linux x86_64 wheels and, for the CUDA 12.8 build, its 2.11.0 support matrix:

The wheel index holds 2.15.0 only for CUDA 13.2 and 13.4, and the newest release on cu130 and cu126 is 2.14.1, on cu129 it is 2.13.0 and on cu128 it is 2.11.0. PyPI lists Python 3.11 or newer for 2.15.0, and NVIDIA's compatibility guide puts CUDA 13.x builds at driver 580 or newer. If the CUDA Version in the nvidia-smi header is lower, take an older build:

python3 -m pip install --upgrade torch --index-url https://download.pytorch.org/whl/cu132
python3 -m pip install torch==2.11.0 --index-url https://download.pytorch.org/whl/cu128

Run the first line on a driver that supports CUDA 13.2, and the second when the driver tops out at CUDA 12.8 or 12.9. A driver that stops at CUDA 13.0 or 13.1 takes torch==2.14.1 from the cu130 index. Then run the check again. The install guide shows how to read the header, the CUDA version guide explains the three CUDA numbers, and the RTX PRO 6000 and B300 pages cover the cards.

An old image or a pinned requirement brought the old build

The build inside a container image or a requirements file decides, not the VM. Docker Hub lists pytorch/pytorch tags such as 2.14.1-cuda12.6-cudnn9-runtime and 2.15.0-cuda13.2-cudnn9-runtime, and the first names the CUDA 12.6 build. The PyTorch + Jupyter template runs quay.io/jupyter/pytorch-notebook:cuda12-latest, a floating tag with PyTorch built for CUDA 12, so I print the architecture list before I trust it on a Blackwell card. A +cu126 pin or a cu126 index URL in a requirements file brings the old build back after you fix it, and the constraints file in the Torch not compiled with CUDA page stops that.

Your own CUDA code was built for another architecture

A custom extension fails the same way when it was compiled without code for your GPU. PyTorch's extension docs say an extension is built by default for the cards visible during the build, plus PTX, and that a new card may need a recompile. You can set the list yourself, and the docs say more architectures make the build slower:

TORCH_CUDA_ARCH_LIST="8.0 9.0 10.0 12.0" python build_my_extension.py

NVIDIA's cuobjdump tool shows which architectures a compiled library holds, with -lelf listing its cubins and -lptx its PTX:

cuobjdump my_extension.so -lelf

The compiler must know the architecture too. NVIDIA's CUDA 12.8 release notes list SM_120 among the Blackwell architectures that release added, and nvcc --list-gpu-code prints what your toolkit supports.

vLLM and llama.cpp

vLLM's installation docs say Blackwell GPUs (B200, GB200) need a minimum of CUDA 12.8, so install PyTorch wheels with at least that version. llama.cpp's build guide says a default build targets the hardware connected at that moment. cmake -B build -DGGML_CUDA=ON -DGGML_NATIVE=OFF covers all CUDA GPUs, and -DCMAKE_CUDA_ARCHITECTURES takes a list of capabilities written without the dot, such as 86;89 for 8.6 and 8.9. So build on the VM that will run the binary, or list the architectures.

When to contact support

Email support@deploygpu.ai if the architecture list includes your GPU and the error still appears, if nvidia-smi shows a different GPU from the offer, or if one GPU of a multi-GPU VM fails and the others work. Send the output of the check above, the nvidia-smi header, the provider and the deployment ID. The contact page is the other way in.