'GLM-5.2 is faster than Qwen' doesn't hold on a 64GB Mac — active 40B vs 3B, and SSD streaming, measured

Originally published on Zenn (Japanese). Cross-posted here.

"GLM-5.2 is supposedly faster than Qwen, so I want to switch my local AI over to it." I went in thinking that, tested it on an M1 Max (MacBook Pro) with 64GB of unified memory, and the conclusion I reached was the opposite. Don't switch. There are two reasons: ① it doesn't even fit in 64GB, and ② even if it did, it is roughly 13× slower by principle. This article is the record of that investigation, and as an anchor for comparison I include my own machine's measured Qwen3.6 figure (60.6 tok/s, median of three runs).

The bottom line up front: "open-source and fast" is true, but not on your machine

GLM-5.2 is an MIT-released 753B (753-billion) parameter MoE model, and anyone can download the weights. "Open source" is no lie. But what hardware can run it is a separate question, and measuring the two points below did not change the answer for a 64GB Mac.

• Even quantized to the extreme it won't fit in 64GB (217GB even at 1-bit)
• An MoE's effective speed is governed by "active parameters," not "total parameters," and GLM-5.2 is about 13× worse here too

The principle of speed: MoE is governed by memory bandwidth × active parameters

A Mixture of Experts (MoE) model does not use all its parameters to generate each token. A router selects only some of the "experts" to compute with. This "number of parameters actually used per token" is the active parameter count, and decode speed is almost entirely determined by it (precisely, "memory bandwidth ÷ the bytes of active parameters"). The total parameter count matters for the storage a model needs, but barely affects speed.

	Qwen3.6 (current, my machine)	GLM-5.2
Total parameters	34.7B MoE	753B MoE
active/token	3B	40B
Real work per token	1×	~13×
Placement	21GB resident on GPU (unified-memory bandwidth)	Won't fit in 64GB, goes via SSD

GLM-5.2's "real work per token" (active 40B) is larger than Qwen3.6's total parameter count (34.7B). Sources: huggingface.co/zai-org/GLM-5.2, and ollama show on our own machine (2026-07-18).

In other words, run on hardware with the same memory bandwidth, GLM-5.2 is by principle roughly 40B ÷ 3B ≈ 13× slower. The "GLM-5.2 is smart, so it's fast" rumor probably originates from one of these:

1. Speed on z.ai's cloud API — that's data-center GPUs. It really is fast there.
2. "It's smart, so there's less rework, so it's effectively faster" — a legitimate reading, but as shown below, at around 2 tok/s this advantage evaporates.
3. Comparisons on 512GB-class machines — the level referenced against DeepSeek-V4 and the like, not a story about a 64GB Mac.

It won't fit in 64GB in the first place: the actual quantization-size table

Lining up the sizes of unsloth's GGUF quantizations (unsloth/GLM-5.2-GGUF) shows in hard numbers that no amount of quantization brings it under 64GB.

Fitting it into 64GB would require 0.7 bit/param. Going below 1 bit is unreasonable by information theory. Source: unsloth/GLM-5.2-GGUF (HuggingFace).

Even 1-bit (the floor of the world) is 217GB — 3.4× the 64GB. This is not a gap that quantization improvements can close; it's an order of magnitude off.

There's a trap here. SixVolts/GLM-5.2-ewaste-edition-GGUF, as the name suggests, claims to be "for underpowered hardware," but the actual sizes were 226.9GB for Q2_K_XL and 403.8GB for Q4_K_XL. Read the README and it plainly states Q2_K_XL is designed "to load with zero spill onto 256GB (32GB×8)." The intended reader's machine is 4× mine. Judge by the name alone and you'll crash. (Incidentally it's also the quality floor, with perplexity +27% relative to Q3_K_M.)

The way it's offered on Ollama is misleading too. The tag on ollama.com/library/glm-5.2 is a single glm-5.2:cloud with no GB size shown. You can call it with ollama run, but that runs server-side on Ollama Cloud, not your machine. Don't count it as local AI.

A loophole did exist — but it required a retraction

At this point in the investigation I nearly declared "impossible on 64GB," but that was wrong. It's only true under the premise "keep all the weights resident in RAM," and an implementation that drops that premise exists.

andreaborio/glm52-ds4-native-64g-q2k-experimental (HuggingFace, MIT) leaves the GGUF body — 244.14GiB (6 shards + SHA-256 manifest + rebuild script) — on the SSD, and holds resident memory to 19.56GiB. The breakdown: attention/router/shared experts at q8_0/f16, the routed MoE part at q2_k for 224.44GiB. The runtime is antirez/ds4 — the glm5.2 branch of the auditable LLM runtime written by Salvatore Sanfilippo (the author of Redis) — which bundles the 2,600 most-frequently-used layer/expert pairs into a separate pack, so the original GGUF doesn't need to be modified.

The key to this implementation is that it recovers the MoE "only 40B active" property through disk bandwidth rather than RAM capacity. It swaps just the needed experts in and out of 19.5GB of RAM.

The measured speeds the author publishes are these three points (test environment: AWS L40S + Apple M5 Pro 64GiB — reference values only, not measured on my own M1 Max).

Context length	Speed
n=8	2.52 tok/s
n=32	2.28 tok/s
n=64	2.01 tok/s

I list all three points instead of averaging for a reason: the trend itself — speed drops as context grows — is the information. The test environment is AWS L40S + Apple M5 Pro 64GiB, and I'll state clearly that it is not a measurement on an M1 Max.

And before you take these numbers at face value, there are caveats from the author himself worth reading.

• Explicitly labeled "still CPU diagnostic code"
• No quality testing done; it's at the stage of passing a smoke test that outputs "Paris"
• Normal ds4 generation is still disabled; what works is only the --glm-dsa-preview short-context preview path
• → GLM-5.2's biggest selling point, the 1M context, is unusable
• Long-context DSA indexer, production integration, and full-graph Metal/CUDA execution are unimplemented
• Downloads and likes aren't tracked (= no evidence of wide use)

Stated precisely: "Impossible resident in RAM; runs at around 2 tok/s with streaming (but at the diagnostic stage)." Neither "completely impossible" nor "already practical" — the truth is in between.

My own measurement: I couldn't measure it once, then measured after the GPU freed up

The procedure for measuring my own machine's real tok/s (Qwen3.6, 34.7B MoE, active 3B) as a comparison target is itself simple. I send a request through our in-house GPU arbitration script (a homemade wrapper that queues jobs so multiple generation jobs don't fight over the same unified memory) to ollama's generate API, and compute tok/s from the response's eval_count and eval_duration.

But the first attempt timed out with no response. The cause was in the arbitration script's design. When acquiring the lock, it stops the Ollama process itself (SIGSTOP) to yield the GPU to other jobs. When the measurement target is Ollama itself, as here, it ends up stopping itself and then trying to talk to itself, so no response comes back. The arbitration wrapper was built specifically for the case where "video/image generation steals the GPU from Ollama"; measuring Ollama itself was out of scope. Another video-generation job was also running in the background, and judging that this was not a value worth forcing an interrupt to measure, I passed on measuring at that moment.

Later, at a moment when I could confirm GPU utilization at 3% with no other generation jobs, I re-measured. To avoid swap from unified-memory co-residency, I first stopped the image-generation server (ComfyUI) that had been resident in the background, freeing reserved memory from 51GB → 42GB, and in that state sent the request without going through the arbitration wrapper (freezing the very thing you want to measure would defeat the purpose). Here are the results with num_predict=300, three runs each, median.

Model	Size	Median tok/s	Three runs
qwen3.6 (35B-A3B MoE)	23.9GB	60.6	60.3 / 60.6 / 61.0
qwen3.6-uncensored-cc	21.2GB	60.3	60.3 / 60.3 / 60.5

The spread is a minuscule 0.2–0.7 tok/s, and being the median of three runs rather than a single shot, it's a trustworthy value. Prefill (prompt eval) is about 593 tok/s. That the two models are nearly the same speed — despite the size difference (21GB vs. 24GB) — is itself corroboration of this article's thesis: the real work of active 3B is the same, and total size doesn't affect speed.

And the crucial comparison: against my machine's Qwen3.6 at ~60 tok/s, GLM-5.2 (ds4 streaming) is a reference ~2 tok/s. A gap of roughly 30×. On top of the 13× predicted by the active-parameter principle, the disk-bandwidth penalty of SSD streaming is added, widening it beyond the theoretical value. "Smart, therefore fast" is not realistically going to close this gap on a 64GB machine.

One lesson worth recording: a benchmark is not a value worth rushing to grab at the cost of stopping other GPU jobs. Rather than forcing your way in when things are busy, waiting for it to free up and measuring in a clean state gives both more trustworthy numbers and healthier operations. That's what I did here.

A procedure for doubting primary sources: "GLM 5.2 Air" turned out to be fake, by self-contradiction

During the investigation I found a benchmark site (llmcheck.net) listing per-Mac tok/s for "GLM 5.2 Air / 106B / Q4_K_M" (M4 Ultra 192GB = 38, M5 Max 128GB = 34, M5 Max 64GB = 30, M4 Max 128GB = 26 tok/s). "30 tok/s on a 64GB Mac" would be an appealing number, but verification revealed these three things.

1. A model called "GLM-5.2-Air" does not exist. HuggingFace's zai-org/GLM-5.2-Air is a 401 (repository absent). Z.ai's official release (2026-06-13) makes no mention of Air, and HF discussions like "Air or Flash model coming?" and "We need some Air" remained requests, unanswered. If the model already existed, those threads wouldn't be up.
2. The same page contradicts itself. It clearly states "106B / Q4_K_M," but the measured Q4_K_M of 106B-A12B is bartowski/TheDrummer_GLM-Steam-106B-A12B-v1-GGUF at 72.9GB, which doesn't fit a 64GB machine. So the page's own quantization and its own "runs on a 64GB Mac" cannot both be true.
3. From these, I judged it a misprint of the real GLM-4.5-Air (110B-A12B) as "GLM 5.2 Air."

I record it as a procedure: there are cases where you can judge truth or falsehood purely by whether the statements within a single page are consistent, without asking anyone externally. (For the record, the real GLM-4.5-Air 110B-A12B does have quantizations that fit 64GB, but I've excluded it here on the judgment that the current Qwen3.6 is stronger.)

Reproducible takeaways

When a new model gets buzz, judging "does it run on my machine" from headlines alone — "huge parameter count," "open-source and free" — leads to crashes. The two axes I used in this investigation were just:

1. GB of the smallest quantization — if even the most aggressively quantized version won't fit your machine's memory, there's no point considering it further.
2. active/token — not total parameters, but the parameters actually in motion per token, determine speed.

Checking just these two first settles most of the "does it fit" / "is it fast" question. For GLM-5.2, both axes came out harsh for a 64GB Mac. That said, the strong phrasing "impossible unless resident in RAM" is wrong — a diagnostic-stage loophole, SSD streaming (ds4), does exist. On that one point alone, I retract my initial judgment.

The scope I measured is one machine, M1 Max 64GB only, and I'm not generalizing. Other models and other machines could reach different conclusions, and I state that as a premise. On that basis, three questions where the answers aren't settled and only readers seem likely to hold the information:

1. Is anyone actually using the ds4 streaming version day-to-day? The author explicitly states no quality testing has been done — are there uses where ~2 tok/s is practical?
2. Does anyone know real information about GLM-5.2-Air/Flash existing? llmcheck.net had a row, but I could find neither an official announcement nor an HF repository.
3. Does anyone have M1-Max-generation measured values for GLM-5.2 (ds4)? I managed one M1 Max data point on the Qwen3.6 side (60 tok/s), but couldn't find an M1 Max measurement on the GLM side. Most benchmark sites skew toward the M4/M5 generation, and numbers for a four-year-old machine are barely out there.