How do you run an LLM locally on a Mac in 2026?

Pick the right runtime for what you actually want to do

If you want the fastest path to a working chat on your Mac, install Ollama. It is a single binary, a single CLI command per model, and it works on every M-series Mac. If you want a GUI with model browsing, parameter sliders, and a built-in local-server endpoint, install LM Studio. If you want the fastest tokens/sec on Apple Silicon and you are comfortable with a Python or CLI workflow, use mlx-lm. If you need the broadest model-format support and do not mind compiling, use llama.cpp directly.

The four are not interchangeable. Ollama is the easiest and the most popular, but it is a wrapper around llama.cpp and it pulls a stable, conservative build. LM Studio is the friendliest GUI but ships its own inference engine. mlx-lm is the native Apple path and is the fastest on M-series for the models it supports, but the model catalog is smaller. llama.cpp is the most flexible and the most work.

• Ollama: one CLI, one model at a time, easiest install, broad model catalog
• LM Studio: GUI-first, good for non-CLI users, ships its own server endpoint
• mlx-lm: fastest native Apple Silicon path, smaller catalog, requires Python comfort
• llama.cpp: most flexible, broadest quantization support, requires building from source for the latest features

Which model fits your Mac

The model you can run is bounded by your unified memory. A 7B-8B model in 4-bit quantization is around 4-6 GB on disk and needs roughly 6-8 GB of RAM to run with reasonable context. A 30B-32B model in 4-bit is around 18-22 GB. A 70B model in 4-bit is around 40 GB. On a 16 GB MacBook Air, stick to 7B-8B in 4-bit or 13B in 4-bit with a short context. On a 32 GB MacBook Pro or Mini, run 30B-32B in 4-bit comfortably. On a 64 GB or 128 GB Mac Studio, run 70B in 4-bit or a small MoE in higher precision.

Do not try to run a model that does not fit. The OS will swap to SSD and the model will become unusably slow. If a model is too big, pick a smaller model or a more aggressive quantization (Q4_K_M, then Q3_K_M, then IQ-series). The quality tradeoff between Q4_K_M and Q8_0 is small for most chat use; the quality tradeoff between Q4_K_M and Q2_K is large enough to be visible.

What to expect for tokens per second

Tokens per second on a Mac is bounded by memory bandwidth, not by raw compute. On M-series hardware, the rule of thumb is roughly 1 token/s per 10 GB/s of memory bandwidth for prompt prefill, and roughly 2-3x that for generation. A MacBook Air with 100 GB/s bandwidth will run a 7B-8B model in 4-bit at around 20-30 tokens/s for generation. A Mac Studio M3 Ultra with 800 GB/s will run a 70B model in 4-bit at around 15-25 tokens/s for generation. The numbers move with model size, quantization, context length, and the specific runtime.

mlx-lm on Apple Silicon is the fastest path for the models it supports. llama.cpp is close behind. Ollama is a thin wrapper that adds a small overhead. LM Studio is the same. If tokens/sec matters, benchmark on your own prompts with your own context size, not on the published model card.

The user-impacting risks to take seriously

Local does not mean private by default. Ollama's server endpoint, LM Studio's server endpoint, and any other LLM server on your Mac will accept connections from your local network unless you bind it to localhost. Confirm the runtime is bound to 127.0.0.1, not 0.0.0.0, before you start it on a laptop you take to cafes. The same defensiveness applies to any MCP server or tool surface that talks to the local LLM.

Local also does not mean offline. Some runtimes call home for model updates, telemetry, or model discovery. If your threat model requires the model to never contact the internet, run it with the network off (e.g. behind a firewall or with Little Snitch rules) and pull model weights over a separate, audited channel. The upside of local is real; it is not a guarantee of privacy without the configuration.

• Verify the server endpoint is bound to 127.0.0.1, not 0.0.0.0
• Read the runtime's telemetry defaults; some phone home by default
• Pull model weights over a verified channel and hash-check before first use
• If the model cannot leave the machine, also confirm the runtime does not exfiltrate prompts

A working setup in under an hour

On a MacBook Air M-series with 16 GB: install Ollama, run 'ollama run llama3.1:8b-instruct-q4_K_M', and you have a working local chat in under five minutes. Add a simple system prompt, ask the model a real question from your work, and time the response. If it is too slow, drop to a smaller model or a tighter quantization. If it is too inaccurate, try a larger model in the same quantization, or a different model in the same size.

On a Mac Studio with 64 GB or 128 GB: install mlx-lm alongside Ollama, and use mlx-lm for the largest models you can fit. Set the context window to a realistic value for your work (8K for chat, 32K for code review, 128K for long-doc summarization). The context window is the largest user of memory after the model itself.

A useful next action

Pick one Mac, one runtime, and one model that fits your RAM. Run a small benchmark with three or four of your real prompts. Time the first-token latency and the steady-state tokens/sec. From there, decide whether to expand the model, switch runtimes, or back out. Local LLM is a different product than a hosted API; it earns its place by being private, cheap, and offline-capable, not by being faster than the flagship hosted model.