🍎 Local LLMs on Apple Silicon: Unified Memory Wins

I have spent enough on GPUs to be defensive about the subject, so it is uncomfortable to admit that the most capable local-inference machine in my house has no discrete graphics card in it at all. Not the fastest. The most capable, which is a different measurement and the one that decides what you can run.

By the numbers#

• Unified memory means a 64GB Mac loads models a 24GB RTX 4090 cannot hold, full stop
• MLX runs roughly 10-30% faster than llama.cpp on supported models, reported around 30-40% on M5
• Ollama 0.19 (March 31, 2026) added a native MLX runner on Apple Silicon — it is no longer a llama.cpp wrapper on a modern Mac
• Practical RAM tiers: 16GB for 7B-class, 32GB as a working floor, 64GB where the capacity advantage bites

Capacity beats bandwidth more often than benchmarks suggest#

Here is the thing benchmark charts systematically undersell. A 4090 will generate tokens faster than an M-series Mac on any model both can load. That last clause is doing enormous work. On my rig, the question I actually run into is not "how fast does this 7B model go", it is "can this machine hold a 70B model at all". Bandwidth decides how fast you go; memory capacity decides whether you go.

Apple Silicon wins that second question at a price no consumer GPU matches, because the CPU and GPU share one memory pool rather than the GPU getting a walled-off 24GB. That is the entire architectural argument, and it is why the GPU buying guide advice about VRAM ceilings needs a Mac-shaped asterisk attached to it.

So what: if your ceiling problem is model size rather than tokens per second, a Mac is the cheaper answer.

The advice that went stale in March#

For years the correct guidance was: Ollama is convenient but it wraps llama.cpp, so you pay a real speed penalty on Apple Silicon versus running MLX directly. Plenty of guides still say exactly that, and as of Ollama 0.19 it is wrong. Ollama now ships a native MLX runner on Apple Silicon, tapping the same Apple framework MLX-LM uses.

That collapses the old trade-off. You previously chose between convenience and speed; now, for most models, convenience costs you very little. This is a good reminder that in local AI a guide's publication date is part of its accuracy, and it is why I re-check runtime claims rather than repeating them from memory.

When MLX directly is still worth it#

Two cases. First, maximum throughput on a supported model, where running MLX-LM without a layer on top still measures ahead. Second, fine-tuning, where you want the framework's own tooling rather than an inference-focused wrapper.

The honest caveat: standalone MLX has a steep learning curve and assumes you are comfortable in Python and a terminal. It is a developer's tool. If that describes you, the speed is there. If it does not, you will spend the difference in frustration and get a slower result overall because you will use it less.

LM Studio remains the answer for a GUI, with the model browser showing each quant against your available memory before you commit to a download, which on a machine where memory is shared with everything else is more useful than it sounds. The Ollama versus LM Studio comparison covers that split in more detail.

So what: default to Ollama, reach for MLX-LM only for peak speed or fine-tuning, use LM Studio if you want to see what fits before downloading.

What the unified-memory pitch leaves out#

Shared memory cuts both ways. Everything else on the machine eats from the same pool, so a 32GB Mac is not offering 32GB to your model. The OS, the browser with forty tabs, and whatever else is resident all take their cut first, and the practical headroom is well under the number on the spec sheet. Quantisation is how you claw that back, and the quantisation explainer covers which levels actually cost you quality rather than just file size.

There is also a thermal reality on laptops that desktop benchmarks never show. Sustained inference on a fanless or lightly-cooled Mac throttles, so the tokens-per-second you measure in the first thirty seconds is not the number you get twenty minutes into a long job.

The numbers I would actually check first#

Before spending anything, run the model you care about on the machine you already own and write down three figures: tokens per second on a short prompt, tokens per second twenty minutes in, and peak memory while it runs. The first tells you whether the machine is fast enough. The second tells you whether it throttles. The third tells you how much headroom you have before the next model size up stops fitting.

That third number is the one people skip, and it is the one that decides your upgrade. Memory pressure on a shared pool shows up as swapping long before it shows up as an error, so a model that technically loads can still make the whole machine miserable. Watch the memory-pressure graph rather than the free-memory figure, because macOS will report memory as used that it would happily reclaim.

One more thing worth knowing: quantisation levels behave slightly differently between runtimes, so a quant that runs well under one stack is not guaranteed to behave identically under another. If you switch from Ollama to MLX-LM for speed, re-check output quality on your own prompts rather than assuming the model is the same model.

So what: measure sustained speed and peak memory before you buy anything, rather than first-token speed alone.

Where I land#

If you already own an M-series Mac with 32GB or more, stop shopping for a GPU and start running models on the machine you have. Install Ollama, pull something in the 7B to 14B range, and see whether the speed is genuinely limiting before you spend money. If your work has you loading large models rather than chasing peak throughput, a used 3090's 24GB does not compete with 64GB of unified memory at any price I have found.