📅 Published 21 March 2026

The reason most ML practitioners on Windows now use WSL2 instead of dual-booting is straightforward: the GPU passthrough works well enough that the overhead is negligible for training runs, and the convenience of staying in one operating system is worth the small performance trade-off. But "works well enough" hides a meaningful amount of setup nuance — particularly around CUDA toolkit versions, driver layering, memory allocation, and the interaction between the Windows host GPU driver and what the Linux guest can actually access.

This guide walks through GPU acceleration configuration in WSL2 for machine learning workloads as of 2026, covering NVIDIA CUDA, AMD ROCm, Intel's compute stack, and the framework-specific setup for PyTorch and TensorFlow. If you have already followed the Linux GUI apps on WSL2 guide on this site and confirmed that glxinfo shows your real GPU, the display passthrough is working — but compute acceleration requires additional verification. This guide is part of the how-to section and connects to the broader Linux on Windows topic.

How GPU passthrough works in WSL2​

WSL2 runs a lightweight Hyper-V virtual machine with a custom Linux kernel. GPU access is provided through a paravirtualised device — /dev/dxg — that translates GPU API calls from the Linux guest into DirectX calls on the Windows host. For NVIDIA GPUs, this means CUDA calls inside WSL2 are translated through the Windows NVIDIA driver without requiring a separate Linux GPU driver installation.

This is the critical distinction that confuses people: do not install NVIDIA Linux drivers inside WSL2. The host Windows driver handles everything. Installing Linux-native GPU drivers inside the VM will conflict with the passthrough layer and break compute access entirely.

Verify GPU visibility from inside your WSL2 distribution:

nvidia-smi

If this command works and shows your GPU model and driver version, the passthrough is functional. If it fails with "command not found," you need the NVIDIA CUDA toolkit for WSL — not the full Linux driver package.

NVIDIA CUDA setup​

For NVIDIA GPUs, the setup is:

1. Windows side: Install the latest NVIDIA Game Ready or Studio driver (version 535+ recommended). The driver includes WSL2 support automatically.

2. WSL2 side: Install the CUDA toolkit without the driver component:

wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install cuda-toolkit-12-6

The cuda-toolkit metapackage deliberately excludes the driver. If any installation guide tells you to install cuda (which includes the driver), ignore that instruction when working inside WSL2.

Verify the CUDA compiler:

nvcc --version

And run a quick test:

cd /usr/local/cuda/samples/1_Utilities/deviceQuery
sudo make
./deviceQuery

A successful result shows your GPU model, compute capability, and available memory.

AMD ROCm considerations​

AMD's ROCm stack in WSL2 has improved significantly but remains less mature than NVIDIA's CUDA passthrough. ROCm support requires specific AMD Radeon Software driver versions on the Windows side and the ROCm runtime inside WSL2. The compatibility matrix is narrower — not all AMD GPUs that support ROCm on native Linux support it through WSL2's passthrough layer.

If you are choosing hardware specifically for ML workloads in WSL2, NVIDIA remains the path of least resistance. If you already have an AMD GPU and need it to work, check AMD's WSL2 compatibility documentation for your specific GPU model before investing setup time.

PyTorch configuration​

PyTorch with CUDA support in WSL2:

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

Verify GPU access:

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

If cuda.is_available() returns False despite nvidia-smi working, the mismatch is almost always a CUDA toolkit version incompatibility — the PyTorch build expects a specific CUDA version that does not match what you installed. Match the CUDA version in the PyTorch install URL to the toolkit version you have.

TensorFlow configuration​

TensorFlow's GPU support in WSL2 follows a similar pattern but with its own version matrix:

pip install tensorflow[and-cuda]

Recent TensorFlow releases bundle their own CUDA and cuDNN dependencies, reducing version mismatch issues. Verify:

import tensorflow as tf
print(tf.config.list_physical_devices('GPU'))

Memory management​

WSL2 shares system RAM with the Windows host, and by default it may claim up to 50% of physical memory. For ML workloads that need to load large models or datasets into system memory alongside GPU VRAM, this default can be insufficient.

Adjust the WSL2 memory limit in %UserProfile%\.wslconfig:

[wsl2]
memory=24GB
swap=8GB

Restart WSL2 after editing:

wsl --shutdown

GPU VRAM is managed separately — it is determined by your physical GPU and the Windows driver allocation. The Linux guest sees the full VRAM available on the host GPU, minus whatever Windows and other applications are using. For serious training work, close GPU-intensive Windows applications (games, GPU-accelerated browsers with many tabs) to maximize available VRAM.

The Debian Intel graphics guide covers the driver side for Intel GPUs, though integrated Intel graphics are generally insufficient for ML training — their utility is primarily inference on smaller models.

Performance expectations​

Benchmarking WSL2 GPU compute against native Linux consistently shows 2–8% overhead depending on the workload. For training runs measured in hours, this translates to minutes of additional time — meaningful for large-scale production training but negligible for development iteration, hyperparameter tuning, and inference.

The overhead comes primarily from the DirectX translation layer and the memory copy between the VM and host. Workloads that are compute-bound (large matrix operations, transformer attention) show less overhead than workloads that are memory-bandwidth-bound (frequent small tensor operations, data loading).

Practical recommendations​

For a development workflow where you are iterating on model architectures and running validation experiments, WSL2 with GPU passthrough is excellent. The ability to use Linux-native ML tooling while keeping your Windows desktop, file management, and communication applications running simultaneously is a genuine productivity advantage over dual-booting.

For production training runs on large models, the 5% overhead may justify a dedicated Linux machine or cloud GPU instances. The decision is economic rather than technical — calculate whether the overhead costs more in GPU-hours than the inconvenience of maintaining a separate Linux environment.

The WSL2 GPU stack is mature enough in 2026 that it is no longer an experiment. It is a legitimate ML development environment used by a substantial fraction of the ML community on Windows hardware.