LLMs on a Mac — what runs at every memory tier
Every Apple Silicon Mac runs something local — the unified-memory tier decides how much. This page measures each tier's ceiling across every build we track (file sizes at pinned revisions, context overhead counted, floor-caliber rows marked), and picks the comfortable Q4 sweet spot for each.
The short answer: 16 GB runs 4B-class models at Q4 with room · 24 GB runs the 30B-A3B MoE · 64 GB runs 27B-class at full BF16 · 128 GB runs the whole tracked 27B-class ladder · 512 GB runs every model we track, Kimi K3 at 1-bit included — linear-state models at floor caliber (weights + overhead, KV unsized).
Data verified · sources pinned in Sources
The unified-memory ladder
One row per memory tier. The pick column is the comfortable Q4-first build — Q4 where it fits comfortably, the nearest quality class where it doesn't (site-wide tight threshold: under 2.5 GiB spare at 32K = tight); the ceiling column is the largest tracked build that fits — a display fact, not a recommendation. macOS reserve is already deducted from usable.
| Mac memory | Typical chips | The Q4-first pick | Tight-max ceiling |
|---|---|---|---|
| 16 GB | MacBook Air / Mac mini / iMac base | Qwen3-4B Q4_K_M · 7.3 GiB (spare 3.7) | Qwen3-Coder-30B UD-TQ1_0 · 10.9 GiB — spare 0.1 tight |
| 24 GB | Mac mini / MacBook Pro mid tiers | Qwen3-30B-A3B UD-Q3_K_XL · 16.4 GiB (spare 2.6) | Gemma-4-31B UD-Q4_K_XL · 19.0 GiB — spare 0.0 tight |
| 32 GB | Mac mini / MacBook Pro top tiers | Qwen3.8-27B NVFP4 (Ollama MLX) · 24.4 GiB (spare 2.6) | 30B-A3B Q6_K · 26.9 GiB — spare 0.1 tight |
| 48 GB | MacBook Pro / Mac Studio Pro-class | Qwen3-Coder-30B-A3B UD-Q8_K_XL · 37.0 GiB (spare 6.0) | Llama 4 Scout Q2 · 40.0 GiB — spare 3.0 floor caliber |
| 64 GB | MacBook Pro / Mac Studio Max-class | Qwen3.5-27B BF16 · 54.4 GiB (spare 4.6) | Gemma-4-31B BF16 (Unsloth) · 58.7 GiB — spare 0.3 tight |
| 128 GB | MacBook Pro Max / Mac Studio | Llama 4 Scout Q4_K_M · 61.4 GiB (spare 58.6) floor caliber | Llama 4 Scout Q8 · 119.9 GiB — spare 0.1 floor caliber |
| 512 GB | Mac Studio M3 Ultra | GLM-5.3-Flash UD-Q4_K_XL · 186.5 GiB (every tracked model fits — K3 only at 1-bit) floor caliber | Kimi K3 1-bit · 475.5 GiB — spare 4.5 fits |
Which Mac has which memory
Find your machine in the chip column, read its tier's row above. The ladder is generation-independent: a memory tier fits the same builds whether the chip is M1 or M5 — the generation changes speed, not what fits.
| Memory tier | Machines offered at this tier |
|---|---|
| 16 GB | MacBook Air (M4/M5 base) · Mac mini base · iMac · MacBook Pro base |
| 24 GB | MacBook Air / Mac mini / MacBook Pro mid configs |
| 32 GB | Mac mini / MacBook Air / MacBook Pro top configs (mini standard-cap on M6 generation) |
| 48 GB | MacBook Pro Pro-class · Mac Studio M5 Max |
| 64 GB | MacBook Pro Max · Mac Studio M5 Max · Mac mini Pro (prior gen) |
| 128 GB | MacBook Pro M4/M5 Max · Mac Studio M5 Max · M4 Max prior gens |
| 512 GB | Mac Studio M5 Ultra (96 GB / 256 GB configs sit between the 128 GB and 512 GB rows) |
Running it: apps, and the two traps
The apps. Ollama is the one-command default (brew install ollama, then ollama run) and ships Metal acceleration for Apple Silicon. LM Studio wraps the same GGUF builds in a GUI with per-build download sizes shown before you commit — the fastest way to see this page's numbers reflected in an app. llama.cpp is the floor: the same engine under both, buildable from source, and the tool whose --n-cpu-moe-style knobs matter when you want to push a tier's ceiling. All three read the same GGUF files this page measures.
Trap one: context eats your tier. The KV cache grows with context out of the same unified pool as the weights — at 32K it adds 1–6 GiB on typical tracked models. A build that fits at 8K can swap at 32K. Every ceiling above is quoted at 32K for exactly this reason; shorter context raises every row a step.
Trap two: swap is a soft cliff, not a wall. macOS will happily load a build bigger than your tier by swapping to the SSD — it runs, crawling, and sustained use wears the drive. Unlike a phone (where an oversized model simply refuses to load), a Mac always says yes and then gets slowly worse. Treat the ceiling column as the no-swap line.
How the numbers are made
Unified memory ≈ VRAM for fit math. The GPU reads weights and KV cache from the same pool, so the same per-build totals decide what fits — a build's 32K total is identical whether the pool is a graphics card or a Mac (the 24 GB tier row above is one such build). Two Mac-specific corrections: the macOS reserve (a few GB the system keeps; this page deducts 5 GiB on the 16–64 GB tiers), and bandwidth — a fit verdict means it runs, not that it runs at desktop-GPU speed.
Totals are measured, not estimated. Every build size is the sum of the actual build's files at a pinned repository revision — GGUF shards for the GGUF builds, the vendor/MLX checkpoint where that is the Mac runtime path (the NVFP4 pick runs via Ollama's MLX backend on Apple silicon; there is no validated GGUF-NVFP4 load path on Metal) — measured where we read the file listing, reported with a link where the community did, plus the context overhead at 32K. Same builds, same thresholds as every model page on this site — the tight line is 2.5 GiB of spare memory, site-wide.
Sources
| Model page | Build | Total @32K | Pinned source |
|---|---|---|---|
| qwen3-4b | Q4_K_M | 7.3 GiB | HF @2f3b082b accessed 2026-09-14 |
| qwen3-coder-30b-a3b | UD_TQ1_0 | 10.9 GiB | HF @b17cb02d accessed 2026-09-14 |
| qwen3-30b-a3b | UD_Q3_K_XL | 16.4 GiB | HF @d5b1d57b accessed 2026-09-14 |
| gemma-4-31b | UD_Q4_K_XL | 19.0 GiB | HF @c1ac76e9 accessed 2026-09-06 |
| qwen38-27b | NVFP4 | 24.4 GiB | HF @f0b7c9e7 accessed 2026-09-21 |
| qwen3-30b-a3b | Q6_K | 26.9 GiB | HF @d5b1d57b accessed 2026-09-14 |
| qwen3-coder-30b-a3b | UD_Q8_K_XL | 37.0 GiB | HF @b17cb02d accessed 2026-09-14 |
| llama-4-scout | UD-Q2-K-XL | 40.0 GiB floor caliber | HF @72a6853f accessed 2026-09-14 |
| qwen35-27b | BF16 | 54.4 GiB | HF @fc05daec accessed 2026-09-06 |
| gemma-4-31b | BF16 (Unsloth) | 58.7 GiB | HF @c1ac76e9 accessed 2026-09-01 |
| llama-4-scout | Q4-K-M | 61.4 GiB floor caliber | HF @72a6853f accessed 2026-09-14 |
| llama-4-scout | UD-Q8-K-XL | 119.9 GiB floor caliber | HF @72a6853f accessed 2026-09-14 |
| glm-53-flash | UD-Q4-K-XL | 186.5 GiB floor caliber | HF @621d456e accessed 2026-09-21 |
| kimi-k3 | UD-TQ1-0 | 475.5 GiB | HF @a0836360 accessed 2026-09-01 |
| Claim on this page | Source |
|---|---|
| Per-build GGUF file sizes (all tiers' picks and ceilings) | unsloth / bartowski / ggml-org GGUF repos (revision-pinned per build) |
| macOS reserve practice (16–64 GB tiers usable = total − 5 GiB) | jola.dev — a 24GB M4 running a 9B Q4 alongside everyday apps (May 2026) · dev.to — 2026 macOS comparison with a per-config model table |
| 128 GB → 120 usable · 512 GB → 480 usable | Site convention established on the cliff-exit pages, cross-checked 2026-10-11 against community sysctl practice and Apple's Metal documentation: QuelLLM — Mac Studio 512 Go setup (iogpu.wired_limit_mb=491520 = 480 GiB) · pinggy — the 512GB default wired ceiling (~75%) and raising it · AIMultiple — Apple Silicon GPU default ≈75% of RAM, raisable leaving 8–16 GB · Apple Metal docs — recommendedMaxWorkingSetSize(the official GPU working-set ceiling these sysctls tune) |
| Chip lineup and config availability (August 2026) | Apple Newsroom — Mac mini M6/M5 Pro · Apple Newsroom — Mac Studio M5 Max/M5 Ultra (to 512GB) · official spec pages: Mac Studio / MacBook Pro / Mac mini / MacBook Air |
FAQ
How much unified memory do I need to run a 70B LLM?
Around 40 GiB of unified memory at 4-bit (Q4_K_M-class) for the weights alone, plus context overhead — a 64 GB Mac runs a 70B-class model comfortably at Q4, and a 48 GB Mac is borderline. macOS also needs roughly 4–6 GB you cannot give to the model, which every tier on this page already accounts for.
Is unified memory the same as VRAM for running LLMs?
Functionally yes for fit math: the GPU reads weights and KV cache from the same unified pool a dedicated card would use as VRAM, so the same per-build totals decide what fits. The differences are practical, not mathematical: macOS keeps a 4–6 GB reserve out of the pool, and memory bandwidth is lower than a desktop GPU's, so a fit verdict means it runs, not that it runs fast.
How much of macOS unified memory is actually usable for an LLM?
Community practice keeps a few GB of the pool for macOS — on a 24 GB Mac that leaves about 18–20 GB you can hand to a model before swapping starts. This page uses total − 5 GiB for the 16–64 GB tiers; the 128 GB and 512 GB tiers carry the site's established 120 GiB and 480 GiB usable values, cross-checked against community sysctl practice (linked in Sources).
Why does context length matter more on a Mac than the spec sheet suggests?
Because the KV cache grows with context and comes out of the same unified pool as the weights. At 32K context the KV cache adds 1–6 GiB on typical tracked models — often the difference between a fit and a swap. Every ceiling on this page is quoted at 32K so the numbers already include that cost.
What happens if the model is bigger than unified memory?
macOS does not refuse — it swaps to the SSD, so the model still loads and answers, but token generation slows to a crawl and sustained use wears the SSD. Treat the ceilings on this page as the no-swap line: a build above its tier's ceiling is a demonstration, not a daily driver.
Are these ceilings the absolute limit?
No — the ceilings are the no-drama line, not the theoretical limit. Community practice pushes past them with RAM offload, speculative decoding (especially for MoE models), 1–2-bit frontier quants, and custom runtimes — trades that cost tokens per second, sometimes heavily (a 24 GB card plus 96 GB of system RAM has a reported community path running a 1-bit frontier model; this site's Bonsai-27B page tracks a true 1-bit 27B that fits in 6.2 GiB). We know those paths exist; the ladder still quotes the comfortable line, because that is the answer for anyone who just wants the model to run.
I did the math myself and the numbers don't add up — is something wrong?
Probably not — every size on this page is the full 32K-context load, not just the weights. Take the 48 GB pick: Qwen3-Coder-30B-A3B UD-Q8_K_XL is 33.5 GiB of weights (the exact size of the pinned Hugging Face build) + 3.0 GiB of KV cache at 32K + ~0.5 GiB of runtime overhead = 37.0 GiB total. The model's own page quotes the smaller Q8_0 build (33.7 GiB all-in) — both are real; they're different files from the same repo. Every figure links back to a pinned source, so you can recompute it the same way.