Jul 3, 2026

WSL 3 + Ollama Setup for Windows 2026: Near-Native GPU

By AIFoss · 10 min read

wslollamawindowsselfhostedai

TL;DR: WSL 3, previewed at Microsoft Build 2026, adds paravirtualized GPU and NPU passthrough so Ollama runs inside Linux on Windows at roughly 3–5% overhead versus bare metal. That fixes the long-standing WSL 2 problem where Ollama on ARM Windows fell back to CPU. It’s an Insiders preview today, so treat it as bleeding-edge, not production.

	WSL 3 (preview)	WSL 2	Native Linux dual-boot
GPU/NPU access	Paravirtualized passthrough, near-native	GPU only, VM overhead; no NPU on ARM	Full native
Overhead vs bare metal	~3–5%	10–20%+ on GPU workloads	0%
Setup difficulty	Insiders enrollment + `wsl --update`	`wsl --install`	Full OS partition
Best for	Windows devs who want Linux tooling + GPU	Existing WSL users, x86 CUDA	Max performance, no Windows dependency

Honest take: If you’re on a Snapdragon X Elite or Intel Core Ultra laptop and Ollama has been stuck on CPU, WSL 3 is the reason to join the Insiders Dev channel. On an established x86 + NVIDIA desktop, WSL 2 already works — wait for WSL 3 to hit stable.

What you’ll have running after this guide

Ollama serving a local model inside a WSL 3 Linux distro, using your GPU or NPU instead of the CPU
A verified passthrough (you’ll confirm the accelerator is actually doing the work, not just claiming to)
Open WebUI in front of it for a browser chat interface, all staying on your machine

What WSL 3 actually changes

WSL 2 runs a real Linux kernel inside a lightweight Hyper-V virtual machine. That design gave you a genuine Linux userland, but hardware access always crossed the virtualization boundary. On x86 desktops with NVIDIA cards, Microsoft and NVIDIA papered over this with a CUDA passthrough driver, so Ollama and PyTorch worked — with some overhead. On ARM Windows laptops the story was worse: as late as 2025, Snapdragon X Elite users reported Ollama running CPU-only inside WSL 2, with the NPU sitting idle because no backend could reach it through the VM.

WSL 3, previewed at Build 2026 on June 2, swaps that model for paravirtualized hardware access. The Linux kernel talks to the Windows GPU and NPU through a thin virtualization layer instead of a full VM boundary, which Microsoft measured at roughly 3–5% overhead versus bare-metal Linux. Microsoft co-announced DirectML 2.0 alongside it, giving the passthrough a common abstraction across vendors.

The practical result: ollama, llama.cpp, vLLM, and anything that sits on top of them (like Open WebUI) can finally use the accelerator on a Windows laptop without a dual-boot partition.

Hardware and Windows requirements

WSL 3 launched with support for Qualcomm Snapdragon X Elite and Intel Meteor Lake / Lunar Lake (marketed as Core Ultra) platforms. AMD support was deferred to a later update — as of July 2026 it is not in the preview, so Ryzen AI users should stay on WSL 2 for now.

OS: Windows 11, current Insider preview build (Dev channel for the earliest access)
CPU/NPU: Snapdragon X Elite, or Intel Core Ultra (Meteor Lake / Lunar Lake)
GPU: the integrated GPU on those platforms, or a discrete GPU where the vendor ships a WSL 3 driver
RAM: 16 GB is the realistic floor for running 7B–8B models comfortably; 32 GB if you want headroom for larger quantizations

If your machine hardware isn’t on that list, none of the passthrough benefit applies and you should skip WSL 3 for now. Don’t fight it — the value is entirely in the accelerator access.

Step 1: Join the Windows Insiders program

WSL 3 is rolling out the same way WSL 2 updates always have: preview first through Insiders, then general availability via Windows Update later. To get it today:

Open Settings → Windows Update → Windows Insider Program.
Enroll and pick the Dev channel (most recent builds, lower stability) or Beta if you want a slightly safer track.
Install pending updates and reboot.

The Dev channel gives you the earliest WSL 3 bits but expect rough edges. If this is your daily-driver machine, that trade-off matters — see the “when NOT to use this” section below.

Step 2: Install or update WSL to the 3.x kernel

If you’ve never used WSL, install it first. Open PowerShell as Administrator:

wsl --install

That enables the Virtual Machine Platform, pulls a default Ubuntu distro, and prompts a reboot. If you already run WSL 2, you instead pull the preview kernel:

wsl --update --pre-release
wsl --version

Expected output (version numbers will shift as the preview moves):

WSL version: 3.0.x.0
Kernel version: 6.x
Windowsversion: 10.0.264xx.xxxx

Seeing a WSL version that starts with 3. is the confirmation that the preview kernel is live. If it still reports 2.x, your Insider build hasn’t shipped the WSL 3 component yet — wait for the next flight. Microsoft’s WSL docs on Microsoft Learn are the source of truth here because the exact flag and build number change during a preview.

Step 3: Install Ollama inside the distro

Launch your distro (wsl or the Ubuntu entry in the Start menu) and install Ollama with the official script:

curl -fsSL https://ollama.com/install.sh | sh

The installer detects the accelerator. On a working WSL 3 setup you’ll see it register the GPU/NPU rather than the “no GPU detected, CPU only” message that WSL 2 gave on ARM. Ollama v0.30.10 (released June 17, 2026) is the current stable line; the July 1, 2026 update added multi-token prediction that speeds up decoding on by default.

Start the server and pull a model:

ollama serve &
ollama run llama3.2

First run downloads the weights, then drops you into a chat prompt:

$ ollama run llama3.2
>>> Explain WSL 3 in one sentence.
WSL 3 lets Linux apps on Windows use the GPU and NPU at
near-native speed through paravirtualized hardware passthrough.
>>> /bye

Step 4: Verify the GPU is actually being used

This is the step most guides skip, and it’s the one that matters. A model that runs is not proof the accelerator is engaged — Ollama will silently fall back to CPU if the passthrough isn’t wired up. Confirm it two ways.

Check what Ollama loaded the model onto:

ollama ps

NAME          ID    SIZE     PROCESSOR    UNTIL
llama3.2:latest ...  6.5 GB   100% GPU     4 minutes from now

If PROCESSOR says 100% CPU, the passthrough failed. On an NVIDIA-backed setup you can cross-check with nvidia-smi inside WSL and watch the process appear while a prompt generates. On Snapdragon/Intel NPU paths, ollama ps reporting GPU (or the vendor’s monitoring tool showing NPU activity) is your signal.

Step 5: Add Open WebUI for a browser interface

Ollama’s CLI is fine, but a browser front end makes it usable day to day. The fastest path is Docker inside WSL:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

Open http://localhost:3000, create the first account (it becomes admin), and point it at http://host.docker.internal:11434 for the Ollama endpoint. For a fuller walkthrough of this pairing on plain Linux, see our Ollama + Open WebUI on Linux setup guide — the WSL 3 steps are identical once the distro is running.

The problem you’ll actually hit: Ollama not reachable from Windows

The most common WSL 3 + Ollama snag isn’t the GPU — it’s networking. Ollama binds to 127.0.0.1:11434 inside the distro by default, which means a browser or app running on the Windows side often can’t reach it, even though WSL 3 mirrors localhost more aggressively than WSL 2 did.

Two fixes, in order of preference:

Keep everything inside WSL. Run Open WebUI in the same distro (as above) and access it through localhost:3000. Nothing crosses the boundary, so nothing breaks.
Expose Ollama deliberately only if a Windows-side app needs it. Set the bind address before starting the server:
```
OLLAMA_HOST=0.0.0.0:11434 ollama serve
```

That second option opens Ollama to your local network, which is a security decision, not a convenience one. An exposed Ollama API with no auth is exactly how the 2025–2026 wave of leaked instances happened. If you do it, firewall the port and read our Ollama security guide first. On a laptop that roams between networks, prefer option 1 every time.

When NOT to use WSL 3

You’re on AMD. Ryzen AI / Radeon passthrough isn’t in the preview as of July 2026. WSL 2 is your path until it lands.
This is your only work machine. The Insiders Dev channel ships unstable builds. A bad flight can cost you a day. Use a spare device or wait for GA.
You already have working x86 + NVIDIA on WSL 2. The upgrade from ~10–20% overhead to ~3–5% is real but incremental. It’s not worth Insider instability if your current setup is fine.
You want maximum performance, period. A native Linux dual-boot still wins by a few percent and avoids Windows entirely. For a dedicated inference box, that’s the better call — pair it with the right card using our sister site’s WSL 3 GPU passthrough hardware guide.

WSL 3 vs the alternatives at a glance

Factor	WSL 3 preview	WSL 2	Native Ubuntu	Ollama on Windows native
GPU on x86 NVIDIA	Yes, ~3–5% overhead	Yes, higher overhead	Yes, 0%	Yes
GPU/NPU on Snapdragon X	Yes (the headline fix)	No (CPU fallback)	Limited ARM drivers	Partial
Linux tooling	Full	Full	Full	No
Stability	Preview	Stable	Stable	Stable
Effort to set up	Medium	Low	High	Lowest

The Windows-native Ollama build is the simplest option if you never touch Linux tooling. WSL 3 exists for the developer who wants both the Linux ecosystem and the accelerator on the same laptop — which, on ARM Windows, was impossible until now.

FAQ

Is WSL 3 generally available yet? No. As of July 2026 it’s a preview delivered through the Windows Insiders program. Microsoft has said it will ship to everyone via Windows Update later, the same rollout path WSL 2 followed.

Do I need a discrete GPU? No. The point of WSL 3 on Snapdragon X Elite and Intel Core Ultra is passthrough to the integrated GPU and the NPU. A discrete GPU helps for larger models but isn’t required to benefit.

Will my WSL 2 distros survive the upgrade? wsl --update --pre-release updates the kernel and platform, not your installed distros. Back up anything important first — it’s a preview — but the upgrade is designed to be in place.

Why is Ollama still using the CPU after I upgraded? Check ollama ps. If it reports 100% CPU, either the WSL 3 kernel didn’t actually install (confirm with wsl --version showing 3.x), your hardware isn’t in the supported list, or the vendor GPU/NPU driver for WSL 3 isn’t present yet. AMD hardware will always fall back today.

Does this work for vLLM and llama.cpp too? Yes. The passthrough is at the WSL layer, so anything that uses the GPU/NPU benefits — llama.cpp, vLLM, and PyTorch included. Ollama is just the easiest starting point.

Sources

Was this article helpful?