Ollama’s MLX path: preview limits, newer variants and benchmark scope

Ollama's March 2026 MLX announcement concerned a specific preview, model and test setup. It did not establish a universal performance upgrade for every model on every Mac. The distinction is important because the earlier article turned a narrow release into broad installation advice and claimed benefits that it had not measured.

There are now two records to keep separate: what the initial preview supported and what the model catalog lists at the time of this November revision. A historical restriction should not be presented as permanent, but a later catalog entry also cannot retroactively change the conditions of the March benchmark.

The preview had a narrower starting point

Ollama's March 30 announcement identified version 0.19 as a preview and highlighted Qwen3.5-35B-A3B with coding-oriented sampling parameters. Its getting-started section requested a Mac with more than 32 GB of unified memory. This is more specific than the earlier article's claim that ordinary updating made a broad range of 7B through 70B models run better through MLX.

The announcement also discussed caching improvements and NVFP4 support. Its performance comparison used Qwen3.5-35B-A3B in NVFP4 against the prior Q4_K_M implementation in Ollama 0.18. That is a comparison of stated configurations, not a controlled demonstration that the framework alone caused every difference.

Both backend implementation and representation can affect a comparison. Without holding the relevant variables constant or evaluating their effects separately, a reported speedup should retain its configuration and attribution. UnliveNews did not reproduce these benchmarks and does not present the vendor's figures as its own tests.

The catalog has subsequently expanded

At this revision, Ollama's Qwen3.5 catalog lists explicit MLX variants at multiple sizes, including 0.8B, 2B, 4B, 9B, 27B and 35B. This updates the initial single-model preview record without implying that every historical tag or every architecture uses the same execution path.

A catalog entry is evidence that a particular artifact is offered. It does not establish that a given user's installed runtime loads it successfully, that an older downloaded artifact changes format automatically or that all listed context limits fit in that user's available memory.

This is why the earlier upgrade-and-look-for-a-log-word procedure was too vague. The runtime version, exact artifact and applicable documentation matter. An unidentified environment variable or a generic instruction to redownload everything is not a verified migration procedure.

Unified memory explains architecture, not unlimited capacity

MLX's own documentation explains that Apple silicon's CPU and GPU access the same memory pool. MLX arrays do not need to be moved between separate device memory locations simply to select which device performs an operation; dependent operations still require scheduling.

That description explains an architectural property. It is not a claim that physical memory becomes larger or that every operation becomes faster. A framework can avoid a category of data movement without eliminating every allocation, temporary buffer or dependency in an application.

The original article asserted improved paging, extra usable capacity and smoother long-context behavior across many models without evidence tied to those workloads. Those assertions are removed. Neither a framework description nor one model benchmark supplies a universal guarantee about operating-system memory pressure.

Model size alone is not a complete workload description

A parameter-count label does not specify the exact representation, prompt length, concurrent requests or implementation. Two runs advertised with the same broad model family can therefore differ in ways that matter to both memory use and performance. A useful comparison records those differences rather than explaining every result with the word optimized.

Time until the first token and the rate of subsequent generation are also different measures. A change that improves prompt processing need not produce the same proportional change during decoding. An interactive workload and a long batch can weight those stages differently.

The earlier article's hardware shopping tiers, expected double-digit gains, battery-life implications and broad model-quality rankings did not follow from the cited records. They are removed rather than converted into unsupported advice for another generation of Mac.

Local execution is a property of the actual workflow

The original Ars Technica report described the initial preview and the interest in local inference. Running a model on a local machine can change where that model's computation occurs. It does not establish that every connected agent, browser action, tool call, log destination or application stays on that machine.

This distinction avoids turning a runtime choice into an automatic privacy or compliance certification. It also avoids implying that enabling broad agent permissions is necessary to demonstrate the backend's value.

The supported conclusion is specific: Ollama introduced an MLX preview with identified starting conditions, and its catalog now offers additional named variants. Performance and suitability remain questions about the actual configuration and workload. The corrected article preserves that progress without inventing personal benchmark results, universal memory headroom or an installation procedure that was never verified.