How to Set Up GPU-Accelerated CUDA Workloads in WSL2

Getting CUDA workloads running inside WSL2, using your actual NVIDIA GPU, depends on WSL2’s GPU paravirtualization mechanism — this walks through the actual setup steps.

Step 1: install the Windows-side NVIDIA driver, not a Linux-side one

Download and install the current NVIDIA driver for Windows,
  specifically one supporting WSL2 (most current drivers do)

This is a critical, frequently-missed detail: you do not install an NVIDIA driver inside your WSL distro at all — the driver installed on the Windows side is what WSL2’s GPU paravirtualization mechanism uses, and installing a conflicting Linux-side driver inside WSL2 can actually break GPU access.

Step 2: verify WSL2 itself is up to date

wsl --update

Step 3: verify the GPU is visible from inside WSL

nvidia-smi

If your NVIDIA GPU is correctly recognized, this shows GPU utilization, memory, and driver version information from inside your WSL distro — confirming the paravirtualization path is working before installing anything CUDA-specific.

Step 4: install the CUDA toolkit inside your WSL distro

# following NVIDIA's WSL-specific CUDA installation
# instructions for your specific distro

NVIDIA publishes WSL-specific CUDA toolkit installation instructions distinct from their general Linux installation guide — using the WSL-specific instructions matters, since they account for the driver already being provided by the Windows side.

Step 5: verify CUDA itself is working

nvcc --version

Step 6: install a machine learning framework with GPU support

pip install torch torchvision torchaudio
# or
pip install tensorflow

Step 7: verify the framework actually sees the GPU

import torch
print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0))

This is the actual, meaningful verification — confirming your ML framework of choice detects and can use the GPU, not just that nvidia-smi runs successfully.

Step 8: run a small benchmark to confirm real acceleration

import torch
import time

x = torch.randn(5000, 5000).cuda()
start = time.time()
y = x @ x
torch.cuda.synchronize()
print(f"GPU matmul: {time.time() - start:.4f}s")

Comparing this against the same operation run on CPU (x = torch.randn(5000, 5000) without .cuda()) confirms genuine GPU acceleration is actually happening, not just that no error was raised.

Step 9: consider DirectML as an alternative for non-NVIDIA GPUs

pip install tensorflow-directml

For AMD or Intel GPUs, or for a more hardware-vendor-neutral path generally, DirectML provides an alternative GPU acceleration route that doesn’t require CUDA specifically.

Why the “don’t install a Linux GPU driver” step trips people up

Everyone setting up GPU compute on a bare-metal Linux machine is used to installing the GPU driver directly on that same Linux system — WSL2’s architecture inverts this specifically, with the driver living on the Windows host and being made available to the Linux environment through paravirtualization, which is the single most common point of confusion for anyone approaching WSL2 GPU setup with conventional Linux GPU-setup habits already in mind.

Understanding the actual proxy device this relies on

Under the hood, WSL2’s GPU access works through a Linux kernel driver called Dxgkrnl, exposing a device node at /dev/dxg that proxies GPU commands back to the Windows-side driver rather than talking to the physical GPU directly. Confirming this device exists (ls -la /dev/dxg) is a useful lower-level check if nvidia-smi itself fails to find a GPU at all, since it isolates whether the fundamental proxy mechanism is present before troubleshooting anything CUDA-specific.

Checking the specific WDDM and driver version requirements

CUDA support in WSL2 depends on a sufficiently current Windows-side NVIDIA driver, tied to specific WDDM (Windows Display Driver Model) version support — checking your installed driver’s version against NVIDIA’s current documented minimum for WSL2 CUDA support is worth doing directly if nvidia-smi reports an older driver than expected, rather than assuming any installed NVIDIA driver automatically supports this feature.

Troubleshooting when the framework doesn’t see the GPU despite nvidia-smi working

If nvidia-smi succeeds but a specific framework like PyTorch still reports no GPU available, the mismatch usually points to a mismatched CUDA toolkit version, a framework build that doesn’t match your installed CUDA version, or a Python environment issue (a different virtual environment than the one CUDA was actually configured in) — checking the specific framework’s own reported CUDA version against what nvcc --version reports is the direct way to isolate a version mismatch from a genuine driver-level problem.

Keeping both sides updated together

Because GPU compute in WSL2 depends on cooperation between the Windows-side driver, WSL’s own platform version, and the CUDA toolkit inside the distribution, a working setup that later breaks after any one of these updates independently is common enough to check for specifically — comparing versions across all three before assuming a deeper, harder-to-diagnose regression is the first, most productive troubleshooting step.

Testing with a minimal CUDA sample before a full framework

Before installing an entire machine learning framework, NVIDIA’s CUDA toolkit includes small sample programs (such as deviceQuery) specifically meant to confirm the toolkit itself can see and query the GPU correctly. Running one of these first isolates a genuine CUDA/driver-level problem from a framework-specific installation issue, narrowing the search considerably before assuming PyTorch or TensorFlow itself is where the fault lies.

Related:

Sources: