Run Local LLMs on a Mac: The 2026 Guide (Hardware, Speeds, Tools)

The short answer: any Apple Silicon Mac with 16 GB of unified memory runs 7B–14B models well, a 64 GB M4 Pro runs 70B-class models at usable speeds, and a 256 GB Mac Studio M3 Ultra runs 200B-class models that no single consumer GPU can hold. Generation speed is set almost entirely by memory bandwidth, so the chip tier matters more than the year. Below: a hardware-to-model table, the RAM math, the three tools that matter (Ollama, LM Studio, MLX), a five-minute setup, and the honest case for renting a Mac instead of buying one.

Which Mac runs which model

The rule that decides everything: a model has to fit in unified memory at the quantization you choose, with a few gigabytes left for the context window and the OS. Once it fits, tokens per second scale with memory bandwidth. Our published benchmarks measured the base M4 (120 GB/s); the other rows are bandwidth-scaled estimates until we publish measured columns for them.

Per-model hardware requirements, quant tables, and the cheapest chip that fits each one live in our model guides — for example Llama 3.1 8B, Qwen 2.5 32B, and Llama 3.3 70B.

The RAM math in one line

Weights in GB ≈ parameters (billions) × bits per weight ÷ 8, plus about 15% runtime overhead, plus context. At Q4_K_M (≈4.85 bits) an 8B model is ~4.9 GB of weights and ~6 GB in memory; a 32B model is ~20 GB; a 70B model is ~42 GB; a 123B model is ~75 GB. Q8_0 roughly doubles those numbers, FP16 roughly quadruples them. Add 1–4 GB for a 32K context, more for 128K. That is why 16 GB tops out at 14B, 64 GB is the 70B threshold, and 128 GB is where 100B+ dense models become practical.

If you would rather not do the arithmetic yourself, the Mac LLM calculator runs both formulas for any chip from M1 to M6 and any memory size Apple ships, and tells you the tokens/sec to expect as well as whether the model fits.

If you already know which machine you are choosing between, every chip people actually use for inference has its own page with the full model by model breakdown at each memory configuration, and the same speed model applied to NVIDIA and AMD shows where a Mac is the wrong purchase.

Why speed is about bandwidth, not cores

Generating one token means reading every active weight once. A 4.9 GB model on a 120 GB/s bus can therefore never exceed ~24 tok/s, and we measured 21.2 — about 87% of the theoretical ceiling. The same math predicts the M4 Pro (273 GB/s) at ~2× and the M4 Max (546 GB/s) at ~4× for the same model, which is what the community consistently reports. Two consequences: a bigger GPU core count on the same bandwidth barely helps generation, and mixture-of-experts models (which only read their active experts per token) run far faster than their parameter count suggests. Prompt processing is the exception — it is compute-bound, and we measured it varying 2× between model families at equal size (Qwen 2.5 7B 1,130 tok/s vs Llama 3.1 8B 587 tok/s).

Ollama vs LM Studio vs MLX vs llama.cpp

• Ollama — the default for anything headless or scripted: one command to pull a model, a local REST API on port 11434, and an OpenAI-compatible endpoint. It runs llama.cpp underneath. Hosting Ollama on a cloud Mac covers the always-on setup.
• LM Studio — the best GUI: model browser, chat window, and a local server that speaks the OpenAI API. Same engine class as Ollama, so same speeds; pick it if you want to click rather than type. Requirements and measured speeds in our LM Studio on a Mac guide.
• MLX— Apple's own array framework. On some models it is the fastest option on Apple Silicon and it is the natural choice for fine-tuning on a Mac; it is a Python library, not an app. See MLX on Apple Silicon.
• llama.cpp — the raw engine when you want every flag, the newest quant formats, or a C/C++ embed. llama.cpp on Apple Silicon has the Metal build and tuning notes.

Five-minute setup with Ollama

brew install ollama
ollama serve &                      # local API on :11434
ollama pull llama3.1:8b             # ~4.9 GB, fits any 16 GB Mac
ollama run llama3.1:8b "Explain unified memory in two sentences."

# OpenAI-compatible endpoint for your existing code:
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.1:8b","messages":[{"role":"user","content":"Hi"}]}'

Point any OpenAI SDK at http://localhost:11434/v1 with a dummy API key and it works. To try a bigger model, check the RAM math above first — pulling a 70B build onto a 16 GB machine will download 40 GB and then fail to load.

Common mistakes

• Buying GPU cores instead of memory. A 24 GB Mac with more GPU cores runs the same 8B model no faster than a 16 GB one on the same chip; the next tier of bandwidth is what changes speed.
• Ignoring the context window. A model that “fits” with 1 GB to spare will swap and crawl the moment you paste a long document. Leave 2–4 GB free, more for RAG.
• Running production on a laptop. Thermal throttling, sleep, and a residential uplink turn a 21 tok/s machine into an unreliable one. Anything that needs to be up 24/7 belongs on a desktop-class Mac with a real network connection.

When a cloud Mac makes more sense than buying

If you need a local-class model available around the clock, reachable by your team or your app, the honest comparison is not laptop vs cloud but buying a Mac mini vs renting one. Owning wins on raw hardware cost over three years; renting wins the moment you count hosting, a static IP, power, remote-access setup, and being your own on-call. A dedicated M4 Mac mini from $99/mo comes with Ollama pre-installed and the OpenAI-compatible endpoint already exposed; the 64 GB M4 Pro tier is where 70B models live. If you would rather test before committing, deploy a model from the catalog — it takes about five minutes.