Why the Biggest Local Models Won't Load on a 512 GB Mac

Here is a puzzle worth sitting with. GLM-5.2, the 744B-parameter mixture-of-experts flagship, has a 4-bit MLX quant that is about 418 GB on disk. That fits, with room to spare, on a 512 GB Mac Studio. We pulled it, pointed MLX at it, and it would not load. macOS killed the process partway through loading. No crash in the model, no bad file, just gone.

That gap between "fits on disk" and "will load" is one of the least-understood realities of running large models on Apple Silicon, and it is worth understanding precisely, because the fix people reach for first usually makes things worse.

Usable memory is smaller than total memory

Unified memory is the headline number on an Apple Silicon Mac, but not all of it is available to hold model weights. Three things take a cut before your model gets any:

• The system reserve. macOS needs headroom to function. Push allocation toward 100 percent and you get beachballs, then lockups. Several GB has to stay free.
• The GPU wired limit. macOS caps how much unified memory the GPU can wire down, near 66 to 75 percent of total by default. Weights that live in GPU memory are bound by that cap unless you change it.
• Load and KV headroom. A model needs working memory above its steady-state footprint: transient buffers while weights are materialized during load, plus the KV cache once it runs. The peak is higher than the on-disk size.

Stack those up and the practical ceiling for a resident model sits well below the number on the box. A model whose file size looks comfortable can still overshoot the ceiling once loading is underway.

The load-time spike is where the biggest models die

Steady-state footprint is not the binding constraint. The load transient is. As MLX materializes the weights, peak memory rises above the eventual resident size before settling. On our 512 GB machine loading the ~418 GB GLM-5.2 quant, that peak crossed physical RAM, and macOS did what it does under real memory pressure: it killed the process. The model that "fit" never finished loading.

This is why disk-size math misleads. A 418 GB file on a 512 GB Mac leaves 94 GB on paper, but the load peak needs more than that margin, and the wired limit has already fenced off a large slice. The headroom that looked generous was already spoken for.

The iogpu.wired_limit_mb footgun

The tempting fix is to raise the GPU wired limit:

sudo sysctl iogpu.wired_limit_mb=458752   # e.g. 448 GB on a 512 GB Mac

For a model sitting just past the default cap, this genuinely helps, and it is the right tool there. But it is not a memory multiplier, and for a model near the physical ceiling it is a footgun on two counts:

• It cannot create memory that is not there. If the load peak exceeds physical RAM, raising the wired limit does not change the outcome. The process still gets killed. That was our GLM-5.2 case: the ceiling was physical, not a policy cap.
• Set it too high and you starve macOS. Wire down nearly all of unified memory and the system has nothing left to work with, producing beachballs, stalls, and lockups that look like a hang. Always leave the system its several GB.

This is a ceiling, not a verdict

Here is the part that matters most, and the reason we are documenting the ceiling rather than the model. Ollama Herd is an open-source project we run as a hobby, and this 512 GB Mac Studio is simply the most memory we could afford to put behind it. We are sharing what we ran into to help, not drawing a line for anyone else. Our result is one data point on one path. The very same 4-bit GLM-5.2 weights reportedly load on the same 512 GB Mac through a different runtime (GGUF via llama.cpp, whose load path behaves differently). A different quantization changes the footprint. Larger or newer hardware changes the ceiling outright. None of that is "GLM-5.2 does not run locally." It is "the MLX 4-bit load path overshoots the usable ceiling on today's largest single Apple Silicon Mac."

So if you have the hardware, or a different runtime, or a smaller quant: try it. Measure the real load peak on your machine, and if it loads where ours did not, that is a genuinely useful result. If it fails in a new way, that is worth an issue upstream on mlx-lm. The frontier of what runs locally moves because people test the edges and report back, not because anyone's single machine drew the line. Our ceiling should be your starting point, not your limit.

How to think about the real ceiling

When you are sizing hardware or picking a quant, plan against usable memory, not total:

The practical takeaway: a model whose 4-bit file is within a slice of your total memory is the one to be careful with. Leave margin, measure the load peak, and raise the wired limit deliberately rather than reflexively. For the sizing math on models that comfortably fit, see the Mac memory guide, and for what we verified actually runs, the tested-models page.

Related Reading

• Mac memory guide, matching models to unified memory
• Models tested on Apple Silicon, the hardware-verified matrix
• MLX vs Ollama, the two backends and when each fits