Ollama's Environment Variables, Explained

Every configurable thing about Ollama is an environment variable; there is no config file. That is a clean design with one sharp edge, which is that the process reading the variables is not the process you are typing commands into, and almost every “I set it and nothing changed” report starts there.

The server reads them, not your shell

ollama run and ollama pull are a client. The thing that loads models, allocates VRAM and answers HTTP is a separate long-lived server process, and it read its environment when it started — which was usually at boot, from a service manager, before your terminal existed. Exporting OLLAMA_NUM_PARALLEL in a shell and then running ollama run changes the client’s environment and nothing else.

The one exception is OLLAMA_HOST, which the client also reads, because the client needs to know where to send requests. That is why that variable appears to work from a shell while the others do not, and why it is the source of the belief that the rest should too.

Where the server’s environment actually lives, per Ollama’s FAQ:

• Linux, systemd. sudo systemctl edit ollama.service, then an Environment="OLLAMA_HOST=0.0.0.0:11434" line under [Service], then sudo systemctl daemon-reload and sudo systemctl restart ollama. Both of those last two — reload reads the unit, restart applies it.
• macOS. launchctl setenv OLLAMA_HOST "0.0.0.0:11434", then restart the Ollama application. The launchctl step is what puts the variable in the environment the app is launched with.
• Windows. The user or system environment variables in Settings, then quit Ollama from the tray and start it again. Quitting matters: closing the window does not stop the server.
• Docker. -e OLLAMA_KEEP_ALIVE=30m on docker run, or an environment: block in compose. This is the one place the model is uncomplicated, which is a decent argument for the container.

To run the server in the foreground with an ad-hoc environment — the fastest way to test a setting before committing it to a unit file — stop the service first and then OLLAMA_DEBUG=1 OLLAMA_NUM_PARALLEL=4 ollama serve.

Address, origins and storage

• OLLAMA_HOST — the address the server binds to, documented with a default of 127.0.0.1:11434. Loopback means local only; 0.0.0.0:11434 exposes it to the network. Treat that change as putting an unauthenticated inference endpoint on your LAN, because that is exactly what it is: there is no API key, and anyone who can reach the port can load models and read your model list.
• OLLAMA_ORIGINS — a comma-separated list of allowed origins, for CORS. Needed when a page in a browser calls Ollama directly; irrelevant when a server-side process does. Ifcurl works and the browser does not, this is the variable.
• OLLAMA_MODELS — the path to the models directory. The usual reason to set it is a second disk. Two things catch people: the service user must own the new directory, and the existing blobs do not move themselves, so a change without a copy looks like every model vanished. See where Ollama stores models.
• OLLAMA_NOPRUNE — do not prune model blobs on startup. Relevant when the model directory is shared or managed by something other than Ollama and you do not want a restart deciding some blobs are unreferenced.

Memory and scheduling

This group decides what is resident and how much of the card each resident thing gets. The four that matter most:

• OLLAMA_KEEP_ALIVE — how long models stay loaded in memory, documented with a default of 5m. It takes Go duration syntax, so 30m and 2h both work; a negative value keeps the model loaded indefinitely and zero unloads it immediately after each response.
• OLLAMA_CONTEXT_LENGTH — the context length to use unless otherwise specified. Its documented default is no longer a single number but is chosen from the available VRAM; the default context length covers the tiers and the precedence, which is worth reading before you set this, because a model image can override it.
• OLLAMA_MAX_LOADED_MODELS and OLLAMA_NUM_PARALLEL — the model count and the per-model concurrency, which multiply into total cache demand. Running multiple models at once works through the budget.
• OLLAMA_GPU_OVERHEAD — reserve a portion of VRAM per GPU, in bytes. The unit is the trap: this is bytes, not megabytes, so a gigabyte reservation is 1073741824. Use it when loads that the scheduler predicts will fit do not.
• OLLAMA_MAX_QUEUE and OLLAMA_LOAD_TIMEOUT — how many requests queue before rejection (512) and how long a stalling load is tolerated (5m).

Performance and hardware

• OLLAMA_FLASH_ATTENTION — enable flash attention. Whether it helps depends on the model and the hardware, and it is a prerequisite for cache quantization on some builds, which is often the real reason to turn it on.
• OLLAMA_KV_CACHE_TYPE — the quantization type for the K/V cache, documented as defaulting to f16. This is the highest-leverage memory setting on the list, because cache size scales linearly with bytes per element: an 8-bit cache halves the per-token cost of context. It is a quality trade, not a free one.
• OLLAMA_SCHED_SPREAD — always schedule a model across all GPUs. For a model too large for one card this is the switch; for several models on several cards it is the opposite of what you want, since it spreads each one everywhere.
• OLLAMA_LLM_LIBRARY — set the LLM library to bypass autodetection. A diagnostic rather than a tuning knob: forcing a CPU backend proves whether a wrong GPU library is the cause of a crash.
• CUDA_VISIBLE_DEVICES — not an Ollama variable, but the usual way to restrict which cards it uses. Ollama’s GPU documentation notes that numeric IDs may be ordered unpredictably and that UUIDs are more reliable.

Debugging, and the authoritative list

OLLAMA_DEBUG=1 raises the log level and is the first thing to set when a model will not load or lands on the CPU — the extra output includes the hardware detection and the layer-fitting decision. OLLAMA_NOHISTORY stops the interactive prompt preserving readline history, which matters on a shared or sensitive machine.

The list above is a guide, not the specification. The specification is the binary, and it will tell you:

ollama serve --help

That prints every variable the build you have actually reads, with its description and current value, which is the only listing guaranteed to match your version. Ollama adds and retires variables between releases — several that appear in older tutorials no longer exist, and setting a name the server does not recognise fails silently, because there is nothing to reject an unknown environment variable.