# Why does ComfyUI say 'no kernel image is available' after I changed GPU?

> Because the PyTorch build on this machine contains no GPU code for this card's generation: the files are fine, the build and the card don't match. Install a PyTorch build that covers this GPU, or rent the GPU generation the setup was built on. The other errors on this page are the same kind of problem: the machine, not your files.

Canonical page: https://renest.ai/answers/errors-after-gpu-change

<p>Every error on this page comes from the machine, not from missing files. Copying the
same folder again, or downloading the models again, won't change any of them. Each section
gives the error as it is usually pasted, what it means, what to do, and where Renest helps
and where it doesn't.</p>

<h2 id="no-kernel-image">"CUDA error: no kernel image is available for execution on the device"</h2>

<p>This means a compiled GPU package on this machine has no code for this card's
generation. It is usually PyTorch itself. It can also be a package with its own GPU code,
such as bitsandbytes, xformers or flash-attn. Each build carries machine code for a list of
GPU generations. A card newer than the list, or an older one that the build dropped, gets
this error the first time it runs real work. ComfyUI often starts normally and fails only
when you queue a prompt.</p>

<p>What to do:</p>

<ul>
  <li>Check which generations the installed PyTorch was built for, and which one this card
  is:</li>
</ul>

<pre>$ python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.get_arch_list())"
$ python -c "import torch; print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0))"</pre>

<ul>
  <li>If the card's capability (for example <code>(12, 0)</code>, written
  <code>sm_120</code>) is not in the list, install a PyTorch build that includes it, using
  the same Python that starts ComfyUI. The official install selector on pytorch.org gives
  the exact command for each CUDA build.</li>
  <li>If the error names a different package in its traceback, that package needs a build
  for this card too. Replacing PyTorch alone won't fix it.</li>
  <li>If you'd rather not change anything, rent the GPU generation the setup was built on.
  That is often the quickest fix on a rented machine.</li>
</ul>

<h2 id="sm-120">"sm_120 is not compatible with the current PyTorch installation"</h2>

<p>This is the warning PyTorch prints for the same mismatch, before it fails. sm_120 is the
compute capability of NVIDIA's RTX 50-series (Blackwell) cards. PyTorch builds for CUDA
releases older than 12.8 don't include it. The message lists the generations the installed
build supports.</p>

<p>What to do: install a PyTorch build for CUDA 12.8 or newer into ComfyUI's own Python, and
check the custom nodes that ship their own compiled code. The machine's driver must be new
enough for that CUDA build, which is the next error on this page. On Windows Portable,
downloading a recent Portable release, which ships a recent PyTorch, is often simpler than
replacing PyTorch by hand.</p>

<h2 id="driver-too-old">"The NVIDIA driver on your system is too old"</h2>

<p>This means the machine's GPU driver is older than the CUDA build of your PyTorch needs.
The driver belongs to the machine, not to your environment. On a rented container you can't
upgrade it. Some templates refuse to start for the same reason with a line like
<code>unsatisfied condition: cuda&gt;=12.8</code>.</p>

<p>What to do:</p>

<ul>
  <li>Rent a machine with a newer driver. On RunPod and vast.ai you can filter machines by
  the CUDA version their driver supports. Pick one at or above the CUDA version of your
  PyTorch build.</li>
  <li>Or install a PyTorch build for an older CUDA release, if that build still covers your
  card. On a new card it often doesn't.</li>
  <li><code>nvidia-smi</code> prints the driver version and the highest CUDA version it
  supports in its top line.</li>
</ul>

<h2 id="no-cuda-gpus">"No CUDA GPUs are available"</h2>

<p>On a rented machine this usually means the GPU can't be used at all, even though the
machine was sold with one. Run <code>nvidia-smi</code>. If it fails, or answers simple
questions but errors on real work, the machine's GPU is broken and nothing inside your
environment can fix it. Other causes: the container was started without GPU access,
<code>CUDA_VISIBLE_DEVICES</code> is set to an empty value, or the card isn't an NVIDIA
card.</p>

<p>What to do on a cloud machine: stop or terminate it and rent another. Don't spend time
reinstalling on a machine whose GPU doesn't answer.</p>

<h2 id="torch-not-compiled">"Torch not compiled with CUDA enabled"</h2>

<p>This means a CPU-only PyTorch is installed where the GPU build used to be. The usual
cause is a custom node's <code>requirements.txt</code> that installed or upgraded
<code>torch</code> from the default package index, which replaced the GPU build. It happens
most often on Windows, where the default index serves CPU-only builds.</p>

<p>What to do: remove the CPU-only build, then install the GPU build from PyTorch's own
package index into ComfyUI's Python. The install selector on pytorch.org gives the exact
command for each CUDA build; pick the one that matches your card and driver. Then check that
it reports a CUDA version:</p>

<pre>$ python -m pip uninstall -y torch torchvision torchaudio
$ python -c "import torch; print(torch.version.cuda, torch.cuda.is_available())"</pre>

<p>The first command runs before the install from pytorch.org, the second after it. On
Portable, run them with <code>python_embeded\python.exe -s -m pip</code> and
<code>python_embeded\python.exe</code> instead of <code>python -m pip</code> and
<code>python</code>. Afterwards, look at which custom node pulled in
<code>torch</code>, or the next install will undo the fix.</p>

<h2 id="illegal-instruction">"Illegal instruction (core dumped)"</h2>

<p>This means the CPU, not the GPU, lacks an instruction a compiled package uses. On rented
x86 machines the missing set is usually avx2, which many compiled packages in an AI
environment assume. The process dies with no Python traceback, often while importing.</p>

<p>What to do: check the CPU's instruction sets, and if avx2 is missing, rent another
machine. Software on that machine can't add it.</p>

<pre>$ grep -o -w avx2 /proc/cpuinfo | head -1</pre>

<p>An empty result means the CPU doesn't have avx2. The similar-looking error
<code>CUDA error: an illegal instruction was encountered</code> is a different problem. It
comes from GPU code, often after an update, not from the CPU.</p>

<h2 id="renest">What Renest checks before a restore, and what it doesn't do</h2>

<p>A Renest restore checks the machine before it downloads anything, so these mismatches
show up before the big download instead of after it. Before any file moves, it refuses:</p>

<ul>
  <li><strong>A GPU outside the generations the nest's PyTorch was built for.</strong> If
  the build carries a forward-compatible form for newer cards, it warns instead of
  refusing.</li>
  <li><strong>A driver older than the nest's CUDA build needs.</strong></li>
  <li><strong>An x86 CPU without avx2.</strong></li>
  <li><strong>A GPU the driver can't start CUDA on.</strong> The restore asks the driver
  directly; if it answers with an error, or finds no GPU when the nest needs one, the restore
  stops (<code>--force</code> carries on anyway).</li>
</ul>

<p>After it installs the dependencies, it asks the installed PyTorch which CUDA version it
reports. If that is a CPU-only build, or a different CUDA build from the one the nest
records, the restore stops there instead of handing you an environment that fails later.
The messages, their exit codes and fixes are in
<a href="/docs/troubleshooting#gpu">If a restore stops</a>.</p>

<p>What it doesn't do:</p>

<ul>
  <li><strong>It doesn't swap your PyTorch version.</strong> A nest carries the versions
  that worked on the machine you packed on. Whether a newer PyTorch would still run your
  custom nodes is a guess, and Renest doesn't make it. To move to a new GPU generation, get
  the setup working on that generation once, then pack it there.</li>
  <li><strong>It can't detect every broken machine.</strong> The check stops on a GPU the driver can't start, and warns on the other common signs of a GPU that doesn't answer. A machine can still pass the check and fail
  once real work starts, with <code>No CUDA GPUs are available</code>
  (<a href="/docs/troubleshooting#node">what to do</a>).</li>
  <li><strong>It doesn't fix the machine.</strong> When the machine is the problem, the
  answer is another machine. A restore code isn't tied to one machine, so you paste the same
  command on the next one.</li>
</ul>

<p>Why a set of verified files can still fail on a new machine, with the cases we measured:
<a href="/blog/verified-files-not-a-working-environment">Every file verified, environment
still dead</a>.</p>

<h2 id="not-renest">When Renest isn't the answer</h2>

<ul>
  <li><strong>You need your setup to run on a GPU generation it never ran on.</strong>
  That means new PyTorch builds and possibly new custom node versions. Do that work on the
  new card. Renest can carry the result once it works there.</li>
  <li><strong>The machine itself is broken</strong>: no GPU, wrong driver, no avx2. Replace
  the machine.</li>
  <li><strong>You run ComfyUI on your own Windows PC</strong> and changed the card. Update
  PyTorch inside the Portable folder. Renest restores onto Linux machines with an NVIDIA
  GPU; see <a href="/answers/when-you-dont-need-renest">When you don't need
  Renest</a>.</li>
</ul>

<p>Related: <a href="/answers/nodes-missing-after-move">Custom nodes missing or
IMPORT FAILED after a move</a> · <a href="/answers/when-is-a-move-finished">When is a
moved setup actually working?</a></p>