Ollama Model Loads Time Out After the 0.32.10 Upgrade: The Load Mode Change and the Fix

If your Ollama install started timing out right after an upgrade, you're probably staring at this after five patient minutes:

Load failed ... timed out waiting for llama-server to start

Nothing in that error says why. The model never finished loading. It's a regression that showed up in 0.32.10 and is still around as of 0.33.x. Here's what's going on under the hood, and what you can actually do about it.

The setup that breaks

The reports cluster around one kind of setup:

• Linux, Ollama running in a container (Podman or Docker)
• An integrated GPU on the Vulkan backend (Radeon 780M / RADV, or a VM with virtio-gpu)
• A model big enough to notice

One reporter on a Ryzen 7 8845HS with 15.5 GB of RAM had 0.32.9 load the same model in about 10 seconds. After moving to 0.32.10, that model never became ready. Every request died at the default OLLAMA_LOAD_TIMEOUT of 5 minutes.

What changed in 0.32.10

The server logs tell the story. On 0.32.9 you see load_mode = mmap. On 0.32.10 and later you see load_mode = none.

With mmap, the runtime maps the model file into memory and pages it in lazily. With none, Ollama stages the entire model into CPU memory buffers first, then hands it to the GPU. That's a lot more up-front work. On a box that's already tight on RAM, it turns into disk thrash, and the load never finishes inside the timeout window.

There's a scheduler line that makes the math obvious:

predicted="22.1 GiB" predicted_num_ctx=131072 ... system_free="14.8 GiB" system_limited=true

The default context window is 131072 tokens. The scheduler wants 22 GB for the model plus KV cache. The machine has 14.8 GB free. Something has to give, and what gives is your load time. Even a tiny 641 MB model took about 99 seconds to stage on the broken path, versus under 2 seconds on 0.32.9. That's a 56x slowdown before a single token comes out.

The trigger appears to be the llama.cpp bump that landed in 0.32.10. The load mode default became "auto", and auto disables mmap for any backend that reports no mmap support. The Vulkan backend reports no mmap support for integrated GPUs, so every iGPU/Vulkan user gets stuck on the slow staging path. A community PR (still unmerged) lays this out in detail.

You'll also see this line and should ignore it:

Failed to create /home/ollama/.cache/mesa_shader_cache (Permission denied)

Looks bad. It's not the cause. A missing shader cache means slower first runs, not a five-minute hang.

What fixes it

Ranked from confirmed to stopgap:

1. Pin Ollama to 0.32.9. This is the only fix the people hitting the bug have confirmed works. In a container, stop pulling :latest and pin the image tag (e.g. ollama/ollama:0.32.9). It's an ugly answer, but it's the honest one until upstream sorts this out.

2. Cap the context window. Part of the scheduler's 22 GB prediction is that 131072-token default. Shrink it:
   

   OLLAMA_CONTEXT_LENGTH=8192

or pass num_ctx per request. It's a documented knob, and it pulls the memory prediction down toward what your machine actually has.

1. Give the load more time. OLLAMA_LOAD_TIMEOUT exists and the server reads it from the environment (default 5m0s). Bumping it to 15m turns a hard failure into a slow success while you wait for a real fix. I couldn't find this one in the public docs, but it shows up in the server env logs, and setting it is harmless.

2. Watch PR #18124. It proposes direct I/O for integrated Vulkan GPUs, the same class of fix that already landed for CUDA and ROCm. Not merged, no maintainer sign-off. Don't hold your breath, but that's the thing to watch.

When this isn't your bug

Check the server logs first. If your load line still says load_mode = mmap, this regression isn't what's biting you, and downgrading won't help. This one is specific to Linux plus integrated GPU plus Vulkan, including VMs. Discrete GPU setups mostly sailed past it.

If you're stuck on it today: pin 0.32.9, cap the context, raise the timeout, and keep an eye on that PR. It's a rough regression to ride, but at least the error message makes sense now.

The issue thread is ollama/ollama#18123 if you want to follow along or add your setup to the list.