How to Clear GPU VRAM Without Rebooting

If your GPU shows "out of memory" errors even after your training job finished, or a game crashed and left VRAM full, you don't always need to restart your machine. In most cases you can free stuck video memory in under a minute using a few simple commands. This guide walks through the exact steps for both Linux and Windows, why VRAM gets "stuck" in the first place, and how to stop it from happening again.

This is especially common on machines running heavy AI workloads or rendering jobs, like the kind you'd run on a dedicated GPU server, where multiple scripts or users may be sharing the same card.

Why Does VRAM Stay Full After a Process Ends?

Video memory (VRAM) is allocated by the GPU driver on behalf of a program. Normally, when a program exits cleanly, the driver releases that memory automatically. But VRAM can stay "stuck" when:

• A process crashed instead of shutting down cleanly (common with PyTorch, TensorFlow, or CUDA scripts)

• A zombie process is still technically running in the background

• The GPU driver itself has entered a bad state after a crash

• A remote desktop or virtual session left an orphaned graphics context open

• Memory fragmentation inside a framework's memory pool (this looks like "full" VRAM but is actually a caching behavior)

Knowing which of these applies to your situation decides which fix below you should try first.

Step 1: Check Current VRAM Usage

Before doing anything, check what's actually using memory. On Linux or Windows (with the CUDA toolkit installed), open a terminal and run:

nvidia-smi

This shows total VRAM, memory used, GPU utilization, and — importantly — a process list at the bottom with the PID of anything holding memory. If that list is empty but memory usage is still high, you're dealing with driver-level memory, not a live process, and you'll want the reset method further down.

Method 1: Kill the Specific Process (Fastest Fix)

If nvidia-smi shows a process still attached to the GPU, this is usually the quickest and safest fix. Find the process ID (PID) in the output, then run:

sudo kill -9 <PID>

Run nvidia-smi again to confirm the memory has been released. This approach only affects the one stuck process and won't interrupt anything else running on the GPU, which matters if you're on a shared or multi-tenant GPU dedicated server.

Method 2: Clear the Framework's Memory Cache

If you're working inside a Python session and the process is still alive but memory usage looks abnormally high, the issue is often just caching, not a real leak. PyTorch and similar frameworks hold onto memory for reuse rather than releasing it back to the OS. Clear it with:

import torch
torch.cuda.empty_cache()

This won't free memory that's actively in use by tensors still referenced in your code, so pair it with del on unused variables first, then run garbage collection:

del model, optimizer
import gc
gc.collect()
torch.cuda.empty_cache()

Method 3: Reset the GPU Without Rebooting (Linux)

When no process is attached but VRAM usage is still stuck, or the GPU shows as "unresponsive," you can reset the device itself without touching the rest of the operating system:

sudo nvidia-smi --gpu-reset -i 0

Replace 0 with the correct GPU index if you have multiple cards. Note that this command only works when no process is using the GPU, so make sure nothing is attached first. On servers where the driver refuses a live reset, you can instead unbind and rebind the GPU from the PCIe bus:

sudo nvidia-smi --query-gpu=pci.bus_id --format=csv,noheader
echo 1 | sudo tee /sys/bus/pci/devices/<bus_id>/remove
echo 1 | sudo tee /sys/bus/pci/rescan

This forces the kernel to re-detect the card as if it were freshly plugged in, clearing its memory state completely.

Method 4: Restart the Display Driver Only (Windows)

On Windows, you don't need to reboot to reset a stuck GPU. Press:

Ctrl + Shift + Win + B

This restarts the graphics driver in place — your screen will flicker briefly, but no applications close and no reboot happens. For headless Windows servers running CUDA workloads, you can also restart the display driver service directly through Device Manager by disabling and re-enabling the GPU entry, or by restarting the relevant service in services.msc.

When You Actually Need a Reboot

A full reboot is only necessary if:

• The GPU has dropped off the PCIe bus entirely and nvidia-smi returns no output at all

• ECC memory errors are being reported (common on data center cards under heavy compute load)

• A kernel-level driver crash has left the system in an unstable state

• Multiple reset attempts fail and the card is still unresponsive

If you're consistently running into this on a production workload, it may be a sign you need more headroom. Comparing options across GTZHost's GPU server plans or checking specs on the GPU dedicated servers – USA page can help you match the card to your actual workload instead of pushing one GPU past its limits.

Preventing VRAM Leaks Going Forward

A few habits go a long way toward avoiding this problem entirely:

• Always release resources explicitly in long-running scripts, especially in try/finally blocks so a crash doesn't leave a dangling process.

• Use watch -n 5 nvidia-smi to monitor VRAM in real time while testing new training scripts.

• Set persistence mode on (sudo nvidia-smi -pm 1) on servers, which keeps the driver loaded consistently and reduces state-related resets.

• Isolate workloads where possible using containers or MIG partitioning, so one crashed job can't affect memory for the rest of the GPU.

• Monitor for zombie processes with ps aux | grep python (or your framework of choice) alongside nvidia-smi, since a process can vanish from one list but linger in the other.

Next Steps

Need more VRAM headroom instead of constantly resetting it? Talk to the team through GTZHost's contact page about sizing a GPU server for your workload.