Ollama works out of the box, but its real power comes from tuning it. Knowing how Ollama environment variables and Modelfile configuration work lets you control where models are stored, how long they stay loaded, and how they behave by default.
If you are already running local AI models with Ollama, this guide takes you one level deeper. You will learn where Ollama stores its files on each operating system, which environment variables matter most, and how to build a custom model with your own system prompt using a Modelfile.
Every command below is tested and real, with specific instructions for Windows, macOS, and Linux.
Where Does Ollama Store Models?
By default, Ollama stores downloaded models in a hidden folder inside your user profile. The exact location depends on your operating system.
| Operating system | Default model storage path |
|---|---|
| Windows | C:Users<username>.ollamamodels |
| macOS | ~/.ollama/models |
| Linux | /usr/share/ollama/.ollama/models |
Inside the models directory you will find two subfolders: manifests and blobs. Manifests are small JSON files describing each model, while blobs hold the actual multi-gigabyte weights.
Because large models can easily consume tens of gigabytes, many users move storage to a secondary drive. That is exactly what the OLLAMA_MODELS variable is for.
Key Ollama Environment Variables
Ollama reads several environment variables when the server starts. The table below summarizes the most useful ones.
| Variable | What it does | Example value |
|---|---|---|
| OLLAMA_MODELS | Changes the directory where models are stored | D:ollamamodels |
| OLLAMA_HOST | Address and port the server listens on | 0.0.0.0:11434 |
| OLLAMA_KEEP_ALIVE | How long a model stays loaded after a request | 30m |
| OLLAMA_NUM_GPU | Limits how many GPUs Ollama may use | 1 |
OLLAMA_MODELS: Change the Storage Location
Set OLLAMA_MODELS to a full folder path to relocate your model library. Move or re-download your models afterward, because Ollama will look only in the new location.
OLLAMA_HOST: Expose the Server on Your Network
By default the server listens on 127.0.0.1:11434, reachable only from the same machine. Setting OLLAMA_HOST to 0.0.0.0:11434 lets other devices on your LAN connect, which pairs well with our guide to running an Ollama API server.
OLLAMA_KEEP_ALIVE: Control Model Unloading
The Ollama keep alive default is 5m, meaning a model unloads from memory five minutes after its last request. Use 0 to unload immediately, or -1 to keep the model in memory indefinitely.
A longer keep alive removes cold-start delay between requests, at the cost of holding VRAM. Short values suit machines shared between many models.
You can also override keep alive per request by passing a keep_alive field in the API body. The environment variable simply sets the default when no per-request value is given.
OLLAMA_NUM_GPU: Limit GPU Usage
On multi-GPU systems, OLLAMA_NUM_GPU caps how many GPUs Ollama will use. This is handy when you want to reserve a card for gaming or another workload.
Note that the similarly named num_gpu inside a Modelfile means something different: it sets how many layers are offloaded to the GPU. More on that below.
How to Set Environment Variables on Each OS
Windows: setx or System Settings
The fastest method on Windows is the setx command in a terminal. It writes the variable to your user environment permanently.
setx OLLAMA_MODELS "D:ollamamodels"You can also use the graphical route: open Settings, search for “environment variables”, and add a new user variable. Either way, fully quit Ollama from the system tray and restart it so the change takes effect.
macOS: launchctl setenv
On macOS the Ollama app does not inherit shell variables, so use launchctl to set them for the GUI session.
launchctl setenv OLLAMA_KEEP_ALIVE "30m"Quit and relaunch the Ollama app afterward. Keep in mind that launchctl variables reset on reboot, so repeat the command or add it to a login script if you want persistence.
Linux: systemd Override
On Linux, Ollama usually runs as a systemd service, so the cleanest approach is editing the service unit.
sudo systemctl edit ollama.serviceAdd an Environment line inside a Service section, then reload and restart the service.
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"sudo systemctl daemon-reload
sudo systemctl restart ollamaVerify the variable landed by checking the service environment or logs with journalctl.
sudo journalctl -u ollama -n 20 --no-pagerThe Modelfile: Custom Models and System Prompts
A Modelfile is Ollama’s recipe format for building a custom model from an existing base. It lets you bake in a default Ollama system prompt, tune generation parameters, and even rewrite the chat template.
FROM: Choose the Base Model
Every Modelfile starts with FROM, which names the base model or a local weights file. This is the only required instruction.
FROM llama3.1:8bSYSTEM: Set a Default System Prompt
The SYSTEM instruction injects a system prompt into every conversation with the custom model. Use it to define tone, role, or output rules once instead of repeating them in each request.
SYSTEM """You are a concise senior code reviewer. Always answer with bullet points and include a severity rating for each finding."""PARAMETER: Tune Generation Behavior
PARAMETER lines set defaults for sampling and context. The most commonly adjusted options are:
- temperature — randomness of output; lower values are more deterministic
- num_ctx — context window size in tokens; higher values use more memory
- num_gpu — number of layers offloaded to the GPU; 0 forces CPU-only inference
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
PARAMETER num_gpu 99Setting num_gpu to a high number like 99 simply offloads every layer the model has, which is the usual intent on a single GPU.
TEMPLATE: Customize the Prompt Format
TEMPLATE redefines how messages are assembled into the raw prompt string. Most users never need it, because the base model already ships a correct template.
When you do override it, you write a Go template referencing .System, .Prompt, and .Response. Get it wrong and output quality collapses, so only touch TEMPLATE when porting a model with an unusual format.
Step-by-Step: Create a Custom Model with ollama create
Here is a complete worked example that builds a coding assistant with a built-in system prompt. First, create a file named Modelfile with this content.
FROM qwen2.5-coder:7b
SYSTEM """You are an expert programming assistant. Give short, correct answers with runnable code examples. Never explain obvious syntax."""
PARAMETER temperature 0.1
PARAMETER num_ctx 16384Next, run ollama create to build the custom model under a new name.
ollama create my-coder -f ModelfileFinally, verify it exists and run it like any other model.
ollama list
ollama run my-coderEvery session with my-coder now starts with your system prompt and tuned parameters. This pattern works great with the best Ollama models for coding as the base.
If you ever need to remove the custom variant, use ollama rm with its name.
ollama rm my-coderConclusion
Ollama environment variables and Modelfiles are the two levers that turn a default install into a tailored local AI setup. Variables control the server — storage paths, network binding, keep-alive timing, and GPU allocation — while the Modelfile shapes how each model behaves.
Start with OLLAMA_MODELS if disk space is your pain point, then create a custom model with a SYSTEM prompt for your most common workflow. Both changes take minutes and pay off every time you run a model.