Ollama "Timed Out Waiting for Llama Runner to Start"? Read the Progress Number, Then Fix It (2026)

By RunAIHome Team · 14 min read
ollamatroubleshootinglocal-llmgpuai

TL;DR: Ollama kills any model load that stalls for 5 minutes and prints timed out waiting for llama runner to start - progress X.XX. The progress number is the diagnosis: a value that was still climbing means a slow disk and OLLAMA_LOAD_TIMEOUT fixes it; 0.00 means the runner never started loading (driver, GPU library, or version bug); 1.00 means the model loaded but the runner never answered its health check. Match the fix to the number instead of blindly reinstalling.

What you’ll be able to do:

  • Decode the progress value in the error and jump straight to the fix class that matches it
  • Raise or disable the 5-minute load timeout in the place Ollama actually reads it — and verify it took effect
  • Tell a genuinely slow load (fixable with faster storage) from a hung runner (fixable with a driver or version change)

Honest take: nine times out of ten this error is either a big model on a slow disk or a bad Ollama/driver pairing. Raising OLLAMA_LOAD_TIMEOUT is the right first move only when the progress number was moving; if it sat at 0.00, more waiting just delays the same failure by however long you added.

You run ollama run on a model you’ve pulled fine, the terminal sits there, and after exactly five minutes you get:

Error: timed out waiting for llama runner to start - progress 0.00 -

Newer builds phrase it as 500 Internal Server Error: timed out waiting for llama-server to start, and API clients surface it as ollama._types.ResponseError, but it’s the same event: the Ollama server spawned its inference subprocess (the “llama runner”), watched it, and gave up. This error has been filed against Ollama continuously from issue #1678 in December 2023 through issue #16132 in May 2026, across NVIDIA, AMD ROCm, and CPU-only machines — because it isn’t one bug. It’s a timeout that half a dozen different failures can trip.

The good news: the error line itself tells you which failure you have. That trailing progress number is the fraction of the model that made it into memory before Ollama quit waiting.

What the timeout actually is

Ollama’s source code defines OLLAMA_LOAD_TIMEOUT as “the duration for stall detection during model loads,” with a default of 5 minutes. The scheduler watches the runner’s load progress; when it decides the load has stalled past that window, it kills the subprocess and returns this error with the last progress fraction it saw.

Three properties of that setting matter, all verifiable in envconfig/config.go:

  • The default is 5m0s. That’s why so many reports of this error mention “exactly five minutes.”
  • It accepts a Go duration string (10m, 1h) or a bare integer, which is treated as seconds. OLLAMA_LOAD_TIMEOUT=600 and OLLAMA_LOAD_TIMEOUT=10m are the same thing.
  • Zero or negative values mean infinite — Ollama will wait forever.

Five minutes is generous for a 4GB model on an NVMe drive and hopeless for a 385GB model on anything. Which is exactly the split you see in the wild: in issue #16132, qwen3:4b loaded in under 5 seconds on the same machine where a 35B model hit the timeout; in issue #4131, 8B models worked while CodeLlama 34B (17.74 GiB Q4_0) timed out on a dual Tesla P40 box.

Triage by the progress number

Progress valueWhat happenedMost likely causeYour fix section
Climbing, then died (0.30, 0.64…)Load was real but too slowBig model + slow disk, or heavy CPU offloadFix 1 + Fix 2
0.00 flatRunner started, never loaded a byteDriver/GPU library hang, multi-GPU stall, version bugFix 3 + Fix 4
1.00Model fully loaded, runner never went healthyRunner process hung after loadFix 4 + Fix 5

To see which case you’re in before the error even fires, watch the server log during a load attempt:

# Linux (systemd)
journalctl -u ollama --no-pager --follow

# macOS
cat ~/.ollama/logs/server.log

# Windows: server.log inside
explorer %LOCALAPPDATA%\Ollama

# Docker
docker logs <container-name>

Those log locations are from Ollama’s official troubleshooting guide. You’re looking for repeated model load progress lines: steadily increasing means Fix 1 territory; frozen means Fix 3.

Fix 1: Raise the timeout (when progress was moving)

If the progress number was climbing when the timer killed it, the load is legitimate — just slower than 5 minutes. This is normal, not broken, for 30B+ models on hard drives, SATA SSDs doing other work, network mounts, and any setup where a big model spills to CPU RAM.

The arithmetic is unforgiving. A 70B Q4_K_M GGUF is roughly 40–43GB of weights. A spinning hard drive sustaining ~150 MB/s needs about 4.7 minutes of uninterrupted full-speed reads to move 42GB — right at the edge of the default window, and one hiccup pushes it over. The same file loads in well under a minute from a Gen4 NVMe drive; we measured the difference directly in our cold-start guide, where a 70B load took 74 seconds from SATA and 18 seconds from NVMe. (Those two disk-throughput figures are manufacturer-class numbers; the load times are measured.)

Set the timeout to something with slack — say 30 minutes:

OLLAMA_LOAD_TIMEOUT=30m

Or OLLAMA_LOAD_TIMEOUT=-1 to disable stall detection entirely while you test.

Where you set it is the part everyone gets wrong. Ollama usually runs as a service, and services don’t read your shell’s exports. Per platform:

# Linux (systemd):
sudo systemctl edit ollama.service
# add:
#   [Service]
#   Environment="OLLAMA_LOAD_TIMEOUT=30m"
sudo systemctl daemon-reload && sudo systemctl restart ollama

# macOS (app):
launchctl setenv OLLAMA_LOAD_TIMEOUT 30m
# then quit and reopen Ollama; note launchctl setenv is lost on reboot

# Windows: quit Ollama from the tray, then
# Settings → Environment Variables → add OLLAMA_LOAD_TIMEOUT for your user,
# and relaunch Ollama

# Docker:
docker run -e OLLAMA_LOAD_TIMEOUT=30m ...

Then verify it took effect: on startup, the server logs its resolved configuration map. If OLLAMA_LOAD_TIMEOUT:30m0s isn’t in that startup line, your value isn’t being read. That verification step exists for a reason — in issue #6678, a Docker user on v0.3.9 passed -e OLLAMA_LOAD_TIMEOUT=60 and watched loads still die at exactly 5 minutes; the variable was absent from the logged config map. Same failure pattern we documented for OLLAMA_HOST in the Open WebUI connection guide: the setting was fine, the place was wrong (or, on that old build, the plumbing was buggy — one more reason to update first).

Fix 2: Make the load actually fast

A bigger timeout makes the error go away; it doesn’t make a 5-minute load pleasant, and you’ll pay it again every time the model is evicted. Two structural fixes:

Move the models to NVMe. Ollama’s blob store defaults to ~/.ollama/models. Relocating it to a fast drive (via OLLAMA_MODELS, set in the same service-level way as above) is the single biggest cold-start win — that’s the 74s → 18s delta measured above, and our SSD guide for local AI covers the drive choice. A Samsung 990 Pro 2TB class Gen4 drive turns even 30B-class loads into a seconds-level event.

Stop cold-loading so often. If the load only hurts because it happens every few minutes, the actual problem is eviction: OLLAMA_KEEP_ALIVE defaults to 5 minutes, after which the model unloads and the next request pays the full load again. Pin it with OLLAMA_KEEP_ALIVE=-1 — full walkthrough in the model-keeps-reloading fix.

And be honest about whether the model belongs on your hardware at all. If you’re loading a 70B on a 24GB card, most of it lives in system RAM and everything is slow, not just the load — see running a 70B on a single 24GB GPU for when that trade is worth it. If the load dies with a memory message instead of this timeout, that’s a different error with its own fix.

Fix 3: Progress 0.00 — the runner never started loading

A flat 0.00 with plenty of free VRAM is not a speed problem, and no timeout value will save you: the runner initialized, touched the GPU, and hung before reading the first tensor.

The reports cluster into three patterns:

GPU allocation stalls. In issue #9209 (Ollama 0.5.11, an NVIDIA A40-48Q with 43.9 GiB free, DeepSeek R1 70B at 39.59 GiB), GPU memory climbed to ~348MB and froze until the timeout, followed by repeated gpu VRAM usage didn't recover within timeout warnings. In issue #8690, a 385 GiB DeepSeek 671B on 8× L40S stalled at ~424 MiB per GPU — all eight CUDA devices initialized, tensor split computed, zero progress. Notably, several of these reports (the A40-48Q, the A40-8Q in #6092) are virtualized vGPU profiles, where driver behavior differs from a consumer card in a desktop.

What to do, in order:

  1. Read the log at the moment of the hang (commands above). A CUDA or ROCm error line right before the silence is your real diagnosis.
  2. Update the GPU driver, then update Ollama (current stable is v0.32.14, released August 15, 2026, per the release history). Driver/runtime pairings cause exactly this hang; Ollama’s own troubleshooting guide notes AMD driver mismatches “hang during device discovery and eventually time out.”
  3. Isolate the GPU path: OLLAMA_LLM_LIBRARY="cpu_avx2" ollama serve forces a CPU-only load (from the official docs). If the model loads fine on CPU, you’ve proven it’s the GPU stack, not the model file.
  4. On multi-GPU rigs, try pinning to one card (CUDA_VISIBLE_DEVICES=0) to rule out a stall in the tensor-split path.

A corrupted or incompatible model file can also wedge the loader — if the log shows architecture or GGUF parsing complaints instead of a silent stall, you’re in unknown-architecture territory, and a re-pull or an Ollama update is the fix.

If the runner crashes rather than hangs, you’ll see llama runner process has terminated instead of this timeout — that error carries an exit code and has its own decoder.

Fix 4: Suspect the Ollama version itself

This error has repeatedly appeared as a regression in specific builds. The cleanest 2026 example is issue #16132: a Radeon 780M iGPU box (ROCm, Docker, 64GB DDR5) that loaded qwen3:4b in under 5 seconds started throwing timed out waiting for llama-server to start on qwen3.6:35b after upgrading from 0.21.1-rocm to 0.30.0-rc15-rocm — and reverting to 0.23.3-rocm resolved it with no other change. The same pattern showed up back in the 0.1.39 pre-release, where all models timed out on one build and worked on the next release candidate.

So when the error appears right after an update, or only on a release-candidate/rocm tag:

# check what you're on
ollama --version

# Docker: pin a known-good tag
docker pull ollama/ollama:0.32.14

Update to current stable first; if current stable is where it broke, pin the previous version and say so on the issue tracker — the maintainers triage these fast when a report includes the server log.

Fix 5: Progress 1.00 — loaded, then silence

The strangest variant: the log shows every layer offloaded, the KV cache allocated, model load completed, waiting for server to become available — then the timeout fires with progress 1.00. Issue #6092 documents it on Ollama 0.3.0 with a 4.12 GiB Qwen2-7B on an 8GB vGPU: the model was fully resident, but the runner’s HTTP health endpoint never answered.

Because the load itself succeeded, disk and timeout tuning are irrelevant here. This is a hung subprocess:

  • Update Ollama — several health-check hangs were version-specific and quietly fixed in later releases.
  • Check whether the system is starved: a machine deep into swap after loading the model can leave the runner too slow to answer. Free RAM matters even for GPU loads; our system RAM guide covers sizing.
  • On virtualized GPUs (the A40-8Q above is one), test the same model on bare metal or CPU-only. vGPU framebuffer profiles are a recurring thread in these reports.

The prevention checklist

Once you’re unstuck, three settings keep you unstuck — all set at the service level, all visible in the startup config log:

SettingValueWhy
OLLAMA_LOAD_TIMEOUT30m (or -1 on huge-model boxes)Default 5m is too tight for 30B+ on non-NVMe storage
OLLAMA_MODELSpath on an NVMe drive74s → 18s measured on a 70B cold load
OLLAMA_KEEP_ALIVE-1 or 30mStop paying the cold load every 5 minutes

And right-size the model: a used RTX 3090’s 24GB running a model that fits will load in seconds and generate at full speed, which beats any timeout tuning you can do for a model that doesn’t. If you need to test a genuinely huge model once before committing to hardware, an hour on a rented big-VRAM card via RunPod is cheaper than a week of fighting this error.

FAQ

Is timed out waiting for llama runner to start the same as llama runner process has terminated? No. The timeout means the runner was alive but never became ready; “terminated” means it crashed and left an exit code. The fixes are different — the crash decoder is here.

Why exactly five minutes? That’s the compiled-in default of OLLAMA_LOAD_TIMEOUT in Ollama’s envconfig/config.go. Any duration string or bare seconds value overrides it; zero or negative disables it.

I set OLLAMA_LOAD_TIMEOUT and nothing changed. Why? Almost always: you set it in a shell, but Ollama runs as a systemd service, launchd app, or container that never saw it. Set it at the service level and confirm it appears in the startup log’s configuration line. One old build (v0.3.9, Docker) also dropped the variable entirely — update before debugging further.

Does a longer timeout slow anything down? No. It’s a stall-detection ceiling, not a delay. Loads that finish in 20 seconds still finish in 20 seconds with a 30-minute timeout.

The progress number is climbing but slowly — should I just wait? Raise the timeout so the load can finish once, then fix the underlying speed: models on NVMe, OLLAMA_KEEP_ALIVE pinned so you rarely cold-load, and a model size that matches your VRAM. Our tokens-per-second tuning guide picks up from there.

Could this be a GPU memory problem? If VRAM is the blocker you normally get an explicit memory error instead — see the CUDA OOM fix and the system-memory error fix. The timeout with free VRAM and progress 0.00 points at the driver stack, not capacity.

Sources

Last updated August 22, 2026. Ollama versions, defaults, and behavior change quickly; check the linked issues and source for the current state before making service-level changes.

Was this article helpful?