What happened
Scantist’s Hugging Face page presents GLM-5.3-SLIM-GGUF as a GLM-5.3-class model with a 192-expert-per-layer MoE architecture. It says neural architecture search selected the 192 experts retained in each MoE layer, removing the other 64 of the original 256. The model has 563B parameters, compared with 753B for the cited Unsloth GLM-5.3 UD-IQ2_M source, and occupies 179.86 GB (167.51 GiB). The page gives the source model’s size as 238.58 GB, making the new file 24.6% smaller. This is a third-party model variant, not an announcement of a new official GLM release.
The card says the build uses Unsloth’s UD-IQ2_M GGUF quantization and that the retained expert tensors were copied byte-for-byte, without re-quantization, retraining or recalibration. Other tensors are described as byte-identical to the source. The MTP layer was removed, and the card explicitly says not to use MTP speculative decoding with this model. It lists the tokenizer and chat template as unchanged. The files are split across six GGUF shards; the first shard is passed to llama.cpp, which loads the others.
For its single-B200 instructions, Scantist specifies a B200 with 183,359 MiB reported by nvidia-smi, CUDA 13, a compatible NVIDIA driver, and 180 GB of free disk space. The documented llama.cpp build uses commit 8e5a58d, dated 2026-10-24. The card estimates that weights use about 167 GiB of GPU memory. With a unified f16 KV pool, it reports about 100K tokens available; using q4_0 KV cache, it reports roughly 340K tokens. The tested server command sets a 102,400-token pool and 10 slots, but the authors warn that requests share the pool and that pool exhaustion can fail running requests.
Scantist reports 92.7% on HumanEval pass@1 with greedy decoding and thinking off, and 84.8% on GPQA-Diamond at temperature 1.0, high reasoning effort and 65,536 tokens. Its page also describes running the model on a Mac Studio with at least 192 GB unified memory using mlx-serve. It provides setup instructions for llama.cpp and integrations including vLLM, Ollama, LM Studio, Jan, Pi, OpenClaw and others. No price is listed for the downloadable model.
What the archive adds
New Runtime’s earlier coverage of per-tensor quantization budgets described a different route to adapting large models for constrained hardware. Earlier coverage also noted Revolut’s reported use of 56 B200s to serve GLM to about 2,000 engineers, and Project Maya’s approach to keeping GLM experts resident in GPU memory. This is a new fact on the broader GLM deployment story: a third-party model card documents a 192-expert variant sized for one B200, rather than an enterprise serving fleet.
Trend signal
This supports the hardware-threshold strand of agent economics moves to completed work only weakly: reducing the accelerator count may change deployment economics, but the model card does not report cost per completed task or compare production workloads. It is more directly a concrete instance of quantization and architecture choices altering what hardware can host a model; this does not establish lower operational cost or equivalent capability.
Why now
The model card dates the tested llama.cpp commit to October 24, 2026 and supplies commands, memory measurements and evaluation scripts, making the claim more actionable than a bare model-size announcement. The source does not explain a broader reason for the timing.
Why it matters
For teams evaluating self-hosted inference, the practical question is not only whether weights fit on a GPU: the remaining memory must also support the KV cache and the workload’s concurrency. Scantist’s figures make that trade-off visible. A roughly 100K-token f16 pool on one B200 may accommodate several short requests, while a single long-context request can consume a large share; q4_0 increases pool capacity but changes the cache representation. This is useful deployment information, not proof that the model matches the original GLM-5.3 in capability or serves a given workload more cheaply. Teams should treat the reported benchmark scores as starting points for their own task-specific evaluations, then measure throughput, latency, memory headroom and failure behavior under realistic request mixes.
Limits and uncertainty
The results are reported by the model publisher and have not been independently verified. The listed benchmark scores are tied to specific settings, including greedy decoding with thinking off for HumanEval and high reasoning effort with a 65,536-token limit for GPQA-Diamond; the page does not establish equivalence to the original 256-expert model across a broader task suite. Its single-B200 setup uses a specific llama.cpp commit, driver and CUDA version, and the page says newer commits may work but were not tested. Multi-GPU deployment on smaller GPUs is described as necessary but untested. The reported memory and concurrency figures also depend on request lengths and KV-cache configuration.
Skill to build now
If you are considering this build, reproduce the publisher’s serving setup before putting it behind a workload: pin the listed llama.cpp commit, record GPU and CUDA versions, and start with the documented 102,400-token shared pool. Send a mix of short and long requests at realistic concurrency, then track peak GPU memory, latency, throughput and errors when the pool fills. Compare f16 and q4_0 KV cache on your own prompts rather than assuming the larger token pool is a free capacity gain.
Reader takeaway
A 179.86 GB GLM-5.3-derived GGUF can, according to its publisher, run fully on one B200, with explicit trade-offs between KV-cache precision, available context and parallel requests. Treat this as a reproducible third-party deployment claim—not evidence that a smaller model preserves the original’s quality or that it will be cheaper for your workload.