You search for mlx-community/gemma-4-26b-a4b-it-4bit inside LM Studio, click download, press Load — and a red Failed to load model dialog stares back, with a stack trace that doesn't tell you which knob to turn. As an indie developer, I'd been trying to move some of the photo-classification work in one of my apps onto on-device Gemma 4 on an Apple Silicon MacBook — mostly to keep API costs down — when I kept hitting this exact wall. Local LLMs are fast once they run; the hard part is often that very first step of getting them to load at all.
"Failed to load model" is not one error — on my benches it splits cleanly into four buckets. Walking through them in order takes well under half an hour. The buckets are memory pressure, file corruption, runtime mismatch, and quantization metadata mismatch.
Open the right log before you click Load again
The Failed to load model dialog hides most of the useful information. Open LM Studio's Developer tab and keep the Console open before clicking Load again — that's where the real exception lives.
Look for these keywords in the console output: metal::CommandBuffer error points to memory, safetensors file is corrupted or header size mismatch means a broken download, unsupported architecture: gemma3_text means the bundled MLX runtime is too old, and mlx.core.array.shape mismatch or missing tokenizer files points to quantization metadata mismatch.
Cause 1: memory pressure (the most common one)
The 4-bit Gemma 4 26B occupies about 16GB on disk and roughly 10–12GB of working memory once loaded. Apple Silicon's unified memory architecture means anything below ~14GB of free memory at load time will fail to allocate the Metal backend.
On the bench I can reproduce this reliably: a 16GB MacBook Air with 40 Chrome tabs open fails 100% of the time. Drop it to 5 tabs and Load succeeds. Open Activity Monitor's Memory tab and verify at least 14GB of free memory before pressing Load.
# Quick freelist check from the terminal
vm_stat | awk '/free|wired|active|inactive|compressed/ { print }'
# Pages free roughly above 3,500,000 ≈ 14GB+ freeDon't forget Spotlight reindexing right after a reboot — that easily chews through several gigabytes. If a load fails immediately after restart, wait 15 minutes and try again.
Cause 2: corrupted model download
If the console shows safetensors file is corrupted or header size mismatch, the download was likely interrupted but LM Studio still marked it as complete. The app does not currently verify checksums on its own.
The cache path on macOS is ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/. A 4-bit 26B model should total 14–16GB across its .safetensors shards; anything well below that is suspicious.
# List the model directory and check total size
ls -lh ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/
du -sh ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/If sizes look off, uninstall the model from LM Studio's Models tab and redownload. In my own experience, the first download on flaky cafe Wi-Fi reliably corrupts; the redo on a wired home connection succeeds. Looks like a CDN-retry interaction between Hugging Face and LM Studio's resume logic.
Cause 3: MLX runtime version mismatch
If the console says unsupported architecture: gemma3_text or similar, the MLX runtime bundled with your LM Studio install predates Gemma 4 support. Gemma 4 MLX support shipped in the LM Studio April 2026 release; earlier builds will reject the architecture.
Check your version under LM Studio → About LM Studio. Anything before 0.3.18 needs an app update first, then a Runtime update inside the Runtime tab (look for "Update available" next to MLX).
Restart LM Studio after updating the runtime. The MLX engine only loads at app launch, so updating without restarting won't take effect — I once burned ten minutes thinking the update had failed before realizing I'd skipped the restart.
Cause 4: quantization / metadata mismatch
mlx.core.array.shape mismatch or "tokenizer config not found" means the partial set of files you got on disk don't agree with each other. Community MLX models ship a .safetensors weights file plus config.json, tokenizer.json, tokenizer_config.json, and special_tokens_map.json. If LM Studio downloaded weights but skipped metadata, Load fails.
# Verify all four metadata files are present
ls ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/ | \
grep -E '^(config\.json|tokenizer\.json|tokenizer_config\.json|special_tokens_map\.json)$'
# If you don't see all four, uninstall and redownloadAnother flavor of this: accidentally pulling both the 2-bit and 4-bit variants into the same model slot, then asking LM Studio to load. Check the Models tab for duplicates.
Triage order matters
You can hit more than one bucket at the same time. The order I use:
First, check Activity Monitor for free memory. If under 14GB, close apps and retry — that resolves cause 1. If it still fails, open the Developer Console and retry; the error keyword tells you whether it's cause 2 (corrupted), 3 (unsupported architecture), or 4 (shape mismatch / tokenizer).
That ordering matters because memory pressure can mask the other causes — under tight memory you sometimes get partway through the load and surface a misleading shape mismatch.
Post-load: confirm you're actually getting MLX throughput
Once Load finally succeeds, sanity-check throughput so you know you're running on the Metal backend and not silently falling back to CPU. On my M5 Pro 32GB MacBook Pro, a 200-token short prompt completes at 38–42 tokens/sec. Drop below ~20 tokens/sec and MLX is likely thrashing or fallen back.
Enable the tokens/sec display in the Inference tab so anomalies show up the first time you ask a question. Because Apple Silicon shares memory between GPU and CPU, the amount of free memory directly drives throughput — for daily Gemma 4 work, 32GB or more is dramatically more comfortable than 16GB.
A pre-flight check for all four buckets
If reading the Console every time gets tedious, run a single script before pressing Load to check free memory, total model size, and metadata presence in one shot — that pre-empts causes 1, 2, and 4.
#!/bin/bash
MODEL=~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit
# 1) Approximate free memory (target: 14GB+)
PAGES_FREE=$(vm_stat | awk '/Pages free/ {gsub(/\./,"",$3); print $3}')
echo "Approx free memory: $(( PAGES_FREE * 16384 / 1073741824 )) GB"
# 2) Total model size (14GB+ is healthy)
du -sh "$MODEL" 2>/dev/null
# 3) Are all four metadata files present? (output of 4 = OK)
ls "$MODEL" 2>/dev/null | grep -cE '^(config|tokenizer|tokenizer_config|special_tokens_map)\.json$'I keep this as precheck-gemma.sh and run it first whenever a load misbehaves. Glancing at three numbers usually tells me where to look before I ever read the stack trace, which makes the initial triage noticeably faster.
Isolate it by bypassing LM Studio with mlx_lm
When you can't tell whether the problem is LM Studio itself or the model/runtime underneath, load the model directly through mlx_lm, skipping LM Studio entirely.
pip install mlx-lm
python -m mlx_lm.generate \
--model mlx-community/gemma-4-26b-a4b-it-4bit \
--prompt "ping" --max-tokens 8If you get the same error here, the cause lives in the model files or the runtime (causes 2–4). If this works but only LM Studio fails, you've narrowed it to LM Studio's cache or Runtime settings. In my case mlx_lm ran fine while LM Studio kept failing, and re-updating the MLX runtime in the Runtime tab fixed it. It's a fast, decisive first move.
Where to go next
Once Gemma 4 loads consistently, the next interesting question is how MLX compares to the GGUF build on the same hardware, and how either stacks up against Gemini API. In my measurements MLX runs about 1.4× the GGUF throughput on Apple Silicon; for short tagging and classification, on-device Gemma is competitive with Gemini 3.2 Pro on quality. Hybrid local-plus-cloud setups are where most real apps end up. Thanks for reading.