Show HN: Which Mac runs which LLM, and how fast

Two numbers decide everything about running a model locally on Apple Silicon. Whether it fits in unified memory, which is arithmetic on the parameter count. And how fast it generates, which is memory bandwidth divided by the size of the weights. Pick your Mac and your model below and the calculator does both.

Yes. Llama 3.3 70B at Q4_K_M runs on M4 Pro with 64 GB.

Expect roughly 5.7 tokens/sec of generation. The weights are 42.8 GB, the 8K tokens context adds about 1 GB, and 53.2 GB of your 64 GB is spoken for once macOS is accounted for.

Rent a Mac that runs it: M4 Pro Mac mini with 64 GB

$197/mo billed annually, or $286/mo billed monthly. A dedicated machine with Ollama and an OpenAI compatible endpoint, ready in about 5 minutes.

That answer costs money. 56 GB of unified memory is not a cheap option on any Mac.

Worth knowing before you commit to the hardware: a month on a rented M4 Pro with 64 GB costs $286, which is enough to run Llama 3.3 70B on your own documents and find out whether 5.7 tokens/sec is actually fast enough for what you had in mind.

·The full buy versus rent arithmetic

Full guide for Llama 3.3 70B ·Measured benchmarks

The two formulas

Memory. Weights in gigabytes are parameters in billions times bits per weight divided by eight. Q4_K_M averages about 4.85 bits once GGUF metadata is counted, Q8_0 about 8.5, FP16 exactly 16. Add 15% for runtime overhead, add the KV cache for your context length, then leave 3 GB for macOS. A model that fits with nothing spare will swap to SSD the moment you paste a long document, and swapping costs far more than any quantization ever saves you.

Speed. Generating one token means reading every active weight out of memory exactly once, so bandwidth divided by weight size sets the ceiling. Sitting on top of that is a fixed cost per token that does not shrink with the model: sampling, kernel launches, framework overhead. Seconds per token is the sum of the two. Fitted against the eight dense runs we measured on two machines, a base M4 and an M5 Pro, that comes out at 90.8% of theoretical bandwidth plus 3.3 ms of overhead, and reproduces every one of those runs to within 4.6%.

That second term is what most calculators leave out, and it is why their numbers stop making sense at the small end. Bandwidth alone predicts 525 tokens/sec for Llama 3.2 3B on an M5 Ultra. Ours predicts 177, because once the weights are down around two gigabytes the fixed cost per token, not the memory bus, is what you are up against. Method and raw JSON for the underlying measurements are on the benchmarks page, and the model with its data and tests is on GitHub under MIT, so you can check it against your own runs.

Worth knowing before you spend money on the strength of a number from a web page.

Minimum memory assumes an 8K context and 3 GB left for the system. Speeds are generation, in tokens per second. A dash means the model does not fit on that chip at its maximum memory configuration.

Speeds for each chip assume its largest memory configuration: M4 at 32 GB, M4 Pro at 64 GB, M4 Max (40-core GPU) at 128 GB, M5 Ultra at 512 GB.

The single most useful table if you are choosing hardware, because bandwidth is what you are actually buying. Figures are Apple’s own published specifications, verified 2026-09-11. Each chip people commonly use for inference also has its own page with the full model by model breakdown at each memory configuration.

About 56 GB at Q4_K_M with a short context: roughly 43 GB of weights, 15% runtime overhead, a gigabyte or two of KV cache, and 3 GB left for macOS. That makes 64 GB the smallest practical configuration, which in the current lineup means an M4 Pro, M5 Pro, or any Max or Ultra chip. At Q8 the same model needs around 128 GB.

Barely, for generation. Producing one token means reading every active weight out of memory once, so generation speed is set by memory bandwidth, not GPU cores. A 24 GB M4 with more GPU cores runs an 8B model at the same speed as a 16 GB M4 because both sit on the same 120 GB/s bus. Prompt processing is the exception: that stage is compute bound and does scale with cores.

They reproduce our own measurements to within 4.6%. The fit rests on ten runs across two machines: six models on a base M4 at 120 GB/s, and four on an M5 Pro at 307 GB/s. The second machine is the interesting one, because the constants were fitted before we had it. At two and a half times the bandwidth the dense predictions still land within 4.1%: 47.4 tokens/sec predicted for Qwen3 8B against 47.8 measured, 28.2 for Qwen 2.5 14B against 29.4. Everything outside those ten runs is extrapolation from the same two constants rather than a reading off a machine. Treat them as planning numbers, accurate enough to choose hardware by and not precise enough to quote.

Because a model that fits with nothing to spare is a model that swaps. macOS, a browser, and whatever agent process is calling the model all need memory, and once the machine starts paging to SSD the generation speed collapses regardless of what the bandwidth math says.

Memory yes, speed no. An MoE model has to hold every expert in unified memory, so the total parameter count decides whether it fits. Per token it reads only the active experts, so generation speed follows the active parameter count. That is why a 671B MoE with 37B active can generate faster than a dense 70B while needing eight times the memory.

If the model you want needs 64 GB or more and the machine has to be reachable around the clock, buying is not the only option. We rent dedicated Apple Silicon with Ollama already installed and an OpenAI compatible endpoint already exposed, from a base M4 Mac mini at $99/mo up to a 256 GB Mac Studio. Same hardware, same math as this page, none of the hosting.