Guide · 2026-07-13

How to Install Ollama on Windows 11 with WSL2 — Full Guide

Last updated 2026-07-13

A tested, no-fluff walkthrough for installing Ollama inside WSL2 on Windows 11, with full NVIDIA and AMD GPU passthrough and a clear verdict on when WSL2 beats the native installer.

By Mohamed Meguedmi · 9 min read

WSL2 or the native Windows installer? The verdict first

Ollama ships a first-party Windows installer, and for a large share of readers that is the correct answer. It is a signed .exe, it registers a background service, and it detects NVIDIA GPUs with zero configuration. If your only goal is to double-click and chat with a model, stop reading and grab it from ollama.com/download.

WSL2 earns its extra 10 minutes of setup for one reason: parity with Linux production environments. Container tooling, shell scripts, systemd services, Open WebUI via Docker Compose, and CI pipelines all behave identically to a cloud Linux host. The table below is the decision you are actually making.

Factor	Native Windows installer	WSL2 + Ubuntu 24.04
Setup time	~3 min	~15–20 min
NVIDIA GPU	Automatic	Automatic (Windows driver only)
AMD GPU (ROCm)	Limited	Supported on ROCm-capable cards
Docker / Open WebUI	Via Docker Desktop	Native, matches prod
Linux tooling & scripting	No	Yes
Filesystem I/O for models	NTFS	ext4 (faster on the Linux VHDX)
Best for	Desktop users, quick tests	Developers, reproducible stacks

Our recommendation: if you write code against the Ollama API, deploy to Linux, or plan to run Open WebUI, install through WSL2. Everyone else is better served by the native path. The rest of this guide covers the WSL2 route.

Prerequisites and hardware reality check

Ollama's speed is bounded almost entirely by GPU VRAM. System RAM matters only for CPU fallback, which is 10–40× slower. Match your target model to VRAM before you install anything — you can size this precisely with our cost calculator and cross-check throughput on the benchmarks pages.

GPU VRAM	Comfortable model (Q4_K_M)	Example	Typical tok/s*
6–8 GB	7B–8B	Llama 3.1 8B, Qwen2.5 7B	35–60
12 GB	12B–14B	Gemma3 12B, Phi-4 14B	30–50
16 GB	up to 22B	Mistral Small 3 24B (tight)	20–40
24 GB	32B	Qwen3-Coder 32B Q4_K_M	18–30

*Indicative single-stream decode on consumer Ada/RDNA3-class GPUs; your numbers vary with quantization and context length.

Software prerequisites:

• Windows 11 (any edition), build 22000 or newer.
• Virtualization enabled in BIOS/UEFI (Intel VT-x / AMD-V) — almost always on by default.
• For NVIDIA: a current Windows Game Ready or Studio driver (R555 or newer recommended). Do not install a Linux GPU driver inside WSL2 — it will break the passthrough.
• For AMD: a ROCm-supported GPU and the matching Adrenalin driver.

Install Ollama inside WSL2

With Ubuntu running, the install is a single official script. From the WSL2 shell:

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

The script detects your architecture, installs the ollama binary to /usr/local/bin, and starts the background server on 127.0.0.1:11434. Verify it responds:

ollama --version
curl http://127.0.0.1:11434

The second command should return Ollama is running. Now pull and run your first model — start small to confirm the pipeline before committing to a large download:

ollama run llama3.1:8b

If the model loads and answers a prompt, the base install is complete. The next section makes it fast.

GPU passthrough: NVIDIA CUDA and AMD ROCm

NVIDIA

This is the smooth path. WSL2 exposes the GPU through the /dev/dxg device and a WSL-specific CUDA runtime that ships with the Windows driver. You install nothing GPU-related inside Linux. Confirm the GPU is visible:

nvidia-smi

If nvidia-smi lists your card, Ollama will use it automatically — no flags required. Watch ollama ps after loading a model; a healthy result shows 100% GPU. NVIDIA's own CUDA on WSL user guide is the authoritative reference and reiterates the golden rule: keep the driver on the Windows side only.

AMD

AMD works but the supported-GPU list is narrower. Ollama bundles its own ROCm libraries, so on a supported RDNA2/RDNA3 card it often works after a standard install. If Ollama falls back to CPU, force the target with an override that reports your GPU as a supported gfx version, then restart the server:

export HSA_OVERRIDE_GFX_VERSION=11.0.0
systemctl --user restart ollama   # or: ollama serve

Verify GPU offload the same way — ollama ps should show a GPU percentage rather than 100% CPU.

Reach Ollama from Windows and add Open WebUI

Because WSL2 forwards localhost, a browser or app on Windows can hit http://localhost:11434 directly — no port mapping needed for local use. To expose Ollama to other machines on your LAN, bind it to all interfaces by setting the host environment variable and restarting:

export OLLAMA_HOST=0.0.0.0:11434
ollama serve

Binding to 0.0.0.0 makes the API reachable by anything that can route to your PC. Only do this on trusted networks, and consider a firewall rule scoped to specific source IPs.

For a chat UI, Open WebUI is the standard companion. With Docker installed in WSL2, one container connects to the host Ollama:

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

Open http://localhost:3000 in Windows, create the first account, and your local models appear in the dropdown. If you want programmatic access instead, every model you pull is immediately available over the OpenAI-compatible /v1 endpoint — see the guides hub for API integration patterns.

Troubleshooting the errors that waste an afternoon

Symptom	Cause	Fix
nvidia-smi not found in WSL2	Old Windows driver, or WSL1	Update the Windows NVIDIA driver; run wsl --update; confirm VERSION 2
Model loads on 100% CPU	GPU not detected / not enough VRAM	Check nvidia-smi; pick a smaller quant; for AMD set HSA_OVERRIDE_GFX_VERSION
curl: (7) connection refused on 11434	Server not running	ollama serve in one shell, or systemctl --user start ollama
Slow model downloads / TLS errors	Corporate VPN or MTU mismatch	Disconnect VPN to test; lower WSL MTU; retry the ollama pull
Out of disk space mid-pull	WSL VHDX default cap	Move the Ollama model dir or expand the WSL virtual disk

A frequent gotcha: after a Windows update, WSL occasionally loses GPU visibility until you run wsl --shutdown from PowerShell and reopen the distro. If a model that previously ran on GPU suddenly drops to CPU, that shutdown-and-restart is the first thing to try.

Where to go next

Once the stack runs, the real question is which model to serve. VRAM ceilings, coding vs. general reasoning, and context-length needs all push you toward different weights. Browse the model catalog to filter by size and license, and note that every specification and benchmark on BestLLMfor is available through our public API under CC BY 4.0 and via our open-source MCP server, so you can pull model metadata straight into your own tooling.

Conclusion & verdict

WSL2 turns a Windows 11 machine into a Linux-native AI host without dual-booting, and in 2026 GPU passthrough is reliable enough to treat as a first-class deployment target. Choose your path deliberately.

Your situation	Verdict
You just want to chat with a model	Native Windows installer — fastest, zero Linux overhead
You build against the Ollama API or deploy to Linux	WSL2 — production parity is worth 15 minutes
You want Open WebUI + Docker Compose	WSL2 — native container workflow
You have an AMD ROCm-capable GPU	WSL2 — broader acceleration support

For the developer audience this site serves, WSL2 is the setup we recommend and the one we validate against. Install it once, wire in your GPU, and you have a reproducible local LLM host that behaves exactly like the cloud you deploy to.