Read almost anything written about Ollama’s move to Apple’s MLX framework and you will meet the same sentence: the new engine needs 32GB of unified memory, and Macs with 8GB or 16GB stay on the old Metal path with no change. It is repeated as a hardware floor, the kind of fact that decides whether someone bothers updating. We cloned the source and went looking for the check that enforces it. There is no such check.
What decides whether a model runs on MLX is the format the model ships in. That is the whole rule, and it is three lines long.
Does Ollama’s MLX engine require 32GB of unified memory?
No, and nothing in the code expresses that idea.
We took a shallow clone of the repository at main on 30 July 2026 and searched for any memory threshold that could act as a gate: constants in the gigabyte range, comparisons against total unified memory, anything named for a minimum. The only memory constant on the Darwin path is in discover/gpu_darwin.go:
“go
metalMinimumMemory = 512 * format.MebiByte
`
512 MiB. That is the floor for using the Metal GPU at all, and it is roughly sixty times smaller than the number everybody quotes.
Searching the Go sources for a 32-gigabyte threshold in any form returns nothing. Not in the scheduler, not in the MLX runner, not in the device layer.
What actually decides whether a model runs on MLX
The routing lives in server/images.go:
`go
func (m *Model) IsMLX() bool {
return m.Config.ModelFormat == "safetensors"
}
“
That is it. If the model was packaged as safetensors, it goes to the MLX runner. If it is GGUF, it goes to llama.cpp. The scheduler branches on that one boolean and hands the request to mlxrunner.NewClient or to the llama.cpp server accordingly.
Your machine is not consulted. The consequence runs both ways, and both directions contradict the popular version:
- A 16GB MacBook Air pulling a safetensors model gets the MLX engine.
- A 128GB Mac Studio pulling a GGUF does not.
There is one memory check on the MLX path, and it is a different kind of check. In x/mlxrunner/client.go, Load compares the size of the specific model you asked for against free GPU memory, minus overhead, before starting the subprocess. That is a per-model fit test, the same question any runtime asks: does this thing fit right now. It is not a judgement about your hardware class, and a small model passes it on a small machine.
Where the 32GB number came from
Not from nowhere. Ollama’s own launch guidance for the MLX engine suggested a Mac with more than 32GB of unified memory. That is a sensible recommendation. The models worth running on the new engine are large, the benchmarks were run on large machines, and someone with 16GB will have a worse time regardless of which runtime serves them.
What happened next is ordinary. A recommendation with a number in it got retold, and in retelling it hardened. “We suggest more than 32GB” became “requires 32GB”, which became “8GB and 16GB Macs are excluded”, which is a claim about behaviour that the software does not have. Each step is a small compression and none of the people making them were being careless.
The reason it matters is that the two statements send you to different places. If MLX is gated on your hardware, the question is whether to buy a bigger Mac. If MLX is gated on model format, the question is which file you pull, and that is free to change. We covered the format side of this when NVFP4 turned out to be an NVIDIA format that only runs on a Mac, for the same underlying reason: the MLX path carries formats the llama.cpp path does not.
What this means if you have a 16GB Mac
It means the engine is available to you and the constraint is elsewhere.
Pull a safetensors model that fits in your memory and Ollama will serve it through MLX. Pull a GGUF and it will not, no matter how much memory you have, because llama.cpp does not support MLX and the two runtimes stay separate by design. The practical question on a small machine was never which engine you are allowed to use. It is whether the model you want exists in safetensors at a size you can hold.
That is a narrower and more useful thing to check than a hardware floor, because you can check it in a model’s file listing in about ten seconds.
Two caveats we will keep attached to this. We read the source at a point in time, main on 30 July 2026, and a gate could be added in any release. And “available” is not “advisable”: nothing here says a 16GB Mac will enjoy running a large model through MLX, only that the software will not refuse on the grounds of the machine. If someone can point at a build where a memory threshold does gate the MLX path, we will publish the correction.
The broader lesson is the one we keep relearning about Ollama’s MLX shift. The interesting behaviour of these tools is decided in a handful of lines that nobody quotes, while the sentences that travel are the ones from the launch post. Reading three lines of Go settled a question that a dozen articles had answered confidently and wrongly, and the reading took less time than the articles did.
One more detail from the same file is worth having, because it explains why the confusion survives contact with experience. The scheduler asks whether a model fits before it starts the subprocess, so a 16GB Mac that reaches for a large safetensors model still fails, just with a different message and for a different reason. Someone hitting that failure and then reading that MLX needs 32GB will reasonably conclude the two are the same fact. They are not. One is about the model you chose and moves when you choose a smaller one. The other was never there.