Is MLX faster than llama.cpp on Apple Silicon?

Usually yes on M4 and M5 Macs. Independent benchmarks show MLX about 1.4x to 1.8x faster than raw llama.cpp Metal at decode, and about 3x faster than default Ollama before the MLX switch. On older M1 Macs with long prompts, llama.cpp GGUF can still win.

Why did Ollama switch to MLX?

Ollama v0.19.0 (late March 2026) added an MLX engine in preview for Apple Silicon. Ollama reported +93% decode speed and +57% prefill on Qwen3.5-35B-A3B versus its previous engine. The MLX path is tuned for the GPU Neural Accelerators in M5-series chips.

Does MLX use less memory than GGUF?

Yes, in measured cases. A 30B-class model used 34.7GB in MLX versus 40GB as GGUF, and a 235B-class model used 124GB versus 133GB. That difference can decide whether a model fits your unified memory at all.

← All guides

Guide August 15, 2026

MLX vs llama.cpp on Apple Silicon: Which Is Faster in 2026?

Ollama itself switched to MLX on Apple Silicon in v0.19.0. That is the strongest signal yet: on newer Macs, MLX is now the fast path, and llama.cpp Metal is the compatibility path.

Short answer

Use MLX if:

Ready to buy? See the tested hardware list with current prices.

you run a Mac with more than 32GB unified memory
you run an M4 or M5 series chip
your model is 14B or larger
your model exists in MLX/safetensors format

Use llama.cpp (Metal) if:

you run an M1 or M2 Mac
your model only exists as GGUF
you need CPU offload or fine-grained quant control
your Mac has 32GB unified memory or less

This is no longer a niche debate. Ollama itself now runs MLX on Apple Silicon.

Ollama switched to MLX in v0.19.0

In late March 2026, Ollama released v0.19.0 with this line: “Ollama is now powered by MLX on Apple Silicon in preview.” That is the project that popularized llama.cpp choosing Apple’s own framework for new Macs.

Ollama’s own preview numbers for Qwen3.5-35B-A3B (NVFP4):

Metric	Ollama 0.18 (llama.cpp)	Ollama 0.19 (MLX)	Change
Decode	58 tok/s	112 tok/s	+93%
Prefill	1,154 tok/s	1,810 tok/s	+57%

The int4 build reaches 134 tok/s decode. The preview launched with Qwen3.5-35B-A3B; Ollama says it will expand the supported list. Secondary reporting (yage.ai) lists about 6 architectures in the preview, including Gemma 3, GLM-4 MoE Lite, Llama, and Qwen 3/3.5 — that list is yage.ai’s, not Ollama’s.

Two hard limits from Ollama’s announcement:

The MLX preview requires a Mac with more than 32GB unified memory. Below that, Ollama falls back to llama.cpp Metal.
Model format decides the engine: safetensors models route to MLX, GGUF models route to llama.cpp (yage.ai’s analysis of the routing; Ollama v0.30.0 notes describe llama.cpp as augmenting the MLX engine).

Benchmarks: how big is the MLX edge?

Independent benchmarks from yage.ai on M4-class hardware:

Comparison	Result
MLX vs default Ollama (pre-0.19)	~3x (130 tok/s vs ~43 tok/s)
MLX vs raw llama.cpp Metal	~1.4–1.8x
Raw llama.cpp Metal, tuned	89.4 tok/s on the same class of model

So most of the famous “3x” gap was Ollama overhead, not llama.cpp itself. Tuned llama.cpp Metal is closer than the headlines suggest. MLX still wins at decode on modern chips.

Memory is the quieter win. Measured by yage.ai:

Model class	MLX	GGUF (llama.cpp)
30B	34.7GB	40GB
235B	124GB	133GB

On unified memory, 5GB can be the difference between a model that fits and a model that swaps. See KV cache quantization: Q8 vs Q4 VRAM for the other big memory lever.

Where llama.cpp still wins

llama.cpp is not obsolete on Macs. It wins when:

Old chips, long prompts. On an M1 Max with a 650-token prompt, GGUF via llama.cpp delivered 20 tok/s effective versus 13 tok/s for MLX (yage.ai). MLX’s advantage is tuned toward newer silicon.
GGUF-only models. Most quantized community models ship as GGUF first. If there is no MLX conversion, llama.cpp is the only path.
32GB or less. The Ollama MLX preview excludes these Macs entirely.
CPU offload. llama.cpp can split layers between GPU and CPU. See llama.cpp MoE offload flags explained.

M5 changes the math again

MLX’s gains grow on M5. yage.ai measured M5 vs M4 on Qwen3-14B-4bit under MLX:

Time to first token: 4.06x faster
Generation: 1.19x faster

Ollama states the MLX path is tuned for the GPU Neural Accelerators in M5, M5 Pro, and M5 Max. The prefill gap is the one that matters for coding agents — long project prompts hit time-to-first-token hardest. If you are choosing a Mac for this, see best local LLM for M4 Max.

 THE MLX MEMORY FLOOR

Ollama's MLX engine requires more than 32 GB unified memory. A 48 GB+ Mac clears that floor and fits 30B-class MLX models (34.7 GB measured) with room for context.

48GB+Premium Mac 48 GB+ ↗

Decision table

Your situation	Better default
M4/M5, 48GB+, model has MLX build	MLX
M5 + coding agent (long prompts)	MLX
M1/M2 Mac	llama.cpp Metal
32GB unified memory or less	llama.cpp Metal
Model only exists as GGUF	llama.cpp
Model barely fits in memory	MLX (smaller footprint)
You need CPU offload	llama.cpp

If you just use Ollama v0.19.0+, it makes most of this choice for you: safetensors goes to MLX, GGUF goes to llama.cpp, and small-memory Macs stay on llama.cpp.

How to test on your own Mac

Pull the same model in both formats (MLX safetensors and GGUF).
Run a long prompt (16K+ tokens) and record time to first token.
Run a short prompt with a 500-token answer and record decode tok/s.
Watch memory in Activity Monitor — swap kills both runtimes equally.
Keep the winner. The answer differs by chip generation and model size.

Final recommendation

On an M4 or M5 Mac with more than 32GB of memory, MLX is the correct default in 2026 — Ollama’s own switch settled the argument. On M1/M2 Macs, small-memory Macs, and GGUF-only models, llama.cpp Metal remains the right tool.

Sources:

Before you order parts, check the tested hardware list for current prices by tier.

Need OpenClaw fixed live?

Remote rescue sessions for gateway, auth, tunnel, VPS, and model access problems.

See Rescue Session