Install Ollama and Run Your First Local Model

Ollama's latest tagged release is v0.32.5, published 27 July 2026, and installing it is a one-liner on Linux and a drag-and-drop on macOS. The part that trips people is not the install. It is that the first answer takes a long time, the default context is small, and the two documentation pages that describe that default do not agree with each other.

Everything below is taken from docs.ollama.com as it read on 31 July 2026. Commands are reproduced exactly.

Four install routes, pick the one that matches your box

Linux. The documented install script:

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

If piping a script into a shell is not something you do, the Linux page publishes a manual route that extracts a signed tarball into /usr:

curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr

There are two variants of that URL. ollama-linux-amd64-rocm.tar.zst adds AMD GPU support, and ollama-linux-arm64.tar.zst covers ARM64 machines. Pinning a specific build is done through an environment variable on the install script, documented as OLLAMA_VERSION=0.5.7 sh.

macOS. The requirement is "MacOS Sonoma (v14) or newer". Mount ollama.dmg, drag Ollama into Applications, and launch it. On first run the app checks whether the CLI tool is on your PATH and asks permission to create a link in /usr/local/bin. Grant it, otherwise the ollama command will not exist in your terminal. Models and configuration land in ~/.ollama, logs in ~/.ollama/logs.

Windows. Use the Windows installer from the download page. This walkthrough does not reproduce Windows-specific steps, so do not assume the curl line works there.

Docker. Useful if you want the whole thing disposable. The CPU-only form:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

With an NVIDIA card, after installing the NVIDIA Container Toolkit, the command gains one flag:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

AMD uses a different image tag and passes two devices through:

docker run -d --device /dev/kfd --device /dev/dri -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama:rocm

The -v ollama:/root/.ollama volume is the part not to skip. Drop it and every model you pull disappears with the container, which on a 14GB download is a costly mistake to make twice.

Your first model, and why the first answer is slow

The quickstart uses one command and one model:

ollama run gemma4

That does three things in sequence. It downloads the weights if they are not already on disk, loads them into memory, then drops you into an interactive chat. Type /bye to leave.

The download is the slow part, and it is a one-time cost. The load is the second slow part, and it recurs. Ollama keeps a model resident for a documented five minutes after use and then unloads it, so a prompt sent after a coffee break pays the full load again. Change that with OLLAMA_KEEP_ALIVE when starting the server, or with the keep_alive parameter on an API call.

If you would rather download without starting a chat, split the two steps:

ollama pull qwen3:8b

Inside a Docker container the same commands work through docker exec:

docker exec -it ollama ollama run llama3.2

Ten commands cover ordinary use

The CLI reference is short. These are the commands and the descriptions the docs give them:

ollama ps earns its place because it reports where the model is running. The processor column shows 100% GPU, 100% CPU, or a split like 48%/52% CPU/GPU. A split placement is the single most common explanation for a local model feeling unusably slow, and it means the weights did not fit where you hoped.

The environment variables the server understands are printed by ollama serve --help, which is the authoritative list rather than anything a blog reproduces.

Two Ollama pages disagree about your default context

This one matters enough to flag rather than paper over.

The FAQ states it flatly: "By default, Ollama uses a context window size of 4096 tokens." No conditions attached.

The dedicated context-length page says something different. It describes the default as assigned by available VRAM, at 4k tokens under 24GB, 32k between 24GB and 48GB, and 256k at 48GB or more.

Both pages are current Ollama documentation. Nothing published reconciles them, and neither page names a version at which the behaviour changed. If your machine has under 24GB of VRAM the two descriptions agree and you get 4k either way. Above that line, you cannot tell from the docs which one governs your install.

Do not guess. Set the value explicitly. Starting the server with an environment variable is the documented route:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Inside a running chat, the same thing per-session:

/set parameter num_ctx 8192

Or pass num_ctx in an API request. The 64000 figure is not arbitrary: the context-length page recommends "at least 64000 tokens" for web search, agents and coding assistance. Every token you add costs memory, and ollama ps reports the assigned context alongside the processor split so you can confirm the bump did not push you onto the CPU.

Where the logs live when it refuses to start

The troubleshooting page publishes exact paths per platform, and knowing them saves an hour of searching.

• macOS: cat ~/.ollama/logs/server.log
• Linux with systemd: journalctl -u ollama --no-pager --follow --pager-end. The Linux page also gives the shorter journalctl -e -u ollama.
• Windows: open the Run dialog and enter explorer %LOCALAPPDATA%\\Ollama for server.log and the rotated server-#.log files. explorer %HOMEPATH%\\.ollama holds models and configuration.
• Docker: docker logs <container-name>

For more detail, set OLLAMA_DEBUG=1. On Windows PowerShell the documented form is:

$env:OLLAMA_DEBUG="1"

followed by launching ollama app.exe.

Two GPU-specific checks are worth knowing. On Linux with NVIDIA, docker run --gpus all ubuntu nvidia-smi verifies the container runtime works at all, and sudo nvidia-modprobe -u loads the UVM driver when discovery fails. On AMD, AMD_LOG_LEVEL=3 turns on informational logging, and driver mismatch messages surface as "failure during GPU discovery" with timeout errors. In both cases the consequence is the same: the model falls back to CPU.

Running it as a service on Linux

The install script sets this up, but knowing the pieces matters the first time you need to change an environment variable.

The unit file lives at /etc/systemd/system/ollama.service. After creating or editing it:

sudo systemctl daemon-reload
sudo systemctl enable ollama
sudo systemctl start ollama

Environment variables for the service do not come from your shell profile, which is the mistake almost everyone makes once. Use sudo systemctl edit ollama, or write them into /etc/systemd/system/ollama.service.d/override.conf directly. A variable you exported in your terminal has no effect on a systemd-managed server.

Removing it later is four steps: sudo systemctl stop ollama && sudo systemctl disable ollama, delete /etc/systemd/system/ollama.service, remove the binaries and libraries, then delete the user, group and model directory. That last one is where the disk space is.

Storage, before it becomes a problem

Models are the largest files most people keep. The documented locations:

• macOS: ~/.ollama/models
• Linux: /usr/share/ollama/.ollama/models
• Windows: C:\\Users\\%username%\\.ollama\\models

To put them elsewhere, "set the environment variable OLLAMA_MODELS to the chosen directory". On Linux that variable belongs in the systemd override, not your shell.

ollama ls shows what you are holding and ollama rm <model> reclaims the space. Pulling three quantizations of the same 8B model to compare them is a reasonable thing to do and costs about 30GB, so check the disk before rather than after.

One binding default worth knowing before the next parts: "Ollama binds 127.0.0.1 port 11434 by default." Nothing outside your machine can reach it until you change OLLAMA_HOST. If you are on an Apple Silicon Mac and want a lighter alternative to compare against, Osaurus targets the same job on that hardware. For everything else, the next parts assume this install and that port.