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 covers it in depth; this page is the more basic thing underneath it.
Four names, four different things
These get used almost interchangeably in casual conversation, and they're not the same kind of tool:
- llama.cpp is the inference engine underneath most of this ecosystem — a C++ implementation that runs GGUF-format models across NVIDIA, AMD, Intel, and plain CPU, not Apple-specific at all.
- MLX is Apple's own array framework and inference library, built specifically for Apple Silicon's unified memory architecture, running its own MLX-format models.
- Ollama is a friendly CLI and local API server wrapped around an inference backend — historically llama.cpp underneath, though that changed recently and specifically for Apple Silicon (more below).
- LM Studio is a desktop GUI app that runs both GGUF and MLX models side by side in the same interface, and is the easiest on-ramp if you don't yet know which format or engine you want.
A real, recent change worth knowing about
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.
Model formats: GGUF vs. MLX, briefly
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.
Where models actually come from
MLX-format models are published on Hugging Face, generally under the mlx-community organization; Ollama pulls from its own 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.
How much RAM you actually need
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 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.
Using a model with nothing else involved
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 <model> drops you into a REPL directly in Terminal. Either one also exposes an OpenAI-compatible local API — http://127.0.0.1:11434/v1 for Ollama, whatever port you configure for MLX or LM Studio's server mode — that any script, editor plugin, or app that speaks the OpenAI API format can point at, with nothing more exotic than an environment variable pointing somewhere on your own machine.
When you'll actually want isolation
The model itself is inert — it's the code an agent generates and executes against that model that creates risk, and that's a different problem from "how do I run a model at all," worth its own guide rather than a section here. If what you're actually building is an AI coding agent, not just a chat window, see the complete AI agent guide for the full VM-isolated setup, the AI Bridge architecture for how the model stays on the host GPU while the agent runs isolated, and the MLX + OpenCode setup guide for one concrete, complete walkthrough.
Related reading: running AI agents safely in an isolated VM, the AI Bridge architecture, and what isolation actually costs, benchmarked across MLX and Ollama. Or download Velo Workspaces and try it yourself.
