TL;DR: Ollama 0.19 (March 2026) swapped its Apple Silicon path from Metal to Apple’s MLX framework, roughly doubling decode speed on M-series Macs. The catch: the MLX backend wants 32GB+ of unified memory, and during the preview it’s opt-in via an environment variable. Below: how to turn it on, confirm it’s actually running, and what speedup to expect.

What you’ll have running after this guide:

• Ollama using the MLX backend instead of Metal, verified from the server logs
• A persistent config so MLX stays on across reboots and app restarts
• A repeatable way to benchmark prefill and decode speed before and after

Honest take: If you have a 32GB+ M-series Mac, this is free performance — flip one switch and decode speed nearly doubles. If you’re on 8GB or 16GB, leave it alone; Metal is still your default and MLX won’t load anyway.

What changed in Ollama 0.19

Before March 2026, Ollama ran on Apple Silicon through llama.cpp’s Metal backend — GPU compute that worked but never fully tapped what the M-series chips can do. Ollama 0.19 replaced that path with MLX, Apple’s open-source array framework built specifically for unified memory.

The difference is architectural. On a discrete GPU, weights live in VRAM and the CPU shuffles data across PCIe. Apple Silicon shares one memory pool between CPU and GPU cores, so the moment you stop copying tensors between separate pools, you reclaim a lot of wasted bandwidth. MLX is designed around that single pool from the ground up; Metal was not.

Linux and Windows are unaffected — they still run on llama.cpp. This is an Apple Silicon-only change. Ollama itself stays MIT-licensed, and MLX is MIT-licensed by Apple, so nothing about your licensing situation changes.

One more piece landed alongside it: NVFP4, NVIDIA’s 4-bit floating-point quantization format. On the MLX path Ollama can serve NVFP4 weights, which hold accuracy better than older 4-bit integer schemes at a similar memory footprint. More on quant formats in our GGUF quantization guide.

The hardware requirement nobody mentions up front

The MLX backend has a hard floor: more than 32GB of unified memory. This is the single most common reason people enable it and see nothing happen.

	MLX backend	Metal backend
Minimum unified memory	32GB (48GB+ recommended)	8GB
Best chips	M5 / M5 Pro / M5 Max	Any M-series
Decode speed (relative)	~2x	baseline
Default in preview	No (opt-in)	Yes
Platforms	Apple Silicon only	Apple Silicon

A 32GB machine technically qualifies but is tight: a 35B-class model in 4-bit eats roughly 20GB, leaving about 12GB for the KV cache. That’s fine for short chats and uncomfortable for long-context work — bump to 48GB or 64GB if you push past a few thousand tokens per conversation.

Macs with 8GB or 16GB don’t get the MLX runner at all. They keep running on Metal, which is the correct default for that memory tier. M1 through M4 chips with enough memory still benefit from the unified-memory optimizations, but the largest gains come on M5, M5 Pro, and M5 Max, which expose dedicated GPU Neural Accelerators that MLX can reach and Metal’s higher-level API can’t.

If you’re still deciding which Mac to buy for local inference, runaihome.com’s breakdown of what 2x MLX inference means for M-series buyers covers the memory-tier tradeoffs in hardware terms.

Step 1: Update Ollama

MLX shipped in 0.19. Anything newer includes it — these examples were run on a current 0.30.x build. Check your version first:

$ ollama --version
ollama version is 0.30.6

If you’re on anything below 0.19, update. The cleanest path on macOS is to grab the latest build from ollama.com/download, or via Homebrew:

brew upgrade ollama

Quit the menu-bar app fully before upgrading — a stale background process will keep serving the old binary and you’ll wonder why nothing changed.

Step 2: Turn on the MLX backend

During the preview, MLX is opt-in. You enable it with an environment variable before the server starts. For a one-off terminal session:

export OLLAMA_USE_MLX=1
ollama serve

To make it stick across reboots, add it to your shell profile:

echo 'export OLLAMA_USE_MLX=1' >> ~/.zshrc
source ~/.zshrc

If you run Ollama as the macOS menu-bar app rather than from a terminal, the ollama serve you start by hand won’t be the process answering requests — the app is. Set the variable so the app inherits it by launching the app from a shell that already has it exported, or set it system-wide:

launchctl setenv OLLAMA_USE_MLX 1

Then quit and reopen the Ollama app so it picks up the new environment.

Why this matters: the env var only affects the process that reads it. Exporting it in your shell does nothing for the menu-bar app, which is a separate process tree. This mismatch is the #1 reason the toggle “doesn’t work.”

Step 3: Verify MLX is actually running

Don’t trust that it worked — confirm it. Start the server in the foreground and watch the startup logs while you load a model:

$ OLLAMA_USE_MLX=1 ollama serve
...
msg="starting llm server" backend=mlx

A backend=mlx line (versus backend=metal) is the signal. Load a model in another terminal to force the runner to spin up:

$ ollama run qwen3:32b "say hi"

Back in the server log you should see the MLX runner initialize and report the model loaded into unified memory. If it silently falls back to Metal, that’s almost always the 32GB requirement — the runner checks available memory and declines if there isn’t enough headroom.

Step 4: Benchmark it yourself

The published figures are real, but numbers from your own machine are the only ones that matter. Use Ollama’s --verbose flag to get eval-rate (decode) and prompt-eval-rate (prefill) per request:

$ ollama run qwen3:32b --verbose "Write a haiku about unified memory."
...
total duration:       2.41s
prompt eval rate:     1810.42 tokens/s
eval rate:            112.30 tokens/s

Run the same prompt with OLLAMA_USE_MLX unset to get your Metal baseline, then compare. For reference, here is what Ollama reported on an M5 Max running Qwen3.5-35B-A3B:

Metric	Metal (before)	MLX (after)
Prefill (NVFP4)	1,154 tok/s	1,810 tok/s
Decode (NVFP4)	58 tok/s	112 tok/s
Decode (int4)	—	134 tok/s

That’s roughly 1.6x on prefill and close to 2x on decode — the kind of gain you usually only get by buying a faster chip. Later 0.x releases added kernel fusion through MLX’s just-in-time compiler and reworked GPU sampling for up to another 20% on top.

The problem I actually hit: MLX “on” but speed unchanged

First attempt, I set export OLLAMA_USE_MLX=1 in .zshrc, opened the menu-bar app, and benchmarked. No change. Decode rate was identical to Metal.

The cause: the app wasn’t reading my shell’s environment. My ollama serve and the app were two different processes, and ollama run was talking to the app’s server, not mine. The fix was either of two things:

1. Kill the app entirely and run everything from one terminal that has the variable exported, or
2. launchctl setenv OLLAMA_USE_MLX 1, then fully quit and relaunch the app.

After that, the server log showed backend=mlx and decode jumped from 60 to 110+ tok/s on the same model. The lesson: always verify with the log line, never assume the variable propagated.

The second gotcha was memory. On a 32GB machine, loading a 32B model plus a long system prompt pushed the KV cache against the ceiling and the runner fell back to Metal mid-session. Dropping to a smaller model or shorter context kept it on MLX. If you live in long-context territory, 48GB+ isn’t optional.

When NOT to bother with MLX

• You have 16GB or less. The backend won’t load. Stay on Metal — it’s the right default for your tier, and there’s nothing to fix. Our Ollama review covers what runs well on smaller Macs.
• You only run tiny models (1B–3B). At that size you’re rarely memory-bandwidth bound, so the MLX speedup is marginal. The gains scale with model size.
• You need production stability today. It’s labeled preview for a reason. For a server that other people depend on, wait for the non-preview release or run Linux + a discrete GPU. If you’re comparing local against cloud for heavy batch jobs, renting time on RunPod is still cheaper than a 64GB Mac for bursty workloads.
• You’re cross-platform. If your workflow has to match Linux/Windows behavior exactly, the backend difference can produce slightly different timing and memory characteristics worth accounting for.

For the GUI-first crowd who’d rather not touch environment variables at all, LM Studio ships its own MLX engine with a checkbox toggle — worth a look if the terminal isn’t your thing.

FAQ

Is MLX on by default in Ollama yet? During the preview it’s opt-in via OLLAMA_USE_MLX=1. Apple Silicon Macs without the variable set continue on the Metal backend. The full release is expected to make MLX the default on eligible hardware.

Does MLX work on M1 / M2 / M3 / M4? Those chips still get unified-memory optimizations, but you need 32GB+ for the MLX runner to load, and the largest speedups (via GPU Neural Accelerators) are specific to the M5 generation. M1–M4 see a smaller bump than M5.

What is NVFP4 and should I use it? NVFP4 is NVIDIA’s 4-bit floating-point format. On the MLX path it tends to preserve accuracy better than older 4-bit integer quantization at a comparable size. If a model is offered in NVFP4, it’s a reasonable default on a 32GB+ Mac.

Will MLX change my output quality? The backend changes how inference is computed, not the weights. Quality should match the same quantization on Metal; what changes is speed and memory efficiency.

My speed didn’t change after enabling it — why? Two usual suspects: the env var didn’t reach the process actually serving requests (common with the menu-bar app), or you’re under 32GB and the runner fell back to Metal. Check the server log for backend=mlx to confirm.

Sources

• Ollama Blog — Ollama is now powered by MLX on Apple Silicon (preview)
• Ollama Blog — Ollama’s highest performance on Apple Silicon yet with MLX
• Ollama v0.19.0 Release Notes (GitHub)
• MacRumors — Ollama Now Runs Faster on Macs Thanks to Apple’s MLX Framework
• AppleInsider — Ollama is supercharged by MLX’s unified memory use on Apple Silicon
• MLX framework (GitHub, Apple)