Ollama's MLX Backend Beats Metal by 93 Percent: Apple Silicon Local Inference Tested (October 2026)

Metric	Metal backend (llama.cpp)	MLX backend (Ollama 0.19)	Change
Decode speed	57.8 tok/s	111.4 tok/s	+93 percent
Prefill speed	1,154 tok/s	1,810 tok/s	+57 percent (1.6x)
Hardware tested	M4 Max, 64GB unified memory	M4 Max, 64GB unified memory	same chip
Model tested	Qwen3.5 (int4)	Qwen3.5 (int4)	same quantization
Minimum memory	Any supported Mac	32GB unified memory	hard floor

Ollama's own 0.19 changelog describes the change directly: "Ollama on Apple silicon is now built on top of Apple's machine learning framework, MLX, to take advantage of its unified memory architecture." That is a bigger statement than it looks. For most of Ollama's life on macOS, the inference path underneath its friendly CLI and REST API was a Metal backed build of llama.cpp, the same general purpose C++ engine that runs on everything from a Raspberry Pi to a server GPU. MLX is Apple's own array framework, written specifically to exploit unified memory, the architecture where the CPU, GPU, and Neural Engine all read and write the same physical RAM instead of copying data across a PCIe bus. Routing Ollama's decode and prefill through MLX instead of a generic Metal shader path is the first time the two most widely used local inference tools on Apple hardware, Ollama and native MLX, are drawing from the same low level primitives.

The release notes list real engineering behind the number, not just a flag flip: improved KV cache efficiency over the Anthropic compatible API, periodic snapshotting during prompt processing in the MLX runner, a fixed memory leak in MLX runner KV cache snapshots, and a correction to flash attention misallocation for certain model types. None of that reads like a marketing bullet. It reads like a team that shipped a new runtime and then spent the following patch cycle fixing the things a new runtime breaks.

The benchmark, and what it does not tell you yet

The 93 percent decode improvement and the 1.6x prefill improvement come from a single, specific, reproducible test: an M4 Max with 64GB of unified memory, running Qwen3.5 at int4 quantization, Metal backend at 57.8 tokens per second decode and 1,154 tokens per second prefill, MLX backend at 111.4 and 1,810 respectively. That is a real, large improvement on real hardware, and it is consistent with what our own MLX versus llama.cpp testing has shown for a while: MLX's unified memory handling has a structural advantage on Apple Silicon that a generic backend has to work much harder to approximate.

What it does not tell you is how this generalizes. One chip, one model, one quantization level is a data point, not a curve. Memory bandwidth scales the benefit on every Apple Silicon generation we have tested, and the architectural reason MLX wins on an M4 Max, cutting out the copies a non native backend pays for, holds just as true on an M3 Ultra or a base M4 Pro, so expect the relative gain to persist even as the absolute tokens per second number moves with the chip's bandwidth. What will not generalize automatically is the specific 93 percent figure for a different model, a different quantization format, or a different context length. Prefill heavy workloads, long context summarization, batch document processing, will see a different ratio than the short, decode heavy chat completion this benchmark effectively measures.

Where it quietly does not activate

Two gates sit in front of the speed up, and Ollama does not make noise when you miss either one.

The first is memory. MLX acceleration needs 32GB or more of unified memory to turn on. A base M1, M2, M3, or M4 with 8GB or 16GB keeps running the old Metal path, full stop. That floor rules out a meaningful share of the Mac mini and base MacBook Air fleet that a lot of local inference tinkering actually happens on, which narrows this release's real audience to Pro, Max, and Ultra buyers, or anyone already running MLX against vLLM for production batching where the memory floor was never the constraint.

The second is model coverage, and this is the one worth flagging loudest. As of 0.19, MLX acceleration is confirmed for Qwen3.5 only. Llama, Mistral, and other architectures are not yet supported. Critically, Ollama does not error out or warn when you load an unsupported model with the MLX backend enabled. It falls back silently to Metal, so a user who sets OLLAMA_MLX=1 and loads a Llama model gets the old performance with no indication that acceleration never engaged. If you are benchmarking your own stack after reading this, confirm the model family before trusting a before and after number, because a silent fallback will make MLX look like it did nothing when the real answer is it was never in the loop.

How to turn it on

The backend is opt in through an environment variable, not a config file setting or a flag on the model pull:

OLLAMA_MLX=1 ollama serve

This requires Ollama 0.19 or later. Restart the server with that variable set, then load a supported model as usual. There is no per model override to force MLX on an unsupported architecture, and there is currently no ollama ps style indicator that tells you which backend served a given request, so the honest answer if you want to confirm it is working is to run the same prompt with the variable set and unset and compare tokens per second directly, the same way the 93 percent figure above was produced.

When this applies to your stack

If you are running Qwen3.5 on a 32GB or larger Apple Silicon Mac for local inference today, turning on OLLAMA_MLX=1 is close to a free 93 percent decode improvement with no downside beyond a preview label, and it is worth doing this week. If your production path runs a different model family, the honest move is to wait for broader MLX coverage rather than assume the number above applies, and to keep measuring your own workload rather than taking a single vendor benchmark as your capacity plan. For teams weighing Ollama against LM Studio and native MLX LM for a client deployment, this closes a meaningful part of the performance gap that used to be the main argument for going straight to MLX LM, without giving up Ollama's simpler operational model. Benchmarking an inference stack against your actual production models and context lengths, not a vendor's best case chip and model pairing, is exactly the kind of infrastructure work Contra Collective does for clients standing up local or hybrid AI deployments.

FAQ

Does the MLX backend work on Intel Macs? No. MLX is built specifically for Apple Silicon's unified memory architecture and has no equivalent path on Intel based Macs.

Why does my benchmark not show a 93 percent improvement? The most common reason is model coverage. As of Ollama 0.19, only Qwen3.5 is confirmed to use the MLX backend, and Ollama falls back to Metal silently for unsupported models rather than erroring.

Do I need 64GB of unified memory like the benchmark used? No, the hard floor is 32GB. The benchmark machine had 64GB, but the MLX backend activates at 32GB; performance below that threshold has not been independently verified at the time of writing.

Is the MLX backend stable enough for production? Treat it as a preview. Ollama's own release notes describe the MLX implementation as still under active development, and the current patch cycle has been fixing memory leaks and misallocation bugs rather than adding new model support.