The best local LLM for your Mac, by how much memory it has

A single answer for each Mac, not a survey of what exists. Six picks, measured on one machine in one run — including the tier where the honest answer is that more memory buys speed rather than intelligence.

"Which model should I run?" has one useful answer, and it is not a list. It is the amount of unified memory in your Mac.

We already published [the survey version of this][mem] — 82 models plotted against the memory they need. This is the other half: for each Mac, one model, and the evidence behind the choice.

There is a reason we had to write it down. Until this week rapid-mlx answered this question two different ways. The curl | bash installer printed one recommendation; the desktop app's picker showed another. At five of six tiers they disagreed. So we picked the table that was actually being maintained, measured every model in it in a single run, and made both front doors read from it.

[mem]: /blog/how-much-memory-local-llm-mac

The table

Peak RSS is the whole rapid-mlx serve process tree; boot is a cold start to a 200 on /v1/models. All six measured in one run on one M3 Ultra, because a column stitched together from different Macs is not a column.

Install, then run the line for your tier:

curl -fsSL https://rapidmlx.com/install.sh | bash
rapid-mlx serve bonsai-27b-2bit

The installer detects your RAM and prints the right line for you, flags included, so you do not have to match the row by hand.

Why each tier gets what it gets

8–15 GB — the tier that had nothing

This one changed most, because until this week it had no answer at all. The app clamped these Macs up to the 16 GB picks, then correctly refused to run them. The first thing a new user saw was the app declining to start the only model it had offered.

LFM2.5-2.6B fixed that, and the reason is architectural rather than a matter of parameter count. Of its 30 layers, 22 are short convolutions and only 8 are attention. KV cache costs roughly 16 KB per token, so a 32K conversation adds about half a gigabyte on top of 1.6 GB of weights. On an M2 Pro it decodes at 97.8 tok/s and prefills at 503 tok/s.

It is post-trained for tool use and instruction following and beats models several times its size on those. It is not a coding model — Liquid publishes it as not recommended for agentic coding or knowledge-heavy work, and we agree. If you want to drive Claude Code or Aider, 16 GB is where that starts working.

16–23 GB — a 27B on a MacBook Air

bonsai-27b-2bit is Ternary Bonsai 27B, a low-bit build of Qwen3.6-27B at 1.71 bits per weight. A 27B-class model at 8.4 GB is why this tier gets something far more capable than its memory would normally buy.

The trade is speed: 17.8 tok/s on an M2 Pro, against 121 tok/s for the much smaller lfm2.5-8b-a1b-4bit that the desktop app offers alongside it as a faster alternative. Quality per gigabyte, not tokens per second.

24–31 GB — flags that are not optional

rapid-mlx serve gemma-4-26b-4bit --no-mllm --kv-cache-dtype bf16 --cache-memory-mb 512

Gemma 4 26B ships a vision tower this tier has no memory for, and an unbounded KV budget will claim the headroom a 24 GB Mac needs for everything else running on it. --no-mllm drops the vision path; the other two cap the cache. With them it peaks at 15.6 GB. Without them you are handing a 24 GB Mac a command that does not fit in it.

The installer prints the full line. Pick the same model by hand on a larger Mac and it keeps vision — the flags travel with the recommendation for this tier, not with the model.

32–63 GB and 64–95 GB — the same model, twice

qwen3.6-35b-4bit and qwen3.6-35b-8bit are the same 35B-A3B weights at two quantizations. 35B total, 3B active per token, so it is fast for its class.

At 32 GB the 4-bit build peaks at 20.4 GB, leaving room for a browser and an IDE — the real constraint on a machine you also work on. At 64 GB the 8-bit build fits at 37.7 GB, and its edge is quantization fidelity on long and hard prompts rather than benchmark points. Note the boot time: 10.6 s against 4.8 s, the only tier where startup is noticeable.

96 GB+ — the honest blank

qwen3.5-122b-mxfp4 is the pick, and its two cells are empty because we have not measured it on the same machine as the rest. Pulling 65 GB onto the shared Studio that also runs our release gate was not worth the disk that day. We would rather show a blank than a number that is not comparable to the five above it.

Fast is the easy half

Memory and throughput are the easy things to measure and the wrong things to optimise alone. A model that fits and runs at 100 tok/s is worthless if it cannot follow an instruction or finish a tool call.

Comparing these six on capability is awkward, because they are quantized differently — 2-bit, 4-bit, 8-bit, MXFP4 — and scores from one quantization do not transfer to another. So the common yardstick is the full-precision base model behind each pick, scored by someone who is not us.

The [Artificial Analysis Intelligence Index][aa] v4.1 is a composite of nine evaluations, and usefully it is not a knowledge quiz: Terminal-Bench v2.1 and τ³-Banking cover agentic tool use, GDPval-AA v2 covers real-world work tasks, SciCode covers coding, GPQA Diamond and CritPt cover reasoning, AA-LCR covers long context. Higher is better. For calibration: the median for comparable open-weights models is 9, and the whole index tops out at 61 — the best frontier model money can rent, running in someone else's datacentre. Everything below runs on your desk with the network off.

[aa]: https://artificialanalysis.ai/

That column does not climb, and we are not hiding it

The base behind the 16 GB pick scores 37 — the highest in the table — and the 24 GB tier scores 26.

Two things are true at once. Qwen3.6-27B is dense and genuinely the strongest base here; Artificial Analysis has it at 37 against 32 for the 35B-A3B MoE, matching what Qwen's own benchmarks show. It is also the slowest, at 59 tok/s against 152 for the MoE on AA's hosted measurements — and our 16 GB pick is not Qwen3.6-27B, it is a 2-bit compression of it running at 17.8 tok/s on an M2 Pro.

So the 24 GB tier buys speed and a vision tower, not raw intelligence. Whether that is the right trade is a fair question, and our own blended capability score — which rates the two nearly level — disagrees with Artificial Analysis here. We are not reordering six tiers on the strength of one composite index. We are going to measure the actual builds and let that decide.

"But two of these are aggressively quantized"

A 27B squeezed to 2 bits and a 122B to MXFP4 are not the models whose scores you just read. That objection is right, and for the 16 GB pick there is a direct answer, because prism-ml benchmarked the low-bit build itself.

80.49 against 85.07 across fifteen benchmarks — 94.6% retained at 1.71 bits per weight. That is why we are comfortable putting a 2-bit model in front of a 16 GB Mac.

The loss is not uniform, which is the useful part. Knowledge, math and straightforward coding barely move: MMLU-Redux 88.05, AIME25 90.84, HumanEval+ 93.90. What degrades is the hard end of instruction-following (IFBench 58.50 against 68.03) and multi-turn agentic work (τ²-Bench 73.61 against 82.90). For chat and code completion a 2-bit 27B is a bargain. For long agent loops, that is where the missing bits show up.

What the 8 GB pick has instead

LFM2.5-2.6B is not on Artificial Analysis, so its row reads blank rather than guessed. Liquid publishes its own numbers, and on the axes this tier is for — tools and instruction-following — it beats a model roughly four times its size:

A negative Omniscience score means a model asserts more than it knows. Every model in that comparison is negative; LFM2.5-2.6B is the least bad. It is a tool-caller, not an encyclopedia — which is the job an 8 GB Mac actually has.

About these numbers

Three things worth knowing before you compare them to anyone else's.

Weights on disk are not what a model costs you. Our own tier table listed bonsai-27b-2bit at 7.6 GB, which is the size of its weight tensors. Served, it peaks at 8.4 GB. Weights are the floor, never the number — on top sit the runtime, the tokenizer, and a KV cache that grows with the conversation.

How you measure moves the answer by two gigabytes. We produced two peak numbers for the same model that differed by 2.3 GB, and the first explanation we reached for — longer prompts cost more memory — was wrong. Through rapid-mlx serve, a short prompt peaks at 8.4 GB and a 2,000-token prompt at 8.5 GB on the same machine. The 10.7 GB came from a bare mlx_lm script: a different metric, and no KV quantization. rapid-mlx quantizes the KV cache to int4 by default, and on a 27B that default is worth about two gigabytes. So "how much memory does this model need" is under-specified until you say which runtime, which KV setting and which counter.

Third-party capability scores are for full-precision models. We serve 4-bit and MXFP4 builds, and quantization costs real capability — we have measured it. On HumanEval's full 164 problems, one model family at two quantization levels differed by 12 percentage points, far too large to wave away. Bonsai is the exception above, because its low-bit build was benchmarked directly. For the Qwen and Gemma rows, read the index as a ceiling for the family, not a promise about the quant on your disk.

Closing that last gap means benchmarking the exact builds we ship on the actual Macs people own, which is what our community benchmark board is being built to do.

Check what your Mac actually has

rapid-mlx doctor

reports chip, memory, free disk and Python, and tells you whether the model you are about to run fits. The full reference table, with HF repos and the reasoning per tier, lives at Hardware tiers.

Frequently asked questions

What is the best local LLM for a 16 GB Mac?

bonsai-27b-2bit — a 27B compressed to 1.71 bits per weight, peaking at about 8.4 GB served. Its full-precision base, Qwen3.6-27B, scores 37 on the Artificial Analysis Intelligence Index v4.1, the highest of any model in our tier table, and the low-bit build retains 94.6% of that base's benchmark average. The cost is speed: roughly 17.8 tok/s on an M2 Pro.

Can an 8 GB MacBook Air run a local LLM?

Yes. lfm2.5-2.6b-4bit peaks at about 2.0 GB served, which leaves room for macOS and the apps you actually use, and decodes at 97.8 tok/s on an M2 Pro. It is strong at tool use and instruction following — beating models four times its size on ToolSandbox and Multi-IF — and is explicitly not recommended for coding work.

How much memory does a model really need?

More than its weights, and how much more depends on your runtime. Add the runtime overhead, roughly 1.2 GB, and a KV cache whose size depends on the model's architecture and on whether the server quantizes it. bonsai-27b-2bit has 7.6 GB of weight tensors and peaks at 8.4 GB served by rapid-mlx, which quantizes the KV cache to int4 by default. Run the same weights with an unquantized cache and it is over 10 GB.

Is a bigger model always better on a Mac?

No, and our own table is the evidence. The base model behind the 16 GB pick scores higher on the Artificial Analysis Intelligence Index than the picks two tiers above it — those buy speed and vision instead. Separately, past the point where a model stops fitting comfortably, memory pressure costs more than the extra parameters return, and Apple Silicon can respond to sustained unified-memory pressure by panicking rather than reporting an out-of-memory error.

Do I have to pick the model myself?

No. curl -fsSL https://rapidmlx.com/install.sh | bash reads your Mac's memory and prints the right serve line, including any flags that tier needs. The desktop app shows the same pick, from the same table.

Which model should I use for coding agents?

Not the 8 GB pick. Claude Code, Codex and Aider need a model that can hold a plan and edit files, which in practice starts at the 16 GB tier and gets comfortable from 24 GB up. Note that 2-bit quantization hits multi-turn agentic work harder than it hits chat or single-shot coding. We wrote up which coding agents actually work locally separately.