What happened
Silicium Rose’s analysis of Scantist’s GLM-5.3-SLIM-GGUF describes a derivative of Unsloth’s UD-IQ2_M GGUF quantization of Z.AI’s GLM-5.3. Scantist’s repository was created on November 2, 2026. It retains 192 of the 256 routed experts in each of 75 mixture-of-experts layers, removing 4,800 of 19,200 routed experts overall. The article says the retained experts were copied in their original order and that Scantist reports no retraining or recalibration. It also says the auxiliary MTP layer was removed. The resulting model is listed at 563 billion parameters, compared with 753 billion for the base model.
The file is 179.86 GB, against 238.58 GB for the Unsloth source quantization, a reported reduction of 24.6 percent. The average is 2.56 bits per weight: the article explains that different tensors use different quantization formats, with experts packed more tightly than attention components. Silicium Rose says Scantist’s card claims the model runs on a single NVIDIA B200 or a Mac Studio with at least 192 GB of unified memory. The tests described in the article, however, were run on one B200; the Mac configuration is a stated target, not a reported measurement.
Scantist’s reported benchmark results are 92.7 percent on HumanEval (152 of 164 tasks), 84.8 percent on GPQA-Diamond (168 of 198 questions), and 71.4 percent on a 570-question MMLU subset. Silicium Rose says the scores came from Scantist’s own scripts and that the repository marks the 256-expert Unsloth version as not measured. Scantist also says it did not run the full-precision model on the same harness. The article therefore treats the effect of expert removal as unmeasured by these scores: they do not show how much quality changed versus the model before pruning.
For operational details, the article reports Scantist’s B200 result of 34.5 generated tokens per second for one sequence, with roughly 10 percent variation between runs. Scantist says the weights require about 167 GiB of GPU memory, leaving capacity for about 100,000 tokens of KV cache across up to 10 requests. The GPQA-Diamond run reportedly took about 13.5 hours, with 275 request aborts and restarts. Silicium Rose also notes that the tested llama.cpp CPU backend could not run this architecture. The article describes the model as released under the GLM-5.3 License, the same terms as the base model.
What the archive adds
New Runtime’s earlier coverage reported that a GLM-5.3-SLIM-GGUF quantization was said to fit on one NVIDIA B200 at 179.9 GB (November 10 note). This is a new fact on that known story: Silicium Rose examines the pruning and quantization claims and foregrounds the missing same-harness baseline for judging the quality trade-off.
Trend signal
This does not yet fit a pattern New Runtime tracks. The episode is nevertheless a bounded warning about interpreting model-compression claims: a smaller artifact and strong standalone benchmark scores do not establish how performance changes against an unpruned model under matched conditions.
Why now
The repository appeared on November 2, and Silicium Rose’s analysis was published on November 13, 2026. That timing makes the note an early scrutiny of a newly circulated derivative, before its single-card claim and benchmark figures can be mistaken for a demonstrated quality-preserving reduction.
Why it matters
For teams considering local inference, the release addresses a real deployment constraint: a model artifact that can fit on one accelerator is easier to test than a larger checkpoint that cannot. But fit is not equivalent to capability. Pruning experts and quantizing weights are two distinct reductions, and the reported scores combine their effects without showing a matched unpruned baseline. A team could use this build as an exploratory candidate, but should not infer parity with GLM-5.3 from the phrase “GLM-5.3-class” or from absolute scores alone.
The operational numbers also matter. A single B200 run at 34.5 tokens per second is a point of reference for one setup, while the reported long GPQA run and repeated request restarts hint at evaluation and memory constraints. Those figures are not a service-level guarantee or a forecast for different hardware, serving stacks, or concurrent workloads. Before committing infrastructure or model quality to this derivative, teams need task-specific tests on their own prompts, a same-harness comparison, and measurements of latency and memory at expected concurrency.
Limits and uncertainty
Silicium Rose reports no independent evaluation of this derivative. The headline scores are attributed to Scantist’s scripts, and the source says Scantist did not run the 256-expert version on the same harness or compare the full-precision model there. The quality cost of pruning therefore remains unquantified by these results. The Mac Studio claim is not backed by a Mac measurement in the described tests. The article also reports that the referenced GLM-5.3-SLIM-E192 page returned an HTTP 401 during its review, leaving the expert-selection method and the cited A/B results inaccessible to the author at that time. These are limits on what the analysis establishes, not evidence that the claimed setup cannot work.
Reader takeaway
Scantist has published a substantially smaller GLM-5.3 derivative with a stated single-B200 configuration. Its reported scores do not establish equivalence to the original, because the comparison that would reveal the cost of pruning was not run on the same harness. Treat the hardware fit as a claim to test and the quality trade-off as an open measurement question.