Apple's Mac Studio line now configures to 512GB of unified memory at 1.2TB/s of memory bandwidth on the M5 Ultra, according to Apple's published tech specs. That capacity is enough to load essentially any open-weight model that exists today. It does not make those models fast, because on a machine like this the binding constraint has never been how much fits - it is how quickly memory can be read.
Key facts
- M5 Ultra: 1.2TB/s memory bandwidth, configurable to 256GB or 512GB of unified memory.
- The 512GB option requires the higher M5 Ultra bin - 36-core CPU, 80-core GPU - not the base M5 Ultra.
- M5 Max tops out at 128GB and 614GB/s, roughly half the Ultra's bandwidth.
- Primary source: Apple Mac Studio tech specs.
Start with the correction, because it changes a purchase. Coverage has been compressing this to "the M5 Ultra goes to 512GB." Apple's specs page is more specific: the 512GB configuration is listed for the M5 Ultra with 36-core CPU and 80-core GPU. If you buy the base Ultra expecting to add memory later, you have bought the wrong machine.
Now the part people keep getting backwards.
Two different numbers govern whether a model is usable on a given machine, and they answer different questions. Capacity - the 512GB - determines whether the model fits. Bandwidth - the 1.2TB/s - determines how fast it runs. They are not interchangeable, and for text generation the second one is almost always the one that bites.
Here is why. When a language model generates text, it produces one token at a time, and producing each token requires reading the model's active weights out of memory and through the compute units. The math is barely doing anything by comparison; the machine spends most of its time waiting for bytes to arrive. So the practical speed ceiling is roughly memory bandwidth divided by the number of bytes touched per token. This is the well-understood reason LLM inference is memory-bound, and it is why a card with enormous compute and modest bandwidth generates text no faster than one with modest compute and the same bandwidth.
The analogy that holds: a warehouse and a loading dock. 512GB is a very large warehouse. 1.2TB/s is the width of the door. You can now store anything you want, and you still get it out one truckload at a time. Doubling the warehouse does nothing for the door.
In practical terms, 1.2TB/s puts a moderately sized model in low-bit form somewhere in the range of a few dozen tokens per second as an idealized upper bound, and drops very large dense models into the single digits to low teens before real-world overhead. Mixture-of-experts models fare much better, because only a fraction of the weights are active per token - which is exactly why mixture of experts architectures have become the default for anyone who wants a big model to run at conversational speed. Quantization helps for the same reason: fewer bytes per weight means fewer bytes through the door.
The most interesting artifact in the community reaction to the M5 generation is not a benchmark. It is a bug report.
llama.cpp issue 23212, "Deterministic temp=0 generation differs across Apple Silicon targets," was opened by Ivan Fioravanti after he ran the same evaluation on two Macs. Same model, same prompt, same seed, same maximum token count, temperature set to zero - the setting that is supposed to remove all randomness. The M5 Max scored 4 of 5 on a five-question math evaluation. The M3 Ultra scored 5 of 5. Every single case produced a different generated-token count on the two machines.
llama.cpp maintainer Georgi Gerganov's explanation is that the M5's Neural Accelerators produce different numerics than M3 GPU cores, and his practical advice is that cross-hardware evaluation comparisons should use recommended sampling parameters and multiple runs rather than assuming reproducibility. This is a concrete instance of a general property that surprises people every time: temperature zero is not deterministic. Floating-point arithmetic is not associative, different hardware reorders operations differently, and when two candidate tokens are nearly tied, a difference in the last bits of a probability flips the choice - after which the two runs diverge permanently.
For anyone benchmarking models locally, that is the more actionable finding of the two. A three-point swing on a five-question evaluation, caused entirely by which Mac ran it, is enough to reverse a conclusion about which model is better.
The honest caveats. Apple's pricing and the availability date for the 512GB configuration could not be verified from the specs page, and should not be assumed from secondhand coverage. Comparisons circulating against used datacenter GPUs - L40S, A100 80GB, H100 80GB - rest on listings nobody has verified and on an Apple price nobody has confirmed, so the "same money" framing is unsupported. And no maintainer-published M5 Ultra inference benchmark has surfaced yet; the throughput figures above are what the bandwidth arithmetic implies, not measured results.
What has genuinely changed is the shape of the question. For years the local inference conversation was "will it fit." Ground Truth has tracked that floor falling repeatedly - three ways the local inference floor fell, and full Kimi K3 running on sixteen desktop boxes. With 512GB on a desk, fitting is close to solved. What remains is speed, and reproducibility, and those are harder problems than buying more memory.
Originally published on Ground Truth, where every claim is checked against the primary source.
