Direct verdict: yes, but only at the edge of what “run” can honestly mean. The smallest live Unsloth two-bit files are 238.459–238.578 decimal GB, which is 222.082–222.193 GiB. On a Mac that actually reports 256 GiB of physical unified memory, that leaves about 33.8–33.9 GiB before macOS, Metal buffers, runtime workspace, prompt processing, KV cache and safety headroom.
One community reproduction reports that UD-IQ2_XXS loaded on an M3 Ultra Mac Studio with 256GB, stayed out of swap at a 2K context, and generated roughly 15.7–16 tokens per second. That is credible evidence of a useful small-context local session. It is not evidence that 128K is dependable, that one million tokens is practical, or that the two-bit model retains the official checkpoint’s coding and agentic scores.
For a dedicated 256GB machine, 8K is credible and 32K is the sensible target. A 128K allocation is a carefully tuned experiment, most plausibly with Q8 KV cache. One million tokens does not fit alongside the two-bit weights, and its cold prefill would take hours even if memory were solved.
This investigation answers the hardware question created by current quantizations and streaming runtimes. Kingy AI’s separate GLM-5.2 launch analysis covers the release, official benchmarks and model positioning; those scores are deliberately not repeated or assigned to the quantized builds here.
Immediate verdict
| Question | Answer on a 256GB Mac Studio | Evidence level |
|---|---|---|
| Can it be downloaded? | Yes. The smallest two-bit directory is 238.459GB across six GGUF shards. Allow roughly 270–300GB of free SSD space so download tools, caches and partial files do not strand the install. | Live repository fact plus engineering allowance |
| Can it be memory-mapped? | Yes. A 64-bit process can map the sharded GGUF. Mapping establishes an address range; it does not prove that every page can remain resident during inference. | Runtime fact |
| Can it load without swap? | Conditionally. One M3 Ultra 256GB owner reports no swap or compression with UD-IQ2_XXS, llama.cpp b9691 and a 2K context. UD-IQ2_M looks feasible by arithmetic but lacks the same 256GB reproduction. UD-Q2_K_XL reportedly hit a Metal command-buffer OOM. |
Unverified community report plus engineering inference |
| Can it retain a useful context window? | Yes at 8K; reasonably at 32K. 128K is knife-edge and should be treated as experimental. The configured 1,048,576-token ceiling is not viable with resident IQ2 weights on 256GB. | Checkpoint fact plus calculated budget |
| Can it run at interactive speed? | For short-context decode, apparently yes. The best relevant 256GB report is about 15.7–16 tok/s on ordinary prompts, but its b9691 build predates corrected IndexShare support. Long prompts can spend minutes in prefill before the first generated token. |
Unverified community report on an obsolete runtime |
| Does Q2/IQ1 preserve coding and agentic capability? | Unknown—and not demonstrated. No matched task-level evaluation was found for the exact 238.459GB or 238.578GB Unsloth build. Official full-model scores cannot be inherited. | Evidence gap |
The labels matter. Checkpoint fact means a value read from a pinned official or quant repository. Vendor claim means the developer’s own measurement. Third-party reproduction means a named tester published enough detail to inspect. Community report means useful but unverified testimony. Engineering inference means arithmetic from stated assumptions, not a benchmark.
Exact checkpoint and quant sizes
The live official checkpoint is zai-org/GLM-5.2 revision b4734de4facf877f85769a911abafc5283eab3d9. Its serialized metadata contains 753,329,940,480 parameters. The 282 weight shards total 1,506,667,387,408 bytes: 1,506.667GB, 1,403.193GiB, or about 1.370TiB. The live config has 78 backbone layers, 256 routed experts with eight selected per token, three initial dense blocks, MLA, IndexShare, one appended MTP layer and max_position_embeddings of 1,048,576.
The current Unsloth conversion is unsloth/GLM-5.2-GGUF revision abc55e72527792c6e77069c99b4cb7de16fa9f23. These are exact live shard sums, not the rounded sizes printed on a model card:
| Unsloth directory | Shards | Exact bytes | Decimal GB | GiB | Fits resident in 256GiB before overhead? |
|---|---|---|---|---|---|
UD-IQ1_S |
6 | 216,715,360,960 | 216.715 | 201.832 | Yes, 54.168GiB gross margin |
UD-IQ1_M |
6 | 228,492,966,624 | 228.493 | 212.801 | Yes, 43.199GiB gross margin |
UD-IQ2_XXS |
6 | 238,458,632,928 | 238.459 | 222.082 | Yes, 33.918GiB gross margin |
UD-IQ2_M |
6 | 238,577,580,768 | 238.578 | 222.193 | Yes, 33.807GiB gross margin |
UD-Q2_K_XL |
7 | 253,878,401,856 | 253.878 | 236.443 | On paper, but only 19.557GiB remains; a Mac OOM is reported |
UD-IQ3_XXS |
7 | 281,688,431,424 | 281.688 | 262.343 | No |
UD-IQ3_S |
8 | 308,641,029,024 | 308.641 | 287.444 | No |
UD-Q3_K_M |
9 | 342,735,510,656 | 342.736 | 319.197 | No; 512GiB candidate |
UD-Q3_K_XL |
9 | 342,965,972,096 | 342.966 | 319.412 | No; 512GiB candidate |
UD-IQ4_XS |
9 | 365,313,223,776 | 365.313 | 340.224 | No; 512GiB candidate |
UD-IQ4_NL |
9 | 372,661,644,384 | 372.662 | 347.068 | No; 512GiB candidate |
UD-Q4_K_S |
10 | 436,431,842,432 | 436.432 | 406.459 | No; 512GiB candidate |
UD-Q4_K_M |
11 | 465,825,525,088 | 465.826 | 433.834 | No; 512GiB candidate |
UD-Q4_K_XL |
11 | 467,289,111,904 | 467.289 | 435.197 | No; 512GiB candidate |
Q8_0 |
17 | 801,357,672,256 | 801.358 | 746.322 | No |
BF16 |
33 | 1,507,988,023,008 | 1,507.988 | 1,404.423 | No |
The unit conversion is the hinge. Repository pages normally display decimal GB: one billion bytes. Operating-memory arithmetic is clearer in GiB: 1,073,741,824 bytes. The 238.578GB UD-IQ2_M is therefore 222.193GiB, not 238.578GiB.
Do not assume the marketing label is the byte count. On the target Mac, run sysctl -n hw.memsize. The budget below assumes it reports 274,877,906,944 bytes, exactly 256GiB. If the returned number differs, recalculate from that number.
256GB memory budget
Here is a reproducible planning budget for UD-IQ2_M, one sequence, MTP disabled and a quiet machine:
| Allocation | GiB | Basis |
|---|---|---|
| Physical unified memory | 256.000 | Assumption to verify with hw.memsize |
| Quantized weights | −222.193 | Exact shard sum |
| macOS and background services | −10.000 | Engineering allowance; close browsers and sync clients |
| llama.cpp server, metadata and Metal buffers | −2.000 | Engineering allowance |
| Prompt-processing activations and scratch | −4.000 | Modest batch/ubatch assumption; can spike |
| Safety reserve | −8.000 | Avoid memory pressure, compression and command-buffer OOM |
| Available for KV cache | 9.807 | Calculated remainder |
UD-IQ2_XXS improves the last line by only 0.111GiB. UD-IQ1_M leaves about 19.2GiB more than IQ2_M after the same non-KV allowances, while UD-IQ1_S leaves about 29.2GiB more. That extra room is real; so is the greater quality risk.
These are planning allowances, not universal constants. macOS may use less after a clean boot or much more on a working desktop. Metal tensor repacking, model metadata, prompt caching, larger batches, concurrent slots, speculative decoding and runtime regressions can all change the peak. A successful mmap followed by an OOM on the first decode is entirely consistent with this budget.
The closest 256GB receipt is a LocalLLaMA report from an M3 Ultra Mac Studio using llama.cpp Metal b9691, UD-IQ2_XXS, context 2,048 and reasoning disabled. The owner reported roughly 226GB model RSS, no observed swap or compression, 75–90 tok/s prompt processing on ordinary prompts and 15.7–16 tok/s generation. A tiny smoke prompt briefly reached about 21 tok/s. The same owner reported that UD-Q2_K_XL started but failed with a Metal command-buffer OOM even at tiny context and batch. This is a valuable community report, not a Kingy-controlled benchmark.
There is a version trap in that receipt: b9691 predates b10121, the first llama.cpp release with proper GLM-5.2 IndexShare semantics. The IndexShare PR notes that corrected decode became slower. The report is therefore useful evidence that the 222.082GiB file can execute and remain resident at 2K; it is not a performance measurement of the current correct runtime.
Q2/IQ1 quality risk
The most important unanswered question is not whether the first token appears. It is what was lost to make 753.33 billion stored parameters occupy 202–222GiB.
IQ2 and IQ1 are mixed, importance-aware schemes; their directory names do not mean every tensor uses exactly two or one raw bits. They protect some tensors more than others. That makes them better than a uniform bit count implies, but it also makes quality model-, calibration- and runtime-dependent. A clean chat answer cannot establish reliable code editing, tool selection, recovery from failed commands or long-horizon planning.
No matched coding or agentic evaluation was located for the exact UD-IQ2_XXS or UD-IQ2_M build. DwarfStar’s 100-case quality fixture compares short continuations and token probabilities against hosted outputs. Colibrì’s token-exact validation checks whether its engine matches the quantized reference. Both are useful regression gates; neither proves that a two-bit quant preserves BF16 coding capability.
Unsloth reports roughly 76.2% top-1 token agreement for its dynamic one-bit recipe and roughly 82% for dynamic two-bit. Those are vendor-reported token-agreement/KL-style diagnostics, not pass rates on coding, tool-use, long-context or agentic tasks. They are a reason to test IQ2 before IQ1, not permission to attach the official checkpoint’s benchmark table to either build.
The best narrow third-party comparison found used the same 30-title translation set on a 512GB Mac Studio. The tester reported UD-IQ1_M at 9.37 tok/s with a judge score of 68 and mixed-character defects, UD-IQ2_M at 9.59 tok/s and 80, an MLX mixed-four-bit build at 5.67 tok/s and 83, and an MLX four-bit build at 5.51 tok/s and 86. That matched small task is evidence that quant choice can change output quality. Translation titles are not coding agents, and a 30-item judge score is not a frontier benchmark.
A four-bit distributed Spark run provides a second warning. A community author reported 63/89, or 70.8%, on Terminal-Bench 2.1 for a custom Int4/Int8 build, versus an official full-model result near 81%. But the run used a 100K rather than 256K context, a smaller token budget, different sampling, a custom runtime and suffered two crashes. It is not a clean quantization A/B and must not be turned into a “ten-point Q4 loss” claim.
Kingy also ran one deliberately small hosted sanity check through the logged-in ChatLLM GLM-5.2 service. The model produced a unified diff that added deterministic topological sorting, cycle detection, dependency-only nodes and immutability tests; seven equivalent local assertions passed. The provider’s serving precision is not disclosed in that session. This proves only that the hosted endpoint solved the task. It provides no evidence about IQ2 or IQ1.
The publication verdict is therefore strict: aggressive quantization may preserve useful behavior, but preservation of GLM-5.2’s coding and agentic capabilities is unverified until the same tasks, harness, context, sampling and token budget are run against a high-quality reference and the local quant.
Context and KV-cache reality
GLM-5.2’s live config accepts up to 1,048,576 tokens. That is an architectural ceiling, not a promise that a 256GB local machine can allocate, prefill or serve it usefully.
The checkpoint uses multi-head latent attention. Its main latent cache is 512 values plus 64 RoPE values per layer and token. GLM-5.2 also has DSA indexer keys. An architecture-efficient cache over 78 layers and 21 full indexers would use 95,232 bytes per token at F16. The current llama.cpp implementation inspected for this article allocates its extra 128-wide indexer cache across all 78 trunk layers, raising the practical F16 figure to 109,824 bytes per token. Its Q8_0 block layout uses 58,344 bytes per token. GLM’s latent design does not use a separate conventional V-cache allocation, so simply doubling a standard K formula would be wrong.
| Allocated context | Current llama F16 cache | Current llama Q8_0 cache | Prefill at a reported 75–90 tok/s | 256GB judgment |
|---|---|---|---|---|
| 8,192 | 0.838GiB | 0.445GiB | about 1.5–1.8 minutes | Credible |
| 32,768 | 3.352GiB | 1.781GiB | about 6.1–7.3 minutes | Sensible everyday ceiling |
| 131,072 | 13.406GiB | 7.122GiB | about 24–29 minutes | F16 breaks the planned reserve; Q8 is still an experiment |
| 1,048,576 | 107.250GiB | 56.977GiB | about 3.2–3.9 hours | Does not fit with IQ2_M; prefill estimate is optimistic |
The prefill times are linear extrapolations from one community report, not measured long-context results. Throughput can fall as the sequence grows, and the 1M run could fail long before completion. Even the 128K Q8 arithmetic leaves only about 2.7GiB beyond the planned 8GiB safety reserve. One larger batch or background process can consume it.
With the stated budget, the mathematical cache ceiling is about 96K tokens at current llama F16 or 181K at Q8_0. Neither number is a service-level promise. A reliable deployment needs to survive full prefill, generation, tool calls and repeated turns while vm.swapusage, compressor activity and Metal errors remain clean.
MTP speculative decoding adds a draft cache and workspace. Current llama.cpp’s draft cache is relatively small—about another 144MiB at 128K F16—but the weight loading and graph workspace also matter. Leave MTP off during the initial fit test. Capacity before speed.
256GB versus 512GB Mac Studio
The 256GB and 512GB machines are not the same class of local GLM-5.2 deployment.
| Hardware | Resident quant tier | Practical context posture | Quality posture |
|---|---|---|---|
| 128GB Mac | No current Unsloth IQ1/IQ2 directory fits resident | SSD expert streaming, a custom routed layout, two-machine split, or impractical | Streaming layout must be evaluated separately |
| 256GB Mac | IQ2_XXS/IQ2_M; IQ1 buys margin |
8K credible, 32K sensible, 128K experimental with Q8 cache | Exact coding/agent retention unproven |
| 512GB Mac | Q3, IQ4 and Q4 can reside | 128K has materially safer room; long context still needs measurement | Quality-first Q3/Q4 comparisons become possible |
On 512GiB, UD-Q3_K_M leaves 192.8GiB before overhead, UD-IQ4_NL leaves 164.9GiB, UD-Q4_K_S leaves 105.5GiB and UD-Q4_K_XL leaves 76.8GiB. That is enough to choose quality before desperation and still fund a substantial KV cache. It does not make one million tokens automatically fast.
There are credible 512GB reproductions. An oMLX maintainer test used a 418.1GB GLM-5.2 oQ4 build on an M3 Ultra 512GB Mac and reported 174.4 tok/s prompt processing, 14.5 tok/s decode and 404.77GB peak memory at 32K plus 128 generated tokens. A separate early MLX mixed-four-bit run reported about 12 tok/s, then hit the default macOS wired-memory limit around 74.5K. Both are useful receipts; neither validates 128K or 1M as a stable daily service.
Apple introduced the M3 Ultra Mac Studio with up to 512GB unified memory in March 2025. As of this evidence snapshot, the current Apple Store no longer presents 512GB as a configurable capacity, and reporting says Apple removed that upgrade in March 2026. Treat 512GB as an existing-owner or used-market option unless the store changes again.
SSD streaming and the 25GB-PC claim
SSD streaming changes “must fit” into “must be available fast enough.” MoE helps because only a subset of routed experts is active for each token. A runtime can keep dense weights, metadata and a hot expert cache in RAM, then fetch missing experts from SSD. It still needs resident memory for dense layers, KV cache, activations, graph scratch and the expert working set. The SSD is not free RAM.
DwarfStar’s pinned July 28 code deliberately supports a small set of GLM layouts, including Unsloth UD-Q4_K_XL and custom routed IQ2_XXS, Q2_K and Q4_K files. It does not promise arbitrary GGUF compatibility. The maintainer reports about 4.8 tok/s for one M5 Max streaming a custom 188GiB routed IQ2_XXS layout, and about 16.8 tok/s across two 128GB M5 Max Macs. Those are project-author measurements on a custom layout, not a result for the 238.459GB Unsloth directory.
Colibrì takes the idea to its logical extreme. Its open-source proof of concept keeps roughly 9.9GB of dense int4 weights resident and works within roughly 20–25GB RAM while reading about 11GB of routed experts per generated token. On the developer’s WSL2/NVMe box, the reported cold rate is 0.05–0.1 tok/s. That is 10–20 seconds per token. A 500-token answer would take roughly 1.4–2.8 hours before prompt processing.
That claim is technically meaningful: a PC with 25GB can execute the model’s quantized forward path. It is not an interactive local assistant. Colibrì’s token-exact checks also prove engine correctness against its quantized reference, not fidelity to BF16. The project recommends its newer group-scaled int4 container after an older scheme reportedly lost about nine quality points and sometimes looped.
For 128GB owners, SSD streaming is therefore the only single-box path in this comparison, but it should be bought as an experiment in storage-aware inference—not sold as equivalent to a resident 256GB session.
Mac versus four DGX Sparks
Four DGX Sparks pool 512GB of coherent memory across four GB10 systems. That creates room for a quality-first mixed int4/FP8 build and distributed context, but it also introduces RoCE networking, sharding, custom containers and multi-node failure modes.
| Deployment | Weights and context | Reported performance | Evidence and caveat |
|---|---|---|---|
| 256GB M3 Ultra Mac | Unsloth UD-IQ2_XXS, 2K |
75–90 tok/s prompt, 15.7–16 tok/s decode | One community owner; no matched quality evaluation |
| 512GB M3 Ultra Mac | oQ4 418.1GB, 32K | 174.4 tok/s prompt, 14.5 tok/s decode | oMLX maintainer reproduction; only 128 output tokens |
| Four DGX Sparks | Mapika NVFP4+MTP about 410GB, 128K | about 475–512 tok/s prompt; 14.5–15.2 tok/s autoregressive or 23.7–24.2 tok/s with corrected MTP4 | Community engineering reproduction, custom vLLM/B12X stack |
| Four DGX Sparks | Custom Int4/Int8 about 372GB, 1M | 1M allocation and generation reported; speed depends heavily on DCP and prompt length | One-rig Hugging Face artifact; custom vLLM fork, not stock support |
The initial four-Spark build used standard 128GB units, a MikroTik RoCE switch, FP8 MLA cache and a custom patched runtime. A follow-up configuration fix lifted speculative decode to roughly 24 tok/s, but left only 2.5–2.7GB free per rank; another user missed the 128K fit by 1–2GB. The one-million-token artifact is reproducible enough to establish technical feasibility on one custom four-node stack, not appliance maturity.
NVIDIA lists 128GB coherent memory and 273GB/s bandwidth per Spark. Its February 2026 price notice set MSRP at $4,699, so four nodes start at $18,796 before tax, switch, cables and storage. The cluster is the stronger route when higher-quality weights and long-context throughput justify distributed engineering. The Mac is the simpler, quieter route when one user can accept IQ2 uncertainty and a 32K target.
Runtime maturity and exact revision requirements
This model arrived faster than stable local support. Reproducibility requires pinning every moving part.
- Official checkpoint: pin
zai-org/GLM-5.2@b4734de4facf877f85769a911abafc5283eab3d9. The latest change addsmoe_router_dtype=float32; the weights themselves did not change. - Unsloth GGUF: pin
unsloth/GLM-5.2-GGUF@abc55e72527792c6e77069c99b4cb7de16fa9f23, select one directory, and record every shard size. Do not download the entire multi-quant repository. - llama.cpp: full GLM-5.2 IndexShare/DSA support landed in PR #25407, merge commit
88bfee1429a2dfacec65d1b0c0852eb327991865, first released asb10121. For a 256GB fit, useb10212or newer: PR #26296, commit82dbc4f017a7b005f993ac2e7af9c048ad686c04, stops loading the bundled MTP layer when speculative MTP is disabled. The cache calculations in this article inspectddd4ec1428a6201e18975ea52b07c71e0f9aef26; pin that full hash or another tested descendant and report it. - MTP: llama.cpp support landed later in PR #25980, merge commit
7be2c65dc9adee9bae784478be0f656e3b683431. Test resident fit with MTP off first. A speed result with MTP is not comparable to plain autoregressive decode. - MLX and Transformers: stock
mlx-lm0.31.3 and current main do not yet provide a clean, merged GLM-5.2 IndexShare path. Issue #1418 and related long-prompt failures remain open; IndexShare PR #1419 is unmerged. MLX also does not directly consume Unsloth’s sub-three-bit GGUFs. It is not the default recommendation for the 256GB IQ2 test. For the official safetensors path, the live config records Transformers5.12.0; the model card’sv0.5.12+entry is malformed and should not be copied. - DwarfStar: pin
ds4@54b36ed9ba42da31b24f2d1a5feb075c2475dbb1and use only a listed GLM layout. Its two-Mac role split is CLI-only and the project labels itself fast-changing/beta. - Colibrì: pin
b085b48888a88d9a1c00b151a9979774b72cdbfdand the recommended group-scaled int4 container. A future container or engine result is a new test.
Two open warnings deserve attention. A Mac 128GB issue reports that a UD quant could OOM under mmap while a non-UD alternative ran, and a separate CUDA/Blackwell issue reports corrupted output from GPU-offloaded UD-IQ2_M while CPU-only output remained coherent. The latter is not a Metal result, but it demonstrates why “the file loaded” is not a sufficient runtime acceptance test.
Code inspection at b10216 found dedicated lightning-indexer implementations for CPU and CUDA but no Metal-specific kernel. That does not mean GLM-5.2 cannot run through a fallback path on Apple Silicon; the community receipt shows that it can. It does mean “Metal-optimized and mature” would overstate the current runtime.
Local-versus-API economics
The official Z.ai price snapshot for GLM-5.2 is $1.40 per million input tokens, $0.26 per million cached input tokens and $4.40 per million output tokens. At those rates:
| Example request | Uncached API cost |
|---|---|
| 8K input + 2K output | $0.0200 |
| 32K input + 4K output | $0.0624 |
| 128K input + 8K output | $0.2144 |
| 1M input + 16K output | $1.4704 |
At an 80% input/20% output mix, the blended list cost is $2 per million total tokens. An illustrative $10,000 local system would need to process about five billion total tokens merely to equal that API spend, before power, SSD, maintenance, engineering time and model obsolescence. Four Sparks’ $18,796 base hardware cost moves the same simple break-even to about 9.4 billion tokens.
Even a machine generating 16 output tokens every second, 24 hours a day for a year, would emit about 504.6 million tokens. At Z.ai’s output list price, that is only about $2,220 of annual API value. A personal workstation will be idle far more often.
API access therefore wins for most readers on cost, immediate quality, elasticity and one-million-token availability. Local wins for different reasons: data control, offline operation, predictable marginal cost at genuinely high utilization, experimentation with weights and independence from provider outages or policy changes. Hosted routes can themselves use FP4 or FP8 and different context ceilings; record the exact provider rather than treating every endpoint called “GLM-5.2” as a BF16 reference.
Reproducible quality and performance test plan
A convincing 256GB result should be reproducible by another owner and should separate capacity, speed and quality.
1. Freeze the artifacts
Record the official and Unsloth revisions above, the six selected shard names, byte totals and checksums. Save the llama.cpp full commit hash, build flags, macOS version, Xcode/Metal version and exact command line. Record sysctl -n hw.memsize rather than writing only “256GB.”
2. Establish the memory baseline
After a clean boot, record vm_stat, sysctl vm.swapusage, Activity Monitor memory pressure and free SSD space. Close browsers, cloud sync, creative apps and local databases. Start with one sequence, context 8,192, MTP off, conservative batch/ubatch and F16 K cache. Capture model RSS, total used memory, compressed memory, swap and Metal errors after load, after full prefill and after 512 generated tokens.
3. Walk the context ladder
Repeat at 8K, 32K and 128K with identical output length. At 128K, compare F16 and Q8_0 K cache. Do not report an allocated context as a successful test: fill it with a deterministic corpus, time the entire prefill, retrieve facts planted near the start and middle, then generate. Stop if swap grows, memory pressure turns red, compression rises continuously or the Metal command buffer fails. A 1M attempt belongs on hardware that can first pass 128K with reserve.
4. Measure latency honestly
Report load time, prompt-processing tok/s, time to first token, autoregressive tok/s, end-to-end wall time, peak unified memory, swap delta, energy use and output length. Publish both a short 2K prompt and filled 8K/32K prompts. One 20-token smoke prompt is not an interactive-speed benchmark.
5. Run a matched quality A/B
Use the same prompt templates, system message, tools, sampler, seed where supported, context, maximum tokens and stop rules against: a disclosed high-quality GLM-5.2 reference; UD-IQ2_XXS; UD-IQ2_M; and at least one IQ1 build. Include deterministic code-repair tasks with executable tests, repository-level agent tasks with a fixed harness, structured tool-call validity, long-context retrieval, repetition/loop detection and a small manual blind review. Terminal-Bench 2.1 or SWE-bench Verified can be used only when the task manifest, harness commit, context and token budget are identical.
Publish Pass@1, test-pass rate, invalid tool calls, nontermination rate, tokens used, wall time and paired failures. Short-continuation KL divergence or perplexity is useful diagnostic evidence, but it cannot replace task completion.
6. Repeat before concluding
Run enough paired tasks to expose variance, then publish the raw prompts, outputs, logs and failures. Only a matched result can support a sentence such as “IQ2 preserves X% of the reference model’s coding success.” Until then, the correct label is not yet verified.
FAQ
Why does a 239GB file leave about 34GiB, not 17GB?
Because the repository figure is decimal GB while the assumed physical memory is 256GiB. The 238,577,580,768-byte IQ2_M directory is 222.193GiB. Subtracting that from 256GiB leaves 33.807GiB. Verify the Mac’s actual byte count before using this calculation.
Is memory mapping the same as loading the model?
No. mmap reserves virtual address space and lets the OS page file regions on demand. A model can map successfully, then fail when inference touches enough pages, allocates KV cache or asks Metal for a command buffer.
Which quant should a 256GB owner try first?
UD-IQ2_XXS has the closest successful 256GB community receipt and a marginally smaller footprint than UD-IQ2_M. That makes it the capacity-first choice. It does not make it the proven quality choice. Start at 8K, one slot, MTP off and a pinned llama.cpp build.
Can a 128GB Mac run GLM-5.2?
Not with any current Unsloth IQ1/IQ2 directory fully resident. It needs SSD expert streaming, a custom routed layout, a second machine or a different model. DwarfStar and Colibrì show technical paths, with very different speed and maturity.
Does a 512GB Mac solve the problem?
It solves the resident-weight problem for Q3, IQ4 and Q4 and gives context much safer room. It does not prove million-token usefulness, eliminate runtime bugs or guarantee that a particular quant retains agentic quality. The 512GB configuration is also no longer shown in Apple’s current store.
Can the 256GB Mac serve one million tokens with a quantized KV cache?
No, not alongside the 222.193GiB IQ2_M weights under the current llama.cpp allocation. Q8_0 cache at the 1,048,576-token ceiling is about 56.98GiB before OS, runtime, activations and reserve. Prefill would also be measured in hours at the available Mac reports.
Is 15–16 tok/s interactive?
For generated text after a short prompt, yes. It is comfortably readable. For a 32K or 128K coding session, time to first token matters more: prefill can take minutes, and the tight memory budget makes long multi-turn agent work less dependable.
Do one-bit variants make the 256GB Mac safe?
They make the memory fit safer. IQ1_S leaves about 54.2GiB gross and IQ1_M about 43.2GiB before overhead. They also increase the risk of broken reasoning, formatting, multilingual output or loops. Use them only with a matched quality suite.
Is the 25GB Colibrì PC claim real?
It is a credible developer proof that disk-streamed GLM-5.2 can execute in roughly 20–25GB RAM. Its reported 0.05–0.1 tok/s is not an interactive experience, and its engine-correctness tests do not establish BF16-equivalent quality.
Should most people buy hardware or use the API?
Use the API unless local privacy, offline operation, weight access or sustained high utilization is the actual requirement. A knife-edge 256GB build is a compelling engineering project, not the cheapest way to obtain dependable GLM-5.2 output.
Methodology and dated sources
Evidence snapshot: July 31, 2026 at 11:00 p.m. PDT. Repository sizes were summed from every live shard at the pinned revisions and converted with 1GB = 1,000,000,000 bytes and 1GiB = 1,073,741,824 bytes. Memory and KV figures are engineering calculations using the live config and inspected runtime allocation; they are not measurements from a Kingy-owned 256GB Mac. The only Kingy execution in this article is the disclosed hosted ChatLLM sanity check, which is not a quantization test.
Official and vendor sources:
- Z.ai GLM-5.2 checkpoint, revision b4734de4 and revision-pinned config, checked July 31, 2026.
- Z.ai GLM-5.2 architecture note, checked July 31, 2026.
- Unsloth GLM-5.2-GGUF, revision abc55e7, exact shard totals checked July 31, 2026.
- Z.ai API pricing, checked July 31, 2026.
- Apple M3 Ultra Mac Studio announcement, March 5, 2025; current-store availability checked July 31, 2026.
- NVIDIA DGX Spark specifications and February 2026 price notice, checked July 31, 2026.
Runtime sources:
- llama.cpp GLM-5.2 IndexShare PR #25407, merged July 24, 2026; MTP PR #25980, merged July 29, 2026; source inspected at
ddd4ec1428a6201e18975ea52b07c71e0f9aef26. - mlx-lm GLM-5.2 tracking issue #1418, IndexShare PR #1419 and long-prompt issue #1453, status checked July 31, 2026.
- DwarfStar/ds4 revision 54b36ed and quality fixture, July 28 revision checked July 31, 2026.
- Colibrì revision b085b48 and benchmark notes, checked July 31, 2026.
Third-party and community reproductions:
- M3 Ultra 256GB,
UD-IQ2_XXS, llama.cpp b9691 community report, June 20, 2026. - 512GB Mac matched 30-title quant comparison, June 26, 2026.
- oMLX GLM-5.2-oQ4 512GB Mac reproduction, merged June 24, 2026.
- WorkingModels 512GB MLX reproduction, June 20, 2026.
- Four-Spark 128K build, June 29, 2026, and configuration follow-up, July 3, 2026.
- Four-Spark one-million-token artifact, measured July 2026.
- Terminal-Bench 2.1 four-Spark repository, checked July 31, 2026.
- Mac Studio 512GB option removal report, March 5, 2026.
Bottom line: the 239GB-class build can run on 256GB, but “fits,” “responds,” “stays fast at long context” and “retains frontier agent quality” are four separate claims. Current evidence securely supports only the first two at small context.