Skip to content

The Mac Studio's Memory Ceiling for Local LLMs, by the Numbers

9 min read · updated August 11, 2026

The Mac Studio is the only personal computer you can buy with enough memory to hold a frontier-scale open-weights model, and the interesting question is not whether it fits but what you get for the money once it does.

What Apple publishes

From Apple’s Mac Studio technical specifications, read on 11 August 2026:

M4 Max   14-core CPU, 32-core GPU              410GB/s    36GB standard
         configurable to 16-core CPU, 40-core GPU  546GB/s    64GB on that chip

M3 Ultra 28-core CPU, 60-core GPU              819GB/s    96GB standard
         configurable to 32-core CPU, 80-core GPU  819GB/s

The specification page lists standard configurations; the chip-level maxima come from Apple’s Mac Studio announcement, which states that the M4 Max model starts at 36GB with support for up to 128GB, and that the M3 Ultra model starts at 96GB and can be configured up to 512GB — described there as the most unified memory ever in a personal computer.

These are the configurations on sale on 11 August 2026. Apple refreshes this product line and the whole table moves when it does; the arithmetic below survives the refresh but none of the numbers do.

The largest model each tier admits

MLX’s default quantization is 4 bits per weight plus an fp16 scale and bias per group of 64, so 4.5 bits per weight, or 0.5625 bytes. At 8 bits the same group overhead gives 8.5 bits, or 1.0625 bytes. Both figures are confirmed against real conversions read through the Hugging Face model API — a 70,553,706,496-parameter Llama-3.3-70B converts to 39,688,567,605 bytes at 4 bits, which is 4.50 bits per weight.

So the parameter count a tier admits, allowing nothing for context or for macOS, is:

tier      4-bit (0.5625 B/param)     8-bit (1.0625 B/param)
 36GB       ~64B parameters            ~34B parameters
 64GB      ~114B                       ~60B
 96GB      ~171B                       ~90B
128GB      ~228B                      ~120B
256GB      ~455B                      ~241B
512GB      ~910B                      ~482B

Subtract real headroom before believing any row. Metal’s reported max_recommended_working_set_size is meaningfully below installed RAM, and the KV cache is a per-token charge on top — for a 70B-shaped architecture, 0.328 MB per token, which is 10.7 GB at a 32k context. The method for both is in how much RAM a 70B needs on a Mac.

Sparse models change the arithmetic in your favour on capacity terms and against you on value-for-money: a mixture-of-experts model must be fully resident even though only its routed experts run per token, so 512 GB buys you the ability to hold a very large sparse model whose per-token work is that of a much smaller one.

Where capacity stops being the constraint

Above roughly 96 GB the binding constraint quietly changes. Decoding at batch size one reads the whole dense model once per token, so the ceiling is published bandwidth over model bytes, and on 819GB/s that is:

model bytes   ceiling at 819 GB/s
   39.7 GB          20.6 tok/s     (70B @ 4-bit)
   80.0 GB          10.2 tok/s     (~140B @ 4-bit)
  160.0 GB           5.1 tok/s
  320.0 GB           2.6 tok/s

batch one, dense, short context, 100% of published bandwidth —
an upper bound no real kernel reaches

The 512 GB tier can hold a dense model that it cannot decode at a speed anyone would sit through, because bandwidth did not scale with capacity: M3 Ultra offers 819GB/s at 96 GB and 819GB/s at 512 GB. Capacity is purchasable; bandwidth per chip is not. That asymmetry is the single most useful thing to understand before choosing a tier, and the underlying argument is in why Apple Silicon punches above its GPU compute.

What 512 GB is actually for

Given the row above, the large tiers are not primarily about running one enormous dense model interactively. The uses that survive the arithmetic:

  • Large sparse models. Where total parameters set capacity and active parameters set speed, a big memory tier converts directly into capability rather than into a slideshow.
  • Batch work. A ceiling of five tokens per second per sequence is unusable interactively and perfectly reasonable overnight across many sequences at once, because batching amortises the single pass over the weights across all of them.
  • Several models resident. A large model, a draft model for speculative decoding, an embedding model and a Whisper model in one process, with nothing evicted.
  • Long context on a large model. The KV cache is the term that grows without bound, and headroom is exactly what buys it.

Speculative decoding deserves the specific mention, because it is the one technique that beats the bandwidth ceiling for a single stream: a small draft model proposes several tokens and the large model verifies them in one pass over its weights. The MLX server exposes it as --draft-model.

Reading this before you order

Memory is soldered to the package, so the tier you order is permanent — there is no second slot and no upgrade path. That makes the decision asymmetric in a way most computer purchases are not: buying one tier too much costs money once, and buying one tier too little costs you the model you wanted for the machine’s whole life.

Concretely: work out the exact byte count of the specific model you want to run, add the KV cache at the context length you actually use, compare against the working set your prospective machine would report rather than its headline RAM, and only then look at the bandwidth column to find out whether the result will be pleasant. If the answer is a ceiling in the low single digits of tokens per second, the tier below with a smaller model will be a better machine.

Two traps in the configurator itself. The bandwidth figure is attached to the chip configuration, not to the product — an M4 Max Studio is 410GB/s in the base configuration and 546GB/s with the 16-core CPU and 40-core GPU, a thirty-three per cent difference in exactly the number that governs decode speed, hidden behind a CPU and GPU core count. And on the M4 Max the largest memory tiers are only offered on the upgraded chip, so the capacity decision and the bandwidth decision are not independent even though they are presented as separate line items.

Finally, a model you are choosing hardware for today may not be the model you run in a year. The one thing the table above says with confidence is that memory tiers have grown far faster than bandwidth has — the generation-by-generation figures show 800, 800 and 819 GB/s at the Ultra tier while capacity went from 128 GB to 512 GB. Buying for capacity is buying into the trend; buying for single-stream speed is buying into the part that has barely moved.