CUDA on WSL2 for RTX PRO workstations: driver, Docker, vLLM and the limits to plan for

What works under WSL2 on an RTX PRO workstation

CUDA on WSL2 works on NVIDIA RTX PRO Blackwell workstation cards such as the RTX PRO 6000 Blackwell Workstation Edition, the RTX PRO 6000 Max-Q and the RTX PRO 5000: the NVIDIA driver goes on Windows, the CUDA toolkit inside the Linux distribution, and PyTorch, GPU containers and vLLM then run on the card. The main limit NVIDIA's guide documents is memory: the WSL virtual machine gets half of the Windows RAM by default, pinned memory is restricted and unified memory is incomplete. WSL2 suits one developer with one model per card; a team service, MIG or a model split across cards belongs on a Linux workstation or a shared server.

This guide is for an IT department that runs Windows workstations and wants its developers to use Linux AI tools on them without dual boot. Every statement comes from NVIDIA's CUDA on WSL user guide (CUDA 13.4, last updated 12 October 2026), the WSL documentation, Docker's and vLLM's documentation, all read on 25 October 2026. Versions change, so read them again before a rollout. Whether Windows Server or Linux belongs on a GPU server is a separate question, answered in our comparison of Windows Server and Linux for a GPU server.

Which cards and which driver model

WSL2 reaches the GPU through the Windows driver, so the card's Windows driver model decides whether it works. NVIDIA's guide states that GPU acceleration in WSL 2 "will be available on Pascal and later GPU architecture on both GeForce and Quadro product SKUs in WDDM mode" and "will not be available on Quadro GPUs in TCC mode or Tesla GPUs yet". Every RTX PRO Blackwell card is far newer than Pascal. A workstation card that drives the monitors runs in WDDM, the display driver model, and that is the case WSL2 is built for.

The Server Edition is different. NVIDIA's Windows data-centre driver notes of October 2026 name TCC as the default mode on the RTX PRO 6000 Blackwell Server Edition, and that card belongs in a rack server running Linux in any case. A compute-only card in a multi-GPU workstation, with no monitor attached, may be in another mode; check it with nvidia-smi -q. Our guide to WDDM, TCC and MCDM explains the modes and how MCDM makes compute-only cards visible to WSL2 on Windows 11.

NVIDIA datasheets and product pages as in our workstation articles (memory, board power). Usable memory by our users-per-card rule: 0.9 × the memory the driver reports, minus 3 GiB per card; the driver reports 95.6 GiB on a 96 GB card, smaller cards scaled by capacity.

The usable column applies inside WSL2 as on Linux: the weights and the KV cache of the conversations in flight must fit in it. Our guide to how many users one RTX PRO 6000 serves derives the rule.

Setting up one workstation in the documented order

NVIDIA's guide gives the sequence. Each step below is from it unless another source is named.

1. Windows driver. Install NVIDIA's RTX/Quadro display driver for Windows. The guide is explicit: "This is the only driver you need to install. Do not install any Linux display driver in WSL." Driver R495 and later provides CUDA in WSL 2.
2. WSL and its kernel. Run wsl.exe --install, then wsl.exe --update for the current WSL kernel. NVIDIA names kernel 4.19.121 as the minimum and recommends 5.10.16.3 or later. The default distribution is Ubuntu.
3. CUDA toolkit inside WSL. Use the WSL-Ubuntu package from NVIDIA's download page, which "does not contain the NVIDIA Linux GPU driver". If you install from the Ubuntu repository instead, take the toolkit metapackage only; the guide says not to choose the cuda, cuda-12-x or cuda-drivers metapackages under WSL 2, because they bring a Linux driver that overwrites the one WSL provides. The guide still prints 12-x package names although it documents CUDA 13.4, so match the name to the version you install.
4. Check the card. nvidia-smi lives in /usr/lib/wsl/lib/. The guide notes that NVML, the library behind it, "does not support all the queries yet".
5. Framework. Install PyTorch or vLLM inside the distribution as on Linux. RTX PRO Blackwell cards are compute capability 12.0, which needs CUDA 12.8 or later, as our article on Blackwell RTX software support sets out.

The WSL documentation adds one rule that matters for models of tens of GB: "For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line". Keep the Hugging Face cache and model directories inside the distribution, not under /mnt/c.

GPU containers: Docker Desktop or Docker Engine in WSL

There are two documented ways to give containers the card.

Docker Desktop. Docker's GPU page (updated 30 September 2026) says that "Docker Desktop for Windows supports NVIDIA GPU Paravirtualization (GPU-PV) on NVIDIA GPUs", with the WSL 2 backend, an up-to-date Windows 10 or Windows 11, current NVIDIA drivers and the latest WSL kernel. Its test is docker run --rm -it --gpus=all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark, and it warns that the CUDA samples "are not meant for performance measurements". Since Docker Desktop 4.54, Docker Model Runner also runs vLLM on Windows through WSL2 for GPUs of compute capability 8.0 or higher, per Docker's announcement of December 2025.

Docker Engine inside the distribution. NVIDIA's WSL guide supports the NVIDIA Container Toolkit in WSL and names its minimum versions. The toolkit's own installation guide (version 1.20.1, updated 18 September 2026) does not mention WSL, and its first prerequisite is to "install the NVIDIA GPU driver for your Linux distribution": skip that step in WSL, where the Windows driver serves the card, and follow the rest, including sudo nvidia-ctk runtime configure --runtime=docker. If containers fail with nvidia-container-cli : initialization error, NVIDIA's guide says to check the Windows build, WSL 2, the driver and the toolkit, then restart the Docker daemon.

Docker on GPU servers without Kubernetes is covered in our guide to Docker GPU assignment; on a workstation the same --gpus syntax applies, with one limit from NVIDIA's guide: with Docker 19.03 only --gpus all works, not a selection by index.

vLLM under WSL2

vLLM's installation guide states that "vLLM does not support Windows natively" and names WSL with a Linux distribution as the way to run it on Windows. It installs and runs there like on Linux, with three points to know.

Pinned memory is off by default. vLLM's CUDA platform code, as published in its current API documentation, checks for WSL. On WSL2 kernels from 4.19.121 pinned memory "is supported but disabled by default", and the variable VLLM_WSL2_ENABLE_PIN_MEMORY=1 turns it on; on older kernels vLLM disables it and logs that this "may slow down performance". Pinned (page-locked) memory speeds up copies between system memory and the card, so set the variable on a current kernel.

CPU offload is risky. For --cpu-offload-gb combined with CUDA graphs, the same code warns that "Windows (WDDM) enforces a hard system-wide cap of roughly 50% of physical RAM on pinned memory shared across ALL processes by default", and that too much page-locked memory can make the host unresponsive. On a workstation, choose a model that fits the card instead of offloading.

Not every feature is tested there. In June 2026 a user on the vLLM forum reported that sleep mode was refused as unsupported under WSL2 on Windows 10 with vLLM 0.23.0; the thread received no answer from the maintainers. Treat features beyond plain serving as something to try on your build before you depend on them.

What a developer can serve on one card, by our users-per-card rule:

Weights are the sums of the safetensors files on Hugging Face (gpt-oss-20b, gpt-oss-120b; Qwen3.8-27B-FP8 repository size 30.9 GB), read 25 October 2026. Cache per 32K conversation with a 16-bit KV cache from each config.json: gpt-oss-20b 0.75 GiB, gpt-oss-120b 1.125 GiB, Qwen3.8-27B 2.0 GiB on its 16 full-attention layers plus at most 0.14 GiB of linear-attention state. Our estimate, not a measurement.

The table sizes every model with a 16-bit KV cache. With an FP8 KV cache, the setting our other Qwen3.8-27B sizings use, a 32K conversation of Qwen3.8-27B takes 1.14 GiB, and by our estimate the counts rise to 9 on the RTX PRO 5000 48 GB, 28 on the 72 GB card and 47 on a 96 GB card.

All three models are under the Apache 2.0 licence according to their LICENSE files. Our workstation buying guide shows which cards and towers we build for this work.

We supply RTX PRO workstation cards and build workstations to order; send us the models your developers run, and our team replies with a card and memory layout that fits them under WSL2.

Memory: the WSL virtual machine, pinned memory and caches

WSL2 is a lightweight virtual machine, and the WSL documentation (updated 16 October 2026) sets its memory default to "50% of total memory on Windows", its processors to the number of logical processors on Windows and its swap to 25 per cent of the memory size. Everything inside the distribution shares that limit: Python processes, containers, model downloads and the page cache of the model files. On a workstation with 256 GB of RAM the distribution gets 128 GB unless you raise it.

The setting lives in %UserProfile%\.wslconfig under [wsl2], for example memory=192GB. The file does not exist by default. WSL applies changes only after the virtual machine has stopped, which the documentation puts at "about 8 seconds" after the last shell closes; wsl --shutdown stops every running distribution at once. The experimental autoMemoryReclaim setting, dropCache by default, returns cached memory to Windows.

NVIDIA's guide adds the limits that come from the GPU side:

• "Full Managed Memory Support is not available on Windows native" and WSL 2 "will not support it for the foreseeable future". Software that relies on oversubscribing GPU memory behaves differently: RAPIDS cudf.pandas, for example, is limited to the card's physical memory under WSL2, as our RAPIDS workstation guide explains.
• "Concurrent CPU/GPU access is not supported" for managed memory.
• Pinned system memory has limited availability, and some deep-learning training workloads may exceed the limit and fail.

For inference with vLLM, which keeps weights and cache in GPU memory, these limits rarely matter. For fine-tuning and data-science work they do, and a training job that fails under WSL2 is worth retrying on Linux before changing anything else.

Several GPUs in one WSL2 workstation

NVIDIA's guide makes no statement on multi-GPU work in WSL2 beyond two entries: NCCL 2.12 or later appears in its support table, and RAPIDS from 22.04 has "Experimental Support for single GPU". The one published four-card setup we found, a vLLM forum report from April 2026 with four RTX PRO 6000 cards (edition not stated), ran under WSL2 with peer-to-peer transfers disabled through NCCL_P2P_DISABLE=1. It reports which GPU kernels failed to start, and it is no reference for speed.

The practical rule follows: in WSL2, run one model per card. Two RTX PRO 6000 Max-Q in one workstation can serve two models, or one developer's model and another's experiments, each pinned to its card with CUDA_VISIBLE_DEVICES. A model that needs two or four cards with tensor parallelism belongs on a Linux machine, where vLLM's multi-GPU paths are documented and tested.

MIG is outside WSL2 as well. NVIDIA's MIG prerequisites for the RTX PRO 6000 and RTX PRO 5000 name Linux and a driver from 575.51.03, while WSL forbids a Linux GPU driver inside the distribution; partitioning a card into isolated instances, as our MIG profile guide shows, is done on a Linux host.

Rolling WSL2 out across a fleet of workstations

The WSL documentation for enterprises names the minimum versions: Windows 10 22H2 or Windows 11 22H2, and WSL 2.0.9 or later, checked with wsl --version. From Windows 11 22H2 with WSL 2.0.9, Windows firewall rules apply to WSL automatically. Access to WSL and its main security settings can be controlled through Intune or Windows policy settings.

For a standard image, build one distribution with the CUDA toolkit, Python and your framework versions, export it with wsl --export and distribute it with wsl --import, as the documentation describes. Three things are listed there as unsupported, and your process has to cover them: updating and patching the Linux distributions with Windows tools, having Windows Update update the distribution contents, and controlling root access inside the distributions. The Linux side of each workstation therefore needs its own patch routine.

Keep the driver branch consistent across the fleet. The Windows driver serves CUDA inside every distribution, so a driver update changes what all of them run on; our article on NVIDIA driver branches and CUDA versions explains how to pin a branch. For WSL2 itself, roll out wsl --update with the driver, since NVIDIA's guide ties performance fixes to the WSL kernel version.

When a Linux workstation or a shared server is better

NVIDIA CUDA on WSL user guide (12 October 2026), NVIDIA MIG prerequisites, vLLM CUDA platform code; read 25 October 2026.

The last row decides the most. A model on a developer's WSL2 workstation stops when that person shuts the machine down or Windows installs an update. When colleagues start to depend on it, move it to a server, as our article on going from Ollama on a PC to a company AI server describes; the developers keep WSL2 for their own experiments and call the server's API. Our entry configuration on the AI servers page, with two RTX PRO 6000 Server Edition cards, two AMD EPYC processors and 384 GB of DDR5 ECC memory, runs Linux and draws about 1.8 kW at the wall by our estimate.

What we supply

We supply the RTX PRO 6000 Workstation Edition and Max-Q, the RTX PRO 5000 with 48 or 72 GB, the RTX PRO 4500 and the RTX PRO 4000 as cards with manufacturer warranty, and build workstations and servers to order, assembled and tested before delivery, with the operating system and drivers installed on request. Quantities and lead time are confirmed in writing with the quote, on one EU contract and invoice. If your developers need a workstation for WSL2 or a Linux server next to their Windows machines, describe the models and the number of developers, and our team proposes the cards for each.

FAQ