The fastest answer to how to load a model in LM Studio: press Cmd+L on macOS or Ctrl+L on Windows and Linux to open the model loader, pick a downloaded GGUF or MLX model, adjust GPU offload and context length if needed, and load it. From a terminal, lms load <model_key> does the same job and lms ps confirms the model is resident.
The click is the easy part. Loads fail around it: the memory guardrail refuses because the estimate at your requested context length doesn’t fit, the model loads but generates at CPU speed because half its layers stayed in system RAM, or a model a script loaded on demand vanishes after an idle hour. Each of those is a setting, and each is fixable.
What does loading a model in LM Studio actually do?
Loading moves a model from disk into working memory so it can generate tokens. LM Studio’s getting-started docs define it as “allocating memory to be able to accommodate the model’s weights and other parameters in your computer’s RAM.” Downloading costs disk space. Loading is what costs RAM and VRAM.
That memory bill has two lines. The weights scale with parameter count and quantization, which is why the same model needs far less at Q4_K_M than at Q8_0 (the trade-offs are in GGUF quantization levels explained). The second line is the KV cache, which scales with context length. The PagedAttention paper from the vLLM authors calls per-request KV cache memory “huge” and dynamic, and that is as true on a desktop as in a serving cluster. Since LM Studio 0.3.27, the loader’s memory estimate accounts for context length, flash attention and whether the model is a vision model, so one file can pass at a short context and fail at a long one. For worked numbers on a common size, see how much VRAM a 7B model needs.
How to load a model in the LM Studio app
- Get a model onto disk. Open the Discover tab (Cmd+2 or Ctrl+2 from anywhere), then search by keyword, by
user/model, or by pasting a Hugging Face URL. The download docs suggest a 4-bit option or higher if your machine can run it. On Windows and Linux that means a GGUF build; on Apple Silicon, GGUF and MLX both work. If a repo only offers a stock.safetensorscheckpoint, read GGUF vs safetensors in LM Studio before downloading a full-precision checkpoint the runtime won’t open. - Open the model loader. The documented path is the Chat tab, then the model loader. The shortcut is faster: since the 0.4.0 release, Cmd/Ctrl+L opens the model picker from anywhere in the app, and pressing it again dismisses it.
- Select the model. The list shows everything you downloaded or sideloaded.
- Check the load parameters. LM Studio by default selects load parameters that optimize performance on your hardware, as Qwen’s LM Studio guide puts it. Override them when you know better, which is usually about context length.
- Load. If the memory estimate exceeds what the machine can spare, the app warns before loading anything. In the GUI you can override the guardrail and try anyway.
To free the memory, eject the model from the same picker.
Which load settings should you change?
Change context length and GPU offload first, then flash attention and parallel slots. Those four decide whether a load succeeds and how fast the result runs:
| Setting | What it controls | When to change it |
|---|---|---|
| GPU offload | Share of model layers placed in VRAM; --gpu takes 0 to 1, off or max | max if the model fits in VRAM; lower it when the load is blocked |
| Context length | Maximum tokens the model considers, and so the KV cache size | Lower it first when the estimate fails |
| Flash attention | Optimized attention computation; included in the memory estimate | Toggle per model and compare |
Parallel slots (n_parallel) | Requests processed at once instead of queued; default 4 since 0.4.0 | Serving several clients from one model |
GPU offload is the same idea as llama.cpp’s --n-gpu-layers, which the llama.cpp server docs describe as the “max. number of layers to store in VRAM.” Layers that don’t fit run on the CPU from system RAM. Partial offload is how you run a model larger than your VRAM, but tokens/sec drops with every layer left behind. The best local LLM for 16GB RAM rundown covers which models fit cleanly.
Set these once rather than on every load. In the My Models tab, the gear icon next to a model opens its per-model defaults for GPU offload, context size and flash attention. Changes made at load time can be saved as the new default, and the defaults apply everywhere the model loads, including lms load.
Loading a model from the command line
lms ships with LM Studio. Run the app once, then lms --help works in any terminal. The lms load reference lists the flags; a typical session looks like this:
# Models on disk, with their keys
lms ls
# Dry run: print the memory estimate, load nothing
lms load --estimate-only qwen/qwen3-4b-2507 --context-length 16384 --gpu max
# Load with explicit settings and a stable name for API clients
lms load qwen/qwen3-4b-2507 \
--context-length 16384 \
--gpu max \
--identifier qwen3-4b-chat \
--ttl 3600
# Models currently in memory
lms ps
# Free everything
lms unload --allRun --estimate-only before any load you aren’t sure of. LM Studio’s own 0.3.27 release notes show it reporting 65.68 GB of estimated GPU memory for gpt-oss-120b, followed by a line saying whether your guardrail settings would allow the load. It honors --context-length and --gpu, so you can tune both until the estimate fits.
Two details trip people up. Models loaded with lms load have no TTL by default and stay resident until you unload them; --ttl adds an idle timer in seconds. And --host points lms load and lms unload at a remote LM Studio instance, which is the normal workflow for a machine with no monitor, like a headless LM Studio server on Unraid.
For a GGUF downloaded outside the app, lms import path/to/model.gguf brings it in through an interactive prompt; the import docs mark the command experimental. Placing the file by hand also works if it follows the ~/.lmstudio/models/publisher/model/model-file.gguf layout.
Loading a model through the API
Scripts and services shouldn’t depend on someone clicking Load. The Python SDK returns a handle to a model, loading it first if it isn’t resident:
import lmstudio as lms
# Returns the loaded instance, or loads it. ttl applies only to a fresh load.
model = lms.llm("qwen/qwen3-4b-2507", ttl=3600)
print(model.respond("Reply with OK if you are loaded."))
# Release the memory when the job is done
model.unload()client.llm.load_new_instance() creates an additional instance instead of reusing one. Over HTTP, the REST load endpoint takes the same settings as JSON:
curl http://localhost:1234/api/v1/models/load \
-H "Authorization: Bearer $LM_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-oss-20b",
"context_length": 16384,
"flash_attention": true,
"echo_load_config": true
}'The response carries "status": "loaded", an instance_id, load_time_seconds and, with echo_load_config, the configuration actually applied. Log that last field. It tells you what the server settled on for anything you left out.
Often you don’t need an explicit load. With JIT loading, which is on by default, a request that names an unloaded model loads it first. JIT-loaded models get a 60-minute idle TTL by default, and auto-evict keeps only one JIT-loaded model in memory at a time; models you loaded manually are untouched. A "ttl" field in the request, in seconds, overrides the timer.
One gap matters for headless setups: the GUI’s “Load anyway” override has no CLI or REST equivalent, according to a user bug report on LM Studio’s tracker. In that report, LM Studio estimated about 22.92 GB for Qwen 3.5-9B at a 110,000-token context, the same setup in standalone llama.cpp used about 11.5 GB, and the model loaded fine once forced through the GUI. That is one user’s measurement, not an independent benchmark, but it shows the estimate can err conservative. When a scripted load is blocked, cut context length or offload rather than hunting for an override flag.
Why won’t my model load in LM Studio?
Most failed loads trace to one of four causes: the memory guardrail blocked it, the file is a format the runtime can’t open, the file sits outside the folder layout LM Studio scans, or it loaded with settings that make it look broken. Each has a quick check.
- “Model loading was stopped due to insufficient system resources.” That’s the guardrail. Lower context length first, then GPU offload, and re-run
lms load --estimate-onlyuntil it passes. - The model never appears in the loader. Check the format (GGUF, or MLX on Apple Silicon) and the
publisher/model/filelayout. - It loads but crawls. That is partial offload. Raise GPU offload if VRAM allows, or drop to a smaller quant. If the hardware itself is marginal, LM Studio’s system requirements sets out the floors.
- It was loaded, and now it’s gone. A JIT-loaded model hit its idle TTL, or another JIT load evicted it.
FAQ
can lm studio load safetensors models
Only as MLX models on Apple Silicon. LM Studio’s llama.cpp runtime opens GGUF files, and its MLX engine, added in version 0.3.4, opens MLX model directories that store weights as safetensors. A stock PyTorch safetensors checkpoint loads on neither, so search for a GGUF or MLX conversion of the same model.
can lm studio load more than one model at a time
Yes, if memory allows. Models loaded manually stay resident side by side, and the Python SDK’s load_new_instance call can run several instances of one model. The exception is JIT loading: with auto-evict on, which is the default, only one JIT-loaded model stays in memory and the previous one is unloaded.
where does lm studio store downloaded models
By default in ~/.lmstudio/models/, organized as publisher, then model, then the model file, preserving the Hugging Face repository structure. You can change the models directory from the My Models tab. Any GGUF you add by hand should follow the same publisher/model/file layout, or use lms import to bring it in.
how do i load a model in lm studio without a gpu
Set GPU offload to zero, or run lms load with —gpu off, and the whole model runs on the CPU from system RAM. It works for small quantized models but generates noticeably slower than a GPU load. Pick a 4-bit quant of a small model and keep the context length modest to stay inside RAM.
Related across the network
- How Much VRAM Do You Need to Run Local LLMs with Ollama? — ollamalab.com
- ComfyUI GPU Requirements: How Much VRAM You Need — comfyuiops.com
