Error messages

RuntimeError: Cannot re-initialize CUDA in forked subprocess

RuntimeError: Cannot re-initialize CUDA in forked subprocess

vLLM starts loading, then a worker process falls over with a traceback that ends:

RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you must use the 'spawn' start method

The text is PyTorch's (it's still there in PyTorch 2.14.0), and vLLM hits it more than most libraries because it splits itself across several processes. 34 issues in the vLLM repo quote it as of September 26, 2026, and several of the recent ones come from vLLM's own automated tests.

What fork and spawn mean here

Python can start a child process two ways. Fork makes an instant copy of the running process, memory and all. Spawn starts a fresh Python and re-imports your script. Fork is faster and it's vLLM's default (VLLM_WORKER_MULTIPROC_METHOD defaults to fork in 0.30.0).

The catch is the GPU. Once a process has set up CUDA, a forked copy inherits a half-copied GPU state it can't safely use, so PyTorch refuses and raises this error the moment the child tries.

What vLLM already does about it

We read vLLM 0.30.0. Before starting workers it checks whether CUDA is already set up in the parent (and a few other cases, such as running under WSL or inside Ray) and, if so, switches to spawn by itself. You'll see a warning that begins We must use the `spawn` multiprocessing start method. Overriding VLLM_WORKER_MULTIPROC_METHOD to 'spawn'. and lists the reason.

So when the error still appears, something slipped past that check. The vLLM docs name the common one: calling GPU functions yourself (their example is torch.accelerator.set_device_index) before creating the engine. Add-ons that bring their own process handling can trip it too, as in #29591 with the LMCache example.

How to fix it

First, move any GPU work to after the LLM(...) or engine is created. If you were only choosing which cards to use, set CUDA_VISIBLE_DEVICES in the environment instead, which is what the docs recommend.

Second, force spawn from the start:

export VLLM_WORKER_MULTIPROC_METHOD=spawn

Spawn re-imports your script in each child, so a script with vLLM calls at the top level will try to start the engine again inside every worker. vLLM's troubleshooting page covers this. The symptom is a different RuntimeError, "An attempt has been made to start a new process before the current process has finished its bootstrapping phase", and the fix is to wrap your code:

if __name__ == '__main__':
    import vllm

    llm = vllm.LLM(...)

That example is copied from the docs, and it's the whole change: imports and engine creation move inside the guard.

If you're using vllm serve and never wrote any Python, the error points at vLLM itself or something it loaded. Update vLLM, then search the issues with the name of whichever extension or flag you've added.