GLM 5.2 at 4-Bit With MTP: The Easiest Way In

GLM 5.2 at 4-Bit With MTP: The Easiest Way In

And the 512GB Mac Studio that Apple just stopped selling.


Apple discontinued the 512GB Mac Studio. Not the chip — the M3 Ultra is still on the shelf — but the 512GB unified memory configuration, the one that cost as much as a used car and sold in numbers that probably did not fill a warehouse. Quietly struck from the catalog. Which is a strange thing to do at the exact moment it became the only consumer machine on Earth that can run GLM 5.2 at 4-bit in a single box.

We have spent two years watching the local LLM crowd chase frontier-class models on Apple Silicon. The pattern is always the same. A model lands. The 192GB machines try. They get something running at 3 tokens a second. The owner posts a screenshot. The thread declares victory. Everyone goes back to CUDA.

GLM 5.2 is different. Not because it is smaller — it is not. It is different because at 4-bit it lands at 418.1 GB, which means the 512GB Mac Studio is the only desktop that can hold the model and still leave room for a real context window.

The “fabled” owners (or a lucky bunch at that) — the few thousand who bought the configuration before it vanished — are sitting on something odd. A discontinued machine that, for one specific workload, has no peer.

The Model, Briefly

GLM 5.2 is Zhipu’s open-weights frontier model. Dense-class reasoning in a Mixture-of-Experts shell, with a Sparse MLA attention mechanism that matters more than the marketing suggests — we will come back to that. It sits in the same weight class as the recent Chinese open-weights releases that have been making Western labs uncomfortable: Kimi K3, DeepSeek, Qwen3, GLM 5.2. The cohort that turned “Chinese models” from a punchline into a price-umbrella problem for the incumbents. A new one lands every few weeks now. GLM 5.2 happens to be the one that fit.

At FP16 it is ENORMOUS. At 8-bit it is still too large for any consumer machine. At 4-bit, with dynamic mixed-precision quantization, it lands at 418.1 GB. That number is the whole story.

Why Q4 Is the Sweet Spot

Quantization is not free. Every bit you shave off adds error. The question is where the error becomes visible, and the answer, for GLM 5.2, is well-documented.

Unsloth’s testing lands on a clear verdict: dynamic 4-bit (UD-Q4_K_XL) and dynamic 5-bit (UD-Q5_K_XL) are “mostly lossless.” Above Q4, you are spending memory for accuracy you cannot measure in practice. Below Q4, you start to feel it — not in benchmarks so much as in the texture of the outputs. Q3 still scores. It just sounds like a slightly different model.

Q4 is the knee of the curve. The point where the model still reasons like itself, and the file still fits on a machine you own.

This is not a new insight. The llama.cpp community settled on Q4_K_M as the default two years ago for the same reason. What is new here is that GLM 5.2 at Q4 is the first time a frontier-class model has landed at a size a single desktop can actually hold. 418 GB is not a server-room number. It is a “if you bought the weird config” number.

The Decode Problem

There has always been a catch with local frontier inference, and it is not prefill.

Prefill — the part where the model reads your prompt — is embarrassingly parallel. Apple Silicon is good at it. A 4-bit GLM 5.2 on a 512GB Mac Studio will prefill at 187 tok/s at 1k context. Even at 32k context, baseline is 87.7 tok/s. Respectable, not CUDA-fast, but certainly not at the same price point.

Decode is the problem. Generating new tokens, one at a time, is memory-bandwidth bound. You are reading the entire model weight file for every token. Baseline decode on GLM 5.2 at Q4 sits at roughly 14–15 tok/s. Fine. Usable. Not fast.

This is where MTP comes in.

Multi-Token Prediction. Instead of generating one token per forward pass, the model predicts several — drafting future tokens in a single pass and accepting them in bulk when they check out. The math is denser than that, but the user-facing effect is simple: fewer passes through a 418 GB weight file for the same number of output tokens. The speedup is not theoretical. On GLM 5.2 at Q4 on the same Mac Studio, users report MTP lifting decode to roughly 24 tok/s — a meaningful gain on the metric that actually matters for interactive use.

It does not sound like much until you use it. 14 tok/s is “I am watching it think.” 24 tok/s is “I am having a conversation.”

MTP does nothing for prefill. Prefill is already embarrassingly parallel — you process the whole prompt in one forward pass, so there is nothing to draft ahead of. MTP is strictly a decode-side optimization. The prefill gains are a separate story.

The Prefill Bonus

Separate from MTP: PR #1984 in oMLX, merged in late June, bundled native Sparse MLA DSA kernels for GLM 5.2. This is a prefill-only optimization — decode is untouched. The numbers are worth stating plainly.

At 32k context, prefill goes from 87.7 to 174.4 tok/s. A 1.99x speedup. Peak memory drops by 18.5 GB.

At 16k, prefill goes from 128.1 to 178.9 tok/s. 1.40x.

At 4k, 1.13x. At 8k, 1.17x. The longer the context, the bigger the win.

This is the Sparse MLA attention path paying off. The model’s architecture was designed for exactly this kind of kernel, and oMLX is the first few inference servers to ship the native implementation on Apple Silicon. Token generation is flat — the PR does not touch decode — but for long-context work the prefill gains are the difference between a model you use and a model you wait on.

The practical implication: you can run GLM 5.2 at Q4 with 32k+ context on a 512GB Mac Studio without the prefill tax that used to make long-context local inference painful.

The Easiest Way In

Here is the part that surprised us.

oMLX is not a research project. It is a menu bar app. The hard work — the custom kernels, the MTP integration, the tiered KV caching, the continuous batching — is done. The user-facing surface is an icon in your menu bar.

Install, if you are on Homebrew:

brew install omlx --HEAD --with-custom-kernel

Or, if you prefer pip:

OMLX_WITH_CUSTOM_KERNEL=1 pip install -e .

The --with-custom-kernel flag matters. That is what builds the Sparse MLA DSA kernels from PR #1984. Without it, you get the pure MLX fallback, which works but leaves the 1.99x prefill gain on the table.

From there: launch the app, point it at a GLM-5.2-oQ4 checkpoint, enable MTP, and you are running a frontier-class model from the same UI chrome as your Bluetooth settings. Continuous batching. Tiered KV caching. Tool calling. The whole server-grade machinery, in a menu bar icon.

This is the “easiest way” part, and it is genuinely easy. Two years ago, getting a frontier model running on Apple Silicon meant a weekend of swapping MLX forks, patching headers, and reading GitHub issues at 2am. Now it is a brew command and a click. The CUDA stack still has its place — a 4090 rig will out-token a Mac Studio on smaller models, and always will — but for the one specific workload of “frontier model, 4-bit, long context, single box, no GPU closet,” oMLX on a 512GB Mac Studio is now the cleanest path that exists.

Who This Is For

To be blunt: this is for the fabled owners. The 512GB Mac Studio is the constraint. If you have one, GLM 5.2 at Q4 with MTP is now the most interesting thing you can do with it — more interesting, frankly, than anything Apple themselves will ship for that machine in its lifetime.

If you do not have one, the math is unforgiving. The 256GB configurations cannot hold the model. The 192GB configurations cannot get close. Cloud is cheaper if you just need occasional API access. The window for “frontier model on a single desktop” is, for now, closed to new buyers.

The Bottom Line

The 512GB Mac Studio is gone. Apple is not bringing it back. If you have one, you are now in a small and shrinking cohort of people who can run a frontier-class open-weights model at 4-bit, with MTP, with long context, from a single desktop, without a GPU stack in the closet.

If you do not have one, this article is not for you — and we are aware of the oddness of writing it anyway. The honest version: GLM 5.2 at Q4 with MTP on oMLX is the cleanest demonstration we have seen of where local LLM inference is going. The model is open. The quantization is mostly lossless. The kernel work is done. The server is a menu bar app. The only thing missing is the machine — and Apple just stopped selling it.

For the fabled owners: run, do not walk, to oMLX. Your hardware just got a second life.


Sources: oMLX · PR #1984 — Sparse MLA DSA kernels · Reddit: GLM 5.2 on Mac Studio speedup PR · Unsloth: GLM 5.2 quantization

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *