Ollama's configuration lives in environment variables, and finding the full list is harder than it should be. The official FAQ documents a handful. The rest are scattered across GitHub issues, Reddit threads, and the source. Two of the top Google results for "ollama environment variables" are literally GitHub issues asking the maintainers to write this page down.
So here it is: every Ollama environment variable, what it controls, its real default, and where to set it on macOS, Linux, Docker, and Windows. This reference was rebuilt on 2026-07-29 by reading envconfig/config.go at v0.32.5 line by line rather than by paraphrasing the FAQ, because on several variables the two disagree and the source wins. This reference assumes Ollama is already running. If it is not, our install guide for Mac gets you there first.
What are Ollama environment variables?
Ollama environment variables are settings the Ollama server reads at startup to control networking, model storage, memory behavior, and inference performance. Ollama v0.32.5 reads 26 OLLAMA_ variables plus the GPU selection and proxy variables it inherits from the environment. The server reads them once when it launches, so changing one only takes effect after you restart Ollama.
The distinction that trips people up: these configure the background server (ollama serve), not the ollama run command. Setting one in the same shell where you type ollama run does nothing if the server is already running as a separate process or a macOS app. The server has its own environment, and that is the one that counts.
Which Ollama version is this reference for?
This reference is audited against Ollama v0.32.5, released 2026-07-27. Every default below was read from envconfig/config.go at that tag. Nothing in that file changed between v0.30.10 (2026-06-17) and v0.32.5: the file is byte-identical across both, so no variable was added, removed, or had its default changed in that window.
That last point is worth stating plainly because most "what's new in Ollama" posts imply otherwise. Between mid-June and late July 2026, zero environment variables changed. What did change was runtime behavior and documentation, and one of those changes invalidates advice that is still repeated almost everywhere, including in the earlier version of this page. It is covered in the flash attention section below.
Where do you set Ollama environment variables?
Set Ollama environment variables in your shell profile for terminal use, with launchctl setenv for the macOS app, in the systemd unit on Linux, or with -e flags for Docker. Ollama reads them at server startup, so restart Ollama after any change.
The right method depends entirely on how Ollama is running, and getting this wrong is the most common reason a variable seems to be ignored.
Terminal (you run ollama serve yourself): add the export to your shell profile.
export OLLAMA_KV_CACHE_TYPE=q8_0Put that in ~/.zshrc (macOS default) or ~/.bashrc, then open a new terminal and start the server.
macOS app: the menu-bar app is launched by launchd, not by your shell, so it never sees ~/.zshrc. Ollama's FAQ specifies launchctl for this case. Set the variable, then quit and reopen Ollama.
launchctl setenv OLLAMA_KV_CACHE_TYPE q8_0Linux (systemd service): edit the unit with sudo systemctl edit ollama.service and add the variable under [Service].
[Service]Environment="OLLAMA_KV_CACHE_TYPE=q8_0"Then sudo systemctl daemon-reload and sudo systemctl restart ollama.
Docker: pass it with -e at run time.
docker run -e OLLAMA_KV_CACHE_TYPE=q8_0 -p 11434:11434 ollama/ollamaWindows: quit Ollama from the task bar, open "Edit environment variables for your account", add the variable, then start Ollama again from the Start menu.
The complete Ollama environment variable reference
Every variable Ollama reads, grouped by what it controls, with the default as compiled into v0.32.5. Where a default is a sentinel value that the server resolves later at runtime, both are given, because the compiled literal and the effective behavior are different numbers and confusing them is the source of most of the wrong tables on this topic.
How do I keep an Ollama model loaded in memory?
Set OLLAMA_KEEP_ALIVE to control how long a model stays in memory after its last request. The default is 5 minutes. Any negative number keeps models loaded indefinitely, and 0 unloads immediately after each request.
This is the variable people reach for after the first time a model unloads mid-session and the next prompt takes ten seconds to reload from disk. A negative value trades RAM for latency: the model sits in memory until you stop the server. On a machine you use for AI all day, that trade is usually worth it. On a 16GB Mac where you also need memory for everything else, the 5-minute default exists for a reason.
The value accepts a duration string such as 10m or 24h, a plain number of seconds such as 3600, or any negative number. -1 is the conventional way to write "forever", but -1m does the same thing: the source converts every negative value to the maximum duration, so there is nothing special about -1 specifically.
What is Ollama's default context length?
Ollama's default context length is no longer a fixed 4096. OLLAMA_CONTEXT_LENGTH compiles to 0, a sentinel meaning "decide at runtime", and the server then picks 4K, 32K, or 256K tokens from the VRAM it finds: 4096 below 23GiB, 32768 at 23GiB or more, and 262144 at 47GiB or more.
The thresholds sit deliberately under the round numbers, so a 24GB Mac clears the 23GiB tier and a 48GB Mac clears the 47GiB one. In practice a 24GB MacBook defaults to 32K tokens and a 64GB machine defaults to 256K, while a 16GB machine stays at 4096. Most references still print a flat 4096 because that is the value the variable used to hold, and it is now correct for the bottom tier only.
Which tier you land in drives how much memory a model needs at load, so it is worth establishing before you tune anything else. You can check where your own Mac lands against a given model rather than working back from the tier boundaries.
Setting OLLAMA_CONTEXT_LENGTH explicitly overrides the tier in either direction. Raising it on a small machine is the quickest way to make a model fail to load, and lowering it on a large one is a legitimate way to keep more models resident at once.
How do I reduce Ollama's memory usage?
Set OLLAMA_KV_CACHE_TYPE=q8_0 to roughly halve the memory the context cache uses. It takes effect only when flash attention is active, which on supported hardware it now is by default.
The context (KV) cache grows with your context length and, at 32K or more tokens, can use more memory than the model weights themselves. How much it costs depends on the model you run: the memory Qwen 3.6 27B needs is listed against every Mac configuration, so you can size the weights side of the equation before adding the cache on top. Quantizing it from the default f16 down to q8_0 cuts that roughly in half for a perplexity increase that benchmarks put at 0.002 to 0.05, which nobody notices in practice. q4_0 quarters it with a larger, measurable trade-off. We cover the full quality and memory picture in Ollama KV cache quantization.
Two caveats the FAQ states but most guides drop. First, this is a global setting: every model the server loads runs with the type you set, and there is no per-model override. A Modelfile parameter for it was proposed in December 2024 and has never been merged, so any guide showing kv_cache_type in a Modelfile or /set parameter is quoting an unmerged pull request. Second, quantized KV cache silently falls back to f16 on model architectures that do not support it, so setting q8_0 is not a guarantee that you got it. Check your memory use rather than assuming.
Is Ollama flash attention on by default?
Yes, on supported hardware. Since October 2025, OLLAMA_FLASH_ATTENTION has been a three-state override rather than an off-by-default switch: leave it unset and Ollama enables flash attention automatically wherever the selected backend and devices support it, set 1 to force it on, or set 0 to force it off.
This is the single most out-of-date piece of Ollama advice in circulation, and this page carried it too until this update. The change landed in commit fdb1094 on 2025-10-01, which swapped the variable from a plain boolean to a three-state one and deleted the branch that required you to opt in. Ollama's own FAQ was not corrected until 2026-07-03, in PR #16994, which shipped in v0.31.2 on 2026-07-06 and removed the sentence "To enable Flash Attention, set the OLLAMA_FLASH_ATTENTION environment variable to 1". For nine months the official documentation told people to set a variable that had already stopped working the way it described, which is why the bad advice is now everywhere.
There is a genuine trap that keeps the myth alive. Ollama's startup environment dump renders this variable's value as false when it is unset, because the dump asks for the value with a false fallback rather than for the resolved runtime decision. So you can start the server, read OLLAMA_FLASH_ATTENTION:false in your own log, and reasonably conclude flash attention is off while it is actively running. That log line reports the variable, not the behavior.
Hardware support is still expanding, which is why the honest answer needs a hardware qualifier and not just a version. v0.31.2 enabled flash attention on NVIDIA GPUs with compute capability 6.x after upstream Pascal kernel fixes, and the gate requires every enumerated device to qualify, so one unsupported GPU in a multi-GPU box turns it off for all of them. Setting OLLAMA_FLASH_ATTENTION=1 is still useful as a forcing function, and 0 is the documented way to rule it out while debugging.
How do I let other devices connect to Ollama?
Set OLLAMA_HOST=0.0.0.0:11434 to bind Ollama to all network interfaces, and OLLAMA_ORIGINS to allow cross-origin browser requests. By default Ollama binds only to 127.0.0.1, so other machines cannot reach it.
The two are separate problems. OLLAMA_HOST controls which network interface the server binds to. OLLAMA_ORIGINS controls which web origins the browser is allowed to call. If you are wiring a web app to Ollama and getting a silent CORS failure, the host is fine and the origins are the issue. We walk through that exact fix in the Ollama CORS fix on Mac.
The default origin list is wider than "localhost". AllowedOrigins() walks localhost, 127.0.0.1 and 0.0.0.0, allowing each over both http and https, bare and on any port, then appends app://*, file://*, tauri://*, vscode-webview://* and vscode-file://*. That is why an Electron, Tauri, or VS Code extension client talks to Ollama with no configuration, and why a dev server on any localhost port does too. What is not covered is an origin that is not local at all: a LAN address, a custom hostname, or a page served from a real domain. One property of the list matters more than its contents: it is appended on every start, so OLLAMA_ORIGINS can only widen it and no value revokes local access.
OLLAMA_HOST also has parsing behavior worth knowing: it defaults the scheme to http and the port to 11434, uses https on port 443 for ollama.com, expects IPv6 addresses in brackets, and on an unparseable port logs a warning and silently reverts to the default rather than failing to start.
Can Ollama offload the KV cache to system RAM?
No. Ollama has no environment variable for KV cache offload and does not expose the underlying flag. It offloads model layers and the KV cache to the GPU together.
This comes up when a model almost fits in VRAM and the cache is what pushes it over. The control people are told to reach for, --no-kv-offload, is a llama.cpp flag, and Ollama never passes it: the argument list Ollama builds for llama-server includes the adjacent --no-mmproj-offload but not this one. Two attempts to surface it went nowhere. PR #9751 has been a draft since 2025-03-26, and an earlier attempt, PR #7274, was closed unmerged on 2025-08-08. The tracking issue, ollama/ollama#9750, is still open but has had no activity since the day it was filed in March 2025.
There is one undocumented side channel. Ollama passes its own environment through to the llama-server process it spawns, and llama.cpp reads LLAMA_ARG_KV_OFFLOAD for this flag. Setting that variable in the server's environment therefore does reach the runner. It is not an Ollama feature, it is not documented, and nothing guarantees it survives a release, so treat it as a workaround rather than configuration.
How can I see which environment variables Ollama is using?
Start the server with OLLAMA_DEBUG=1 and Ollama logs its environment at startup. The dump is close to complete but not exact: at least one variable is missing from it, and two report a placeholder instead of the value actually in effect.
This is still the fastest way to confirm a variable took effect, because the most common configuration bug is setting the variable in one environment and running the server in another. If the dump shows the value you set, the setting is live. If it shows the default, you set it in the wrong place.
Three exceptions to know before you trust it. OLLAMA_AUTH is declared in the source but has no entry in the map that backs the dump, so it never appears at all. OLLAMA_FLASH_ATTENTION prints false when unset even though the real default is automatic, as described above. OLLAMA_IGPU_ENABLE prints an empty string when unset, because it has no fixed default and the decision is made per device. For those three, the log tells you what you set, not what the server decided.
Which Ollama environment variables no longer exist?
Several variables that older guides still recommend are dead. OLLAMA_MAX_VRAM has been removed from Ollama's production code, and OLLAMA_TMPDIR is still recommended by Ollama's own troubleshooting page despite no code reading it.
This matters more than a normal deprecation list because these appear in highly ranked tuning guides, so people set them, see no effect, and assume they set them in the wrong place. They did not. The variable is gone. The table below is the current status of every commonly cited variable that Ollama does not read.
The case for not configuring any of this
Ollama has quietly gotten better at this. Flash attention turns itself on now, context length scales with your VRAM instead of sitting at 4096, and the loaded-model limit adapts to your GPU count. Those were all manual variables not long ago, and the honest read is that the gap between "Ollama out of the box" and "Ollama tuned" is smaller in v0.32.5 than it has ever been.
What remains is that the configuration surface is still 26 variables wide, the documentation lags the code by months at a time, and the defaults that are left are still cautious. The context cache defaults to f16 when q8_0 would save memory for free, and it is a global setting that silently degrades to f16 on architectures that cannot take it, so the one memory lever you are told to pull is also the one you cannot verify from the outside.
ToolPiper takes the other approach. It bundles the same llama.cpp engine and runs the same GGUF models, but it decides the KV cache type per model rather than globally: it reads each model's GGUF header, checks the head dimensions against what the Metal backend can actually serve, and uses q8_0 when it is safe and f16 when it is not. You get the memory saving on every model that supports it and a load that works on the ones that do not, with no variable to set and no silent fallback to discover later. It also serves CORS headers natively so there is no origins variable to set, and shows per-model memory directly so you can see what a model costs before you load it.
And the variables above stop being the interface. The tuning they express - context length, keep-alive, parallelism, flash attention - is settings in a native app rather than environment state you export in a shell profile and re-derive on every machine. That is a transition path, not the recommended setup. The honest limitation: ToolPiper is macOS only. If you run Ollama on Linux or Windows, the variables in this reference are how you get there, and they work.
Download ToolPiper at modelpiper.com, or use the reference above and keep tuning Ollama directly.
Part of our series on running Ollama on Mac. See also: Ollama KV cache quantization, the Ollama CORS fix, and running multiple Ollama models on Mac.