Short answer: llama.cpp does not support MLX, has never supported MLX, and there is no open work to make it. Apple Silicon in llama.cpp is served by the GGML Metal backend, which is a different thing that people reasonably confuse with MLX.
Ollama, separately, does support MLX, on macOS, and has since March 2026. Those two answers get tangled because Ollama bundles llama.cpp, so “Ollama supports MLX” and “llama.cpp supports MLX” sound like the same sentence. They are not.
The maintainer’s reasoning
The canonical answer sits in llama.cpp Discussion #4345, opened on 6 December 2023, four days after MLX was released. Maintainer slaren:
> “This seems to be like Apple’s equivalent of pytorch, and it is too high level for what we need in ggml. However, the source code has a Metal backend, and we may be able to use it to learn how to better optimize our Metal kernels.”
That is a rejection on architectural grounds, and it is worth reading precisely. MLX is a framework: array operations, autograd, a whole programming model. GGML wants a backend: something that hands it kernels for a device. Adopting MLX would mean putting a framework underneath a framework. What slaren left the door open to was borrowing MLX’s Metal kernel *ideas*, not depending on MLX itself.
We searched every llama.cpp issue and pull request with MLX in the title. Nine results, all time. Every one is about either conversion (convert_hf_to_gguf.py choking on MLX-fused checkpoints, GGUF to MLX and back) or performance comparison. Not one is a proposal to adopt MLX as a backend. There is no newer maintainer statement than slaren’s, because the question was settled the first time it was asked.
So when you search “does llama.cpp support mlx” and find nothing definitive, that is not because the answer is hidden. It is because the answer is a three-year-old comment in a discussion thread that nobody wrote an article about.
Why the question keeps coming back
Because the performance gap is real, and Mac users can feel it.
Issue #19366, 5 February 2026, reported llama.cpp running at roughly one third of MLX’s token generation on Qwen3-Coder-Next on an M4 Pro. The gap is worst on hybrid and linear-attention architectures, where MLX’s kernels are simply further along.
That issue was closed by the stale bot on 24 March 2026 with no maintainer response. Which tells you the state of play honestly: the gap is acknowledged by users, unaddressed in that thread, and not being closed by adopting MLX.
Ollama’s published figures for its MLX engine point the same direction. Qwen3.5-35B-A3B on an M5: decode from 58 to 112 tok/s, prefill from 1154 to 1810 tok/s. On M5 and later, MLX also uses the GPU Neural Accelerators, which llama.cpp’s Metal backend does not.
We have not measured any of these ourselves. They are the vendors’ and reporters’ numbers, and we flag them as such. Our own Apple Silicon figures, taken on studio hardware, sit in local LLM benchmarks on an M4 Pro.
What Ollama actually did
Ollama shipped the MLX engine “in preview” in v0.19.0 on 27 March 2026, with a launch post on 30 March advising “a Mac with more than 32GB of unified memory.”
Then it did something that confuses the picture further. In v0.30.0 on 13 May, it reintroduced llama.cpp *alongside* MLX: “improved compatibility and performance using llama.cpp. This augments the MLX engine on Apple Silicon, bringing support to a wider range of hardware.”
So a current Ollama on a Mac has two engines, and which one serves your request depends on the model. That is the actual source of most confusion in this area, and it is why “does Ollama use MLX” has no clean yes or no.
Two things we could not confirm, and will not assert:
- Whether MLX is formally out of preview. “Preview” is the last official label, from v0.19.0. The June performance post drops the word but never declares general availability.
- The 32GB switchover rule. Third-party posts claim that below 32GB you automatically get llama.cpp Metal instead of MLX. That does not appear in the v0.30.0 release notes or in Ollama’s own GPU documentation, which mentions Metal and says nothing about MLX. Treat it as folklore until someone documents it.
Choosing between them, on a Mac
This is the decision that matters, and it is not close once you name your priority.
Pick MLX when you want speed and the newest formats. It is faster on Apple Silicon, materially so on recent architectures. It is where NVFP4 lives in Ollama. See NVFP4 on Apple Silicon, where the format is macOS-only precisely because it arrived through MLX. It is also where MTP speculative decoding lives.
Pick llama.cpp Metal when you want breadth. We take the two apart kernel by kernel in MLX vs llama.cpp vs MetalRT. The entire GGUF ecosystem on Hugging Face. Every quantization scheme, including imatrix quants and the whole q*_K family. Partial offload. Mature feature coverage. And it runs on everything: Mac, Windows, Linux, CUDA, ROCm, Vulkan, bare CPU. If you want one stack that behaves the same on your Mac and your Linux box, this is it.
The MLX costs are specific and worth knowing before you commit:
- Apple only. No portability at all.
- Safetensors, not GGUF. A different distribution universe.
- Thinner surface. No vision on the coding NVFP4 tags. Structured outputs via
formatwere being silently ignored on the MLX engine as recently as Ollama issue #17013 on 2 July 2026, a failure mode that is worse than an error, because your schema is dropped without complaint.
The short version
- llama.cpp: no MLX support, by design. slaren, December 2023: too high level for GGML. Nine MLX-titled issues in the repo, none proposing a backend.
- llama.cpp on Apple Silicon uses the GGML Metal backend. That is what people mean when they think llama.cpp “supports MLX”. It does not.
- Ollama: yes, MLX on macOS since v0.19.0 (27 March 2026), still labelled preview as of its last official mention, running *alongside* llama.cpp since v0.30.0.
- The performance gap that drives the question is real and documented at roughly 3x on some architectures, and it is not being closed by adopting MLX.
- MLX for speed and new formats. llama.cpp Metal for breadth, portability and the GGUF ecosystem.