Every local-AI page on this site starts with a number: how much VRAM the card has, how much RAM the box has, which runtime to install. The gap in our articles is the operating system: the platform coverage runs from Apple silicon to phones, the browser and a Raspberry Pi, but an ordinary Linux workstation or server and a Windows PC are not on it - a scan of the 939 article titles published before this one finds no Linux or Windows install page. Our shorter Linux guide and Windows guide cover the runtime choice on each platform, but neither walks the install itself the way this page does. Both platforms run the same MIT-licensed Ollama build, and neither install is the same job as the Mac one described in running LLMs locally on Apple silicon.
Verified 30 October 2026 against Ollama’s own documentation, the Ollama repository and its release feed, the Hugging Face model API and the live Ollama library. The current release is v0.40.13, published 28 October 2026.
Install Ollama on Linux
Ollama’s Linux documentation leads with one command:
curl -fsSL https://ollama.com/install.sh | shThe same page carries manual installs as well: an AMD64 tarball (ollama-linux-amd64.tar.zst) extracted into /usr, an ARM64 tarball (ollama-linux-arm64.tar.zst) and a separate ROCm package (ollama-linux-amd64-rocm.tar.zst) for AMD cards. There is no apt, dnf or pacman instruction on that page. The script can be pinned with OLLAMA_VERSION, and the documentation shows OLLAMA_VERSION=0.5.7 as the example.
Running it in the background is the next step, and the same page calls it “Adding Ollama as a startup service (recommended)”. It creates an ollama user and group, writes a unit file to /etc/systemd/system/ollama.service, then runs:
sudo systemctl daemon-reload
sudo systemctl enable ollama
sudo systemctl start ollama
sudo systemctl status ollamaThe unit file it publishes is short, and User=ollama in it decides where models can be written:
[Unit]
Description=Ollama Service
After=network-online.target
[Service]
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=$PATH"
[Install]
WantedBy=multi-user.targetLogs go through journald: journalctl -e -u ollama.
Two details cause most of the Linux friction. The FAQ puts the default model directory at /usr/share/ollama/.ollama/models and says the ollama user needs read and write access to whatever OLLAMA_MODELS points at. And because the service runs as its own user, a variable exported in your shell never reaches it: the FAQ says environment variables should be set with systemctl edit ollama.service, followed by systemctl daemon-reload and systemctl restart ollama.
Install Ollama on Windows
Windows takes fewer steps. The documentation says “The Ollama install does not require Administrator, and installs in your home directory by default.” The installer is OllamaSetup.exe, which doubles as the update mechanism, and OllamaSetup.exe /DIR="d:\some\location" puts the binaries somewhere else.
The stated requirements are “Windows 10 22H2 or newer, Home or Pro” and “NVIDIA 551.61 or newer Drivers if you have an NVIDIA card”. For AMD cards the same page asks for an “AMD ROCm v7 / HIP7-capable driver stack for ROCm acceleration, or a Vulkan-capable AMD Radeon driver for Vulkan acceleration”. The disk requirement is stated plainly: “You’ll need at least 4GB of space for the binary install”, and the models themselves need room “which can be tens to hundreds of GB in size”.
There is a standalone archive for a CLI-only install. It carries “only the Ollama CLI and GPU library dependencies for Nvidia”, and two further packages can be extracted into the same directory depending on the hardware: ollama-windows-amd64-rocm.zip for AMD GPUs and ollama-windows-amd64-mlx.zip for MLX (CUDA). The Windows page also documents where everything lands: %LOCALAPPDATA%\Programs\Ollama for the binaries, %LOCALAPPDATA%\Ollama for logs and updates, and %HOMEPATH%\.ollama for models and configuration, matching the FAQ’s C:\Users\%username%\.ollama\models.
WSL2 needs naming, and the answer sits in two different documents. Ollama’s Windows installation page, read in full on 30 October 2026, does not describe WSL2 as an install path, but the FAQ does describe WSL2 networking settings that “can impact both installing Ollama, as well as downloading models”: “Large Send Offload Version 2 (IPv4)” and “Large Send Offload Version 2 (IPv6)”, both of which it says should be disabled.
Pick a first model that fits the machine
After installation the loop is one command, ollama run <tag>, which the quickstart describes as “Ollama downloads the model and starts a chat on your computer.”
| Model | Ollama tag | Download size | Licence | Note |
|---|---|---|---|---|
| Gemma 3 270M | gemma3:270m | 292MB | gemma | Smallest download on this list; gated on Hugging Face |
| Gemma 3 1B | gemma3:1b | 806MB | gemma | Gated on Hugging Face |
| Llama 3.2 3B | llama3.2:3b | 2.0GB | llama3.2 | Gated on Hugging Face |
| Gemma 3 4B | gemma3:4b | 3.4GB | gemma | Gated on Hugging Face |
| Qwen3.5 4B | qwen3.5:4b-q4_K_M | 3.3GB | Apache-2.0 | The unqualified tag lists 3.3GB - 4.0GB |
| Granite 4.0 H Tiny | granite4:7b-a1b-h | 4.2GB | Apache-2.0 | 7B total, 1B active per token |
| Qwen3.5 9B | qwen3.5:9b-q4_K_M | 6.6GB | Apache-2.0 | The unqualified tag lists 6.6GB - 7.6GB |
Licences are read per repository from the Hugging Face API rather than inferred from the model family, and the Ollama tag is a repackaged build of that model. Four of the seven rows carry a trap this site has published wrongly before: google/gemma-3-270m-it, google/gemma-3-1b-it, google/gemma-3-4b-it and meta-llama/Llama-3.2-3B-Instruct are all gated: manual on Hugging Face, meaning a manual access request, while the Ollama tags download without one. Move from a runtime pull to the original weights later and that request is waiting for you.
The download size is not the memory footprint. The FAQ says Ollama uses a context window of 4096 tokens by default, that required RAM will scale by OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH, that OLLAMA_NUM_PARALLEL defaults to 1, and that models are kept in memory for five minutes before being unloaded. The VRAM tier index covers the other half of this decision, and a machine with no discrete card at all is a different problem again.
Confirm the GPU is doing the work
The check is one command. ollama ps lists what is currently loaded into memory, and the FAQ explains the Processor column: “100% GPU” means the model was loaded entirely into the GPU, “100% CPU” means it was loaded entirely in system memory, and “48%/52% CPU/GPU” means it was split across both.
| Vendor | What Ollama’s hardware support page requires | Note |
|---|---|---|
| NVIDIA | ”Ollama supports Nvidia GPUs with compute capability 5.0+ and driver version 550 and newer." | "Nvidia GPUs with compute capability 5.0 through 6.2 require driver version 570 or newer.” Windows asks for 551.61 or newer |
| AMD on Linux | ”Ollama requires the AMD ROCm v7 driver on Linux.” | The page lists supported Radeon, Radeon PRO, Radeon AI PRO, Ryzen AI and Instinct parts |
| AMD on Windows | ”Ollama requires an AMD ROCm v7 / HIP7-capable driver stack on Windows.” | A shorter list: Radeon RX 7000 and 9000 parts and Radeon PRO W7900 through W7500 |
| Intel | No Intel card list appears in the hardware support page | It links to Intel’s own Linux GPU driver instructions |
| Vulkan | ”Vulkan is enabled by default when the backend is installed.” | Disable it with OLLAMA_VULKAN=0 or GGML_VK_VISIBLE_DEVICES=-1 |
If you want to ignore the GPUs and force CPU usage, the documentation says to “use an invalid GPU ID (e.g., “-1”)”. That is also why the Processor column matters more than the installer output: a card below the published floor does not fail loudly, it moves the work to the processor. Ollama’s troubleshooting page describes the AMD version of this, where older drivers “failed to finish discovery before timeout” and the model falls back to the CPU.
The failures worth knowing before you hit them
| Symptom | Usual cause | Fix |
|---|---|---|
| The client cannot reach the server | ”Ollama binds 127.0.0.1 port 11434 by default.” | Set OLLAMA_HOST with systemctl edit ollama.service on Linux, or for your Windows user account, then restart the service or the tray app |
| A model download stalls under WSL2 | WSL2 networking settings | Disable “Large Send Offload Version 2 (IPv4)” and “Large Send Offload Version 2 (IPv6)“ |
| Everything runs on the CPU | The driver is below the published floor | Read the Processor column in ollama ps, then update the NVIDIA or ROCm driver |
| ”failed to finish discovery before timeout” on AMD | ROCm 7 libraries on an older kernel driver | Update to a compatible ROCm 7 driver, and check /dev/kfd access, which may need the video or render group |
| The installer cannot write its temporary files | /tmp mounted noexec | Set OLLAMA_TMPDIR to a writable location such as /usr/share/ollama/ |
| Models missing after you moved the folder | OLLAMA_MODELS changed but the service was not restarted | Reapply the variable, then systemctl daemon-reload and systemctl restart ollama |
Bottom line
Linux is a one-line install followed by a systemd unit. Windows is an installer that needs no administrator rights and keeps everything in your home directory. Choose the first model by download size and licence rather than by parameter count, because the Gemma and Llama tags carry community terms and access requests on Hugging Face while Qwen3.5 and Granite 4 are Apache-2.0 and open. Then run ollama ps and read the Processor column, since a driver below the published floor does not announce itself.
The honest limits are worth stating: the hardware support page lists no Intel cards and points at Intel’s own driver instructions instead, and the model sizes here are the live library figures for 30 October 2026, which move whenever a model is re-quantised. This site does not own the hardware to test, so the page quotes install steps and published driver floors rather than throughput numbers.