Ollama keep_alive: retain or unload a model deliberately

Ollama’s keep_alive controls how long a model stays loaded after a request. It affects the next request’s loading work and the memory left for other applications. It does not by itself define generation speed, model quality or the complete memory requirement.

Separate loading from generation

A first request after unloading can include reading weights and preparing execution. A repeated request may avoid that work. The generate API exposes timing information that helps separate those stages; preserve the relevant response fields and request settings.

Record the pause before each request. Without that interval, two similar timing reports can describe different states. A fast request immediately after another one is not a reliable estimate for a user who returns after a long idle period.

Set an explicit test interval

The original local example for an already available model is:

curl http://127.0.0.1:11434/api/generate \
  -d '{"model":"qwen3:8b","prompt":"Reply with one word.","stream":false,"keep_alive":"10m"}'

The prompt asks for a one-word answer. The 10m value is an experimental retention period, not a recommendation for every workstation. Replace the model tag with the installed artifact and inspect ollama ps after the request.

Keep server defaults and per-request settings in the notes. If several clients use different values, a single screenshot is unlikely to explain the full retention behaviour. Test the route the actual application uses.

Test unloading separately

The documentation provides 0 for unloading after the request. Verify the documented behaviour with a small test and check the loaded-model state. Do not unload a model currently needed by another authorised task without coordinating the test.

A completed HTTP response and the later release of memory are separate observations. Use the process information and appropriate system monitoring at a defined point rather than concluding that unloading failed from an unrelated allocation.

Compare two realistic schedules

Try three requests with short pauses, followed by one after a longer idle period. Save loading time, generation time and occupied memory. If the application alternates models, include an A, B, A sequence to reveal switching costs.

For a shared workstation, also check what memory remains for the owner’s applications. A useful result describes both the user-visible delay and the operating schedule. Preserve the model, context and retention value so another person can reproduce the chosen compromise after restarting the service.

Turn the check into a practical next step

Retention trades repeated loading against occupied memory. Choose it from the request schedule and verify the effect with process information and timings.

For the documented details, consult the primary documentation; configuration reference. Continue with ollama two models parallel and ollama cpu gpu split.