Ollama Unknown Model Architecture: The Version Table

The string in quotes is not a typo and not a corrupt download — it is the general.architecture field written into your GGUF, and the code trying to read it does not have an entry for that name. What fixes it depends entirely on where the file came from. If you ran ollama pull against Ollama's own library, upgrade: every architecture in the table below was added in a specific release and this page names it. If you imported a GGUF from Hugging Face or built one yourself, upgrading may not help, because Ollama pins its llama.cpp source to a single build (b10488 on main when this was written) — an architecture that landed upstream after that pin is invisible to your Ollama until the next vendor sync, no matter how new your version number looks.

That split is the whole page. It explains the reports that read like nonsense otherwise: the same architecture string loading from one GGUF and failing from another, a model that worked before an upgrade and not after, and a brand-new Ollama that still cannot open a file llama.cpp quantised last week.

Everything below is read from Ollama's release notes, Ollama's own repository on main, llama.cpp's architecture registry, and linked GitHub issues. Where a version number appears it is because a release note names that architecture. Where one does not appear, the row is missing on purpose.

What is the quoted string in the error

It is a metadata key inside the model file. GGUF stores an architecture name, the loader looks that name up in a fixed table, and if there is no match it stops. You can see both halves in one log, from issue #14499 (Ollama 0.17.4, Windows, RTX 5070 Ti):

llama_model_loader: - kv   0:                       general.architecture str              = qwen35moe
...
print_info: file format = GGUF V3 (latest)
print_info: file type   = Q4_K - Medium
print_info: file size   = 19.71 GiB (4.88 BPW)
llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'qwen35moe'
llama_model_load_from_file_impl: failed to load model

Two things worth noticing before you change anything.

The file is fine. GGUF V3 (latest), a readable quant type and a readable file size all print before the failure. The loader parsed the header successfully and then refused the contents. So re-downloading, re-pulling and clearing ~/.ollama will not do anything — a point worth internalising before you spend an evening on it.

The lookup table is llama.cpp's. The names live in src/llama-arch.cpp as LLM_ARCH_NAMES, mapping an enum to a literal string — LLM_ARCH_GEMMA4 to "gemma4", LLM_ARCH_QWEN35MOE to "qwen35moe", LLM_ARCH_OPENAI_MOE to "gpt-oss". If your string is not in that file it will never load through the llama.cpp path, whatever you do to Ollama.

Through the CLI or the API you will usually see it wrapped, like this report on Ollama 0.30.5 from issue #16547:

Error: 500 Internal Server Error: llama-server process has terminated: exit status 1: error loading model: unknown model architecture: 'mllama'

The 500 and the terminated-runner phrasing are transport and wrapper. Our guide to what Ollama's llama runner exit codes mean unpacks that outer layer; ignore it here and read the string in quotes.

Which architecture is yours

Column three is the Ollama release whose own notes name that architecture or ship that model family — nothing is inferred. Dates are the GitHub release dates. If an architecture you are hunting for is absent from this table, that is deliberate: no release note names it, and guessing a version would make this table worse.

Read the fourth column, not just the third. Four rows in that table have two versions in them, and that is not sloppiness — it is the actual behaviour. Qwen 3.5 and Laguna were runnable from Ollama's library months before an imported GGUF of the same family would load, because those are two different code paths.

Architectures people hit this error with that no release note names

These strings all exist in llama.cpp's registry, so the file is loadable in principle, but searching every Ollama release note back to v0.0.11 turns up nothing that names them. For these, the fix is a newer Ollama whose pinned llama.cpp build is recent enough — not a specific announced version, because there was never an announcement.

Why does the official model work when the Hugging Face GGUF does not

Because they are loaded by different engines, and only one of them is pinned to llama.cpp.

Ollama has its own inference engine written in Go, and it also vendors llama.cpp. Release notes give this away constantly with the phrase "now run on Ollama's engine" — v0.12.0 for Bert and Qwen 3, v0.13.0 for DeepSeek-V3.1, v0.17.1 for Nemotron. Those are architectures being implemented natively in Ollama, which is what makes ollama pull qwen3.5 work. An arbitrary GGUF you pulled from hf.co/... takes the llama.cpp route instead, and llama.cpp has to know the name.

The clearest statement of this is from an Ollama maintainer on #14499, answering someone whose Qwen3.5 MoE GGUF would not load on 0.17.4 — a version that had shipped Qwen 3.5 to the library the day before:

qwen3.5 models from HF are not currently supported in ollama, needs either a vendor sync (#14134) or tweaking of the go runner.

"Vendor sync" is the mechanism. Ollama's llama/README.md opens with it:

LLAMA_CPP_VERSION pins Ollama's llama.cpp source. An update can change more than compilation: it can affect model loading, GPU discovery, scheduler inputs, runtime logs, streaming, and compatibility patches.

That file is a single line. On main at the time of writing it reads b10488. So the question "does my Ollama support this architecture" really means "was this architecture in llama.cpp at build b10488", and your Ollama version number does not answer that on its own.

How fast does the pin move? Eight commits touched LLAMA_CPP_VERSION between 6 July and 18 August 2026 — 43 days across seven intervals, so roughly one bump every six days. That is quick, but it is not instant, and it is why a model released on a Tuesday can be unloadable on the newest Ollama on Wednesday.

What this means in practice. When a new model lands and your GGUF will not open:

1. Try the official pull first. ollama pull <model> against the library uses whichever engine Ollama implemented, and that is frequently ready before the vendor bump. It is also the cheapest test you can run.
2. If there is no library entry, wait for a release rather than hunting for a flag. There is no setting that adds an architecture. The Ollama version history tracks what each release actually shipped so you can tell when yours arrived.
3. Do not assume a bigger version number contains it. The pin is what matters, not the release number.

Can upgrading Ollama remove an architecture you already had

Yes, and this is the case nobody expects. It has a well-documented instance.

Ollama v0.4.0 (October 2024) added mllama for Llama 3.2 Vision. Ollama v0.30.0 (13 May 2026) was the release that rebuilt model loading on llama.cpp for wider hardware support — and its own release notes carry this, verbatim, under Known issues:

llama3.2-vision is not yet supported

Which is exactly what #16547 is: unknown model architecture: 'mllama' on 0.30.5, from someone running ollama run llama3.2-vision after a successful pull. The comments on it are all the same shape — "I have the same error now after I updated ollama. Before the update, this model worked for me." The most recent of those is dated 11 August 2026. The issue itself was closed as a duplicate on the day it was filed, not fixed.

There is a structural reason it has not come back quickly: mllama does not appear in llama.cpp's LLM_ARCH_NAMES at all. Checked against src/llama-arch.cpp on master, there is no entry for it. So once model loading moved onto llama.cpp, the vision variant had nowhere to go — this cannot be resolved by a vendor bump, only by Ollama's own engine carrying it again.

The practical rule: if a model stopped working after an upgrade, do not troubleshoot your machine. Check that version's release notes for a Known issues block, and if you need the model today, install the older release. Rolling back is covered in the version history guide.

Why does the same architecture load from one file and not another

Because architecture support and this specific file's metadata are separate problems, and this error cannot distinguish them.

Issue #15508 is the clean example. On Ollama 0.20.5 — a release well after Gemma 4 shipped in v0.20.0 — the reporter can load a Gemma 4 GGUF from Hugging Face and cannot load one they built themselves with ollama create, and ollama show reports architecture gemma4 for both. A commenter with their own Gemma 4 builds put the conclusion plainly:

If ollama pull batiai/gemma4-31b:iq4 loads for you but the mradermacher variant still errors with unknown model architecture: 'gemma4', it's almost certainly a metadata/arch-field mismatch in that specific GGUF, not your Ollama install.

So before you conclude anything about versions, run the two-file test:

# Does ANY file with this architecture load on this machine?
# Pick a different uploader's GGUF of the same model, then:
ollama pull hf.co/OTHER_UPLOADER/SAME_MODEL-GGUF:Q4_K_M

If a different GGUF of the same family loads and yours does not, the version table above is irrelevant to you. Your file is the problem, and the fix is a different quant from a different uploader — not an upgrade, not a reinstall.

The degenerate version of this is an empty architecture string. Issue #3638 records unknown model architecture: '' — nothing between the quotes. That is not an unsupported model; that is a file whose general.architecture key is missing or unreadable, which means a truncated download, a bad conversion, or a sharded model that was never merged. On sharded repos in particular, an Ollama maintainer noted on #14575 that "Split models are supported, but only via the create flow" — the Hugging Face registry path "synthesizes the Ollama model on the fly so it's unable to glue the GGUFs together into a single GGUF". Download the parts, merge them, then ollama create. Ollama's official import docs cover the Modelfile side of that (FROM /path/to/file.gguf), and our Modelfile guide covers the rest. Do not read the short architecture list on that docs page as the real support matrix, though — it names only Llama, Mistral, Gemma and Phi3, which is far narrower than what Ollama actually loads.

How do you check the architecture before downloading 132 GB

Because this error fires at load time, not at pull time, you can spend hours downloading a model you were never going to run. Issue #10920 is someone who waited "nearly 4 hours" for a 132 GB pull to complete before finding out.

Two checks, both cheap:

Read it off a model you already have. ollama show prints the architecture as its first field — this is from #15508, verbatim:

  Model
    architecture        gemma4
    parameters          30.7B
    context length      262144
    embedding length    5376
    quantization        unknown

Read it off the repo before you pull. Hugging Face model cards for GGUF repos list the architecture, and the uploader's notes usually say which llama.cpp build was used to quantise. If that build is newer than your Ollama's pin, expect this error.

One habit worth forming: when a model is only days old, prefer the official Ollama library entry over a third-party GGUF even if the third-party quant is more convenient. The library entry exists precisely because someone made it work. The wider set of pull-stage failures — as opposed to load-stage ones — is covered in our guide to Ollama pulls that stall or run slow.

What to do when your architecture is not in either table

Work down this list. It is ordered by how likely it is to end the problem, not by effort.

1. Upgrade, then re-test. One command, and it fixes the majority of these because the pin moves roughly weekly. ollama --version first so you know what you moved from.
2. Search llama.cpp for your exact string. Open src/llama-arch.cpp and search for the quoted name. Present means wait for a vendor bump. Absent means no amount of upgrading will help and you need a different runtime.
3. Search the Ollama tracker for the string in quotes, including the quotes. Every architecture in this article has an issue behind it, and the thread will usually tell you which release closed it.
4. Try a different GGUF of the same model. Ten minutes, and it separates "this architecture" from "this file" definitively.
5. Check the release notes of the version you upgraded from and to. If it worked before, this is where the answer is.

If you are still stuck after those, the failure is probably not really an architecture failure — the broader Ollama troubleshooting guide covers the load failures that only look like this one, and the complete Ollama guide covers the import paths from the beginning.

What this page cannot tell you

• We have not run every model in these tables. Version numbers come from Ollama's published release notes, architecture strings from llama.cpp's source, and everything else from the linked issues. Nothing here is a claim about our own hardware.
• The pin moves after publication. LLAMA_CPP_VERSION read b10488 on main when this was written. Open the file rather than trusting that string later.
• Missing rows are honest, not lazy. Several architectures that people definitely hit this error with are absent from the main table because no Ollama release note names them. They are listed separately with their issue numbers instead.
• "Named in" is not the same as "first supported". A release note is evidence that support existed by that date, not proof it did not exist earlier and go unmentioned. Treat the column as a safe upper bound.
• Closed does not mean fixed on your machine. #16547 was closed as a duplicate and people were still reporting it two months later. Read the thread, not the label.

FAQ

What does "unknown model architecture" mean in Ollama

The model file declares an architecture in its general.architecture GGUF metadata key, and the loader has no entry for that name in its lookup table. It is a support gap, not a corrupt file — the same log usually prints the GGUF version, quant type and file size correctly on the lines just above the error.

Will upgrading Ollama fix it

For a model from Ollama's own library, usually yes, and the table above names the release. For a GGUF you imported, not necessarily: Ollama pins one llama.cpp build in a file called LLAMA_CPP_VERSION, and an architecture added upstream after that pin is not in your build regardless of your version number. That pin moved eight times in the 43 days to 18 August 2026, so waiting a week is often the whole fix.

Why does ollama pull work but my Hugging Face GGUF fail for the same model

They take different code paths. Models Ollama has implemented run on Ollama's own engine — release notes phrase this as "now run on Ollama's engine" — while an arbitrary imported GGUF is loaded by the vendored llama.cpp. An Ollama maintainer summarised it on issue #14499: HF Qwen3.5 models needed "either a vendor sync or tweaking of the go runner", even though the library already had Qwen 3.5.

My model worked before I upgraded. Why is it unknown now

Because an upgrade can drop an architecture. Ollama v0.30.0 rebuilt loading on llama.cpp and listed llama3.2-vision under Known issues as "not yet supported"; issue #16547 is that showing up as unknown model architecture: 'mllama', with people still reporting it in August 2026. mllama is not in llama.cpp's architecture registry at all, so a vendor bump cannot bring it back. Roll back if you need that model today.

The quoted architecture is empty, with nothing between the quotes

That is a file problem, not a support problem. Issue #3638 records exactly that — two quote marks and no name. An empty string means the general.architecture key is missing or unreadable: a truncated download, a failed conversion, or a multi-part model that was never merged into one GGUF. Sharded repos need to be downloaded and merged first, then imported with ollama create; the Hugging Face pull path cannot glue the parts together.

Is there a flag or environment variable that forces the model to load

No. Architecture support is compiled in, on both engines. If the name is not in the table the loader consults, nothing you set at runtime will change that, and re-pulling or clearing your models directory will not either.

Sources

• llama.cpp — src/llama-arch.cpp (LLM_ARCH_NAMES, the authoritative architecture-string registry)
• ollama/ollama — llama/README.md and LLAMA_CPP_VERSION (how the llama.cpp source is pinned, and to what)
• ollama/ollama — releases (every version and date in the tables; quoted lines are verbatim from the release notes)
• Ollama — importing a model (the FROM /path/to/file.gguf Modelfile path and ollama create)
• ollama/ollama issues #3638, #4248, #6721, #10920, #11347, #12984, #14499, #14575, #15499, #15508, #16547