"No Kernel Image Is Available" on RTX 50: sm_120 Fix

Your card needs sm_120 and something in your stack was compiled without it — most often PyTorch itself, because the CUDA 12.6 wheels on pytorch.org are built for compute capabilities 5.0 through 9.0 and stop there. Every GeForce RTX 50-series card reports compute capability 12.0. Run one command to see the mismatch, and one more to fix it:

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

If the arch list ends at sm_90 while the capability prints (12, 0), you have found the bug and the fix is a CUDA 13.x wheel:

pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu130

If the arch list does contain sm_120 and the error still fires, PyTorch is innocent and a second compiled wheel — xformers, flash-attn, bitsandbytes, sageattention, or a ComfyUI custom node — is the one missing your architecture. That case is section three, and it is why "just install CUDA 12.8" works for some people and not others.

---

What the Error Actually Means

It is a linker-level miss, not a driver problem. nvidia-smi will keep working perfectly while every kernel launch fails.

The exact string people paste into Google is:

RuntimeError: CUDA error: no kernel image is available for execution on this device

CUDA kernels are compiled ahead of time into architecture-specific machine code (cubins, tagged sm_XX) and packed into a fat binary. At launch, the runtime looks for a cubin matching your GPU. If it finds none — and there is no PTX intermediate to JIT-compile from — you get this error. Your driver is fine. Your toolkit is fine. The binary you are running simply does not contain code for your card.

Blackwell made this common again because it introduced a new compute capability that older builds cannot possibly contain. Years after launch it is still one of the most-reported Blackwell failures, because the long tail of local-AI projects pins older torch versions in requirements.txt — search GitHub for "no kernel image is available" is:issue and scan the dates yourself if you want a sense of the volume.

Which cards report what

Per NVIDIA's CUDA GPUs compute-capability list:

Note the correction there: RTX PRO Blackwell workstation cards are 12.0, not 12.1. Only GB10 is 12.1, and it needs less special handling than the internet implies — see the sm_120-vs-sm_121 section.

---

Step 1: Localise the Fault

Do not upgrade anything yet. Print the arch list first — it takes ten seconds and tells you whether this is a PyTorch problem or a second-wheel problem.

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

Read it against this table, which is PyTorch's own release build matrix — the values it feeds to TORCH_CUDA_ARCH_LIST when it compiles the wheels it publishes:

Source: .ci/manywheel/build_env_setup.py and .github/scripts/generate_binary_build_matrix.py in pytorch/pytorch, read 2026-08-18. The stable CUDA version in that matrix is 13.0.

Two things fall out of this table that are worth internalising:

1. cu126 has no Blackwell support and never will. It is retained for older hardware — it is the only current index that still carries sm_50 and sm_60, i.e. Maxwell and Pascal. If you clicked "CUDA 12.6" on pytorch.org because it looked like the safe conservative option, that choice is the entire bug.
2. cu130 and later dropped everything below sm_75. Turing (RTX 20-series) is the floor. A 10-series card on a CUDA 13.x wheel throws this same error from the opposite direction.

There is a third fact with no visible tell: PyTorch's build config emits PTX for compute capability 12.0 on nightly/dev builds only — release and RC wheels ship SASS exclusively, to keep the library size down. So a stable wheel has no JIT fallback path. Either your architecture is in the compiled list or the launch fails. This is why "it works on nightly" reports exist and are not superstition.

---

Step 2: Fix PyTorch

If your arch list stopped at sm_90, install a CUDA 13.x build. As of 2026-08-18 PyTorch's build matrix carries four CUDA targets — 12.6, 13.0, 13.2 and 13.4 — with 13.0 as the stable default, and 12.8 is not among them.

That last point is worth saying loudly, because the most-copied advice on this error is still "install the cu128 wheel". That was correct in 2025. The build matrix has moved twice since — the old cu128 index still resolves, so the command appears to work, but it is no longer a version PyTorch builds for. The install commands for the current indexes:

# CUDA 13.0 — the stable default in PyTorch's build matrix
pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu130

# CUDA 13.2 — newer option, same Blackwell support
pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu132

# CUDA 12.6 — only if you are on Maxwell/Pascal. NOT for RTX 50-series.
pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu126

Uninstall first if you are switching indexes, otherwise pip may keep the old build:

pip uninstall -y torch torchvision torchaudio
pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu130
python -c "import torch; print(torch.cuda.get_arch_list())"

The last line is not optional. Confirm sm_120 is in the list before you go looking for another cause.

About the driver and the system CUDA toolkit

The pip wheels bundle their own CUDA runtime, so a separately installed CUDA Toolkit is almost never what is broken — you do not need to install CUDA 13 system-wide to use a cu130 wheel. The driver is the one system component that must be new enough for the runtime, and it is the only place "update your drivers" is legitimate advice. ComfyUI's own README says as much for its bundled build: the standard Windows portable "comes with python 3.13 and pytorch cuda 13.0. Update your Nvidia drivers if it doesn't start."

If PyTorch now reports sm_120 and imports cleanly, but your workload still throws the error, move to step 3.

---

Step 3: The Second Wheel

This is the case the popular advice misses. Four libraries account for most of it, and each one can be checked directly rather than guessed at.

Any package that ships pre-compiled CUDA kernels has its own architecture list, independent of PyTorch's. A wheel built when sm_120 did not exist will throw this error inside an otherwise perfectly configured environment.

The universal check: look inside the binary

NVIDIA's cuobjdump lists the cubins embedded in any host binary, object file or library, and names them by architecture. From NVIDIA's own documented example output:

$ cuobjdump a.out -lelf
ELF file    1: add_new.sm_100.cubin
ELF file    2: add_new.sm_120.cubin
ELF file    3: add_old.sm_100.cubin
ELF file    4: add_old.sm_120.cubin

Point it at the suspect extension — the .so on Linux, the .pyd on Windows — inside your site-packages:

# Find the compiled extension, then list its architectures
python -c "import xformers, os; print(os.path.dirname(xformers.__file__))"
cuobjdump -lelf /path/to/site-packages/xformers/_C.so | head

No sm_120 in that output means that library is your culprit, full stop. cuobjdump ships with the CUDA Toolkit; if you have no toolkit installed, use the per-project checks below instead.

The four usual offenders

Deliberately no version numbers in that table: they change faster than any article can, and a stale "install version X" line is how people end up back where they started. Open the releases page, take the newest build that lists your torch and Python version, and verify it with cuobjdump rather than trusting the tag.

The rule that saves time: reinstall the extension, not PyTorch. Once torch reports sm_120, replacing torch again changes nothing and costs you a 3GB download. Get a wheel of the extension that matches your torch version, your CUDA build and your Python minor version — all four have to line up — or build it yourself with the architecture set explicitly.

---

sm_120 vs sm_121: What DGX Spark Owners Need

GB10 reports compute capability 12.1, and it does not need an sm_121-specific build. An sm_120 cubin is valid on it.

NVIDIA's compatibility rule is that a cubin is compatible with devices of the same major compute-capability revision at an equal or higher minor revision, and incompatible across major revisions. 12.0 code on a 12.1 device is therefore fine; 9.0 code on a 12.x device is not.

You can see PyTorch relying on this directly. Its aarch64 CUDA 13.x wheels — the ones a Grace-based DGX Spark or ASUS Ascent GX10 installs — are compiled for compute capabilities 8.0, 9.0, 10.0, 11.0 and 12.0. There is no 12.1 in that list, and the wheels work. So if you own one of these boxes and someone tells you that you need a special sm_121 build, they are guessing. What you need is the same CUDA 13.x wheel as everyone else.

Where sm_121 does matter is when a project hardcodes architecture lists for its own builds and enumerates only 12.0, or when it detects your capability, reads 12.1, and refuses to proceed. That is a project bug, not a hardware limitation, and the workaround is usually to override the detection with TORCH_CUDA_ARCH_LIST.

If you are still choosing hardware in this class, our GPU prices and memory shortage breakdown covers where the GB10 boxes sit against discrete cards, and the hardware hub has the full picture.

---

Building From Source

When no prebuilt wheel exists for your combination, compile with the architecture pinned explicitly. One environment variable controls it.

# RTX 50-series / RTX PRO Blackwell (and valid on GB10 too)
export TORCH_CUDA_ARCH_LIST="12.0"

# Add a PTX target if you want a JIT fallback for future architectures
export TORCH_CUDA_ARCH_LIST="12.0+PTX"

# Multiple targets, semicolon-separated — this is the exact format
# PyTorch's own build scripts generate for their release wheels
export TORCH_CUDA_ARCH_LIST="8.0;8.6;9.0;12.0+PTX"

pip install --no-build-isolation -e .

Three things that go wrong here:

• Use the dotted form, 12.0, not sm_120. The variable takes compute-capability numbers.
• +PTX costs build time and binary size but buys forward compatibility on architectures released after your build. PyTorch's release wheels deliberately skip it; your one-off build can afford it.
• Your CUDA Toolkit must be new enough to know about the architecture at all. If nvcc rejects compute_120, the toolkit predates Blackwell support and no environment variable will help — install a CUDA 13.x toolkit.

Also set it before building anything that compiles CUDA kernels through PyTorch's extension machinery, which includes sageattention, most flash-attn source builds, and a good number of ComfyUI custom nodes.

---

ComfyUI-Specific Traps

Two ComfyUI-specific ways to land here, both avoidable.

First, the download. ComfyUI publishes more than one Windows portable package, and the older-hardware variant is a loaded gun for 50-series owners. From the official README: the standard NVIDIA portable "supports 20 series and above" and ships PyTorch CUDA 13.0, while the separate cu126 portable is labelled for "Nvidia 10 series and older GPUs, DO NOT USE THIS ON NEWER 20 SERIES AND ABOVE GPUS." Those capitals are theirs. Grab the cu126 package for a 5090 and this error is the guaranteed result — and the arch table above explains precisely why.

Second, custom nodes. A node that ships or builds its own CUDA kernels has its own architecture list, and installing it can also move your torch version underneath every other compiled extension you have. If your ComfyUI console shows import failures rather than a runtime CUDA error, that is a different problem with a different method: read the traceback logged just above the Cannot import line at startup, and start from the general local AI troubleshooting guide. If nodes import fine and generation dies with the kernel-image error, run the step-1 command inside ComfyUI's own Python and work through this page.

Once everything runs, the ComfyUI complete guide and our CUDA optimization notes cover getting speed out of the card you just fixed.

---

Where This Page's Facts Come From

Being straight about the evidence, because on this topic the wrong number costs you a 3GB download and an afternoon:

• Nothing here is a measurement. Every architecture figure on this page is read from a primary source: PyTorch's published build matrix for the per-wheel architecture lists, NVIDIA's CUDA GPUs list for per-product compute capabilities, and NVIDIA's binary-utilities documentation for the cuobjdump output format. All of those are linked in the sources section — go read them if a claim here matters to your decision.
• No tokens-per-second claims appear anywhere on this page, and that is deliberate. Whether a wheel contains sm_120 is a fact about a binary that you can check on your own machine in ten seconds; how fast a 5090 generates is a measurement, and this page has none to offer.
• Version numbers rot fast. PyTorch's CUDA build targets have changed more than once during Blackwell's life — cu128 was the answer for most of 2025 and is not a build target today. Check the selector on pytorch.org rather than trusting any article's copy-paste, including this one, and use the arch-list command as your ground truth. The command never goes stale; the version numbers always do.
• What no article can tell you is whether a given third-party wheel supports your card, because that changes weekly and per project. That is exactly why the cuobjdump -lelf check is the centre of this page: it answers the question for any binary, without waiting for anyone to update a compatibility table.

Still picking a card? RTX 5090 vs 5080 and the RTX 5070 12GB write-up cover what fits in each, and the RTX 5060 Ti 16GB page covers the cheapest 16GB Blackwell option.

---

Sources

• pytorch/pytorch — .ci/manywheel/build_env_setup.py (TORCH_CUDA_ARCH_LIST_TABLE, PTX arch policy) and .github/scripts/generate_binary_build_matrix.py (CUDA_ARCHES, CUDA_STABLE), read 2026-08-18. These two files are the authoritative answer to "which architectures are in this wheel" — open them on main for the current state.
• PyTorch — Get Started Locally — the stable pip install commands and CUDA index options offered on 2026-08-18.
• NVIDIA — CUDA GPUs compute capability list — per-product compute capabilities for GeForce RTX 50-series, RTX PRO Blackwell and GB10.
• NVIDIA — CUDA Binary Utilities — cuobjdump --list-elf behaviour and sample output.
• NVIDIA — CUDA compatibility documentation — cubin compatibility across minor and major compute-capability revisions.
• facebookresearch/xformers, Dao-AILab/flash-attention, bitsandbytes-foundation/bitsandbytes, thu-ml/SageAttention — each project's README and releases page for the diagnostic commands quoted above.
• Comfy-Org/ComfyUI — README portable-package descriptions and CUDA build notes.

---

FAQ