Your Mac Does Not Give the GPU All Its Memory

What LLM can my Mac run? The answer starts with a number that is not printed anywhere on the machine: macOS hands the GPU roughly 75% of your unified memory and keeps the rest. On a 24 GB MacBook that is about 18 GB to work with, not 24. On a 64 GB machine it is about 48. The tool above already applies that, which is why the pool it reports is smaller than the number on your invoice.

That single fact decides almost every “will this model run on my Mac” question, and Apple has never published a formula for it.

So do not take our 75% as the answer. Your machine already knows the real number. Paste what it reports into the box in the tool above and every figure on this page becomes yours instead of our estimate. The two commands are below, and neither takes longer than pressing enter. What follows is why the estimate exists at all, and how far off it can be.

The Number macOS Actually Gives Your GPU

Metal exposes a property called recommendedMaxWorkingSetSize, and every local runtime treats it as the ceiling. llama.cpp reads it, MLX reads it, Ollama reads it through llama.cpp. On Apple silicon it comes out around 75% of installed memory.

Around is doing real work in that sentence. Published measurements on smaller machines come in lower, closer to 65%, and no source we can find documents where the boundary sits or whether one exists. So the honest version is a range:

The 24 GB machines are where this bites hardest, and not because the gap is largest. It is because that is exactly where a popular model lands. Qwen 3.8 27B at Q4_K_M with an 8K context needs 17.66 GiB by our calculator. At 75% a 24 GB Mac offers 18.0. It fits, with a third of a gigabyte to spare. At 65% it offers 15.6 and the same file does not load at all.

Nothing about the model changed. The verdict flipped on a property Apple does not document.

Stop Guessing: Your Mac Reports the Real Figure

Everything above is modelling. This part is measurement. The exact ceiling your machine gives the GPU is printed by two runtimes, and the tool above reads either one. Paste it in and the estimate is replaced by your machine’s own answer.

If you use llama.cpp, it is already in your startup output. Look for the line that begins ggml_metal_init:

ggml_metal_init: recommendedMaxWorkingSetSize = 51539.61 MB

If you use MLX, one line prints it:

python -c "import mlx.core as mx; print(mx.metal.device_info()['max_recommended_working_set_size'])"

Paste either of those into the tool above and it does the rest: it recognises the machine, works out the true fraction and moves the slider to it. The MLX output carries your memory size as well, so it configures everything in one go. The llama.cpp banner gives the ceiling alone, so pick your machine from the list first and paste after.

You will probably find your fraction is not 75%. That is the point. Ours is a modelled default for people who have not looked yet, and it stops being relevant the moment you do.

And please send it to us. Mail admin@vramcalculator.com with your chip, your memory and that number. The tiered rule does not exist in public, and it can only be built from machines we do not own.

You Can Raise the Limit

The ceiling is adjustable, which is the single most useful thing most Mac owners do not know about running models locally.

Leave the system 8 to 16 GB. That is the consistent advice from the people documenting this, and it is the reason the slider above stops at 92% rather than 100%. macOS still has to run, and a machine that has handed everything to the GPU does not fail gracefully.

Raising it is also what makes a Mac competitive on paper with a very different machine. An NVIDIA DGX Spark holds 128 GB and its single-node builds expect about 114 GiB of that free, roughly 96%. A 128 GB Mac starts at 75%. Most of that difference is a setting, not silicon.

Pooling Several Macs

Mac Studios and Minis get linked together for exactly the models unified memory is good at, and the memory adds up rather than being duplicated. That is not a community rumour: Apple documented it at WWDC26, in the session Explore distributed inference and training with MLX, running four M3 Ultras.

The weights are sharded. In Apple’s words, “MLX LM shards the model and coordinates the distributed inference for you.” Two ways to split it:

• Tensor parallelism, the default, splits the model by width, so “each machine holds part of every layer” and all of them work on the same token at once
• Pipeline parallelism splits it by depth, so each machine holds a group of layers and data moves through them in sequence

Either way the memory is divided, so the tool above multiplies your pool by the machine count. Apple’s own example is the clearest statement of why anyone bothers: Kimi 2.6 has a trillion parameters and needs roughly a terabyte at 8-bit, which “does not fit on a single M3 Ultra, but it can fit across four.”

The interconnect is new and it matters. Apple states that “starting in macOS 26.2, Remote Direct Memory Access protocol, shortly RDMA, is supported over Thunderbolt 5.” MLX’s own documentation adds the part that decides your setup: its JACCL backend provides RDMA over Thunderbolt and is “necessary for things like tensor parallelism”. Since tensor parallelism is the default, a cluster without Thunderbolt 5 is not blocked, but it is on the slower road, using ring-over-TCP instead.

This is also why the tool flags a multi-machine setup differently from a multi-GPU one. Thunderbolt is roughly an order of magnitude slower than the PCIe link between two cards in one box, so the advice is not the same advice.

MLX or llama.cpp

Both read the same ceiling, so neither gives you more memory to play with. They do differ in what they spend before the weights land.

MLX publishes its own benchmark table, on one 64 GB M4 Max, and the shape of it is informative. Plotting memory against effective bits per weight across two models, one 4B and one 30B, the slope recovers the parameter counts to within half a percent. That is only possible if MLX adds no proportional overhead at all, unlike the 2 to 5 percent the other runtime profiles in our calculator carry. What is left is a constant of about 1 GiB, and it holds steady across a 7.5x change in model size.

So in the tool above, MLX is modelled as roughly a gigabyte of fixed cost and nothing on top. It is a derived figure from published numbers rather than something we measured, and if MLX changes its allocator it will move.

What We Do Not Know, and Why We Are Saying So

This tool is an alpha, and the honest list of gaps is short but real.

The tier boundary. We model the default at 75% and show 65% as the floor. Where the true boundary sits, or whether machine size is even the variable, is undocumented. We are not going to ship a guessed cutoff, because a calculator that says no with confidence is worse than one that says it depends, here is how to check. The paste box is that check, and it is why this gap costs you nothing personally even though it is still a gap in the model.

Per-node overhead in a cluster. A sharded machine holds more than its slice of the weights, and nothing published says how much more. We model none of it, so cluster figures are optimistic by an unknown margin.

Mixture-of-experts on Metal. Liquid AI’s own numbers show a MoE model gaining 2.54x from speculative decoding on an H100 and only 1.18x on an M4 Max, which they attribute to how MoE currently runs on Metal in llama.cpp rather than to the method. Expect the memory picture to be steadier than the speed picture on Apple silicon.

Everything here is modelled, not measured on a Mac. We have not tested any of it on Apple hardware and do not claim to have. Every figure is arithmetic over published specifications, which is exactly why corrections from people who own these machines are worth more to us than another week of reading.

FAQ

How much of my Mac’s memory can the GPU use?
About 75% by default, so roughly 18 GB on a 24 GB machine and 48 GB on a 64 GB machine, though some machines report closer to 65%. Rather than trusting that range, paste your llama.cpp startup banner or one line of MLX output into the tool above and it will use your machine’s actual figure. It can also be raised with a system setting.

Can a 24 GB Mac run Qwen 3.8 27B?
At Q4_K_M with a short context, just barely: it needs 17.66 GiB against the roughly 18 GB a 24 GB machine allows by default. There is almost no room for a longer context, and if your machine reports a lower ceiling it will not load. A smaller quantization removes the doubt entirely.

Does adding a second Mac double the memory I can use?
Effectively yes, because MLX shards the model across machines rather than copying it to each. Apple demonstrates a trillion-parameter model running across four M3 Ultras that fits on none of them alone. Speed is the part that depends on your interconnect.

Do I need Thunderbolt 5 to cluster Macs?
Not to make it work, but the default parallelism strategy expects the RDMA path that Thunderbolt 5 provides, and macOS 26.2 is where that support arrives. Without it you fall back to a slower transport over ordinary networking.

Is MLX more memory efficient than llama.cpp on a Mac?
Slightly, and not for the reason people usually give. Both are bound by the same system ceiling. MLX appears to add no proportional overhead on top of the weights, where other runtimes add a few percent, so the difference is a fixed cost of about a gigabyte rather than a scaling advantage.