Ollama keep_alive: Diagnose Reload Delays Before Tuning

Updated 22 October 2026 · Sources & corrections

Quick answer: Ollama’s keep_alive setting controls how long a local model remains loaded after a request. It can help avoid a repeat load when requests are spaced apart, but it does not establish that slow token generation is fixed. Check the server’s loaded-model list and compare its loading and generation metrics before changing a global setting.

This guide focuses on residency and timing diagnosis, not a hardware benchmark. It assumes a working local Ollama server and an installed text model. If a request cannot find the model, use our model-name and server-address checks first.

What keep_alive changes

The official FAQ documents a five-minute default residency period and per-request overrides. Choose an explicit value for the test rather than assuming every client uses the server default.

The request field overrides the server’s OLLAMA_KEEP_ALIVE default. Restarting a service to change an environment variable also changes the test conditions, so start with a per-request setting when diagnosing one client. Indefinite residency is not extra memory and does not remove competition from other workloads.

Confirm what is loaded on the same server

In PowerShell, inspect the running-model API before the first test request and again after it:

$baseUrl = 'http://127.0.0.1:11434'
(Invoke-RestMethod -Uri "$baseUrl/api/ps").models | Select-Object name, expires_at, size_vram

The running-model endpoint reports loaded models, including their expiry and memory information. An empty list does not mean installed model files were deleted. It also does not prove which process served an application configured for another host. Keep the address identical throughout the comparison.

For command-line inspection, ollama ps provides a human-readable view. Read column names rather than relying on a fixed column position across versions. Our model-storage guide covers the separate question of where downloaded files live.

Separate loading from prompt work and generation

The usage reference documents timing fields in nanoseconds. Convert durations to seconds by dividing by one billion. For output token rate, divide eval_count by eval_duration / 1e9; keep that rate distinct from the time the user waited for the complete HTTP request.

These are diagnostic directions, not automatic causal conclusions. Do not classify every slow first answer as a cold load just from its position in a sequence.

Capture two comparable requests without forcing an unload

The following PowerShell example calls the same local model twice with an explicit ten-minute residency request. It does not stop a service, delete files or deliberately evict a model. It does perform inference and consume compute if you run it. Use a suitable installed tag.

$baseUrl = 'http://127.0.0.1:11434'
$modelTag = Read-Host 'Enter an installed local model tag'
$payload = @{
    model = $modelTag
    prompt = 'Reply with one short greeting.'
    stream = $false
    keep_alive = '10m'
} | ConvertTo-Json

1..2 | ForEach-Object {
    $ordinal = $_
    $started = [DateTime]::UtcNow.ToString('o')
    $timer = [Diagnostics.Stopwatch]::StartNew()
    $result = Invoke-RestMethod -Uri "$baseUrl/api/generate" -Method Post -ContentType 'application/json' -Body $payload -TimeoutSec 180
    $timer.Stop()
    if ($result.error -or $result.done -ne $true) {
        throw 'Generation failed or did not complete; do not compare as success.'
    }
    $rate = if ($result.eval_duration -gt 0) {
        $result.eval_count / ($result.eval_duration / 1e9)
    } else { $null }
    [pscustomobject]@{
        request = $ordinal
        started_utc = $started
        wall_seconds = [Math]::Round($timer.Elapsed.TotalSeconds, 3)
        load_seconds = if ($null -ne $result.load_duration) { $result.load_duration / 1e9 } else { $null }
        prompt_seconds = if ($null -ne $result.prompt_eval_duration) { $result.prompt_eval_duration / 1e9 } else { $null }
        output_tokens = $result.eval_count
        generation_tokens_per_second = $rate
        done_reason = $result.done_reason
    }
}

The generation endpoint reference defines these request and response fields. This code was parsed for PowerShell syntax, not executed against an Ollama server for this article. No sample timing numbers are supplied as if they were measured.

Record enough context to interpret the result

Save the request settings, Ollama version, exact model tag, timestamp and loaded-model snapshots alongside the two rows. Record whether other applications were using the same machine. Use the same prompt and generation configuration, and inspect output counts and stop reasons before comparing rates.

Two requests are a quick diagnostic, not a reproducible benchmark. Prompt caching can change later requests, and different answers can change output length. If the model was already loaded, request one is not a cold-start measurement. Repeat the observation under documented conditions before drawing a conclusion.

Choose a residency policy after diagnosis

For repeated interactive use, a moderate residency window may suit the observed gap between requests. For a shared machine, consider the memory required by other models and applications. The FAQ describes models being unloaded to make room under memory pressure; a timer alone is not a resource-capacity plan.

If the model stays loaded but generation is still slow, return to our GPU, model and connection checks. If API output is difficult to decode, the streaming JSON guide addresses response framing separately.

Sources and verification scope

Reviewed against the linked official Ollama references on 22 October 2026. The PowerShell examples passed syntax parsing only; no model run, latency measurement or hardware performance improvement is claimed. The featured image is an original generated illustration. Read our sourcing and correction policy.