PantheonSim / No CUDA-capable device

CUDA error: no CUDA-capable device is detected

PantheonSim, the GPU simulator for CUDA and ROCm, can supply a CUDA device on a machine that has none, but on a real system this error has to be fixed where it comes from. It and torch.cuda.is_available() returning False mean the same thing: the CUDA runtime looked for a GPU it can use and found none. This page walks through the causes in the order worth checking them, then shows how to test the code path with no GPU.

What the error means

The message is the CUDA runtime's cudaErrorNoDevice, error code 100. It is returned when the runtime finds no CUDA-capable device it is allowed to use. That is not always a missing card. The card can be missing, the driver can be absent or not loaded, a container can have been started without access to the device, or an environment variable can be hiding the device. PyTorch reports the same situation by returning False from torch.cuda.is_available(), often with a warning that begins CUDA initialization that names the underlying error.

Check these in order

Run the commands on the machine where the program runs, not on your laptop. Stop at the first one that fails.

lspci | grep -i nvidia          # is there an NVIDIA device on the PCI bus?
nvidia-smi                      # does the driver talk to it?
lsmod | grep nvidia             # is the kernel module loaded?
ls -l /dev/nvidia*              # do the device files exist?
echo "[$CUDA_VISIBLE_DEVICES]"  # is something hiding the devices?
dmesg | grep -iE 'nvrm|xid'     # did the driver complain?

1. There is no GPU. If lspci shows no NVIDIA device, the machine has no card CUDA can use. This is the normal state of a CPU-only cloud instance, a laptop with only integrated graphics, and every GitHub-hosted runner. The fix is a machine with a GPU, or running the code somewhere that simulates one (see below).
2. The driver is not installed or not loaded. If nvidia-smi says it could not communicate with the NVIDIA driver, install the driver for your card, or load it. A common cause on a working machine is a kernel update that left the module unbuilt, so reinstall or rebuild it for the running kernel and reboot. Another is Secure Boot refusing an unsigned module; the kernel log says so.
3. The container cannot see the GPU. A GPU on the host does not appear in a container by itself. With Docker, install the NVIDIA Container Toolkit and start the container with --gpus all, then check with docker run --rm --gpus all ubuntu nvidia-smi. In Kubernetes, the pod needs a request for the nvidia.com/gpu resource and the cluster needs NVIDIA's device plugin. If /dev/nvidia* is missing inside the container, this is the cause.
4. CUDA_VISIBLE_DEVICES hides everything. An empty value, -1 or an index that does not exist leaves the program with no devices. Run unset CUDA_VISIBLE_DEVICES and try again. Job schedulers and notebook launchers set it, sometimes to an index on another node.
5. The GPU fell off the bus. If the driver loads but the card has stopped answering, the kernel log shows Xid errors. A reboot or a GPU reset is the usual cure, and repeated errors point to hardware, power or cooling.
6. You are inside WSL2. The GPU comes from the Windows driver. Install the NVIDIA driver on Windows and do not install a Linux display driver inside the WSL distribution.
7. A virtual machine without passthrough. A VM sees a GPU only when the hypervisor hands one through.

A neighbouring error is easy to mistake for this one. CUDA driver version is insufficient for CUDA runtime version means a device exists but the driver is older than the toolkit the program was built with. Update the driver, or build with an older toolkit.

When PyTorch says CUDA is not available

Everything above applies, and PyTorch adds one more cause that is its own: the wheel itself may not have CUDA in it. Check what you installed:

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

If torch.version.cuda prints None, or the version ends in +cpu, you have a build without CUDA support, and no driver fix will help. Install a CUDA build from PyTorch's own index instead, choosing the CUDA version your driver supports:

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

If it prints a CUDA version and False, go back to the list: the runtime is there and the device is not.

In CI and other machines with no GPU

On a runner or container with no GPU, this error is correct, not a bug. A test that needs a GPU has three honest options: run it on a GPU runner, skip it when no device is found, or run it against a simulated GPU. For the first two, make the code say what happened. Test for the device, and fail with a message that names the cause, instead of letting the raw CUDA error surface:

int n = 0;
cudaError_t err = cudaGetDeviceCount(&n);
if (err == cudaErrorNoDevice || n == 0) {
  fprintf(stderr, "no GPU here: run on a GPU runner or set the simulator up\n");
  return 77;   /* many test runners treat 77 as 'skipped' */
}

How the simulator helps

PantheonSim is an open source simulator that gives a program the CUDA driver, runtime and libraries on a machine with no GPU. It helps in two ways.

It supplies a device, so GPU code can run on a GPU-less machine. Build with the real nvcc, linking the runtime shared, and run under vgpu run. The program finds a simulated card, such as a T4:

nvcc -cudart shared my_app.cu -o my_app
build/vgpu run --gpu nvidia/t4 ./my_app

For PyTorch, the official CUDA 13 build runs unmodified; --preload is needed so PyTorch finds the simulator's libraries and not NVIDIA's:

build/vgpu run --gpu nvidia/t4 --preload python -c "import torch; print(torch.cuda.is_available())"

The PyTorch guide covers what is supported.

It reproduces the no-device case on purpose. The simulator reads CUDA_VISIBLE_DEVICES by the driver's rules, so a value that shows no device (an empty value, an index past the last, or text that is not a number) gives cudaErrorNoDevice (100) from every runtime call. That lets you test your own handling of the error without taking a GPU away from a machine:

CUDA_VISIBLE_DEVICES=5 build/vgpu run --gpu nvidia/t4 ./my_app    # one device exists, 5 names none

The simulator does not fix a real machine. If production reports this error, the checklist above is the cure. What the simulator gives you is a way to check that the code works when a device exists, and fails clearly when none does, before it reaches a machine with a GPU. It checks behaviour, not speed, so keep a run on real hardware.

Questions

Next steps

To test GPU code in continuous integration without GPU runners, see CUDA and HIP tests in GitHub Actions. To try a simulated machine now, open the playground, read the docs, or see how the simulated nvidia-smi reports a machine.