Ollama Keep Alive in 2026: How to Keep Models Loaded, Avoid Reloads & Fix Slow Requests
If Ollama feels fast on the second request but painfully slow after a few minutes, the problem may not be your model, GPU or prompt. Ollama can unload models when they are no longer needed, and its scheduler can also load, keep, and evict models according to available memory and concurrent demand.
This makes keep_alive, ollama ps, context length, parallel requests and model scheduling important when you use Ollama as an application backend rather than just an interactive chatbot. The goal of this guide is to show how to control and diagnose model residency without treating “keep the model loaded forever” as a universal fix.
What Ollama model residency actually means
When you call Ollama, there are two separate things to think about: the model files stored on disk and the model runner loaded into memory. A model can be downloaded and available locally while its active runner is not resident in GPU or system memory.
That distinction explains a common pattern: the first request is slow because the runner must be loaded; later requests are faster because it remains resident; after an idle period, the next request becomes slow again because the runner has been unloaded.
Ollama's newer scheduler also considers the actual memory required to run a model instead of relying only on a rough estimate. Ollama says this improved scheduling reduces unnecessary out-of-memory failures and improves placement across GPUs.
How to check what is loaded right now
Start with:
ollama psThis is more useful than looking only at ollama list. The latter tells you which models are available locally; ollama ps tells you which models are currently running.
For a repeatable troubleshooting test, record the output immediately after a request, wait for your configured idle period, and run ollama ps again. If the model disappears, the runner is no longer resident and the next request will need another load.
What does keep_alive do?
The keep_alive setting controls how long Ollama should keep a model loaded after a request. You can set it for an individual API request or configure a default through the Ollama environment.
| Goal | Example | Trade-off |
|---|---|---|
| Default behavior | Omit keep_alive | Less memory pressure, but idle models can be unloaded |
| Keep a model warm temporarily | "keep_alive":"30m" | Faster repeat requests while consuming memory |
| Keep it loaded indefinitely | "keep_alive":-1 | Can reserve substantial memory and interfere with other models |
| Unload after the request | "keep_alive":0 | Frees residency quickly, but repeated requests pay load cost |
Use the shortest residency period that gives your application a meaningful benefit. “Forever” is a resource policy, not a performance setting.
Set keep_alive with the native Ollama API
A simple request can explicitly keep a model warm:
curl http://localhost:11434/api/chat \
-H "Content-Type: application/json" \
-d '{
"model": "gemma3:4b",
"messages": [
{"role": "user", "content": "Reply with OK"}
],
"stream": false,
"keep_alive": "30m"
}'For an unload test, use:
curl http://localhost:11434/api/chat \
-H "Content-Type: application/json" \
-d '{
"model": "gemma3:4b",
"messages": [
{"role": "user", "content": "Reply with OK"}
],
"stream": false,
"keep_alive": 0
}'Then run:
ollama psThe exact model name must match a model installed on your machine. Replace gemma3:4b with your actual tag.
Set a default with OLLAMA_KEEP_ALIVE
If you operate Ollama as a service and want a consistent default, Ollama supports the OLLAMA_KEEP_ALIVE environment variable.
For example, on a Linux systemd installation, the environment can be configured as part of the Ollama service:
[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"After changing a systemd override, reload the service configuration and restart Ollama:
sudo systemctl daemon-reload
sudo systemctl restart ollamaVerify the service is running:
systemctl status ollamaDo not assume that changing the environment variable changes an already-running model immediately. Test with a fresh request and inspect ollama ps.
Why keep_alive does not guarantee permanent GPU residency
This is the most important distinction for troubleshooting. A keep-alive preference does not mean Ollama can ignore memory pressure or scheduling decisions.
If you keep several large models warm, the scheduler still has to decide what can coexist. Loading another model may require an existing runner to be evicted. A long keep-alive therefore should not be interpreted as “reserve this model's VRAM no matter what.”
Ollama's model scheduling documentation describes memory-aware scheduling and multi-GPU placement.
Context length can change the memory picture
Two requests using the same model weights can have very different memory requirements because context and KV cache consume additional memory. A coding agent configured for a large context can therefore behave differently from a short chat request even when both use the same model tag.
That matters when you diagnose unexpected model eviction. If the model fits comfortably with a small context but becomes difficult to keep resident at a much larger context, reducing context can be a more appropriate fix than forcing keep_alive=-1.
Parallel requests make residency harder to reason about
An application that sends one request at a time is fundamentally different from an application with multiple agents or users hitting Ollama concurrently. Active requests can require additional memory, and scheduling decisions become more important as concurrency increases.
This is particularly relevant for coding-agent workflows. Ollama's ollama launch integration supports tools such as Claude Code, OpenCode, Codex and Droid, and Ollama's own guidance recommends large context for coding workloads.
A practical diagnostic workflow
Step 1: establish the baseline
ollama psSend one short request and run ollama ps again. Record the model, processor placement and residency information shown by your installed Ollama version.
Step 2: measure the first request
The API response contains timing information such as load and evaluation durations. A large load duration on the first request is expected when the runner was not resident. The useful comparison is between the first request and a second request made while the model remains loaded.
Step 3: test keep_alive
Use a short explicit value such as 30m. Wait less than 30 minutes and repeat the request. Then inspect ollama ps.
Step 4: test memory pressure
Load another model or increase the workload carefully. If the original runner disappears, the important question is no longer “why didn't keep_alive work?” but “did the scheduler have enough memory to keep both runners resident?”
Step 5: check the actual GPU memory
On NVIDIA, use:
nvidia-smiCompare this with ollama ps. Ollama has specifically described its newer scheduler as improving the correspondence between its reported memory usage and tools such as nvidia-smi.
When Ollama repeatedly reloads a model
Repeated loading can come from several different causes:
- The keep-alive period is too short for your workload.
- Another model needs memory and causes eviction.
- Context or concurrency makes the active workload larger than expected.
- A client is explicitly sending its own
keep_alivevalue. - A backend or version-specific scheduler issue is involved.
There are public GitHub reports of scheduler and residency problems in particular hardware/backend combinations. For example, a September 2026 report describes repeated eviction and reload behavior on an NVIDIA GB10 system with Ollama 0.30.6 despite a configured 30-minute keep-alive. That is a community bug report, not proof that the behavior is universal.
Another 2026 report describes a scheduler restart involving context size on Windows and an AMD RX 9070 XT. Again, treat this as a version-specific diagnostic clue rather than a general rule.
Be careful with keep_alive=-1
Keeping a runner alive indefinitely can be useful for a dedicated single-model workstation, but it can be a poor default for shared hardware.
| Hardware/workload | Reasonable starting approach | Why |
|---|---|---|
| Single local chatbot | Default or 10–30 minutes | Good balance between warm responses and memory use |
| Dedicated coding-agent machine | 30 minutes or longer during active sessions | Repeated agent calls benefit from a warm runner |
| Several models on one GPU | Shorter keep-alive | Leaves scheduler room to switch models |
| Memory-constrained laptop | Default or short duration | Avoid unnecessary resident memory pressure |
| Dedicated inference server | Workload-specific | Measure concurrency, context and model-switch patterns first |
OpenAI-compatible clients: verify what they actually send
If you access Ollama through its OpenAI-compatible endpoint, do not assume that a setting in your SDK is being translated exactly as you expect. Client libraries may add or omit request fields, and some integrations have historically had issues around passing extra Ollama-specific parameters.
If behavior looks wrong, reproduce the request directly with curl against Ollama. Once the native HTTP request behaves correctly, compare the application's generated request with the working request.
Security implications of a long-lived model
A model remaining resident is not automatically a security problem, but it changes the operational profile of a service. A long-running endpoint may remain reachable for hours, and multiple applications may share the same Ollama instance.
- Bind Ollama to the interfaces you actually need.
- Do not expose port 11434 publicly without appropriate network controls.
- Be deliberate about which applications can submit prompts.
- Do not assume local inference means every local process is trusted.
- For agent workflows, separate model serving from privileged tools whenever possible.
When keep_alive is not the right fix
If the first request is slow because the model is too large for your hardware, keeping it loaded longer will not solve the underlying capacity problem. If the model is constantly evicted because several models compete for memory, choose a smaller model, reduce context, reduce concurrency or simplify the workload.
Likewise, if the problem is CPU fallback, keep-alive only keeps the wrong execution path warm. Diagnose GPU/backend selection first.
FAQ
What is the default Ollama keep-alive?
Ollama has historically used a finite default residency period, but applications can override it. For reproducible deployments, explicitly configure and verify the value you want rather than relying on an assumed default.
Does keep_alive=-1 use more VRAM?
It can keep a model resident longer, so memory occupied by that runner remains unavailable for other workloads until the scheduler unloads or replaces it. The exact impact depends on the model, backend, context and other loaded models.
How do I force Ollama to unload a model?
Send a request with keep_alive set to 0, then verify the result with ollama ps. If concurrent requests are active, unloading behavior can depend on those requests finishing.
Why is my second request fast but the next request minutes later slow?
The model was probably unloaded between requests. Check ollama ps, then test with an explicit keep-alive period that covers the interval between your requests.
Why does Ollama still evict my model when keep_alive is long?
Memory pressure, concurrent workloads, backend behavior or a version-specific scheduling issue can matter. Treat keep-alive as a residency preference and inspect actual memory and scheduler behavior rather than assuming it is an absolute reservation.
Official sources
- Ollama: New model scheduling
- Ollama launch for coding tools
- Ollama documentation
- Ollama GitHub repository