ThinkFacility

Error messages

llama_model_load: error loading model: unknown model architecture: 'qwen4exp'

The message

llama_model_load: error loading model: unknown model architecture: 'qwen4exp'
llama.cpp as of September 20, 2026 read September 20, 2026QwenAPI errors

What it means

Your llama.cpp build predates Qwen3.8-Flash-Next support. The qwen4exp architecture was added in pull request 27742, merged on Aug 27, 2026, so anything built before that has no code for the name the file declares.

What to do

Update to a llama.cpp built after August 27, 2026, or to a wrapper that ships one. Rebuilding a fork that hasn't taken the upstream merge won't help, however recent its own build number looks.

The name in the quotes is the architecture the GGUF file declares, and qwen4exp is what llama.cpp calls Qwen3.8-Flash-Next. Support for it went in through pull request 27742, "model: add Qwen3.8-Flash-Next (qwen4exp)", which was merged on Aug 27, 2026. A binary from before that has no entry under that name.

Architecture
qwen4exp
Model
Qwen3.8-Flash-Next
Added by
llama.cpp pull request 27742, merged Aug 27, 2026
Ollama
0.33.3, the first release whose llama.cpp can load qwen4exp

What the failure looks like

It stops early. The loader prints the file format and the size, then gives up before it reads a single tensor. Here's the report that prompted this page, from someone trying to open unsloth's 76.32 GiB UD-IQ3_XXS split of Qwen3.8-Flash-Next on Windows.

llama_model_load: error loading model: unknown model architecture: 'qwen4exp'

From Feature Request: please ad support to model architecture: 'qwen4exp' · Issue #82 · AtomicBot-ai/atomic-llama-cpp-turboquant · GitHub

Two lines follow it, and they're consequences rather than separate problems: llama_model_load_from_file_impl reports that it failed to load the model, and common_init_ repeats the failure with the path to your first .gguf shard.

Why a recent build can still fail

That report was filed on Sep 16, 2026, three weeks after the merge, from build 10708. The repository it was filed in is a fork of llama.cpp, and a fork keeps its own build numbers and its own merge history. Check where your binary came from before you trust the number on it.

The same applies to anything that bundles llama.cpp. For Ollama the line is 0.33.3, described in the pull request thread as the first release whose llama.cpp can load qwen4exp.

Errors that look like it but aren't

An out-of-memory failure prints "error loading model: unable to allocate ROCm1 buffer" and names the buffer it couldn't get. That one is about size, and dropping layers onto the CPU clears it.

There's also a failure with no error line at all, where llama-server wedges during load on HIP and has to be killed. We wrote that one up separately as the ROCm livelock. If your process is still spinning rather than exiting, that's the page you want.

Support for qwen4exp is still moving: the pull request thread runs through mid-September 2026 with Vulkan and Metal work hanging off it. Pull master rather than the last release tag if you're on a GPU backend.