LM Studio "Failed to Load Model": Every Error Decoded and Fixed (Windows, Mac, Kali)

When LM Studio says "Failed to load model", the app itself is fine: the engine that runs the model (llama.cpp or MLX) refused or crashed while loading it. Five causes cover almost every case: the memory guardrail stopped it ("Model loading was stopped due to insufficient system resources"), the model does not fit in your VRAM or RAM at the GPU offload and context length you chose, the runtime is older than the model ("unknown model architecture"), the download is incomplete or the wrong file type, or the GPU driver or engine crashed (the strange "Exit code: 18446744072635812000"). The quickest fixes, in order: expand the error to read the real line, update the engine in Settings > Runtime, lower the context length and GPU offload, and pick a smaller quantization. Every error message, and the fix for each on Windows, Mac and Linux including Kali, is below.

Ethan had promised Jake a private AI assistant for writing estimates and emails, running on Jake's new laptop with no subscription and nothing leaving the machine. He installed LM Studio, downloaded a popular 27B model because the reviews were good, clicked Load, and got a red box: "Failed to load model". He tried again and got a different message about insufficient system resources. He updated the app and got the same error. Then he expanded the details and read the one line that mattered: the laptop had 8 GB of graphics memory, and the model he picked, at the context length LM Studio had filled in by default, needed more than twice that. A 9B model at a sensible context length loaded in eleven seconds and has run every day since. Almost every "Failed to load model" ends the same way once you read the actual line underneath it. This page shows you where that line is, what each version of it means, and exactly what to change.

What "Failed to load model" actually means

LM Studio is two things in one window. The app is the interface you click: the model search, the chat, the settings. The work of actually running a model is done by an engine (LM Studio calls them runtimes): llama.cpp for GGUF model files on Windows, Linux and Mac, and MLX for MLX-format models on Apple Silicon Macs. When you click Load, the app asks the engine to read the model file, place its layers in your graphics memory (VRAM) and system memory (RAM), and set aside working memory for the conversation.

"Failed to load model" means that step did not finish. Either the app stopped it before it began (the memory guardrail), or the engine tried and failed: it ran out of memory, did not understand the model's design, could not read the file, or crashed outright. The message on its own does not say which, which is why the next step matters more than any fix.

Two things follow from this. First, reinstalling LM Studio rarely helps, because the app is usually not the problem. Second, the engine is updated separately from the app, so an up-to-date LM Studio can still be running an engine that is months old.

Step one: read the real error line

Every useful clue is in the detailed message, not the headline. Find it in one of three places.

1. Expand the error. The red error box in the chat or in the model loader usually has a details or "show more" section. Open it and look for a line beginning with llama_model_load:, error loading model, an exit code, or a memory figure.
2. Open the developer logs. In LM Studio, open the Developer view and its server logs, then try loading again and watch the lines appear. LM Studio 0.4.21 and later write clearer load errors here than older versions.
3. Use the command line. If you have LM Studio's lms command installed, run lms log stream in a terminal, then load the model in the app. Every log line from the engine prints in the terminal, where you can copy it.

Copy that line into a note. Then match it against the table below; the fix for each is in the sections that follow.

The error decoder: every message and what it means

What the details say	What it means	Go to
Model loading was stopped due to insufficient system resources	LM Studio's guardrail estimated the model will not fit and refused before trying	Guardrail
unknown model architecture: '…'	The engine is older than the model's design	Runtime
failed to allocate … buffer, CUDA error: out of memory, ErrorOutOfDeviceMemory	Graphics memory ran out during loading	VRAM
Exit code: 18446744072635812000 (or a similar huge number)	The engine crashed; usually a memory access violation from the driver or engine	Crash codes
Exit code: null, or the load stops with no message	The engine process was ended from outside, often by the system running out of memory	RAM and context
data is not within the file bounds, failed to read, unexpected end of file	The download is incomplete or damaged	Download
invalid magic, not a GGUF file, unsupported format	The file is not a model LM Studio's engine can read on this computer	File type
Cannot read properties of undefined	An error in the app's interface, not the model	App errors
No message, and loading was very slow before it failed	The model spilled from VRAM into RAM, then the system ran out	VRAM

A worked example: reading the log lines

The detailed error is often a few lines from llama.cpp. They look intimidating, but each has one useful word. Here are typical examples and how to read them:

llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'kolibri1'

The key words are unknown model architecture, and the name in quotes is the model family your engine does not know. The fix is an engine update, or a model your engine supports.

ggml_backend_cuda_buffer_type_alloc_buffer: allocating 9216.00 MiB on device 0: cudaMalloc failed: out of memory

Here the engine tried to reserve about 9 GB on the first NVIDIA card (device 0) and the card did not have it. The number tells you how far over you are: on an 8 GB card, you need to free a little more than 1 GB, by lowering GPU offload a few layers, shortening the context, or picking a smaller quantization.

llama_model_load: error loading model: tensor 'blk.31.ffn_down.weight' data is not within the file bounds

The engine reached a part of the model that should be in the file and was not there: the download is incomplete. Delete it and download again.

Lines that mention vk or Vulkan and OutOfDeviceMemory mean the same as the CUDA out-of-memory line, on AMD or Intel graphics. Lines that mention ROCm or HIP errors on AMD cards often mean the card or driver is not supported by that engine; switching to the Vulkan engine is the quick test.

"Model loading was stopped due to insufficient system resources"

This is not a crash. It is a safety check LM Studio runs before loading anything. LM Studio estimates how much memory the model needs at your chosen settings, the model's weights plus the working memory for the context length you asked for, compares it with the memory that is free, and refuses if the estimate is too high. The point is to stop a too-large model from freezing your whole computer.

Four ways through, from safest to riskiest:

1. Lower the context length. In the model's load settings, set Context Length to 4096 or 8192 instead of the model's maximum. The working memory for a long context can be as large as the model itself, so this one change often cuts the estimate in half.
2. Close memory-hungry apps (browsers with many tabs, games, video editors) and try again, since the check measures free memory at that moment.
3. Choose a smaller quantization of the same model, such as Q4_K_M instead of Q8_0. The sizes are listed on the model's download page in LM Studio.
4. Select Load anyway in the error dialog, or relax the guardrail level in LM Studio's settings. Do this only when you are confident the estimate is wrong, and save your work in other apps first, because a model that truly does not fit can make the computer unresponsive.

When the estimate is wrong

The guardrail is an estimate, and it can be pessimistic. Two cases are well known. Some newer models are estimated at roughly twice the memory they actually use. And on computers with unified memory, such as AMD Ryzen AI Max laptops and mini PCs, where a large share of RAM is reserved for the graphics chip, the check can count only the leftover system RAM and block models that would fit in the reserved video memory. In both cases, Load anyway (or a relaxed guardrail) works, and the model runs normally.

Check before you load, from the command line

LM Studio's lms command can show the estimate without loading:

lms load --estimate-only
lms load --estimate-only --context-length 8192

Pick the model from the list it shows, and compare estimates at different context lengths. Note that the Load anyway override exists only in the app; loads started from the command line or LM Studio's local API stay blocked by the guardrail, so lower the settings rather than fight it there.

"Unknown model architecture": update the runtime, not just the app

Every model family has its own design, its architecture, and the engine needs code for each one. When a new family appears, support lands first in llama.cpp (or MLX), then in the engine version LM Studio ships. Until your engine has it, the model fails with unknown model architecture followed by the family's name. The file is fine; your engine is simply older than the model.

1. Open Settings and go to Runtime (older versions call this Developer > Runtimes, or Runtime Extension Packs).
2. Check for updates, and update the engine you use: CUDA llama.cpp for NVIDIA graphics, Vulkan llama.cpp for AMD and Intel graphics, CPU llama.cpp for no graphics card, and MLX on Apple Silicon Macs.
3. Make sure the updated engine is selected for the model type (GGUF uses llama.cpp; MLX models use MLX).
4. Load the model again.

If the newest engine still does not know the architecture, the model is newer than llama.cpp's support for it. That happens for days or weeks after some releases, especially for unusual designs. We saw it with Aleph Alpha's Kolibri this month, which needs a patched llama.cpp; our Kolibri guide shows what to do in that situation, and our Ternary Bonsai guide explains the same pattern for another model. Waiting for an engine update, or using a different model, are the only real options.

When an update made things worse

Occasionally an engine update breaks loading for models that worked yesterday. If the error appeared right after an update, open Settings > Runtime and switch back to the previous engine version, which LM Studio keeps installed for a while. Note the versions, and try the next update when it arrives.

Out of graphics memory: GPU offload, context and quantization

Most "Failed to load model" errors on Windows and Linux PCs with a graphics card are memory. A model's size in memory is roughly its file size plus the working memory (KV cache) for the context length, plus a little overhead. The GPU offload setting decides how much of that goes into graphics memory; the rest stays in system RAM and is processed more slowly by the CPU.

Model size (Q4_K_M)	File size, roughly	Fits fully in	Partly offloaded on
3B to 4B	2 to 3 GB	4 GB VRAM	Any PC with 8 GB RAM
7B to 9B	4.5 to 6 GB	8 GB VRAM	4 to 6 GB VRAM + 16 GB RAM
12B to 14B	7.5 to 9 GB	12 GB VRAM	8 GB VRAM + 16 GB RAM
24B to 32B	14 to 20 GB	24 GB VRAM	12 to 16 GB VRAM + 32 GB RAM
70B	about 40 GB	48 GB of VRAM across cards	24 GB VRAM + 64 GB RAM, slowly

These are guides, not guarantees: add the context memory on top, and mixture-of-experts models behave differently from dense ones. Our honest guide to RAM and VRAM tiers goes deeper.

The four settings that fix most memory errors

1. Context Length. Many models advertise 128K or 256K tokens, and some setups default to large values. Each doubling of context roughly doubles the working memory. Start at 8192, and raise it only when you need long documents.
2. GPU Offload. The slider or layer count decides how many layers go to the graphics card. If loading fails with an out-of-memory error, lower it a few layers at a time until the model loads. Everything still works, just more slowly for the layers left on the CPU.
3. Quantization. Q4_K_M is the usual sweet spot of size and quality. Q5 and Q6 are a little better and larger; Q8 is close to full quality and nearly twice the size of Q4. If a model nearly fits, step down one level.
4. Flash attention and KV cache type. In the advanced load settings, flash attention reduces memory use for long contexts on supported cards, and storing the KV cache at lower precision saves more. Both are worth trying when you need long context on limited VRAM.

One more trap: other programs use graphics memory too. A game launcher, a browser using hardware acceleration, or a second model already loaded in LM Studio can take gigabytes. Eject other models (the eject icon next to each loaded model), close graphics-heavy apps, and check the memory figure again.

The advanced load settings, in plain English

Open a model's load settings (the gear or settings panel next to the model before loading) and you will see more options than most people need. These are the ones that affect whether a model loads:

• Context Length: the conversation memory, in tokens. The biggest single lever on memory use.
• GPU Offload: how many of the model's layers go to the graphics card. More is faster, until the card runs out.
• Offload KV Cache to GPU Memory: puts the conversation memory on the graphics card too. Faster, but uses VRAM; turn it off when a model barely fits.
• Flash Attention: a more memory-efficient way of computing attention on supported cards. Worth turning on for long contexts.
• K and V cache quantization: stores the conversation memory at lower precision, saving memory with a small quality cost. Often paired with flash attention.
• Keep Model in Memory and Try mmap(): control how the file is held in RAM. If loads fail on a machine with little RAM, turning off "keep in memory" can help; if loading is unusually slow from a slow drive, mmap behavior matters. LM Studio 0.4.21 updated these options for newer llama.cpp engines.
• Number of experts (on mixture-of-experts models): how many experts are active per token. Leave it at the default unless you know why you are changing it.

If you have changed many settings and nothing works, reset the model's load settings to defaults, set only context length and GPU offload yourself, and build up from there.

Loading from the command line and the API

LM Studio can also load models without the window, through its lms command and its local server, which apps and coding tools use. A few differences catch people out:

lms ls
lms load --context-length 8192 --gpu max
lms ps
lms unload --all

• lms ls lists downloaded models, lms load loads one (pick from the list, or name it), lms ps shows what is loaded, and lms unload frees memory.
• --gpu controls offload (for example max, off, or a fraction such as 0.5), and --context-length sets the context, the same two levers as in the app.
• The guardrail cannot be overridden here. There is no Load anyway from the command line or API, so lower the settings until the estimate passes.
• Apps that request a model through the API can trigger loading on demand. If an app asks for a model that does not fit, the load fails inside that app with a less helpful message; load the model yourself with settings that work, and point the app at it.

If your editor or chat app says it cannot reach LM Studio at all, that is a different problem from a failed load: start the local server in LM Studio's Developer view and check the address and port the app is using.

Crash codes: "Exit code: 18446744072635812000" and friends

That enormous number is not a real exit code. It is a negative Windows error code displayed as if it were a positive 64-bit number, and rounded on the way. Worked back, 18446744072635812000 corresponds to 0xC0000005, Windows' code for an access violation: the engine tried to read or write memory it was not allowed to touch, and Windows ended it. Other huge numbers starting 1844674407 are the same kind of crash with a different code underneath.

In LM Studio, an access violation during loading almost always comes from one of these, in order of likelihood:

• The graphics driver. An old, broken or Windows Update-supplied driver. Install the latest driver directly from NVIDIA, AMD or Intel; our guide to updating drivers properly explains why the manufacturer's own driver matters.
• The engine version. A bad engine release, or one that does not yet support your new graphics card. Very new GPUs often need the newest CUDA engine; a crash right after an engine update calls for switching back.
• Running out of memory in a way the engine did not catch, especially with GPU offload set to maximum on a card with little VRAM. Lower the offload and try again.
• A missing Microsoft Visual C++ runtime on Windows, which some reports link to helper processes in LM Studio failing with Windows side-by-side errors. Installing the latest Visual C++ Redistributable (x64) from Microsoft is a quick, safe check.

A quick way to separate the engine from the driver: switch the runtime to CPU llama.cpp and load a small model. If it loads on the CPU, the problem is on the GPU side, driver or engine; if it still crashes, look at the file and the app.

Exit code null and loads that die quietly: RAM and context

When the engine disappears without an error of its own, something outside ended it. On Linux and Kali, that is usually the kernel's out-of-memory killer, which ends the largest process when RAM runs out; on Windows, a system under heavy memory pressure can do the same to the engine. Signs are a long, slow load with the disk working hard (Windows paging memory to disk), then failure.

The fixes are the same as for VRAM, aimed at system memory: lower the context length first, then use a smaller quantization or model, and close other programs. On Linux, check with free -h before loading, and look for "Out of memory: Killed process" in sudo dmesg or journalctl -k after a failure to confirm the cause.

Damaged or incomplete downloads

Model files are large, and a download that stops early or is interrupted by sleep or a network drop leaves a file the engine cannot read. Errors mention data outside the file bounds, failure to read tensors, or an unexpected end of file.

1. In LM Studio, open My Models, find the model, and delete it.
2. Download it again from LM Studio's model search, and let it finish completely before loading.
3. Compare the file size shown on the download page with the size on disk.

Large models are often split into several files named like -00001-of-00003.gguf. All parts must be present in the same folder; a missing part produces the same read errors. If your disk is nearly full, downloads can fail silently, so check free space first.

The wrong file type for your computer

Not every file on a model's page is something LM Studio can load on your machine:

• GGUF files work everywhere through llama.cpp: Windows, Linux and Mac.
• MLX models work only on Apple Silicon Macs, through the MLX engine.
• Safetensors files, the original format most models are published in, are not loaded directly as GGUF. Download a GGUF or MLX version instead (LM Studio's search shows those).
• Vision models often need an extra "mmproj" file alongside the main model. Downloading through LM Studio's search handles this; manually copied files may lack it, which breaks image input or loading.

If you added a model by copying files into LM Studio's models folder, keep the publisher and model folder structure LM Studio expects; a file dropped loose in the wrong place may not appear, or may fail to load.

"Cannot read properties of undefined" and other app errors

Messages that sound like programming errors, such as "Cannot read properties of undefined", come from LM Studio's interface rather than the engine. They usually follow an interrupted update, a damaged settings entry for one model, or a bug in a specific version. Restart LM Studio fully (quit it from the system tray, not just the window), update to the latest version, and if one model keeps triggering it, delete and download that model again. If the error persists across models after an update, the version itself may have a bug; LM Studio's public bug tracker on GitHub is where such issues are reported and usually fixed within a release or two.

NVIDIA, AMD, Intel and integrated graphics

Graphics	Engine to select	Common load problems
NVIDIA GeForce / RTX	CUDA llama.cpp	Old driver; newest cards need the newest CUDA engine
AMD Radeon	Vulkan llama.cpp (ROCm on supported cards)	Driver version; Vulkan memory errors at high offload
Intel Arc	Vulkan llama.cpp	Driver version; start with partial offload
Integrated graphics / unified memory	Vulkan, or CPU	Guardrail counting only leftover RAM; shared memory limits
No graphics card	CPU llama.cpp	RAM and context length; CPU must support AVX2

On laptops with both integrated and NVIDIA graphics, make sure LM Studio runs on the NVIDIA card: in Windows, Settings > System > Display > Graphics, find LM Studio, and set it to High performance. Otherwise it may see only the small integrated chip and fail or run slowly.

Older computers: the AVX2 requirement

On Windows and Linux PCs with Intel or AMD processors, LM Studio requires a CPU with the AVX2 instruction set, which almost every processor from about 2013 onward has, but some older and budget chips do not. Without it, LM Studio or its engine may not start at all. To check on Windows, Microsoft's free Sysinternals tool Coreinfo lists AVX2 support (coreinfo -f); on Linux and Kali, run:

grep -o avx2 /proc/cpuinfo | head -1

If it prints avx2, you are fine. If not, LM Studio is not an option on that machine, but Ollama or llama.cpp built for your CPU may still run small models; our comparison of local AI runners helps you choose.

On a Mac

• Apple Silicon only. LM Studio runs on M1, M2, M3 and M4 Macs with macOS 14 or newer. Intel Macs are not supported.
• MLX or GGUF. MLX models usually load and run fastest on a Mac. If an MLX model fails, try the GGUF version of the same model with the llama.cpp engine, or the other way round; when a model family is brand new, one engine often supports it before the other.
• Memory is shared. The graphics chip uses part of your Mac's unified memory, and macOS limits how much the GPU may take by default. A model that needs nearly all of your RAM may fail even though it looks like it should fit; choose a smaller quantization or lower the context length.
• Update both. As on Windows, update LM Studio and the MLX and llama.cpp engines in Settings > Runtime. New models such as Gemma 4 failed to load on Macs until the engines were updated.
• Run it from Applications. Move LM Studio into the Applications folder and open it from there, so macOS does not run it from a temporary, restricted location.

On Linux and Kali

LM Studio for Linux comes as an AppImage, a single file you run directly. Most Linux-specific load problems are about starting the app or reaching the GPU, before any model is involved.

1. Make it executable: chmod +x LM-Studio-*.AppImage, then run it from your user account, not as root.
2. If it will not start and mentions FUSE or libfuse.so.2, install the FUSE 2 library: on current Kali and Debian, sudo apt install libfuse2t64; on older releases, libfuse2. If apt cannot find the package, our guide to Kali's "Unable to locate package" error fixes the sources list.
3. Check the GPU is visible before blaming LM Studio: for NVIDIA, nvidia-smi should list your card and driver. If it does not, install the NVIDIA driver first; on Kali, the nvidia-driver package plus a reboot is the usual route.
4. In a virtual machine, such as Kali in VirtualBox or VMware, there is normally no access to the host's graphics card, so only the CPU engine works. Use small models, or install LM Studio on the host instead.
5. Watch RAM: Kali machines are often lean, and the out-of-memory killer ends large loads quietly. Check free -h, lower the context length, and confirm with sudo dmesg | grep -i "killed process".

For a complete Kali setup with a model that is known to load well, our guide to running Gemma 4 on Kali Linux walks through it end to end.

Pick a model that will load the first time

Most failed loads start with a model that was never going to fit. Before you download, check three things on the model's page in LM Studio:

• The file size of the quantization you are picking, against your VRAM (for full speed) or VRAM plus RAM (for partial offload). Leave a few gigabytes free for context and other apps.
• LM Studio's compatibility hint, which marks downloads likely to fit your machine and warns about ones that will not.
• How new the model is. Models released in the last few days may need an engine update or may not be supported yet.

For a first model on an ordinary laptop, a 4B to 9B model at Q4_K_M is the reliable choice. Our guide to the MiMo V2.6 9B model and our guide series to running AI locally list good starting points for each hardware tier.

When to try Ollama or llama.cpp instead

LM Studio, Ollama and llama.cpp share much of the same engine, so a model that truly does not fit will not fit in any of them. But there are times when switching helps:

• The guardrail blocks a model you know fits, and you need to load it from scripts: Ollama and llama.cpp do not have LM Studio's guardrail.
• A brand-new model is supported in llama.cpp before LM Studio ships the engine update: llama.cpp's own builds get support first.
• You need to run on a server or headless machine, where Ollama or llama.cpp's server is simpler.

For everyday use on a desktop, though, fixing the load settings in LM Studio is usually quicker than switching tools.

A checklist that prevents most failed loads

1. Keep LM Studio and its engines updated, and note the engine version when a model works.
2. Install graphics drivers from NVIDIA, AMD or Intel directly, not only through Windows Update.
3. Set the context length deliberately; 8192 is a safe start.
4. Choose Q4_K_M first, and step up only if memory allows.
5. Eject models you are not using, and close graphics-heavy apps before loading big models.
6. Let downloads finish, and keep 20 GB or more of free disk space.
7. When a load fails, read the detailed line before changing anything.

LM Studio "Failed to load model": frequently asked questions

"Failed to load model" sounds final, but it is almost always one of a handful of fixable things, and the detailed line underneath tells you which: the guardrail being careful, a model too big for your settings, an engine that needs updating, a damaged download, or a driver crash. Read that line, update the runtime, bring the context length down, and choose a size your hardware can hold, and nearly every model that should run on your machine will. Jake's assistant has written a year's worth of estimates by now, and Ethan has not had to touch it since the day he read that one line.

Revision note. Written October 4, 2026, as a complete guide to LM Studio's "Failed to load model" errors. May every model you choose load on the first click.