Every VRAM-tier guide on this site, including the hub that sorts models by card, assumes a discrete GPU with its own memory pool and a number on the box. Apple Silicon has none. Every M-series chip shares one pool between CPU and GPU, which Apple’s Metal API exposes as hasUnifiedMemory, “A Boolean value that indicates whether the GPU shares all of its memory with the CPU”. Reading a 16GB MacBook Air as a 16GB graphics card misleads in both directions. (Source)
The bigger correction is counterintuitive: on a Mac, capacity is rarely the ceiling. Bandwidth and the fraction of unified memory the GPU may hold are. A 128GB Mac Studio is not a 128GB GPU.
Updated August 2026. Refreshed monthly as models and runtimes change.
The GPU Does Not Get All of the Memory
Apple documents a threshold, not a percentage. recommendedMaxWorkingSetSize is “An approximation of how much memory, in bytes, this GPU device can allocate without affecting its runtime performance”, and the guidance is to keep total footprint under it. (Source)
That threshold is not an abstraction. llama.cpp’s Metal backend reads exactly that property as the device limit, dev->props.max_working_set_size = dev->mtl_device.recommendedMaxWorkingSetSize;, and warns when allocation passes it. (Source)
The override is a macOS sysctl, not a runtime flag: sudo sysctl iogpu.wired_limit_mb=<mb>. The lead maintainer called it load-bearing on 2025-08-18: “Increasing the memory limit is needed for such big models because they cannot fit in the default memory limit - not sure you can do anything else here.” (Source) (Source)
Apple has never published the default fraction. The circulating numbers come from a third party who disassembled Apple’s AGXAccelerator driver in 2023, finding a reserve of about one third at or below 32GB of RAM and one quarter above it (the cutoff constant, 0x800000000, is exactly 32GB), plus user reports clustering between 67 and 93 percent usable. Plan on two thirds to three quarters of installed memory, more above 32GB, and treat that as community-derived from reverse-engineered code and anecdote, not an Apple specification. Apple’s own MLX framework rests on the same property: “A notable difference from MLX and other frameworks is the unified memory model. Arrays in MLX live in shared memory.” (Source)
Bandwidth Decides Decode Speed
Prefill pushes many prompt tokens through each weight load, so it is compute-limited. Decode emits one token per step and streams the whole weight set through memory every step, so it is bandwidth-limited. The compute half comes from llama.cpp’s lead maintainer in the project’s Apple Silicon benchmark thread, 2023-11-26: “At large batch size (PP means batch size of 512) the computation is compute bound. I.e. the speed depends on how many FLOPS you can utilize.” That framing is the maintainer’s, not Apple’s. (Source)
Apple’s published bandwidth figures, taken from its own launch announcements for M1 Pro and M1 Max, M1 Ultra, M2, M2 Pro and M2 Max, M2 Ultra, M3 Ultra, M4 Pro and M4 Max, M5 and M5 Pro and M5 Max, with the 819GB/s M3 Ultra figure read off the Mac Studio technical specifications:
| Chip | Published memory bandwidth | Announced |
|---|---|---|
| M1 Pro | 200GB/s | 2021-10-18 |
| M1 Max | 400GB/s | 2021-10-18 |
| M1 Ultra | 800GB/s | 2022-03-08 |
| M2 | 100GB/s | 2022-06-06 |
| M2 Pro | 200GB/s | 2023-01-17 |
| M2 Max | 400GB/s | 2023-01-17 |
| M2 Ultra | 800GB/s | 2023-06-05 |
| M3 Ultra | over 800GB/s at launch; 819GB/s on the specs page | 2025-03-05 |
| M4 | 120GB/s | 2024-10-30 |
| M4 Pro | 273GB/s | 2024-10-30 |
| M4 Max | up to 546GB/s; 410GB/s on the 14-core CPU build | 2024-10-30 |
| M5 | 153GB/s | 2025-10-15 |
| M5 Pro | up to 307GB/s | 2026-03-03 |
| M5 Max | up to 614GB/s; 460GB/s on the 32-core GPU build | 2026-03-03 |
The base M1, base M3 and M3 Pro are absent because their launch releases stated no figure, and M3 Max because its numbers trace to a support page that did not render reliably.
The line-up is also not ordered the way the names suggest. MacBook Air and MacBook Pro ship M5-family silicon, but Mac Studio still ships M4 Max and M3 Ultra, and there is no M5 Ultra. M3 Ultra at 819GB/s is therefore still the highest-bandwidth chip Apple sells: for decode, the newest die is not the fastest one available.
Four Runtimes, and the Comparison Nobody Has Published
llama.cpp installs from an official Homebrew formula, brew install llama.cpp, is MIT licensed (“Copyright (c) 2023-2026 The ggml authors”) and reads GGUF. Its build docs: “On MacOS, Metal is enabled by default. Using Metal makes the computation run on the GPU.” (Source) (Source)
Ollama is also MIT and takes GGUF through a Modelfile; it “supports GPU acceleration on Apple devices via the Metal API”. It is no longer only a llama.cpp wrapper: its main-branch development docs, undated when checked on 2026-08-02, say “The MLX engine enables running safetensor based models.” and “On macOS arm64, MLX is enabled by default.” Defaults move between releases, so re-check that page. (Source)
LM Studio ships both engines, switchable per model, having added MLX in version 0.3.4 on 2024-10-08. It is the one proprietary option, granting “a non-exclusive, non-transferable license to use the Software solely for Your personal and / or internal business purposes”, which excludes resale and SaaS. (Source) (Source)
MLX and mlx-lm are Apple’s own, both MIT (“Copyright © 2023 Apple Inc.”), installed with pip install mlx and pip install mlx-lm, and use a safetensors format from mlx_lm.convert rather than GGUF. None of these runtimes use the Neural Engine, though the evidence differs in strength. For MLX it is explicit: the README lists devices as “currently the CPU and the GPU”, and an ANE-support issue opened on 2023-12-06 was closed as wontfix. For llama.cpp it is absence of mention rather than denial, its docs describing Metal and the GPU only. (Source)
Which engine is faster has no primary-source answer. No same-chip, same-model, same-quantisation comparison appears in either project’s documentation: llama.cpp’s benchmark thread never mentions MLX, mlx-lm’s BENCHMARKS.md has no llama.cpp column, and no Apple ML Research post making the comparison surfaced. Any “MLX is N percent faster” figure comes from blogs and forums, not from either project.
What Actually Fits
Sizes are real file sizes from the Hugging Face API, weights only, except the two Qwen3-30B-A3B figures, which are peak-memory readings from mlx-lm’s own benchmark table; the KV cache grows on top. The usable budget applies the community-derived fraction above and is an estimate.
| Memory | Est. GPU-usable | Fits (file size) | Does not fit |
|---|---|---|---|
| 8GB | ~4-5GB | Llama-3.2-1B-Instruct Q4_K_M 0.81GB; Llama-3.2-3B-Instruct Q4_K_M 2.02GB; Phi-3.5-mini-instruct Q4_K_M 2.39GB | n/a |
| 16GB | ~9-10GB | Meta-Llama-3.1-8B-Instruct Q4_K_M 4.92GB, MLX 4-bit 4.52GB; Mistral-7B-Instruct-v0.3 Q4_K_M 4.37GB; Gemma-2-9B-it Q4_K_M 5.76GB | n/a |
| 24GB | ~14-16GB | Qwen2.5-14B-Instruct Q4_K_M 8.99GB; Gemma-2-27B-it Q3_K_M 13.42GB | Qwen2.5-14B-Instruct Q8_0 15.70GB, tight |
| 32GB | ~19-21GB | Qwen2.5-32B-Instruct Q4_K_M 19.85GB, MLX 4-bit 18.43GB; Qwen3-30B-A3B-Instruct-2507 MLX 4-bit 18.20GB | Qwen3-30B-A3B-Instruct-2507 q8 33.46GB |
| 64GB | ~43-48GB | Llama-3.1-70B-Instruct Q4_K_M 42.52GB, MLX 4-bit 39.69GB; DeepSeek-R1-Distill-Llama-70B Q4_K_M 42.52GB | either at Q8_0, roughly 75-77GB |
| 96GB | ~68-72GB | Qwen2.5-72B-Instruct Q4_K_M 47.42GB, MLX 4-bit 40.90GB | 70-72B Q8_0 at 75-77GB, borderline |
| 128GB | ~91-96GB | Qwen2.5-72B-Instruct Q8_0 77.26GB | Qwen3-235B-A22B-Instruct-2507 MLX 4-bit 132GB |
A 235B mixture-of-experts model at 4-bit does not fit a 128GB Mac: 132GB exceeds nominal capacity before any usable-fraction discount. Llama-3.1-405B is out of reach at every tier, its BF16 weights working out to roughly 812GB, calculated from the parameter count rather than read from a published file size.
Measured Throughput, and What Happens Past the Ceiling
From llama.cpp’s benchmark thread, model llama 7B, pp512 as prefill and tg128 as decode:
| Chip | Quant | Prefill tok/s | Decode tok/s | Posted |
|---|---|---|---|---|
| M1 Pro, 16-core GPU | F16 | 302.14 | 12.75 | maintainer 2023-11-22 |
| M1 Pro, 16-core GPU | Q4_0 | 266.25 | 36.41 | maintainer 2023-11-22 |
| M2 Ultra, 76-core GPU | F16 | 1401.85 | 41.02 | maintainer 2023-11-22 |
| M2 Ultra, 76-core GPU | Q4_0 | 1238.48 | 94.27 | maintainer 2023-11-22 |
| M3 Max, 40-core GPU | F16 | 779.17 | 25.09 | community 2023-11-24 |
| M3 Max, 40-core GPU | Q4_0 | 759.70 | 66.31 | community 2023-11-24 |
| M4 Max, 14-core CPU, 32-core GPU, 36GB | F16 | 736.25 | 24.29 | community 2026-01-16 |
| M4 Max, 14-core CPU, 32-core GPU, 36GB | Q4_0 | 713.93 | 69.95 | community 2026-01-16 |
The M4 Max rows land below M3 Max here. That is almost certainly a build, macOS or configuration difference between two people posting three years apart, not a generational regression, and it is reproduced as posted. (Source)
MLX publishes its own figures for a 64GB M4 Max on macOS 26.1, with a 2048-token prompt and 128 generated tokens. Different models and harness, so they do not compare with the table above. (Source)
| Model | Quant | Prompt tok/s | Generation tok/s | Peak GB |
|---|---|---|---|---|
| Qwen3-4B-Instruct-2507 | bf16 | 1780.63 | 52.47 | 9.02 |
| Qwen3-4B-Instruct-2507 | q8 | 1606.57 | 86.91 | 5.25 |
| Qwen3-4B-Instruct-2507 | q4 | 1622.27 | 134.52 | 3.35 |
| Qwen3-30B-A3B-Instruct-2507 | q8 | 1719.47 | 83.16 | 33.46 |
| Qwen3-30B-A3B-Instruct-2507 | q4 | 1753.90 | 113.33 | 18.20 |
Crossing the ceiling is not a graceful slowdown. A report filed on 2026-02-23 against a 24GB M4 Pro: “System Failure: The OS becomes extremely sluggish, memory faults occur, and even the system speakers stop working/distort (likely due to coreaudiod being paged out) before a crash… the system still enters a swap death spiral once physical RAM is exceeded”. (Source)
Sustained load costs more on fanless hardware, documented inside Apple’s own MLX project. A contributor on 2026-03-16: “I am benchmarking mlx-lm with llama.cpp on my (fanless) MacBook Air M4. To avoid thermal throttling during longer benchmarks, I would like to incorporate cooldown delays between consecutive runs”. llama.cpp’s llama-bench ships a --delay flag for exactly that. (Source)
What This Means
A Mac buys capacity cheaply and bandwidth expensively, inverting the usual advice. A 70B at 4-bit loads on 64GB, but how fast it answers is set by the chip’s bandwidth and by how much of the pool the GPU may wire down. Prompt processing is the weak point for the same reason: prefill is compute-bound, and Apple publishes no GPU throughput figure of any kind, so no honest number can be put on the gap. Memory is also effectively fixed at purchase, an inference from Apple’s configuration pages presenting it as a chip-tied build option rather than an Apple statement to that effect. Phones face a stricter version of the same trade, in the Android and iPhone guide.
The Bottom Line
Ignore the VRAM tiers on a Mac. Take installed memory, keep two thirds to three quarters as the working budget, and check a model’s real file size first. Use llama.cpp or Ollama for GGUF, mlx-lm or LM Studio for Apple’s format, and discount any claim that one is a fixed percentage faster, because neither project has published the comparison. Expect decode to track the bandwidth column, expect a fanless Air to throttle on long runs, and stay under the ceiling: past it the failure mode is a swap death spiral, not a slow reply.