Instructions to use Jundot/GLM-5.2-oQ4e-mtp with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- MLX
How to use Jundot/GLM-5.2-oQ4e-mtp with MLX:
# Download the model from the Hub pip install huggingface_hub[hf_xet] huggingface-cli download --local-dir GLM-5.2-oQ4e-mtp Jundot/GLM-5.2-oQ4e-mtp
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- LM Studio
Benchmarks on M3 Ultra 512GB (oMLX v0.5.1): MTP +33% decode, quality vs imatrix GGUF
Sharing real-world benchmark data since there don't seem to be public numbers on this quant yet. Setup: Mac Studio M3 Ultra 512GB, macOS 26, oMLX v0.5.1 (from the published omlx-0.5.1-cp311 wheel, native GLM DSA kernels confirmed via native_kernel_status()), mtp_enabled: true in model_settings.json, greedy single-stream.
This is one of only ~4 of ~29 GLM-5.2 MLX conversions on the Hub that actually keeps the MTP draft tensors (all 54 mtp.0.block.* present). Most mlx-community/pipenetwork conversions drop them, so Lightning MTP is a no-op there. Here it works and helps.
Throughput (M3 Ultra, oMLX v0.5.1):
| metric | MTP off | MTP on |
|---|---|---|
| decode, prose | ~15 tok/s | ~19 tok/s (+24%) |
| decode, code | ~15 tok/s | ~20 tok/s (+33%) |
| cold prefill (~8-16k, guard 470) | ~194 tok/s | ~194 tok/s |
| model load (413GB) | ~72s | ~72s |
MTP has no prefill penalty (an initial "slower" reading was a prefix-cache artifact). Multi-turn works cleanly on v0.5.1 with a right-sized --hot-cache-max-size 8GB (MLA KV is compact, so a few GB caches ~90k tokens): a 2nd turn over a ~6.8k prefix hit cached_tokens=6656 and ran ~6x faster than cold, no hang.
Quality (our internal agentic coding/repair eval suite, matched-cell vs an imatrix-tuned unsloth GLM-5.2 UD-Q4_K_M GGUF on llama.cpp): correctness parity on the bulk of tasks (identical pass rates on repair/patch/build-recovery families), but ~9% behind on the hard/adversarial tail (20/23 vs 22/23 matched wins). The two misses were an adversarial "review trap" and a strict contract-patch, both completed within budget but produced the wrong answer where the imatrix GGUF got it right. Plausibly the 4-bit oQ vs imatrix-tuned-quant precision difference on tricky cases.
Net: the fastest-decoding fits-a-512GB-box GLM-5.2 variant we've measured (MTP is the differentiator), excellent for throughput-sensitive use; the imatrix GGUF edges it slightly on hard-case reliability. Thanks for keeping the MTP tensors in this one. Happy to run more configs on the 512GB M3 Ultra if useful.