On Windows, choose the runtime boundary before installing drivers and downloading models. A native application, a WSL environment and a Docker container have different processes, storage and localhost addresses. Mixing them is a common source of misleading “model missing” and GPU errors.

Use the local inference hub for the full workflow. This is a documentation-based installation guide, not a tested hardware ranking.

Choose one initial path

Path	Appropriate first job	Boundary to understand
Native Ollama	CLI/API and local coding integrations	Windows app, environment and model store
Native LM Studio	Visual download, loading and chat	Selected runtime and local server
WSL/Linux environment	Linux-oriented serving toolchain	Separate packages, processes and network path
Docker	Repeatable service configuration	Container GPU access and persistent volumes

Start native if you only need local chat or an API. Do not add WSL just to make a Windows installer work. For shared serving, inspect the current vLLM deployment requirements before choosing a platform.

Native Ollama: verify the app and endpoint

Download the installer from the official Windows instructions. Open a new PowerShell session after installation so it sees the updated command path.

Get-Command ollama
ollama --version
Invoke-RestMethod http://127.0.0.1:11434/api/version
Invoke-RestMethod http://127.0.0.1:11434/api/tags

The normal desktop installation runs as a background/tray application; do not assume it is a Windows system service. A separately deployed standalone/service setup has different administration requirements.

Select a supported local tag from Ollama’s library, then replace the placeholder:

ollama pull MODEL_NAME
ollama run MODEL_NAME
ollama ps

If the API is reachable but the model is not, check the server’s installed tags. If no listener answers, use connection diagnosis.

GPU checks without driver guesswork

For NVIDIA hardware, inspect nvidia-smi and the current vendor/Ollama compatibility requirements. The reported CUDA compatibility of a driver is not proof that every toolkit is installed. Native applications may bundle runtime components; do not install an arbitrary toolkit as a universal fix.

AMD, Intel and Vulkan support depends on the actual backend, GPU and release. Use the current support documentation, not a blanket “AMD is slower” or “Intel requires oneAPI” rule.

After generation, inspect processor allocation and server logs. A supported GPU can still have too little free memory for the selected model and context. Follow GPU detection or memory diagnosis according to the evidence.

WSL is a separate installation

Follow Microsoft’s WSL installation guide if the chosen tool needs Linux. For NVIDIA CUDA on WSL, follow the vendor’s Windows-driver/WSL guidance rather than installing a conflicting Linux display driver inside WSL.

Verify the GPU from inside the environment and record where the model server is running. A Windows app and a WSL server can hold different models even on the same machine. Test connectivity from the real caller instead of assuming localhost forwarding covers every configuration.

Storage, safety and reproducibility

Model files, caches and context require different capacity budgets. If moving Ollama’s store, use the documented OLLAMA_MODELS setting, restart the intended server and preserve the original files until the new path is verified.

Do not disable antivirus or add broad security exclusions as a default performance tweak. Collect evidence for any storage/scanning bottleneck and involve the administrator where appropriate.

Record installer/runtime version, exact model tag, driver/backend and a small acceptance request. Then add Continue or another client. Local model execution does not guarantee that extensions, cloud-model selections or tools are offline.

Sources checked November 10, 2026: Ollama Windows, hardware support, NVIDIA CUDA on WSL, LM Studio requirements.