Which Local LLM Fits Your Mac's RAM? (2026 Guide)
How much unified memory does a local model really need? A no-nonsense map from your Mac's RAM to the largest model you can actually serve — and the exact command to run it.
The single most common question we get about running LLMs locally on a Mac is some version of: "I have an M-series MacBook with N gigs of RAM — what's the biggest model I can actually run?"
The honest answer is that unified memory, not raw compute, is the wall you hit first on Apple Silicon. Your Mac's RAM decides which weights can stay resident; everything else — speed, context length, batch size — is a knock-on effect. This guide gives you a straight memory-to-model map, explains the one rule of thumb worth memorizing, and clears up the most expensive misconception (that Mixture-of-Experts models are "smaller").
The one formula that matters
At 4-bit quantization — the default most people run on MLX — a model's weights take roughly 0.55 GB of memory per billion parameters. Add a bit for the KV cache (which grows with your context length) and headroom for macOS itself, and a workable planning rule is:
weights (GB) ≈ params (B) × 0.55 # 4-bit usable RAM ≈ total RAM − 3 GB (macOS) − KV cache
So a 14B model needs ~8 GB of weights; a 32B model needs ~18 GB; a 70B model needs ~40 GB. You want those numbers to sit comfortably below your usable RAM, not right at the edge — a model that technically loads but leaves 500 MB free will swap, stutter, and eventually get killed.
The quantization you pick moves this line. 8-bit roughly doubles the weight cost (~1.1 GB/B); 6-bit sits in between. If a model almost fits at 8-bit, drop to 4-bit before you drop to a smaller model — a 4-bit 32B beats an 8-bit 14B on almost every task.
Why MoE doesn't save memory — only speed
This trips up nearly everyone. A Mixture-of-Experts model like a 35B-A3B (35B total parameters, ~3B active per token) is fast because only the active experts run per token — but all 35B parameters still have to be resident in memory. The "A3B" buys you throughput, not a smaller footprint.
A 35B-A3B MoE needs the RAM of a 35B model, not a 3B one. Size your Mac by total parameters for memory, and think about active parameters only when you're estimating speed.
gpt-oss-20b is the happy exception that makes MoE feel small on laptops: at Apple's MXFP4 quantization its ~20B total weights compress to roughly 12 GB, which is why it runs comfortably on a 16 GB Mac and became the default lightweight agent model for MacBook users.
The RAM → model map
Numbers below assume 4-bit quants (MXFP4 for gpt-oss), a moderate context window, and that you're not running a dozen other heavy apps. Treat the "comfortable" column as the sweet spot and "tight" as the ceiling.
| Mac RAM | Comfortable | Tight ceiling | Good rapid-mlx aliases |
|---|---|---|---|
| 8 GB | 3–4B dense | 7–8B dense | qwen3.5-4b, gemma-4-4b |
| 16 GB | 7–9B dense, gpt-oss-20b |
14B dense | qwen3.5-8b, gpt-oss-20b, gemma-4-12b |
| 24 GB | 14B dense, 20–30B MoE | 32B dense | qwen3.6-27b, gpt-oss-20b, gemma-4-27b |
| 32 GB | 27–32B dense, 35B-A3B MoE | 49B MoE | qwen3.6-35b, gemma-4-27b, gpt-oss-20b |
| 48 GB | 35B MoE + room to spare | 70B dense (4-bit) | qwen3.6-35b, qwen3-coder |
| 64 GB | 70B dense, large MoE | 100B+ MoE | qwen3.5-70b, gpt-oss-120b |
| 128 GB+ | 100B+ MoE, gpt-oss-120b |
frontier-class MoE | gpt-oss-120b, qwen3.5-122b-a10b |
A few reads of this table:
- 16 GB is the real entry point for serious local work. Below it you can
run useful small models, but you're picking between coding help or a long document, not both.
- 32 GB is the coding sweet spot. A 27–35B model at 4-bit leaves enough
room for a large context window, which matters far more for agentic coding than another few billion parameters.
- Past 64 GB, memory stops being the constraint and prompt-processing
speed does. That's a different article.
How to actually run it
Every alias in the table is a one-liner. rapid-mlx is an OpenAI-compatible server, so once it's up your existing tools (Claude Code, Cursor, Aider, anything that speaks the OpenAI API) point straight at it:
pip install rapid-mlx rapid-mlx serve qwen3.6-35b # → OpenAI-compatible server on http://localhost:8000/v1
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen3.6-35b","messages":[{"role":"user","content":"hi"}]}'
If an alias is too big for your Mac, rapid-mlx will tell you before it tries to load — it won't silently thrash. Drop one tier in the table and try again.
Leave headroom for context
The number people forget is the KV cache. A long context window is not free: at 32K+ tokens the cache can add several gigabytes on top of the weights. If you plan to feed a model whole files or long agent traces, budget one tier down from the ceiling so the cache has room to grow.
Rule of thumb: if you're doing long-context or agentic work, pick the model that fits your RAM with 20% to spare. That spare space is where your context lives.
Pick yours
The fastest way to go from "how much RAM do I have" to "what should I run" is the live picker — choose your Mac, and it shows exactly what fits: models.rapidmlx.com. For the full per-family breakdown — every alias, quant, and tool-call parser — start at the model families docs. And if you're setting rapid-mlx up for the first time, the quickstart has you serving a model in about two minutes.
pip install rapid-mlx,
then rapid-mlx serve <alias>. Browse every supported
model on the family docs or pick one by your
Mac's RAM at models.rapidmlx.com.