"No kernel image is available" on RTX PRO Blackwell (sm_120): causes and fixes

What the error means

The message "CUDA error: no kernel image is available for execution on the device" says that the CUDA runtime found no code in the program that this GPU can run. On an NVIDIA RTX PRO Blackwell card, compute capability 12.0 or sm_120 in compiler terms, the cause is almost always software built before CUDA 12.8 or built without 12.0 in its target list: an older PyTorch wheel, a custom CUDA extension compiled for the cards the developer had at the time, or a container image from the Hopper or Ada years. The fix is a build that contains sm_120 code, and the checks below find which component lacks it.

The error appears at the first kernel launch, which can be deep inside a model: a tensor moves to the GPU without complaint and the first attention or matrix kernel fails. PyTorch often prints an earlier warning at import, which this page also covers. Every RTX PRO Blackwell card we supply reports 12.0, from the RTX PRO 6000 in its Server, Max-Q and Workstation editions to the RTX PRO 5000, 4500, 4000 and 2000, so one fix covers all of them. Engine support for these cards in vLLM, SGLang and TensorRT-LLM, release by release, is the subject of our guide to RTX PRO Blackwell (SM120) software; this page is about the error itself and about code you build yourself.

How CUDA chooses code for a GPU

A CUDA binary can carry two kinds of GPU code, and NVIDIA's Blackwell compatibility guide (CUDA 13.4 documentation, last updated 12 October 2026) gives the rules for both. A cubin is machine code, "supported to run on any GPU with the same major revision and same or higher minor revision" of compute capability. PTX is an intermediate form, "supported to run on any GPU with compute capability higher than the compute capability assumed" when it was generated, and the driver compiles it at load time. At launch the runtime takes a matching cubin if there is one, otherwise it compiles the PTX; in the guide's words, "If neither compatible cubin nor PTX is available, kernel launch results in a failure." That failure is the error on this page.

compute capabilities from NVIDIA's CUDA GPU list as given in our driver-branch guide; cubin rule from NVIDIA's Blackwell compatibility guide, 12 October 2026, applied by us. Read 25 October 2026.

Three consequences follow from the rule. Kernels compiled only for the H200 NVL, 9.0, or for the L40S, 8.9, do not run on an RTX PRO 6000, because the major revision differs. A cubin for the B200, 10.0, does not run there either, although both chips are called Blackwell. And by the same rule a cubin for 12.0 runs on DGX Spark, 12.1, but not the other way round. The guide adds that architecture-specific PTX, with an a suffix such as compute_90a, is neither forward nor backward compatible: Hopper's compute_90a PTX does not run on Blackwell, so kernels built only that way need a separate sm_120 build.

Finding the component that lacks sm_120

Start with PyTorch, because it is part of almost every stack. Two calls answer the question: torch.cuda.get_device_capability() returns (12, 0) on an RTX PRO Blackwell card, and torch.cuda.get_arch_list() lists the targets the installed build carries. A working build lists sm_120; a PyTorch forum post of January 2026 shows a list ending in 'sm_90', 'sm_100', 'sm_120'. If PyTorch lacks it, it says so at the first CUDA call, with the template in its source: "{} with CUDA capability sm_{} is not compatible with the current PyTorch installation." followed by "The current PyTorch install supports CUDA capabilities {}."

If PyTorch is fine, the kernel at fault is in another binary. NVIDIA's cuobjdump lists what any CUDA executable, library or Python extension module contains: cuobjdump -lelf lists "all the ELF files available in the fatbin", the cubins, with file names such as add_new.sm_120.cubin, and cuobjdump -lptx lists the PTX. Run it on the .so files of the packages in the traceback, typically a FlashAttention build, a quantisation library or an in-house extension. A library that shows only sm_80 and sm_90 cubins and no PTX is the one to rebuild.

NVIDIA also documents a test you can run before the new cards arrive. Set CUDA_FORCE_PTX_JIT=1 on a current machine and start the application: embedded cubins are ignored, the PTX is compiled at load, and "An application fails to execute if it does not include PTX." An application that passes contains PTX that the RTX PRO cards can compile, provided the driver is at least as new as the toolkit that produced it. Unset the variable afterwards.

We supply the RTX PRO 6000 in all three editions and build servers with it, with driver, CUDA and container runtime installed on request; send us the frameworks and extensions your code depends on, and we reply with a driver and CUDA combination that runs them.

Cause 1: a PyTorch wheel without sm_120

PyTorch's release notes for 2.7.0, published on 23 April 2025, list "NVIDIA Blackwell Architecture Support" among the highlights, "Blackwell support added across native kernels, CUDA math libraries, and torch.compile" and CUDA 12.8 in the build pipeline. An answer on the PyTorch forum in March 2026 sums up the rule: "Release 2.7.0 built with CUDA 12.8 supports sm_120." Wheels built with CUDA 12.6 do not include it; a user in the same thread reported that a cu126 install warns that it "supports sm_50 - sm_90".

The CUDA variant of an installed wheel shows in its version string, for example 2.10.0+cu128. The fix is to reinstall from the index for CUDA 12.8 or later, whose address ends in the CUDA version, such as download.pytorch.org/whl/cu128, and to pin it in the requirements file so that a later install does not fall back to a different variant. PyTorch's stable documentation pointed to release 2.14 on 25 October 2026; any release from 2.7.0 on works with RTX PRO Blackwell in a CUDA 12.8 or newer build. Older pinned environments, common in research teams, are where the error usually comes from.

Cause 2: a custom extension or FlashAttention build without 12.0

Extensions built with PyTorch's CUDAExtension take their targets from TORCH_CUDA_ARCH_LIST. PyTorch's documentation for 2.14 describes the default: "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." It warns that "If down the road a new card is installed the extension may need to be recompiled." Many projects set the list explicitly, and a list such as "8.0 8.6 8.9 9.0" without +PTX gives cubins for Ampere, Ada and Hopper and nothing an RTX PRO card can use. That build produces this error.

The documentation gives the syntax and a recommendation. TORCH_CUDA_ARCH_LIST="6.1 8.6" builds two targets; a +PTX suffix adds PTX that "can runtime-compile for any CC >= the specified CC". It then advises: "If you know exact CC(s) of the GPUs you want to target, you're always better off specifying them individually", because relying on older PTX "can modestly reduce performance on those newer CCs". Each target adds build time, as the documentation also notes. For a server with RTX PRO 6000 Server Edition cards, build with "12.0"; for a fleet that also has H200 NVL and L40S cards, with "8.9 9.0 12.0". With the default list, a visible card newer than the build toolkit supports makes PyTorch fall back to the newest PTX that nvcc can produce, which runs only after JIT compilation; build on CUDA 12.8 or later to get native sm_120 code.

Two widely used projects deserve a note. vLLM, which builds its own kernels, states in its installation guide that "Global +PTX requests in TORCH_CUDA_ARCH_LIST are ignored for general extension targets"; a maintainer wrote in GitHub issue 16901 in June 2025 that SM120 support had landed in the published wheel and Docker image. The FlashAttention README lists FlashAttention-2 for Ampere, Ada and Hopper GPUs, FlashAttention-3 for Hopper and FlashAttention-4 for "Hopper and Blackwell GPUs (e.g. H100, B200)", without naming sm_120. Check such a package with cuobjdump before you rely on it on RTX PRO cards; inference engines bring their own attention kernels for SM120, as our software guide lists.

Cause 3: an old container image, or a driver older than the toolkit

The CUDA runtime and libraries come with the container image and the driver with the host, as our guide to NVIDIA driver branches and CUDA versions explains. An image built on a CUDA release older than 12.8 cannot contain sm_120 cubins, because CUDA 12.8 was the first toolkit to produce them; at best it carries PTX for an older target and runs after JIT compilation. Rebuild such images on a CUDA 12.8 or newer base, and rebuild the extensions inside them with 12.0 in the target list. TensorRT engines are a stricter case: an engine is built for one GPU type, and our page on serving vision models with Triton, ONNX and TensorRT explains why an engine built on an L4 does not load on an RTX PRO card.

The opposite mismatch gives a different error. When an image is newer than the host driver, PTX from the newer toolkit cannot be compiled by the older driver. vLLM's troubleshooting page lists "RuntimeError: CUDA error: the provided PTX was compiled with an unsupported toolchain" and "The NVIDIA driver on your system is too old" for this case. It offers a compatibility package as a workaround, which it says works only on select professional and data-centre GPUs; the lasting fix is a driver from a branch that pairs with the image's CUDA version. CUDA 13.0 pairs with R580, and both R580 and R595 list every RTX PRO 6000 edition.

JIT compilation is a stopgap

Software that runs on an RTX PRO card only through PTX works, with two costs. MathWorks describes a similar mechanism for MATLAB on Blackwell, with "a brief one-time delay" while the byte code is compiled and cached, and NVIDIA's guide notes that the driver caches the compiled cubins, "so this is often a one-time cost". PyTorch's documentation adds the performance cost of older PTX quoted above. For a production server, build native sm_120 code and keep PTX only as insurance for the next generation, for example with "12.0+PTX" as the last entry of the list.

Mixed fleets: one build for every card type

A company that runs H200 NVL servers next to RTX PRO 6000 Server Edition nodes, or keeps L40S cards in service, needs code for each capability in every image it deploys on both. The table gives the target list per fleet; our guides to mixing Ada and Blackwell GPUs and to H200 NVL and RTX PRO 6000 in one platform cover drivers, scheduling and node labels.

our recommendation from PyTorch's CUDAExtension documentation (2.14) and NVIDIA's Blackwell compatibility guide (12 October 2026). Builds that need architecture-specific a features need a separate image per target.

In Kubernetes, label the nodes with their compute capability and keep images built only for 12.0 off the Hopper and Ada nodes; GPU Feature Discovery publishes the label nvidia.com/gpu.compute.major for this, 12 on RTX PRO Blackwell and 8 on Ada, as the mixing guide shows, and 9 on the H200 NVL by its compute capability.

We build servers with RTX PRO 6000 Server Edition and H200 NVL cards for mixed fleets and install the driver branch your images need on request; tell us which cards you run today and which you plan, and we reply with a configuration for both.

FAQ