MLX Model Coverage on Apple Silicon (July 2026): What Actually Exists and What's Missing

Bottom Line (July 2026)

• MLX is Apple’s array framework, and models converted to MLX format run faster than the equivalent GGUF on Apple Silicon. Ollama measured roughly 1.6x prefill and close to 2x decode on its MLX path.
• Coverage is not uniform. Qwen 3.5/3.6 is fully converted at 4bit and 8bit. Gemma 4 has conversions published but broken across quants. Laguna XS 2.1 is converted but mlx-lm does not recognize the architecture.
• The “8bit Gemma 4 doesn’t work” report is real and documented. The cause is a quantization-metadata mismatch in the QAT checkpoints plus a new gemma4_unified architecture loaders did not support.
• Ollama’s MLX preview needs more than 32GB of unified memory and started with a single model family. That is Ollama’s shipping decision, not an MLX limit.
• Under 32GB, get MLX elsewhere: LM Studio’s MLX engine, oMLX, or mlx_lm directly.
• When in doubt, use GGUF. A model that loads correctly beats a faster one that does not load.

Everything below is split into verified (we read the upstream repo, issue, or vendor post) and community-reported (users say it, we have not reproduced it). MLX build availability changes weekly; this was checked in July 2026.

What MLX Actually Is

MLX is Apple’s open-source array framework, built for the unified-memory design of M-series chips. It is not a model format in the way GGUF is a model format — it is the compute layer, and “an MLX model” means a set of weights converted into the layout MLX expects.

Those conversions mostly come from one place: the mlx-community organization on Hugging Face, which republishes upstream models in MLX format at various quantization levels. A repo name like mlx-community/Qwen3.6-35B-A3B-8bit tells you the source model and the quant in one string.

The runtimes that consume them:

• mlx_lm — the reference command-line and Python path from the MLX team. Fastest to get new features, strictest about architecture support.
• LM Studio’s MLX engine — the easiest GUI route on a Mac.
• oMLX — a community server that fills gaps mlx-lm has not covered yet, including some architectures mlx-lm refuses.
• Ollama — added an MLX backend in preview, covered below.

The important consequence: a conversion existing on Hugging Face does not mean your runtime can load it. Those are two separate gates, and most of the frustration in this space comes from confusing them.

The Coverage Table

Status as of July 2026. This changes weekly — treat it as a starting point, not a permanent answer.

The Gemma 4 Problem, Explained

This is the one people keep hitting, so it is worth being precise. The comment we saw — “Gemma 4 in 8bit doesn’t work with mlx yet, only the 4bit ones work” — is directionally right, and the underlying cause is more interesting than a missing conversion.

Two things are going wrong at once.

1. The architecture was new. Gemma 4 introduced a unified architecture using Per-Layer Embeddings, and MLX loaders did not recognize it. The symptom is a hard failure at load: Unsupported model type: gemma4_unified. This has been filed against mlx-lm, against LM Studio, and against Ollama’s MLX runner independently.

2. The quantization metadata lies. The Gemma 4 QAT checkpoints pack attention at 4-bit and the MLP at 8-bit, but the container declares a single global quant type. A loader that trusts the metadata reads the 8-bit MLP as 4-bit and the matmul produces nonsense. On top of that, the PLE architecture uses ScaledLinear layers that multiply outputs by a scalar — so any quantization error introduced there gets amplified rather than averaged away.

That second point is why “just use the 4bit one” is not a clean answer either. The 4-bit builds load more often, but there are upstream reports of tool calls failing on gemma-4-26b-a4b-it-4bit and load errors on the small gemma-4-e4b-it-4bit. Community-reported, and consistent with the same root cause.

There is at least one community effort (FakeRocket543/mlx-gemma4) publishing PLE-safe quantizations specifically to work around this. If you need Gemma 4 on MLX today, that is the direction to look — but it is a third-party fix, not an official one, and you should validate output quality yourself before trusting it in a loop.

Ollama’s MLX Situation

Ollama shipped MLX support as a preview in 0.19. Two things about it surprise people.

It requires more than 32GB of unified memory. That is Ollama’s stated requirement for the preview. It is not an MLX restriction — MLX runs fine on a 16GB Mac through other runtimes — but it is a real gate if you are going through Ollama.

Coverage started at one model. The MLX backend launched covering Qwen3.5-35B-A3B, which is exactly the second comment we saw: “the only MLX model for Ollama needs more than 32GB of RAM. I want smaller models with MLX.” That is an accurate description of the preview. Ollama 0.20, in development, adds Gemma 4 to the MLX backend — which, given the section above, will be interesting to watch.

If you run Llama 4, Mistral, or Phi through Ollama, the MLX path currently does nothing for you.

Under 32GB, or on a model Ollama’s MLX backend does not cover, go around Ollama. LM Studio’s MLX engine, oMLX, and mlx_lm all run MLX weights without Ollama’s memory gate. You lose Ollama’s model management; you gain access to the actual coverage that exists on mlx-community.

One caveat worth flagging: there are community reports of oMLX running out of memory during prefill on 24-32GB Macs even when the weights themselves fit comfortably. Prefill on a long prompt allocates well beyond the weight footprint. If you are near the line, cap your context before you blame the model. Same failure mode we cover in OpenClaw out of memory.

When to Just Use GGUF

This is the practical takeaway, and it is unglamorous.

MLX gives you roughly 1.6x prefill and 2x decode when it works. That is a real, significant win. But it is a win on top of a model that loads and produces correct output. If the MLX build of the model you want is missing, broken, or unsupported by your runtime, the GGUF is not the compromise — it is the working option.

Use GGUF when:

• The model has no mlx-community conversion, or only a conversion your runtime cannot load (Laguna XS 2.1 under mlx-lm today).
• The MLX build has open breakage reports for your quant (Gemma 4, most quants, right now).
• You need tool calling to be reliable. Tool-call correctness is the first thing that breaks in a bad conversion, and it is the thing agent loops depend on entirely. See local LLM tool calling reliability.
• You are under 32GB and want to stay inside Ollama’s model management.

Use MLX when the model is in the verified-green part of the table — which today means the Qwen 3.5/3.6 family above all else. If you want MLX speed and you are flexible on model, that is the path with the least friction.

How to Check Coverage Yourself

Since this changes weekly, the durable skill is checking rather than trusting a table:

1. Search the mlx-community organization on Hugging Face for your model name.
2. Read the quant suffix in the repo name: 4bit, 6bit, 8bit, bf16, plus variants like DWQ (distilled weight quantization) and OptiQ (mixed per-layer bit-widths from a sensitivity pass).
3. Open the Discussions tab before you download. Broken conversions get reported there within days of publishing. The Gemma 4 8bit breakage was visible in discussions long before it was fixed anywhere.
4. Check your runtime separately. Search the mlx-lm and LM Studio issue trackers for the architecture name. A conversion existing and your runtime supporting it are different questions.
5. Validate with a tool call, not a chat turn. A broken quant often produces plausible prose and malformed JSON.

Related Guides

• Ollama faster on Mac: the MLX tag you are probably missing — the speed numbers, measured on an M3
• Best local LLMs for 32GB RAM and 24GB RAM — the tiers below Ollama’s MLX gate
• Qwen 3.6 vs Gemma 4 for agentic work — the model comparison behind the coverage question
• OpenClaw Gemma 4 setup — running Gemma 4 the way that currently works
• Local LLM tool calling reliability — why a bad quant shows up as broken JSON first
• Ollama vs LM Studio — picking the runtime that actually loads your model