## TL;DR

Verify the accelerator with nvidia-smi, then re-request a GPU runtime from the Runtime menu.
Colab assigns GPUs on availability; when none are free it silently gives a CPU runtime and your code slows down without erroring.
Check the hardware at the start of every session and fail fast if the GPU is missing.

```text
colab GPU runtime unavailable: silently fell back to CPU
```

## Use this when

- Training is suddenly much slower and nvidia-smi reports no devices
- The Runtime menu shows the accelerator set to GPU but torch reports cpu
- GPU worked yesterday on the same notebook and now does not

## Not for this skill when

- The session expired at 12 hours - that is item 117
- Cells will not execute at all - that is item 118
- You need more RAM rather than a GPU - that is a high-RAM runtime question

## Steps

1. Check what you actually got: run nvidia-smi in a cell.
   Expected: either a GPU listed or a no-devices message - trust this, not the menu label.

2. Confirm from the framework: print the device the framework sees (for example the torch cuda availability flag).
   Expected: agreement with nvidia-smi.

3. Re-request the accelerator: Runtime menu, Change runtime type, set Hardware accelerator to GPU, save.
   Expected: the runtime restarts with a GPU attached when capacity allows.

4. Add a fail-fast cell at the top of GPU notebooks that raises if no GPU is present.
   Expected: future silent fallbacks become loud immediate errors.

5. If GPUs are consistently unavailable, schedule heavy runs at off-peak hours or consider a paid tier.
   Expected: higher GPU assignment rates.

## Tool compatibility

Google Colab, NVIDIA drivers via nvidia-smi, PyTorch / TensorFlow / JAX

## Variant phrasings

### colab GPU unavailable fell back to CPU

Same fix applies: see the Steps section above.

### colab no GPU assigned silently CPU

Same fix applies: see the Steps section above.

### colab runtime type GPU but no cuda device

Same fix applies: see the Steps section above.

## Why it happens

Colab's free GPU pool is shared and finite. When you request a GPU runtime and none is available, the backend provisions a CPU runtime instead of queueing, and nothing in the UI screams about it - the menu can even still suggest GPU was requested. Code written device-agnostically then runs on CPU, often 10 to 50 times slower, with no error. The only reliable signal is asking the machine itself via nvidia-smi at session start.

## Edge cases / pitfalls

- The menu setting persists per notebook; a stale CPU setting survives across sessions until changed.
- Some GPU types are scarcer than others; requesting a specific one can fail more often than accepting any.
- Fail-fast cells save hours of slow training discovered too late.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TsVUz4KkdmI1tU13ozf8zw