A failed load is frustrating because the message rarely names the cause. The same failure surfaces whether the model is too big, half downloaded, or a format the selected runtime cannot read, and the advice you find online is usually someone guessing which of those they had.
On an Apple Silicon Mac the list is short. Four causes cover nearly everything, and they are distinguishable in about a minute if you check them in the right order. Start with the one that is most common and cheapest to rule out.
Cause 1: it does not fit under the Metal ceiling
The most common cause, and the one people rule out incorrectly. Apple Silicon uses unified memory, and macOS reports a working-set ceiling to Metal that is a fraction of installed RAM, not all of it. On our M2 Max with 32GB it reads 26,800,603,136 bytes, roughly 25GiB. A model plus its KV cache has to fit under that number, not under your RAM total.
The check: add the model file size to a rough allowance for the context. If the total is above about three quarters of your installed memory, this is your cause even if Activity Monitor shows free RAM. Two details catch people out:
The KV cache is part of the footprint and it scales with context. A model that loads at 4K can fail at 32K with no change to the file. If you raised context length before this started, put it back and try again.
A previously loaded model may still be resident. Run lms ps to list what is currently in memory. Unloading the last one you used frees its whole footprint.
The full mechanism, including why the GPU offload slider does not help here, is in the GPU offload piece.
Cause 2: the runtime cannot read that file
LM Studio ships two engines, llama.cpp and Apple MLX, and they read different files. A GGUF needs the llama.cpp runtime and an MLX-format model needs the MLX one. Point the wrong runtime at a file and the load fails on format rather than on memory, which is why the search queries around this cluster are about compatible runtimes and formats rather than about size.
Two more format traps sit in this category and neither is LM Studio's doing:
Safetensors is not GGUF. Plenty of Hugging Face repositories publish only the original weights. Those need conversion before any llama.cpp-based tool can load them, and downloading one by hand into the models folder produces exactly this failure.
Split GGUFs need every shard. Large models are often published as model-00001-of-00003.gguf and friends. Copy in one part and the load fails; the loader needs all of them present, in the same directory, with their original names.
Cause 3: the download is truncated
An interrupted download leaves a file that looks right in Finder and is not. A GGUF carries its metadata in a header, so a truncated file often gets far enough to be recognized as a model and then fails partway through loading, which reads as a mysterious engine error rather than a disk problem.
The check takes ten seconds: compare the size of the file on disk against the size listed on its Hugging Face page. Sleep during a download, a dropped network, or a disk that filled up will all produce this, and the fix is always the same. Delete the file and download it again rather than resuming, because a resumed transfer over a corrupted range does not repair it.
Cause 4: the architecture is newer than the engine
Model architectures ship faster than the engines that read them. When a new family lands, llama.cpp adds support in a build, and every app that embeds llama.cpp gets it only when that app updates its bundled engine. A brand new model with a GGUF that will not load in an app that is a few versions behind is usually this, not a broken file.
The tell is the model's age. If it was published in the last few weeks and everything older loads fine, update the app first. This is a normal consequence of how the engine ecosystem works rather than a defect, and it affects every llama.cpp-based tool including ours.
Working through it in order
The order below is by likelihood times cost, so you spend the least time on the most common cause. Most people stop at step one or two.
The alternative: the checks that should not be yours to run
Three of the four causes above are things software can know before you hit the button, and that is the design difference rather than a claim about engine quality. The inference is the same: ToolPiper embeds upstream llama-server directly, build b10068, unmodified, and our same-bytes benchmark on an M2 Max put speed at parity, within single digits in both directions with the winner flipping by model.
What is different is what happens before the load. The app reads your installed memory and the live Metal working-set ceiling and sizes model suggestions against them, so the list tells you what your Mac can hold before you spend the download. There is one runtime for GGUF and no runtime picker to get wrong. Models land as plain, named files in ~/Library/Application Support/ToolPiper/models/, where a truncated download is a visible size mismatch rather than a mystery. On the MLX path the memory reading is a hard gate: a load that would not fit is refused before any allocation, because a wired-memory overflow on Apple Silicon is not a failure an app can catch.
Cause four is not solvable by anyone. When a new architecture lands, every llama.cpp-based app waits for the next engine bump, including this one. What we do about it is publish the build number so you can check: currently b10068, stated on the product page, so you can compare it against what upstream added and know rather than guess.
The honest limits: macOS 26 or newer, Apple Silicon only. LM Studio's floor is macOS 14.0 and it runs on Windows and Linux too.
If none of the four fixes landed and you are weighing a move, settle the cost question first. LM Studio is free locally and sells cloud inference by the token. Loading and running models here is free as well, with no account and no cap, so trying it costs you a download rather than a decision. What each side actually charges for.