LM Studio Stuck at “Preparing Model”

The dialog says the model is being prepared and then nothing changes. No error, no exit code, no progress. That state is not one bug — it is three, and they are distinguishable in about a minute if you check them in the right order.

What the preparing stage actually is

LM Studio ships a llama.cpp-derived runtime and drives it out of process. Before a single token can be generated, that runtime has to open the GGUF file, read its header and key-value metadata, look up the architecture named in that metadata, build a compute graph for it, allocate a context and a KV cache sized by your context-length setting, and then map or read the weights into memory. The UI collapses all of that into one label.

That matters because the three things which hang there fail at three different points in the sequence, and each leaves a different trace. A truncated file dies while reading the header or while mapping tensors. An unknown architecture dies at the graph-building step and usually does print something, into a log you are not looking at. A load that is thrashing has not failed at all — it is doing real work at disk speed.

Before anything else, open the app log. LM Studio surfaces the backend runtime’s stderr in its developer or console pane, and that pane is where the real message lands when the dialog stays silent. If it shows a GGML_ASSERT line, you are not in any of the three cases below and the assertion itself names the fault.

Cause 1: a truncated or corrupted download

This is the most common one and the easiest to rule out, because a GGUF file has a known size. Every quantisation on a Hugging Face model card lists its exact byte size next to the file. Compare the file on disk against it:

# macOS / Linux
ls -l ~/.lmstudio/models/<publisher>/<repo>/<file>.gguf

# Windows PowerShell
Get-Item "$env:USERPROFILE\.lmstudio\models\<publisher>\<repo>\<file>.gguf" |
  Select-Object Length

If the number is smaller than the published size, the download stopped early. That happens when a proxy closes a long connection, when the disk fills partway through a 40 GB pull, or when the app was quit during the transfer. A partial GGUF is not detectably invalid at its first byte — the magic and header are the first thing written, so the file looks like a real GGUF right up to the point where the tensor data runs out. That is precisely why it hangs rather than erroring cleanly: the loader is waiting on bytes that are not there.

A file that matches on size can still be wrong if the transfer was silently re-encoded, which is what a captive proxy or an aggressive corporate TLS inspector does. Hugging Face publishes a SHA-256 for each file in the repository’s file listing; if the size matches and the model still will not prepare, hash the file and compare. Delete and re-download rather than resuming — a resumed download over a corrupted prefix reproduces the fault.

Cause 2: an architecture the runtime does not know

GGUF stores the model family in a metadata key, general.architecture. The runtime reads that string and looks it up in a table of graph builders it was compiled with. A model published the week a new family lands — a new Qwen, a new Gemma, a new MoE routing scheme — has an architecture string that a runtime built two months earlier has never heard of.

The giveaway is that the file is the right size, other models in the same folder load, and the model in question is recent. LM Studio bundles its inference runtimes separately from the app itself and updates them on their own cadence, so the fix is to update the runtime, not only the application. In current versions that is a dedicated runtimes pane; the lms command-line tool exposes the same list.

Read the architecture out of the file yourself if you want certainty rather than inference. Any GGUF metadata reader will print it — the gguf Python package ships gguf-dump, and it prints the key-value block alongside the tensor list. An architecture string you have never seen, against a runtime you have not updated since before that model existed, is your answer.

Cause 3: it is not stuck, it is paging

The third case is not a failure. If the weights plus the KV cache do not fit in the memory available, the operating system will not refuse — it will page. On macOS that means compressed memory and swap; on Windows it means the pagefile. The load continues at the speed of your SSD instead of the speed of your RAM, which can turn twenty seconds into twenty minutes without producing a single error.

The tell is disk activity: sustained reads at hundreds of megabytes per second while the dialog does not move. Activity Monitor, Task Manager’s disk column, or iostat will show it. If that is what you have, the model is too large for the configuration you asked for, and there are two dials. Context length sizes the KV cache directly and is often the larger of the two — halving it halves that allocation. GPU offload decides how many layers sit in VRAM; on a discrete GPU, offloading fewer layers moves the pressure to system RAM rather than removing it, so on a machine that is short on both, the quantisation is the thing to change. A smaller quantisation of the same model is the reliable fix.

The order to check these in

1. Open the app’s log or developer pane and read the backend’s output. If there is a message there, none of the below applies — follow the message.
2. Compare the file size on disk with the size on the model card. A mismatch ends the investigation: delete and re-download.
3. Watch disk read throughput for thirty seconds. Sustained heavy reads mean it is paging, not hung — reduce context length or pick a smaller quantisation.
4. Load a small, old, well-known GGUF from the same folder. If that works and only the new model hangs, update the inference runtime, not the app.
5. If it still hangs with an updated runtime, dump the GGUF metadata and check general.architecture against the runtime’s supported list before filing anything.

One thing that is not a cause, despite appearing in most advice: the model not being visible in the list at all is a different problem with a different mechanism, covered in the page on downloaded models that never appear. A model that is stuck preparing has already been found.