Ollama’s Gemma 4 Runs Nearly 90% Faster in One Mac Coding Test

Ollama’s MLX engine has moved beyond its initial Apple Silicon preview, adding broader model support and several layers of performance work. Its largest later published gain is for Gemma 4: the June 29 Gemma benchmark says Ollama 0.31 generated tokens nearly 90% faster on average with Gemma 4 12B in the Aider polyglot coding-agent test, using NVFP4 on an M5 Max.

The original proposition remains valid: MLX gives Ollama a native execution path designed for Apple Silicon, while quantization and caching can reduce memory traffic and repeated prompt processing. What changed is the scope of the evidence. The strongest result now comes from a model-specific speculative-generation feature, not from a universal acceleration that applies equally to every Mac, model or prompt.

The original MLX release had narrow boundaries

Ollama’s first MLX release was a focused preview built around one Qwen model rather than a wholesale migration of every workload. The March 30 preview details identify Qwen3.5-35B-A3B as the featured model, compare an NVFP4 package against Ollama 0.18 running Q4_K_M, require more than 32GB of unified memory, and list projected int4 performance of 1,851 tokens per second for prefill and 134 for decoding in Ollama 0.19.

Those figures belong to complete test configurations: model, quantization, software path and Apple hardware. They cannot establish that MLX alone produced every part of the difference, nor do they promise the same rate for smaller chips, longer contexts or unrelated architectures.

The preview nevertheless introduced three consequential changes. Ollama could run supported models through Apple’s MLX framework, load weights represented in NVFP4, and preserve selected cache states for reuse when requests shared prompt prefixes. Each addresses a different constraint: computation, weight storage and repeated context processing.

Later engine work improved more than raw decoding

Subsequent changes refined the shared MLX engine before the Gemma-specific acceleration arrived. According to Ollama’s June 11 engine results, fused Metal kernels and revised GPU-backed sampling made output up to 20% faster; in an average of 10 runs with an 8,300-token input, NVFP4 generated about 20% faster than Q4_K_M.

The same comparison found that model-optimized NVFP4 roughly halved the perplexity loss of Q4_K_M for Gemma 4 12B when both quantized representations were evaluated against unquantized BF16 weights. That is evidence about one quality metric for one model. It does not demonstrate equivalence to full precision in factual accuracy, reasoning reliability or coding correctness.

NVFP4’s name can also create the wrong impression. Although the format comes from NVIDIA’s model-optimization work, Ollama’s Mac implementation executes through an MLX and Metal-backed path on Apple Silicon. Supporting an NVIDIA-developed weight format does not place CUDA or an NVIDIA processor inside the Mac.

Why Gemma 4 gained much more in the coding test

The larger Gemma improvement comes from multi-token prediction, not simply another round of general kernel tuning. A compact draft model proposes a short continuation, and the main model verifies those proposed tokens together. When several are accepted, generation advances by more than one token during a verification round.

Code is a favorable workload because it contains repeated identifiers, closing syntax and recurring structural patterns. A coding agent also invokes the model repeatedly while inspecting files and using tools, so faster generation can affect many calls over the course of one task.

The draft length is adjusted while the model runs. Ollama tracks proposal acceptance and verification cost, reduces speculation when it stops helping, and can return to ordinary one-token decoding. This matters because an overly long rejected proposal can consume more work than it saves.

The benchmark result therefore has a precise meaning: the tested Gemma package and draft model worked particularly well on the selected coding-agent workload and machine. Less predictable prose, a different quantization, another model or another Apple chip may produce a smaller gain.

Caching targets a separate source of agent latency

Generation rate is only one component of an agent session. Each tool call may resend system instructions, tool definitions, conversation history and previously read files, forcing the model to process a long shared prefix before producing another answer.

Ollama’s snapshot system saves reusable model state at selected points, including likely branches, positions inside long prompts and the boundary before a response. A compatible later request can resume from one of those states instead of processing the entire common prefix again.

The benefit depends on actual overlap. A retry, branch or handoff may reuse substantial context, while an unrelated request cannot benefit from a different conversation’s cached state. Snapshot reuse consequently reduces prompt-processing work in suitable sessions; it does not multiply the decoding speed of every response.

What Mac users can reasonably expect

The most defensible expectation is improved performance from a supported, explicitly MLX-oriented model package on an Apple Silicon Mac with sufficient unified memory. Available memory must accommodate the weights, context cache, operating system and other applications, so fitting the model alone does not guarantee comfortable operation with a long context.

Gemma 4 is the clearest example of the newer path because its package combines the MLX engine, NVFP4 weights and a draft model for speculative generation. An older local copy must be pulled again to receive the draft-model files; updating only the Ollama application does not retroactively replace an already downloaded package.

For other models, the evidence supports a more measured conclusion. MLX-specific kernel and sampling work can accelerate decoding, NVFP4 can offer a better tested quality-versus-size trade-off than Q4_K_M, and snapshots can avoid repeated prompt processing. The nearly 90% result shows what a tightly matched model and coding workflow can achieve, not that every local LLM on every Mac is now almost twice as fast.

Also read:

• Thirteen Bullets and One Molotov Cocktail: How Anti-AI Protest Just Got Deadly Serious
• Test to Perfection: Why Quality Assurance Is So Crucial in Tech
• Mythos Just Rewrote the Rules of Cybersecurity: One AI Found 271 Firefox Vulnerabilities in a Month — More Than Human Teams Had in 18 Months