Using Your Nvidia GPU VRAM as Swap Space on Linux
Most Linux workstations doing serious compute work share a familiar failure mode: the CPU is spinning, the disk light is solid amber, and the system has ground to a near-halt because RAM ran out and the kernel is swapping to an NVMe — or worse, a spinning disk. Meanwhile, a few centimetres away on the PCIe bus, a GPU is sitting on 12, 16, or 24 gigabytes of some of the fastest memory ever put into a consumer device. Completely unused.
A tool called nbd-vram makes that VRAM available as a Network Block Device (NBD), which Linux can then treat as a regular block device — and therefore as swap space or even a temporary filesystem.
How It Actually Works
The approach is elegant in its simplicity. NBD is a long-standing Linux kernel feature that lets a block device be served over a socket. Normally that socket goes over a network, but nothing stops it from being a local Unix socket or loopback interface.
nbd-vram allocates a region of GPU VRAM using CUDA, exposes it as an NBD server, and hands Linux a /dev/nbdX device node. From that point on, the kernel has no idea it's talking to GPU memory. You can run mkswap, swapon, format it as ext4, or use it however a block device allows.
# Start the nbd-vram server backed by 4 GB of VRAM
sudo nbd-vram --size 4G --socket /tmp/vram.sock
# Connect the kernel NBD client
sudo nbd-client -unix /tmp/vram.sock /dev/nbd0
# Use it as swap
sudo mkswap /dev/nbd0
sudo swapon /dev/nbd0 --priority 100
Setting a high --priority tells the kernel to prefer this swap partition over any slower alternatives. Pages will be evicted to VRAM before they ever touch disk.
Why VRAM Makes an Unusually Good Swap Tier
Modern GDDR6X and HBM memory operates at memory bandwidths that are 10–30× what even the fastest NVMe SSDs can sustain. Swap latency is dominated by two things: bandwidth for large sequential evictions and random-access latency for page faults. VRAM wins decisively on bandwidth; latency is higher than system DRAM but orders of magnitude better than any persistent storage medium.
The realistic use cases break into a few clear buckets:
- ML inference and fine-tuning rigs where the model fits partly in CPU RAM but keeps spilling. Routing overflow pages to VRAM instead of disk can keep a training loop alive rather than OOM-killing it.
- Compilation and build servers with large link steps. A Rust or C++ full rebuild can briefly spike RAM usage well past installed capacity.
- Data engineering workloads where a Pandas or Polars operation materialises an unexpectedly large intermediate frame.
- Virtualisation hosts running GPU-passthrough VMs where the host itself is memory-constrained.
The Limitations Worth Knowing
This is not a silver bullet, and being honest about the constraints matters before you architect anything around it.
VRAM is shared. If you allocate 8 GB of a 12 GB card for swap, your GPU workloads have 4 GB left. On a dedicated inference server that's a real trade-off. On a developer workstation that mostly runs CPU work with occasional GPU bursts, the trade-off is far more acceptable.
PCIe bandwidth is the bottleneck, not VRAM bandwidth. Data moving between CPU and GPU travels over the PCIe bus, which tops out around 16 GB/s on a x16 Gen 4 slot. That's still faster than most NVMe drives under swap pressure, but it's far below VRAM's raw bandwidth spec. Expect real-world swap throughput in the 8–14 GB/s range rather than the 600+ GB/s the memory chips themselves can sustain.
No persistence across reboots. VRAM is volatile. Swap data lives only as long as the card is powered and the driver is loaded. This is actually fine for swap — you never want swap to persist — but it means this device cannot double as durable storage.
Driver and CUDA dependency. This requires the proprietary Nvidia driver stack and a CUDA installation. AMD GPU support via ROCm would require a different implementation, though the NBD approach itself is hardware-agnostic in principle.
What This Signals About the Memory Hierarchy
The more interesting story here is architectural. The classical memory hierarchy — registers, L1/L2/L3 cache, DRAM, NVMe, spinning disk — was designed when GPUs were display adapters. That hierarchy is now meaningfully wrong for any machine with a modern discrete GPU.
VRAM sits between DRAM and NVMe on almost every relevant metric: capacity is usually less than total system RAM but greater than typical L3 cache, bandwidth is extraordinary, and latency over PCIe is worse than DRAM but far better than storage. It is a genuinely new tier in the hierarchy that operating systems do not yet treat as a first-class citizen.
Projects like nbd-vram, along with work on CUDA Unified Memory and AMD's Smart Access Memory, are early probes into what OS-level VRAM awareness could look like. The Linux kernel's heterogeneous memory management (HMM) subsystem is laying groundwork for more formal integration, but userspace tooling like this fills the gap today.
Practical Recommendations for Software Teams
If your team runs ML workloads or memory-intensive data pipelines on Linux machines with Nvidia GPUs, it is worth benchmarking nbd-vram against your current swap configuration. The setup cost is low — an afternoon at most — and for workloads that occasionally spike past available RAM, the performance difference between disk swap and VRAM swap can be the difference between a slow run and an unusable one.
For SaaS teams building inference APIs, consider whether a VRAM swap tier could allow you to serve larger models on existing hardware before reaching for a more expensive instance type. An extra 8 GB of VRAM-backed swap on a GPU server might defer a significant infrastructure cost.
Why this matters for your project: Memory constraints are one of the most common reasons ML pipelines fail in production and build pipelines slow to a crawl on developer machines. Treating VRAM as a programmable memory tier — even through the relatively blunt instrument of a swap device — is a low-cost, high-leverage optimisation available on hardware most engineering teams already own. Knowing your full memory topology and using all of it is good engineering.
