Re:Ollama is now powered by MLX on Apple Silicon in preview
by LuxBennu on Tuesday March 31, 2026 @01:01AM
(#47582925)
Already running qwen 70b 4-bit on m2 max 96gb through llama.cpp and it's pretty solid for day to day stuff. The mlx switch is interesting because ollama was basically shelling out to llama.cpp on mac before, so native mlx should mean better memory handling on apple silicon. Curious to see how it compares on the bigger models vs the gguf path
[ Parent
| on HN ]
Re:Ollama is now powered by MLX on Apple Silicon in preview
by zozbot234 on Tuesday March 31, 2026 @04:37AM
(#47584360)
They initially messed up this launch and overwrote some of the GGUF models in their library, making them non-downloadable on platforms other than Apple Silicon. Hopefully that gets fixed.
Re:Ollama is now powered by MLX on Apple Silicon in preview
by goldenarm on Tuesday March 31, 2026 @05:07AM
(#47584599)
How many tokens per second?
Re:Ollama is now powered by MLX on Apple Silicon in preview
by LuxBennu on Wednesday April 01, 2026 @03:21AM
(#47597902)
Roughly 8-12 token/s on generation depending on context length. Prompt processing is faster obviously. Haven't benchmarked it super carefully though, just eyeballing the llama.cpp output.
Re:Ollama is now powered by MLX on Apple Silicon in preview
by yg1112 on Tuesday March 31, 2026 @01:50PM
(#47591055)
The key difference is that MLX's array model assumes unified memory from the ground up. llama.cpp's Metal backend works fine but carries abstractions from the discrete GPU world — explicit buffer synchronization, command buffer boundaries — that are unnecessary when CPU and GPU share the same address space. You'll notice the gap most at large context lengths where KV cache pressure is highest.
Re:Ollama is now powered by MLX on Apple Silicon in preview
by lioeters on Tuesday March 31, 2026 @04:38PM
(#47593169)
Insightful comment, thanks!
Re:Ollama is now powered by MLX on Apple Silicon in preview
by LuxBennu on Wednesday April 01, 2026 @03:25AM
(#47597922)
that tracks with what i've noticed practically. shorter prompts feel basically the same between llama.cpp metal and what i'd expect from native mlx, but once context gets longer the overhead starts showing up. would be interesting to see if ollama's mlx path actually handles kv cache differently under the hood or if it just skips the buffer sync layer