How to Run Local LLMs on Apple Silicon A developer guide details how to run local large language models on Apple Silicon, noting that as of Ollama 0.19 (March 2026), Ollama replaced its Metal-backed llama.cpp inference path with Apple's MLX framework on Macs with 32GB or more of unified memory, while 8GB and 16GB machines still use the older Metal/llama.cpp path. The writeup compares GGUF and MLX model formats, advises reserving roughly 20-25% of unified memory for the OS and display compositor, and points to LM Studio and Ollama's `ollama run` REPL plus OpenAI-compatible local APIs for running models without a VM or agent. This is about the model, on its own — what tool to install, what format to pull, and how to actually talk to it. Not wrapped in a VM, not wired up to a coding agent. If you want that part too, the complete AI agent guide https://www.veloworkspaces.com/blog/zero-tax-virtualization/ covers it in depth; this page is the more basic thing underneath it. These get used almost interchangeably in casual conversation, and they're not the same kind of tool: As of Ollama 0.19 March 2026 , Ollama replaced its Metal-backed llama.cpp inference path with Apple's own MLX framework on Macs with 32GB or more of unified memory — a substantial speed improvement on supported hardware. 8GB and 16GB Macs still run the older Metal/llama.cpp path unchanged. If you're on a 32GB+ Mac, "MLX vs. Ollama" is a less clean-cut choice than it used to be: for many models, Ollama is now MLX under the hood, not a genuinely separate engine. Worth checking your installed Ollama version and hardware tier before assuming older comparisons still describe your setup exactly. GGUF is llama.cpp's own model container format — broad, well-supported, with the longest tail of available conversions older models, fine-tunes, merges because the ecosystem around it is the largest. MLX-format models are built specifically for Apple's framework, and on the same chip an MLX build is commonly meaningfully faster than the equivalent GGUF for supported models. Neither format is strictly better — GGUF wins on breadth and portability, MLX wins on Apple Silicon-specific speed for models that have an MLX conversion available. Quantization — the 4-bit, 8-bit tradeoffs that actually determine how much RAM a given model needs — is its own topic: see LLM quantization explained for Mac users https://dev.to/wango/llm-quantization-explained-for-mac-users-3cm0 . MLX-format models are published on Hugging Face https://huggingface.co/models?library=mlx-lm , generally under the mlx-community organization; Ollama pulls from its own library https://ollama.com/library . Both move fast — new releases and their MLX/GGUF conversions can lag each other by days to weeks, so treat any specific model tag you read including on this blog as a snapshot rather than a permanent recommendation, and check the source directly before pulling. This blog already has a detailed RAM-to-model-size table, broken down from 16GB through 128GB+ Macs with specific MLX and Ollama tags per tier — see Section 3 of the complete AI agent guide https://www.veloworkspaces.com/blog/zero-tax-virtualization/ rather than a second copy of the same table here. The short version: reserve roughly 20–25% of total unified memory for the OS and display compositor before budgeting the rest for model weights and KV cache, since both the model and macOS itself draw from the same pool. For the actual math behind those numbers — and how to work out a model that isn't already tabulated — see how much RAM local LLMs actually need https://dev.to/wango/how-much-ram-do-you-need-for-local-llms-on-a-mac-5b0m . None of this requires a VM or an agent. LM Studio gives you a chat window the moment a model finishes downloading. Ollama's own ollama run