Ollama Is 2x Faster on Mac: The Version and Settings That Do It

Your Mac is running Ollama at about half the speed it can. Not because of the model you picked, and not because you need more RAM. The speed is sitting in a version number and a model tag you probably never pulled.

The change that caused it is documented. Ollama 0.19, previewed on March 30, 2026, rebuilt the Apple Silicon path on Apple’s MLX framework instead of the older llama.cpp backend. On Ollama’s own bench the decode rate went from 58 tokens per second to 112.

Where the 2x actually comes from

Ollama published the numbers in the MLX preview post, tested March 29, 2026 on Qwen3.5-35B-A3B:

Decode is the number you feel. It is the rate text appears after the model starts answering. It roughly doubled on the same hardware with no config change other than the version and the model variant.

Two things about that table matter more than the headline:

1. The two rows are not the same quantization. 0.18 ran q4_K_M, 0.19 ran NVFP4. Part of the gain is the engine, part is the format. Ollama’s June 11, 2026 follow-up separates them: on the updated engine, NVFP4 generates about 20% faster than q4_K_M, and the engine optimizations themselves added up to 20% on top. So the format is a real slice of the win, not the whole thing.
2. The benchmark ran on M5-class silicon. M5, M5 Pro and M5 Max have Neural Accelerators in every GPU core, and MLX uses them. Older M-series chips still gain, but do not expect this exact table on an M1.

Lever 1: get on a version that has the MLX engine

Check what you are running:

ollama --version

Anything below 0.19 is on the old Apple path and cannot reach these numbers. Current releases are in the 0.32 line as of August 2026. Upgrading is worth it beyond raw speed: Ollama v0.32.6, August 4, 2026, added another Apple-specific win. The release note is one sentence: “Qwen3.5 is faster on Apple GPUs: the MLX engine now uses the model’s MTP head for speculative decoding automatically.”

Multi-token prediction means the model drafts several tokens per step instead of one, then verifies them. You get the gain by updating, not by configuring anything. Ollama did not publish a percentage for it, so treat the size of that second bump as unquantified.

Lever 2: pull the MLX variant, not the default tag

This is the part most people miss. Being on a new Ollama does not put your existing models on the fast path. The variant you pulled decides the backend.

Look for a tag with an MLX-native format in it: nvfp4, mxfp8, or an mlx-bf16 build. A plain q4_K_M tag is a GGUF build and runs the older way.

Discovery is genuinely awkward right now. Ollama’s search does not surface MLX variants well, so the reliable route is the model page on ollama.com and the MLX blog posts rather than ollama run autocomplete.

Once a model is loaded, confirm what you got:

ollama run <model> --verbose

The tokens-per-second line at the end of a response is the truth. If it reads roughly half of what Ollama’s post shows for comparable hardware, you are still on the old path.

Lever 3: fix the context length, which is the quiet killer

Ollama sets context length from available VRAM, and the documented defaults are:

Both ends of that table cause problems. On a 16GB Mac, 4k is too small for coding agents and web search, and the model silently drops history. Ollama’s own guidance says agent and coding workloads want at least 64,000 tokens. On a big Mac, a 256k default reserves cache you are not using, which crowds out the weights.

Set it deliberately:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Then check the allocation is what you asked for and the model is fully on the GPU:

ollama ps

Read the PROCESSOR column. Anything less than 100% GPU means part of the model is running on CPU, and no amount of engine tuning recovers that. Shrinking the context until it fits entirely is faster than a bigger window that spills. More on that failure mode in context window traps for local agents.

Lever 4: flash attention and a quantized KV cache

These two settings are documented in the Ollama FAQ and work together.

Flash attention cuts memory growth as context grows. Ollama enables it automatically when the backend and device support it. To force it:

OLLAMA_FLASH_ATTENTION=1

With flash attention on, you can quantize the key/value cache. The default is f16. Ollama documents q8_0 as using about half the memory of f16 with “a very small loss in precision” that “usually has no noticeable impact on the model’s quality.”

OLLAMA_KV_CACHE_TYPE=q8_0

Note what this does and does not do. It buys memory, not arithmetic speed. The reason it shows up in a speed guide is second order: cache memory you free is memory the weights can use, which is what keeps ollama ps reading 100% GPU. It is also a global setting, so it applies to every model you run. We compare the tradeoff at each level in KV cache quantization: q8 vs q4.

Lever 5: stop paying the reload tax

If your Mac feels fast in a session and slow when you come back to it, you are measuring model loading, not inference. Ollama unloads idle models. Keep one resident:

OLLAMA_KEEP_ALIVE=-1

Any negative value keeps the model in memory indefinitely. 0 unloads immediately after each response. You can also send keep_alive per request through /api/generate and /api/chat, and the request parameter overrides the server variable.

For an always-on local agent, pinning one model is the difference between a 200ms first token and a 15 second cold start, every single time you switch tasks.

The 10-minute pass

1. ollama --version. Below 0.19 means you are on the old Apple engine. Update.
2. Repull your main model as an MLX variant (nvfp4, mxfp8, or mlx-bf16).
3. ollama run <model> --verbose and write down the tokens per second. This is your before-and-after number.
4. Start the server with OLLAMA_CONTEXT_LENGTH=64000, plus OLLAMA_FLASH_ATTENTION=1 and OLLAMA_KV_CACHE_TYPE=q8_0 if memory is tight.
5. ollama ps. If PROCESSOR is not 100% GPU, lower the context until it is.
6. OLLAMA_KEEP_ALIVE=-1 if you use the model all day.

Do those and the same Mac does roughly twice the work. The 2x is the engine and the model format. The rest of the list is what stops you from giving it back.

What this does not fix

Long context is memory-bandwidth-bound. When the window is genuinely full, decode falls off hard regardless of backend, and no environment variable saves you. That is physics on unified memory, not a misconfiguration.

If you are choosing between backends rather than tuning one, see MLX vs llama.cpp on Apple Silicon and Ollama vs llama.cpp. If you are sizing a machine, the best local LLMs for a 128GB Mac is the tier where these numbers stop being theoretical.

I help teams get more out of local and cloud AI setups without overpaying for either. Book a call at cloudyeti.io/meet.