If you have ever started ComfyUI from a fresh clone, a new conda environment, or after an update and been greeted with AssertionError: Torch not compiled with CUDA enabled, you already know how it feels: the error reads like a hardware verdict, but it almost never is one. The message is not telling you that your GPU is broken or that your driver is wrong (at least not first). It is telling you that the Python process ComfyUI just booted is running a build of PyTorch that does not include CUDA support, or that it cannot see a CUDA-capable device through the torch it actually imported.
This article walks through what the error actually means, how to confirm which of the three or four common root causes you are hitting, and how to fix it without nuking your whole installation. No fake benchmarks, no invented output — every diagnostic command below is one you can run yourself, and the environment evidence shown here was captured on a real machine.
What "Torch Not Compiled with CUDA Enabled" Actually Means
ComfyUI calls torch.cuda.is_available() (or a closely related assertion) early in startup. If that check returns False, ComfyUI refuses to continue on a GPU path and raises the AssertionError we are talking about. The important thing to internalize is the distinction between two different questions:
Is my GPU physically present and functioning? This is answered by nvidia-smi, the NVIDIA driver, and the OS — completely outside Python.
Does the torch that THIS Python process imported see CUDA? This is answered by torch.cuda.is_available() and torch.version.cuda, and it depends entirely on *which* Python interpreter ran and *which* PyTorch wheel is installed for it.
Almost every real-world case of this error is a failure of the second question, not the first. The GPU is fine; the Python environment is pointing somewhere wrong.
Diagnose Before You Fix: The Three Questions in Order
Before touching anything, capture three pieces of ground truth. On a real Ubuntu host, here is the output these commands produced:
$ which -a python3 python
/home/ubuntu/.hermes/hermes-agent/venv/bin/python3
/usr/bin/python3
/bin/python3
/home/ubuntu/.hermes/hermes-agent/venv/bin/python
$ python3 --version
Python 3.11.16
$ pip3 --version
pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12)
Look closely at that output. There are three different python3 binaries on the PATH, and the python3 --version reports 3.11.16 while pip3 --version reports it is bound to Python 3.12. That mismatch — python3 and pip3 pointing at two different interpreters — is the root cause of a huge fraction of “Torch not compiled with CUDA enabled” reports. You install torch with one interpreter, then launch ComfyUI with a different one that has no torch (or has a CPU-only torch).
Question 1: Does the OS see the GPU at all?
nvidia-smi
If this prints a table with your GPU, driver version, and CUDA version, the hardware and driver are fine. If it errors with command not found or No devices were found, stop here — this is a driver/installation problem, not a torch problem, and you should install the NVIDIA driver before doing anything else. On the host used for this article there is no nvidia-smi at all, which is exactly why the next question is decisive.
Question 2: Which Python is ComfyUI actually launching with?
ComfyUI runs under *some* specific interpreter. If you started it from a conda env, a venv, a system Python, or a portable install, the answer changes. Capture the interpreter’s identity and its torch in one shot:
python -c "import sys, torch; print(sys.executable); print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available())"
Run that with the *exact same* python (or python3) command you use to launch ComfyUI. If it raises ModuleNotFoundError: No module named 'torch', the interpreter you are launching with simply does not have PyTorch installed — the message was not about CUDA at all, there is just no torch to check. That is precisely what happened on the machine captured here:
$ python3 -c "import torch; ..."
ModuleNotFoundError: No module named 'torch'
Question 3: Is the torch you DO have a CUDA build or a CPU build?
Once import torch succeeds, the two values that matter are:
import torch
print(torch.version.cuda) # e.g. "12.4" or None
print(torch.cuda.is_available()) # True or False
If torch.version.cuda is None, you installed the CPU-only wheel of PyTorch. This is the single most common cause of the error. The pip install torch default on many systems pulls the CPU build; you need the CUDA-indexed wheel from PyTorch.org’s command generator instead.
If torch.version.cuda prints a version (e.g. 12.4) but is_available() is False, the torch is a CUDA build but cannot talk to a device — usually a driver/runtime version mismatch or a missing libcudart lookup.
Fix 1: Install the Correct CUDA PyTorch Build
The authoritative way to get a CUDA-enabled torch is not a bare pip install torch. It is the command from the official PyTorch Get Started page, which lets you pick your OS, package manager, and CUDA version and returns an index URL. On Linux with pip and CUDA 12.4, it looks like this:
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
The --index-url is the part that people omit. Without it, pip installs the stock CPU-indexed wheel from PyPI, and you get torch.version.cuda == None followed by the very AssertionError this article is about.
Fix 2: Make the Interpreter and the Installer the Same One
The environment evidence above shows the mismatch in the wild: python3 is the venv at Python 3.11, while pip3 belongs to the system Python 3.12. If you pip install torch in that state, you may install it into 3.12 while ComfyUI launches with 3.11 (or vice versa). The fix is to always install *through* the interpreter you will launch with, using the -m pip form, which guarantees the package lands where that interpreter can see it:
python3 -m pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
python -m pip always installs into the environment of the python you invoked. pip (or pip3) alone depends on your PATH and can silently target a different Python. When the venv has no pip module at all (No module named pip — as captured here), bootstrap it with python3 -m ensurepip or recreate the venv cleanly, then use python3 -m pip from then on.
Fix 3: Validate the Toolchain After You Change Anything
After reinstalling, do not trust the installer’s exit code. Re-run the ground-truth check with the same interpreter ComfyUI will use:
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"
You want all three healthy: a torch.__version__ that matches what you just installed, a torch.version.cuda that is a real version string (not None), and torch.cuda.is_available() returning True. Only then relaunch ComfyUI. If ComfyUI still raises the assertion after all three are green, the remaining suspects are a launch wrapper that injects its own environment (portable bundles, run_nvidia_gpu.bat on Windows, or a CONDA_PREFIX pointing elsewhere) rather than torch itself.
Common Traps That Fake You Out
The portable install trap.** On Windows, the portable ComfyUI bundles its own embedded Python. Installing torch into a system Python or a separate conda env changes nothing for the portable build — you must install into the portable bundle’s own python_embeded interpreter, or switch to the git/manual install.
The “but it worked yesterday” trap.** An update (torch or ComfyUI) can pull a CPU wheel or a different CUDA minor version. If the error appeared immediately after an update, the diff is almost always environmental, not a hardware regression.
The conda/PATH trap.** If conda and system Python both exist, your launch shell’s PATH decides which python ComfyUI actually runs. conda activate in one terminal does nothing for a launch from a different terminal or a service manager.
The nvidia-smi-still-shows-GPU trap.** nvidia-smi reporting a GPU does not mean your torch sees it. nvidia-smi lives at the driver level; torch.cuda.is_available() lives at the Python-package level. Both have to be healthy.
Verification Checklist
Work through these in order and you will land on the real cause instead of reinstalling everything blindly:
nvidia-smi shows the GPU and driver — confirms hardware/driver, not torch.
which -a python3 python reveals how many interpreters are in play and which is first on PATH.
python -c "import sys; print(sys.executable)" names the exact interpreter ComfyUI will use.
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())" confirms torch exists, is a CUDA build, and can see the device.
Only after all four pass, relaunch ComfyUI and confirm the error is gone.
If you got this far and are still on CPU, the issue is outside torch (driver version, libcudart path, or a wrapper injecting its own environment), and the next step is collecting ComfyUI’s full startup log rather than re-reinstalling torch a second time.
Conclusion
“Torch not compiled with CUDA enabled” is a Python-environment diagnosis wearing a hardware-error costume. The GPU is almost always fine. What is broken is the chain between the interpreter you *launched* and the torch build you *installed* — a wrong python on PATH, a pip bound to a different interpreter, a CPU-only wheel pulled because the --index-url was omitted, or an update that silently swapped your torch build. Confirm the hardware once, then interrogate the interpreter, then install CUDA-enabled torch *through* that same interpreter, and re-verify with torch.cuda.is_available(). Fix those links and the assertion disappears — without touching your driver and without reinstalling ComfyUI.
For a deeper look at what CUDA out-of-memory symptoms look like once you *are* on the GPU, see llama.cpp “CUDA Out of Memory” on a 16GB card. For the authoritative install matrix, use the PyTorch Get Started page and the torch.cuda.is_available documentation.
Leave a Reply