How to Keep Ollama Model Loaded for Memory

Why Ollama dey unload model after some minutes?

Ollama dey keep model loaded for memory for five minutes after the last request, then e free am. The next request gatz read the weights from disk and map dem into RAM or VRAM again, so e go stall before the first token show. Na why chat UI or coding agent fit dey fast, go quiet for some time, then e slow again for the next message. Nothing spoil. Idle timer don expire.

The timer na keep_alive. E dey apply to each model, and e restart every time request finish. Model wey dey answer request at that time no dey unload, because server only dey expire model wey no get active request. As of August 2026, default na five minutes, and e apply to every model wey this server load.

You fit set keep_alive for two places: for individual request, or as server default. systemd drop-in na wetin make server default remain after restart. This guide assume say Ollama don already dey run as service. If e no dey run like that, start with installing Ollama for VPS and come back.

Which models dey resident now, and when dem go expire?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Empty output mean say nothing dey loaded, so the next request go pay full load time. PROCESSOR tell you where the weights dey. 100% GPU and 100% CPU na the clear cases. A split like 25%/75% CPU/GPU mean say the model no fit inside VRAM, so part of am dey run for processor and generation dey slower.

UNTIL na the countdown, and e dey print relative time like 4 minutes from now. E dey print Forever when dem load the model with negative keep_alive. E dey print Stopping... during the short period wey server dey unload.

The column set don change between releases, so read the header instead of counting fields for script. For anything automated, ask the API:

curl -s http://localhost:11434/api/ps

Each entry carry expires_at, an absolute timestamp like 2026-08-09T14:38:31.83753Z, and size_vram, the part of that model wey dey inside GPU memory. A size_vram of 0 mean say the model dey run for CPU.

Wetín reload really dey cost

No dey guess am. Ollama dey report load time for every response as load_duration, for nanoseconds.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

The first call dey load the model, so e get big load_duration. Divide am by 1000000000 to read am as seconds. The second call dey run while the model still dey resident and e report much smaller number. The difference between those two figures na wetin every user go pay once the timer don expire, and na the full reason to change keep_alive. For the generation speed before and after that pause, see how to measure tokens per second for your own box.

Keep Ollama model dey memory for one request

Send keep_alive with the request. E apply to that model from the time request finish.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Four value forms dey accepted:

• duration string: "30m", "24h", "90s"
• plain number, wey dem read as seconds: 3600
• negative value, -1 or "-1m", wey mean say no idle timeout at all
• 0, wey mean say unload am as soon as this request finish

Value wey dey for request go override server default, for both directions. This one important pass as e fit sound: client wey send im own keep_alive go win over anything wey you configure for server.

You fit also load model without generating anything. Send only the model name. Server go load am and return empty response with "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Na this command you go run after reboot, or after you pull new model, so the first real user request no go wait for the model to load. CLI dey do the same work with one flag:

ollama run --keepalive 30m qwen3:8b "hello"

Make e dey loaded by default with OLLAMA_KEEP_ALIVE

Server dey read OLLAMA_KEEP_ALIVE when e start, then e dey use am for every model wey no carry im own value. E dey accept the same formats like the request field, so 30m, 3600 and -1 all dey work.

The main issue na which environment variable environment need dey inside. If you run export OLLAMA_KEEP_ALIVE=30m for your SSH session, e no go do anything, because packaged install dey run server as systemd service under im own user and im own environment. Your login shell and that service no dey share environment. Na this be the commonest reason why the setting dey look like say e no work.

Make e survive restart with a systemd drop-in

sudo systemctl edit ollama.service

Editor go open with two comment markers. Type between dem: systemd dey discard anything wey you write below the second marker.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

When you save, e dey write /etc/systemd/system/ollama.service.d/override.conf. This one na drop-in, no be edit of the unit wey package release, so Ollama package upgrade wey replace ollama.service no go change your setting. If drop-ins and unit files new to you, the systemd service and timer guide explain how the mechanics work.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

The last command dey print the environment wey the service go really run with. If OLLAMA_KEEP_ALIVE=30m no dey for that line, the drop-in no take effect. The cause almost always na missing [Service] header or lines wey you type below the marker. The restart itself go drop every loaded model, so the next request go be cold load. Warm am up with the preload call above.

Wetin keeping model resident go cost you

The SIZE column for ollama ps na memory wey dey hold for the whole idle window, no be only when request dey happen. An 8B model for 4-bit quantisation dey around 5 to 6 GB. A 27B model na different matter, and the memory calculation to run one for CPU-only VPS worth working through before you decide to keep one resident. Set keep_alive to -1 and you don decide say the model pass every other thing for the box, permanently. For small VPS, na direct trade-off against your database, web app, and build jobs.

Monitor the real numbers instead of trusting estimate. Run this while model dey loaded, then run am again after ollama stop:

free -h

The available column na the memory wey kernel fit still give to new process. For NVIDIA GPU box, nvidia-smi dey show the same situation for VRAM. If the box run out of memory, kernel go kill one process to recover:

sudo dmesg -T | grep -i "out of memory"

A line wey name ollama mean say model server na the victim. A line wey name your database mean say model win and something wey matter to you lose. Both outcomes come from the same decision: long keep-alive window for box wey no get spare capacity.

Two costs for here easy to miss. Longer context length dey reserve bigger KV cache (key value cache, the per token attention state wey model dey keep while e dey generate), and that cache na part of the resident size. OLLAMA_NUM_PARALLEL above 1 dey reserve that cache once for every parallel slot. If you plan to serve several people from one model, size the memory for the slots, no be for the weights alone.

Reasonable default: one model for box wey get spare capacity fit use -1. Shared box should use window wey cover the gaps between your requests, like 30m, so the memory go return when you stop work.

Unload model sharp sharp

ollama stop qwen3:8b

E go return with no output, and model go disappear from ollama ps. Name wey no dey loaded go give couldn't find model "qwen3:8b" to stop. For API form, na request without prompt, with keep_alive set to 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

Reply go carry "done_reason": "unload". Use this one instead of restarting the service. systemctl restart ollama go free the memory too, but e go remove every other model wey dey loaded and stop any request wey dey run.

How to run more than one model for one server

OLLAMA_MAX_LOADED_MODELS dey limit how many models fit stay loaded at once. As of August 2026, the default na three per GPU, or three for a CPU-only machine. The limit count models, but memory na the real limit. So, system fit reject another large model because memory don full, even before you reach three.

When person request new model and memory no enough, scheduler go unload one model wey dey resident to create space. E prefer model wey no get active request. E fit also remove model wey timer never expire, including model wey load with -1. So, negative keep_alive mean say no idle timeout dey. E no lock the weights against request for another model.

System dey log this decision for debug level. Add another Environment="OLLAMA_DEBUG=1" line to the same drop-in, restart, then monitor:

sudo journalctl -u ollama -f

If you see line about unloading a runner to create space near the request wey cause am, e show say these two models no fit stay together for this machine. The solution na to use fewer models for this box, or set long window for the one wey must answer fast and 0 for the one wey you call rarely.

Guidance wey fit last pass the next release

Ollama dey release often and e dey change im defaults, so check the build wey dey in front of you instead of memorising numbers:

ollama --version
ollama serve --help

ollama serve --help dey list the environment variables wey that build actually dey read, including OLLAMA_KEEP_ALIVE. Two rules don remain true across releases and you fit safely use dem. Value for the request dey override server default. And ollama ps na the real proof of wetin dey loaded, no matter wetin config file talk say suppose dey loaded.

If editor or agent dey control your server, check wetin that client dey send before you blame the server. Pointing coding agent go your own Ollama server explain where those request settings dey.

FAQ

Why Ollama dey unload my model after 5 minutes?

Five minutes na the default keep_alive, wey be the idle timer Ollama dey start when request finish. When e expire, server go free the weights, so the next request go load dem again from disk. Na this reload cause the pause wey you dey feel. Raise am for one request by sending "keep_alive": "30m" inside the JSON body, or set am for the whole server with the OLLAMA_KEEP_ALIVE environment variable.

How I fit keep Ollama model loaded for memory permanently?

Use negative value: "keep_alive": -1 for the request, or OLLAMA_KEEP_ALIVE=-1 for the server. ollama ps go then show Forever for the UNTIL column. This one remove only the idle timer. If another model request come and memory no plenty, the scheduler still go unload this one to create space.

Why OLLAMA_KEEP_ALIVE no dey work?

Check where you set am. Run systemctl show ollama --property=Environment. If the variable no dey inside that output, server never see am, because variable wey you export for your shell no reach systemd service. Set am with sudo systemctl edit ollama.service, then run sudo systemctl daemon-reload and sudo systemctl restart ollama. The other reason fit be client wey dey send im own keep_alive for the request. This one go override the server default.

How I fit free the memory without restarting Ollama?

ollama stop qwen3:8b go unload that one model immediately, while server and every other loaded model continue to run. Through the API, send request wey no get prompt and "keep_alive": 0. The reply go come back with "done_reason": "unload". Confirm am with ollama ps. The model no suppose dey listed again.