LM Studio’s banner tells you a load failed and nothing about why. The useful text is the llama.cpp line it wraps, and there are three quite different ones hiding behind the same red box.
Where the real error is
LM Studio is a desktop front end over llama.cpp (and, on Apple silicon, MLX). When a load fails, the app shows its own failure notice — the wording and whether it includes a numeric exit code have both varied across releases — and beneath or behind it is the engine’s own output. Expand the error detail, or open the developer/server log pane, and look for a line beginning llama_model_load: or llama_model_loader:. That line names the cause.
Because LM Studio’s own chrome is redesigned periodically, this page quotes only the engine strings, which are stable across both LM Studio and plain llama.cpp. If your build shows different wrapper text, the engine line underneath still applies.
Three engine lines account for the large majority of reports, and they map cleanly onto three causes.
Cause one: unsupported architecture
llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'deepseek2'
This is not a broken file and not a memory problem. Every model family needs explicit support in llama.cpp — the graph, the attention variant, the rope handling — and support lands in llama.cpp first, then in the engine version LM Studio ships, then in the LM Studio release you have installed. That chain is why a GGUF published this morning can be unloadable this afternoon in a perfectly healthy installation. The same error has been reported in turn for gemma, qwen2, deepseek2 and mllama, each time resolved by an update rather than by anything the user did to the file.
The fix is to update LM Studio, and specifically its runtime: the app manages engine versions separately from the application itself, so updating the app without updating the runtime can leave you exactly where you were. If the architecture is genuinely not in llama.cpp yet, no version of LM Studio will load it, and the only options are a different runtime or waiting.
A close relative worth knowing: a multimodal GGUF that needs a separate projector file will load its language half and fail or misbehave on images if the projector is missing. That is a packaging problem, not an architecture one, and the model card usually says which files are required.
Cause two: not enough memory
The engine line here names an allocation, not an architecture:
ggml_backend_cuda_buffer_type_alloc_buffer: allocating 4300.00 MiB on device 0: cudaMalloc failed: out of memory
llama_model_load: error loading model: unable to allocate CUDA0 buffer
LM Studio makes this easy to trigger, because its load screen exposes GPU offload and context length as sliders and both of them are effectively memory dials. The context slider in particular is deceptive: raising it costs KV cache proportionally, so a model that loads at 4K can fail at 32K with no other change. Two adjustments, in this order: pull the context length down, then pull the GPU offload down. The mechanism behind both is in the load-time CUDA OOM page.
On Apple silicon the same failure appears as a Metal buffer allocation error, and the constraint is the unified memory pool shared with the rest of the system rather than a dedicated card; running models on Apple silicon covers what that changes.
One tell that distinguishes memory from everything else: the failure moves when you move the sliders. Architecture and corruption failures are identical at every setting.
Cause three: an incomplete file
A truncated or partially written GGUF fails structurally, and the engine says so in terms of the file rather than the model:
- A bad header produces a magic-number complaint — unknown magic and version combination covers exactly that string.
- A file that is structurally valid but short produces a tensor complaint: a wrong tensor count, or a failure reading tensor data past the end of the file.
- A multi-part GGUF with a missing shard fails looking for the next part. Split models are published as
-00001-of-00003.ggufand all parts must be present in one directory.
Verify rather than guess: compare the on-disk size to the size on the model page. Downloads interrupted by sleep, a dropped connection or a full disk are the usual origin, and a disk that filled during the download leaves a file that looks plausible and is not. Delete and re-download; do not attempt to resume a file you already suspect.
A variant specific to LM Studio: models added by pointing the app at a directory rather than downloaded through it must sit in the expected folder layout, publisher over model over file. A GGUF dropped loose in the models root either does not appear or appears and fails, and neither symptom mentions the directory structure. If the file is one you fetched yourself, check the layout before you suspect the file.
Working through it in order
- Open the engine log and read the first line that mentions
llama_model_load. Everything below depends on which of the three shapes it has. - If it names an architecture: update the runtime, then the app. If the architecture is new this week, check whether llama.cpp itself supports it yet before assuming your install is at fault.
- If it names an allocation: reduce context, then reduce GPU offload, reloading between changes. If it loads at any setting, it is a budgeting problem and not a broken model.
- If it names the file, a magic number or a tensor: check the file size against the publisher’s, check for missing shards, then delete and re-download.
- If the model loads but never becomes usable, that is a different symptom — a model stuck preparing — and if it never appears at all, see models missing from the list.
The architecture case has an awkward property: the fix is a release you do not control, and until it lands the model simply cannot run on this machine. Teams that ship on top of local models generally keep a hosted route for exactly that window, which turns a blocked week into a more expensive week. That is a routing decision, and it is easier when both backends sit behind one interface.
Top comments (0)