Ollama Stuck Loading a Model? Causes and Fixes

While Ollama says it is loading, it is reading the model file from disk into RAM or VRAM and setting up memory for the context. When that never finishes, there are five usual reasons: the disk is slow, the model plus its context does not fit in memory, the load is queued behind another model, your client hung up and cancelled it, or the GPU backend has hung. The server log tells you which. A load is only killed for being slow when the model runner prints nothing for OLLAMA_LOAD_TIMEOUT (5 minutes by default). That kill is the error timed out waiting for llama-server to start (older builds say llama runner). On a slow disk, raising that value is a real fix. On a hung backend, it only makes you wait longer.

If your problem is a download that will not move (pulling manifest or a stuck progress bar), that is a different stage with different causes. See Ollama pull stuck or slow. This page starts once the model is on disk.

Everything below was read from ollama/ollama at tag v0.40.13 (released 28 October 2026) and Ollama's FAQ, or quoted from the GitHub issue linked next to it.

What is Ollama doing while it says loading?

It has started a separate model runner, llama-server, and is polling it until it reports ready. The spinner in ollama run, and the "loading" state in Open WebUI and other apps, are all the same wait. You can follow it in the server log. These are the lines a normal load writes, in order:

The line you stopped on is the clue. Stuck before loading model points at the runner or the GPU backend. Stuck in loading model points at the disk or at memory. No starting llama-server at all means the load never started, which is usually the queue.

Step 1: is it loading, queued or stalled?

Watch the log while it loads, and ask the server what it has in memory. Open the log in one window and reproduce the load in another.

# macOS (desktop app)
tail -f ~/.ollama/logs/server.log
# macOS (Homebrew service)
tail -f "$(brew --prefix)/var/log/ollama.log"
# Linux (systemd)
journalctl -u ollama -f
# Docker
docker logs -f <container-name>

# Windows
Get-Content "$env:LOCALAPPDATA\Ollama\server.log" -Wait -Tail 20

In the other window:

ollama ps
ollama run qwen3:8b "hi"

ollama ps lists models that have finished loading, with how much of each sits on the GPU (100% GPU, 100% CPU or a split such as 48%/52% CPU/GPU, per Ollama's FAQ). Use what you see to pick a section:

Cause 1: the disk is slow

On a first load, the whole model file has to come off the disk, so load time is roughly file size divided by read speed. On a fast internal SSD that is seconds. On a spinning disk, a USB drive or a network share, it can be minutes.

For scale, the qwen3:8b model file is 5,225,374,496 bytes (from its manifest on the Ollama registry, 2 November 2026). Here is how long reading it takes at a few read speeds. These are calculated, not measured, and a real load adds GPU upload and setup time on top:

Time your own disk on the actual model file. Find the file with ollama show --modelfile, whose FROM line is the path to the model's blob, then read it end to end:

# macOS / Linux
ollama show --modelfile qwen3:8b | grep '^FROM'
dd if=/path/from/the/FROM/line of=/dev/null bs=8m      # Linux: bs=8M status=progress

# Windows
ollama show --modelfile qwen3:8b | Select-String '^FROM'
$p = 'C:\path\from\the\FROM\line'
Measure-Command { $s=[IO.File]::OpenRead($p); $b=New-Object byte[] 8MB; while($s.Read($b,0,$b.Length)){}; $s.Close() }

On the Apple M3 Pro (18 GB) we use for benchmarks, with Ollama 0.12.3, dd read the 2.49 GB phi4-mini blob from the internal SSD in 0.58 seconds, about 4.3 GB/s. We cannot tell whether some of it came from the file cache, which is why a test like this is most honest right after a reboot. On storage like that, the disk is never the reason a load stalls.

A second load of the same model is usually much faster, because the file is still in the operating system's file cache. If the first load after a reboot is slow and the next one is quick, your disk is the bottleneck. Fixes, best first: move the models to an internal SSD (set OLLAMA_MODELS the way OLLAMA_MODELS not working describes, not with a symlink), keep the model loaded between uses with keep_alive (below), or raise OLLAMA_LOAD_TIMEOUT if loads are being killed partway through.

Cause 2: the model and its context do not fit in memory

When the weights plus the context's memory are bigger than your free VRAM, Ollama puts part of the model in system RAM. When that is also short, the operating system starts swapping, and a load that should take seconds can crawl. ollama ps shows the split once the load finishes. Anything other than 100% GPU on a machine with a GPU means some layers live in system RAM.

The context size is the part people forget. Ollama's default context is chosen from your VRAM (OLLAMA_CONTEXT_LENGTH is documented as "4k/32k/256k based on VRAM"), and every app that sends a bigger num_ctx makes the runner reserve more memory before it can start. Two checks:

# What the runner was started with: look for -c (context) on the "starting llama-server" line
# (macOS app log shown; use your platform's log from Step 1)
grep "starting llama-server" ~/.ollama/logs/server.log | tail -n 1

# Try the same model with a small context
ollama run qwen3:8b
>>> /set parameter num_ctx 4096
>>> hi

If the small context loads quickly and the big one crawls, the fix is the context, not the model. Our Ollama RAM and VRAM table gives per-model memory figures, and Ollama out of memory errors covers the cases that end in a crash rather than a crawl.

Cause 3: it is waiting behind another model

If another model is loaded and there is no room for yours, your request waits. Ollama's FAQ says so directly: "If there is insufficient available memory to load a new model request while one or more models are already loaded, all new requests will be queued until the new model can be loaded. As prior models become idle, one or more will be unloaded to make room for the new model."

The key word is idle. A model that another app is still using (a chat window mid-reply, an embedding job, an agent loop) is not idle, so yours sits in the queue and looks exactly like a slow load. ollama ps shows what is holding the memory:

ollama ps
ollama stop <the-other-model>

If you switch between models all day, lower the time they stay loaded (OLLAMA_KEEP_ALIVE, default 5m), or let fewer stay loaded with OLLAMA_MAX_LOADED_MODELS. Both are set on the server, the same way as OLLAMA_LOAD_TIMEOUT below.

Cause 4: your client gave up, which cancelled the load

If the app that asked for the model disconnects, Ollama stops loading it. The code path is explicit. When the request's context ends, the server logs

client connection closed before llama-server finished loading, aborting load

and returns timed out waiting for llama-server to start: context canceled. The words "timed out" there are misleading: nothing on the server timed out. Your client did.

Issue #10671 is the textbook case (older wording, llama runner). A 6K-token prompt worked from ollama run but failed from the reporter's web app every time. An Ollama collaborator pointed at that warning line and replied: "Client has a ~15 second timeout." The CLI waits as long as it takes, and the app did not.

Fixes:

• Raise the timeout in your client or library. Large models can take longer than a minute to load the first time.
• Preload the model before the app needs it. Ollama's FAQ gives ollama run llama3.2 "" for the CLI, or an empty API request such as:

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

A negative keep_alive keeps the model loaded until you unload it (ollama stop qwen3:8b), so later requests skip the load entirely.

Cause 5: the GPU backend hangs

Sometimes the runner starts, the disk goes quiet, and nothing ever happens. That is a bug in the GPU path rather than a slow load, and it shows up most on AMD, on Vulkan and inside virtual machines. Two 2026 threads show the shape:

• Issue #18123 (open): Ollama in a VM using a virtio-gpu Vulkan device. gemma4:e4b loaded on 0.32.9 and timed out on every build from 0.32.10. The reporter said it was still failing on 0.40.0 in October. Pinning 0.32.9 was the working state.
• Issue #16787 (closed): an RX 7900 XTX on ROCm in the ollama/ollama:rocm container. Some newer models stalled at waiting for llama-server to become available while others loaded fine. The reporter got them working by building the image with a different ROCm version, and even then they took "10-15 minutes" to load.

What to try, in order:

1. Update Ollama, or roll back one release if a model loaded before an update and does not now. The Ollama version history shows what changed when.
2. Switch backend to rule the GPU path in or out. Vulkan is on by default (OLLAMA_VULKAN defaults to enabled in envconfig). Setting OLLAMA_VULKAN=0 on the server takes it out of the picture. A load that works on another backend, or on the CPU, confirms the backend is the problem.
3. Capture a debug log with OLLAMA_DEBUG=1 on the server, and search the issue tracker for your GPU and the last line before the stall.

If the runner crashes rather than hangs, you will see llama-server process has terminated instead, and the exit code explains it. See llama runner process has terminated.

What does OLLAMA_LOAD_TIMEOUT actually measure?

It is a stall timer, not a total load limit. In WaitUntilRunning (llm/llama_server.go), the deadline is "last activity plus OLLAMA_LOAD_TIMEOUT", and it moves forward whenever there is activity. Two things count as activity: llama-server writing any output, and the runner's status switching to loading model. A load can therefore take 20 minutes without being killed, as long as the runner keeps printing. A load that goes silent for 5 minutes is killed with:

timed out waiting for llama-server to start - <last error line the runner printed, if any>

An empty message after the dash, as in issue #16412 (error="timed out waiting for llama-server to start - "), means the runner printed no error at all before it went quiet.

The value comes from envconfig.LoadTimeout(). It accepts a duration such as 15m or a plain number of seconds such as 900, and zero or a negative value means no limit at all. Set it on the server process, not in the shell where you run ollama run:

# Linux (systemd): add under [Service], then reload and restart
sudo systemctl edit ollama
#   Environment="OLLAMA_LOAD_TIMEOUT=15m"
sudo systemctl daemon-reload && sudo systemctl restart ollama

# macOS (desktop app): then quit and reopen Ollama
launchctl setenv OLLAMA_LOAD_TIMEOUT 15m

# Docker
docker run -d -e OLLAMA_LOAD_TIMEOUT=15m ... ollama/ollama

On Windows, add OLLAMA_LOAD_TIMEOUT as a user environment variable (Settings, search "environment variables"), then quit Ollama from the tray and start it again. The general rule, that the daemon reads its own environment rather than your shell's, is explained in Ollama systemd env vars that do not apply.

Raise it for slow disks. Do not use it to paper over Cause 5. With no limit, a hung backend never errors, and you just wait forever instead of after 5 minutes.

Why is a model stuck at Stopping...?

Stopping... means the server has decided to unload the model and is waiting for the runner to let go. In ollama ps (cmd/cmd.go), UNTIL shows Stopping... whenever the model's expiry time is in the past. In the scheduler (server/sched.go), an expired model that still has a request in progress is not unloaded. The scheduler checks again every 10 milliseconds until that request finishes. So a model that stays at Stopping... has a request that never finishes.

An Ollama collaborator put it this way in issue #14364: the state "indicates that the server wanted to unload the model. This usually happens for a model change or when model parameters (eg, num_ctx) are changed by the client. Since the state persists, the unload didn't complete, indicating the model runner got wedged." The suggested fix there was to kill only the runner, not the whole server.

# macOS / Linux: find the runner (llama-server on current builds; "ollama runner" on older ones)
ps aux | grep -E "llama-server|ollama runner" | grep -v grep
kill <pid>

# Windows
tasklist | findstr /i "llama-server"
taskkill /PID <pid> /F

The next request starts a fresh runner and loads the model again. Issue #17428 (an embedding model on Apple Silicon, open) reports exactly that: killing just the stuck runner cleared Stopping..., and the same request then answered in about 1.2 seconds. If it keeps happening, look at what keeps that request alive. A client streaming a very long answer, or several apps sending different num_ctx values to the same model, forces reloads over and over.

Older builds: "timed out waiting for llama runner to start - progress 0.00"

Before the runner was renamed llama-server, the same timeout reported how far the load had got. In v0.16.2, llm/server.go built the message as:

return fmt.Errorf("timed out waiting for llama runner to start - progress %0.2f - %s", s.loadProgress, msg)

and the stall timer reset whenever that progress number moved. So the number tells you where it stalled:

• progress 0.00: nothing was loaded before it stalled. The runner never got going, which points at the GPU backend (Cause 5) or a memory setup that never completed (Cause 2), not at a slow disk. Issue #8690 is a DeepSeek 671B model stalling at 0.00 on eight L40S cards.
• progress 1.00: every weight was loaded and it stalled afterwards, while setting up memory or the GPU. That rules out the disk. See issue #6092.
• Anything in between: it stalled partway through reading the file, which points at the disk or at memory pressure.

Current builds dropped the number. The last error line the runner printed is what follows the dash now.

Honest limitations

• We did not reproduce a stalled load. The machine we test on is used for benchmarks, and none of the failures above happen on it. The one measurement on this page is the disk read in Cause 1. Everything else comes from the source at v0.40.13 or from the linked threads.
• The read-time table is arithmetic. Real loads add GPU upload, memory setup and, for big contexts, a lot of allocation time.
• Backend hangs change with every release. The two threads in Cause 5 describe specific hardware and versions. If yours differs, treat them as a pattern, not a diagnosis.
• Apps add their own timeouts. Open WebUI, editor plugins and agent frameworks each have their own limits, and they change between versions. #10671 shows the pattern. The number in your app may be different.

FAQ

How long should an Ollama model take to load?

It depends almost entirely on the file size and where the file lives. Your own log tells you: every successful load writes llama-server started in N seconds. Compare a first load after a reboot with a second load. A big gap between them means the disk is what you are waiting for.

What is the default OLLAMA_LOAD_TIMEOUT?

Five minutes, from envconfig.LoadTimeout() in v0.40.13. It measures silence, not total time: the clock restarts whenever the model runner prints anything. You can set it as a duration (15m) or as seconds (900), and zero or a negative number disables it.

Why does ollama run work but my app times out loading the same model?

Because the app has its own, shorter, timeout and cancels the request. When the client disconnects, Ollama aborts the load and logs client connection closed before llama-server finished loading, aborting load. Preload the model first or raise the app's timeout. See Cause 4.

How do I stop a model that is stuck at Stopping...?

Kill the model runner process only (llama-server on current builds), not the Ollama server. The next request starts a new runner. If it keeps coming back, something is holding a request open or keeps changing num_ctx.

Does Ollama load models faster from an SSD?

On a first load, yes, because the whole file has to be read once. The read-time table above shows the scale. After that, a second load often comes from the operating system's file cache and is fast wherever the file lives, as long as you have enough free RAM to keep it cached.

Is "stuck on pulling manifest" the same problem?

No. That is the download stage, before anything is loaded, and it has its own causes: registry, DNS, proxies and partial downloads. They are covered in Ollama pull stuck or slow.

Other Ollama errors: every error string, indexed · llama runner process has terminated · out of memory (CUDA and RAM) · timed out waiting for server to start

Sources

• ollama/ollama v0.40.13: llm/llama_server.go (WaitUntilRunning, the stall deadline, what counts as activity, the timeout and cancellation messages, load modes)
• envconfig/config.go (LoadTimeout, OLLAMA_VULKAN, OLLAMA_CONTEXT_LENGTH)
• server/sched.go (expiry with requests still running) and cmd/cmd.go (Stopping... in ollama ps)
• v0.16.2 llm/server.go (the older llama runner ... progress message)
• Ollama FAQ (ollama ps processor column, preloading, keep_alive, queued loads)
• Issues: #10671 (client timeout cancels the load), #18123 (Vulkan VM regression), #16787 (ROCm load hang), #16412 (timeout with an empty message), #14364 and #17428 (Stopping...), #8690 and #6092 (progress 0.00 and 1.00)