Instructions to use malaiwah/GLM-5.3-Flash-TR3-6bpw with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use malaiwah/GLM-5.3-Flash-TR3-6bpw with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("image-text-to-text", model="malaiwah/GLM-5.3-Flash-TR3-6bpw") messages = [ { "role": "user", "content": [ {"type": "image", "url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/p-blog/candy.JPG"}, {"type": "text", "text": "What animal is on the candy?"} ] }, ] pipe(text=messages)# Load model directly from transformers import AutoProcessor, AutoModelForMultimodalLM processor = AutoProcessor.from_pretrained("malaiwah/GLM-5.3-Flash-TR3-6bpw") model = AutoModelForMultimodalLM.from_pretrained("malaiwah/GLM-5.3-Flash-TR3-6bpw", device_map="auto") messages = [ { "role": "user", "content": [ {"type": "image", "url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/p-blog/candy.JPG"}, {"type": "text", "text": "What animal is on the candy?"} ] }, ] inputs = processor.apply_chat_template( messages, add_generation_prompt=True, tokenize=True, return_dict=True, return_tensors="pt", ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=40) print(processor.decode(outputs[0][inputs["input_ids"].shape[-1]:])) - Trellis
How to use malaiwah/GLM-5.3-Flash-TR3-6bpw with Trellis:
# No code snippets available yet for this library. # To use this model, check the repository files and the library's documentation. # Want to help? PRs adding snippets are welcome at: # https://github.com/huggingface/huggingface.js
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- vLLM
How to use malaiwah/GLM-5.3-Flash-TR3-6bpw with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "malaiwah/GLM-5.3-Flash-TR3-6bpw" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "malaiwah/GLM-5.3-Flash-TR3-6bpw", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }'Use Docker
docker model run hf.co/malaiwah/GLM-5.3-Flash-TR3-6bpw
- SGLang
How to use malaiwah/GLM-5.3-Flash-TR3-6bpw with SGLang:
Install from pip and serve model
# Install SGLang from pip: pip install sglang # Start the SGLang server: python3 -m sglang.launch_server \ --model-path "malaiwah/GLM-5.3-Flash-TR3-6bpw" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "malaiwah/GLM-5.3-Flash-TR3-6bpw", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }'Use Docker images
docker run --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env "HF_TOKEN=<secret>" \ --ipc=host \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path "malaiwah/GLM-5.3-Flash-TR3-6bpw" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "malaiwah/GLM-5.3-Flash-TR3-6bpw", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }' - Docker Model Runner
How to use malaiwah/GLM-5.3-Flash-TR3-6bpw with Docker Model Runner:
docker model run hf.co/malaiwah/GLM-5.3-Flash-TR3-6bpw
GLM-5.3-Flash-TR3-6bpw (K6)
The first 6-bit (K6) TR3/MCG trellis quantization of
zai-org/GLM-5.3-Flash —
321B-total / A18B MoE, glm5_next hybrid architecture. Routed experts and the
MTP layer quantized at K6 (96-word trellis, MCG 0xCBAC1FED); everything else
(KDA linear-attention layers, DSA indexer, hyper-connections, routers, norms,
embeddings, lm_head) bit-exact native BF16. 253.5 GB — 77% of the official
FP8's footprint.
Quality — SEALED five-cold-run qualification
⚠ Scope disclosure — this number is a panel25 number
Added 2026-08-29. Nothing here is a correction: 0.013723 is and remains the correct mean over the full 25-window panel. What changed is that the panel is now known to contain calibration-adjacent windows, so the scope has to travel with the number.
brandonmusic ran a 13-gram overlap scan of his sealed panel against its own calibration-role windows and found that the whole
axis4_reasoningdomain shares 37–39 % of its 13-grams with calibration material — despite the panel being clean at the document-hash level. Document-hash dedup is not enough. He excluded that domain and scored his primary numbers on the 17 windows that survive. The finding, the scan and the 0.05 threshold are his.Every malaiwah number on this panel used all 25 windows, so every one of them carries the same contamination. Recomputed on his clean scope, from our own published per-window arrays (no GPU, no re-measurement — this is arithmetic on data already published):
panel25 (published) clean17 (his scope) move K6 sealed 0.013723 0.011677 −14.91 % K6 streaming 0.013715 0.011676 −14.87 % K8 0.012384 0.010829 −12.55 % official FP8 0.020615 0.018665 −9.46 % BF16 floor (cross-stack) 0.012712 0.010648 −16.24 % brandonmusic 4bpw 0.024555 0.024949 +1.61 % The comparisons hold, and one of them strengthens. K6 beats the official FP8 on 17 of 17 clean windows, and the margin widens: 1.50× on panel25 becomes 1.60× on clean17. The K8-over-K6 result survives but weakens — the paired BCa interval still excludes zero, but its lower bound falls from +0.000695 to +0.000153 and the sign test goes from p = 0.0041 to p = 0.049. We will not restate "K8 is better than K6" without naming the scope.
Do not difference a panel25 number against a clean17 one. They are answers to different questions. Our registry enforces this structurally:
clean17is its own derived panel with its own comparability key.The quantization-attributable table below cannot be recomputed on the clean scope — its floor is the streaming BF16 floor, whose receipt is scalar-only (run means and a tokenwise digest, no per-window array), and substituting the cross-stack floor would be the cross-lane subtraction our registry refuses. It stands as a panel25 number.
Full recompute, with per-domain tables, paired intervals and provenance:
reports/clean-scope-recompute.json. Working: PROTOCOL-ALIGNMENT.md §4.One protocol note, not a correction. His protocol masks the 24 padded
lm_headcolumns before the log-softmax; ours never has. Measured on his real teacher window, the padded columns hold ~1.6e-8 of the probability mass, and because this quant shares the teacher's native BF16 head the effect collapses toKLD × mass— 1.0e-10 nats, moving the value above at its 9th significant figure. For scale, our own sealed-vs-streaming bridge is 8.5e-6 and the window-clustered SE on this panel is 3.19e-3. No correction and no bias disclosure is warranted; we are adopting masking anyway. Script and receipts:bin/padded_column_study.py.
Mean KLD(teacher ‖ K6) = 0.013723 nats over the full sealed panel (25
windows, 51,175 positions per run) — five cold runs, bitwise identical
(population stddev exactly 0.0), the same determinism property as
brandonmusic's protocol. Quality gate (< 0.06): passed. Receipts:
receipts/k6-five-run-kld.json,
receipts/k6-packed-kld.json (evidence-artifact
hashes included).
| Model | Mean KLD (nats) | Size | Scope |
|---|---|---|---|
| This K6 (sealed) | 0.013723 | 254 GB | full panel × 5 bitwise-identical runs |
| This K6, streaming lane | 0.013715 | 254 GB | full panel × 2 bitwise-identical runs; −8.5e-6 vs sealed (receipt) |
| K8 sibling | 0.012384 | 331 GB | full panel × 2 bitwise-identical runs, streaming lane |
| Official FP8 (full panel) | 0.020615 | 328 GB | cross-stack, receipt |
| brandonmusic 4bpw | 0.024555 | 176 GB | full panel, his stack |
| Official FP8 (his stack, v44) | 0.024629 | 328 GB | 1 window × 5 runs |
| NVFP4 (his stack, v44) | 0.060535 | ~180 GB | 1 window × 5 runs |
K6 delivers 1.5× lower divergence than the official FP8 release at 77 % of its bytes (1.8× vs the 4bpw, 4.4× vs NVFP4). Panel-wide top-1: 96.56 % (full 25-window panel, streaming lane). Serving is now independently live-qualified on 4× RTX PRO 6000 Blackwell (SM120) with the digest-pinned turnkey image and profile below; the earlier SM90 qualification limitation no longer applies to the serving claim.
Quantization-attributable error (the floor removed)
Scoring the unquantized BF16 weights against this teacher on this panel already costs 0.011506 nats — the price of the comparison itself (teacher captured on a different runtime; bf16 addition is not associative across differing expert-combine orders). Two cold runs, identical means. Removing it:
| panel KLD | attributable to quantization | |
|---|---|---|
| BF16 (floor) | 0.011506 | — |
| K8 (331 GB) | 0.012384 | 0.000878 |
| K6 (254 GB) | 0.013715 | 0.002209 |
K8's quantization error is 2.52x smaller than K6's, against a raw ratio of only 1.11x — K8 removes ~60% of the divergence K6 leaves behind. Raw KLD understates differences between good quants because the floor is common to both. Method, receipts and the ways this subtraction can be misused: BF16-FLOOR.md.
What this is (and is not)
- Codec: EXL3-format TR3/MCG trellis (turboderp's
exllamav3 kernels @
c5d9c657did the encoding math), through brandonmusic's GLM-5.3 quantization pipeline with a small disclosed patch series. - Serving runtime: use
malaiwah/glm52-exl3-vastwithMODEL_PROFILE=glm53-k6. The image pins the qualified Glm5Next vLLM, B12X, EXL3, CUDA, and 21-file fail-closed runtime overlay as one contract. - Not stock exllamav3/TabbyAPI or stock upstream vLLM: those stacks do not
carry this complete
glm5_next+ TR3/MCG K6 serving path. - Topology-neutral checkpoint: canonical unsharded tensors; TP layout is a load-time decision. The qualified deployment is exactly TP4/DCP4 on four 96 GiB RTX PRO 6000 Blackwell GPUs.
- Measured memory: the packaged image loads 58.96 GiB of model tensors per rank. At GMU 0.93, final profiling reported 63.74–63.78 GiB weights + non-torch, 3.02 GiB peak activations, 0.45–0.46 GiB CUDA graphs, and 21.52–21.56 GiB KV per GPU.
- Shared down-
suhtopology: all 288 experts per layer share the down-projection input sign vector (measured fidelity-free: worst-layer −2×10⁻⁶ relative output error). A one-transform-per-layer grouped-GEMM hoist remains an optimization opportunity; it is not claimed by this release.
Provenance & disclosed deviations
Full receipts ship in this repo and in the
fidelity suite.
Key pins: BF16 source zai-org/GLM-5.3-Flash-BF16 (weights == a6c167b6),
calibration = brandonmusic's published EP4 captures (sealed inventory
f56e9d62… adopted verbatim), same transform-seed discipline as the K8
sibling (parts-bin assembly compatible). Disclosed deviations from his sealed
K4 campaign: encoded on 4×H200 SM90 (his: 4×B200 SM100; fat 9.0;10.0
extension build), verified-equivalent R10 codec (we
encoded with a reconstruction while his numeric core was unpublished; he has
since published the sealed closure, and a head-to-head on identical real
inputs came back 120/120 encodes byte-identical — 624 MiB of packed trellis,
0 differing bytes, decoded-weight delta exactly 0.0. His published core
admits only K3/K4/K5, so K6/K8 are a declared rate extension, not a
substitution; driving his sealed primitives past that admission constant
reproduces our bytes exactly. Fidelity impact is identically zero. Evidence:
closure-comparison.json,
issue #1), K4-KL gate satisfied via a disclosed bridge
document carrying his real published K4 receipt hashes, qualification at EP8
(his reader default EP4). The five-run qualification receipts land here when
sealed.
Family
| K4 | K6 (this) | K8 | |
|---|---|---|---|
| Repo | brandonmusic's 4bpw | here | malaiwah/GLM-5.3-Flash-TR3-8bpw |
| Size | 176 GB | 254 GB | 331 GB |
| Mean KLD (same panel) | 0.024555 | 0.013723 | 0.012384 |
Same pipeline, calibration, and panel across the family. A payload parts-bin dataset (K6 + K8 per-choice payloads, same seed) is published: GLM-5.3-Flash-TR3-partsbin-v1 — multi-precision K6K8 mixes become offline assembly, no GPU re-encode.
Lineage on the Hub
Z.ai published two sibling roots for this model and neither declares the other:
zai-org/GLM-5.3-Flash (the
FP8 release, where most traffic lands) and
zai-org/GLM-5.3-Flash-BF16
(the BF16 weights). This quant declares BF16 as its base_model because
that is what it was actually quantized from — the FP8 release is a sibling
quantization of the same model, not our source, and it is the baseline we
measure against rather than build on. Quants that list FP8 as their base were
genuinely made from the FP8 weights; the trees differ for real reasons.
Related work on the same model, all measured on one panel in the quant-fidelity registry: brandonmusic 4bpw, 0xSero Dione Q4, orcarouter MLX. Collection: GLM-5.3-Flash — measured quants & fidelity.
Credits
Base model by Z.ai. Quantization pipeline, calibration captures, and teacher panel by brandonmusic (co-credited — see the collaboration thread). Trellis codec and kernels by turboderp. Campaign log, tools, and every patch: malaiwah/glm53-flash-fidelity-suite.
Serving — live-qualified turnkey profile
Qualification result
The shipped profile is glm53-k6. It was booted from the packaged appliance
on 4× RTX PRO 6000 Blackwell 96 GiB and passed the appliance's arithmetic,
factual, instruction-following, strict structured-output, and tokenizer-exact
32K retrieval gates. Runtime fingerprint:
vllm-0.1.dev20111+g7f1e92bec.d20260827-tp4-95ae22a9.
- Appliance source commit:
a0d05f76994cf44f3667c0d2910d3b0e4d305d23 - Qualified parent:
verdictai/glm53-flash-exl3-k4@sha256:0f1cdcc8891f1cc3a444121eb61d366289a1cbba285f0892dcbb24bc94961692 - Published appliance:
ghcr.io/malaiwah/glm52-exl3-vast@sha256:5a0d4b370e9f6a2ef85fa8b8c213492122554b34ba18d630a3a78130758914cf - Shape: TP4 / DCP4 A2A, B12X sparse MLA, Triton MoE, EXL3 K6, calibrated NVFP4-DS MLA KV, MTP off, batch 3,072, C8, GMU 0.93
- Request limit: 458,752 tokens; text-only qualification scope
The cap is a correctness boundary, not a memory-capacity guess. Two independent 448K trials produced tokenizer-exact 449,461- and 449,462-token documents and retrieved 3/3 facts at 15%, 55%, and 90% depth. A 480K trial exhausted both 2,048- and 4,096-token answer budgets. A concurrent 505K stress trial caused persistent degenerate follow-on output until restart. Therefore this release does not claim a 500K usable request. The 458,752-token envelope leaves about 9K tokens beyond the longest passing document for template, query, and output.
| document tokens | independent seed | retrieval | elapsed |
|---|---|---|---|
| 384,612 | 20260831 | 3/3 | 81.058 s |
| 449,462 | 20260901 | 3/3 | 95.839 s |
| 449,461 | 20260903 | 3/3 | 94.578 s |
The final appliance boot auto-profiled 20,043,933 logical KV tokens (43.69× one maximum request) and 21.52–21.56 GiB KV per GPU. That large pool is concurrency capacity; it does not override the single-request correctness gate.
Measured throughput
Unique-prefix prefill, one request, no prefix reuse:
| prompt | client-observed tok/s | server-accounted tok/s |
|---|---|---|
| 8K | 2,983 | — |
| 32K | 4,322 | 5,238 |
| 64K | 4,637 | 5,326 |
| 128K | 4,907 | 5,326 |
Aggregate target-only decode (MTP_TOKENS=0):
| input context | C1 tok/s | C4 tok/s | C8 tok/s |
|---|---|---|---|
| 0 | 75.15 | 241.31 | 397.19 |
| 32K | 69.51 | 234.64 | 349.38 |
| 128K | 64.72 | 223.01 | 323.64 |
No preemption was observed in the qualification matrix. These are measurements from one 4× RTX PRO 6000 Blackwell PCIe host, not guarantees for other topology, clock, thermal, driver, storage, or request mixes.
Why K6 is the production default
K8 improves raw panel KLD from 0.013723 to 0.012384 nats (absolute 0.001339) but grows from 254 GB to 331 GB: about 77 GB / 30% more checkpoint bytes. Its live-qualified eager profile uses 78.94–78.97 GiB/GPU for weights plus non-torch allocations and leaves 7.10–7.14 GiB/GPU for KV. K6 leaves 21.52–21.56 GiB/GPU for KV and is 5.3–7.3× faster at short context, or 8.3–24.4× faster when the measured 32K/128K prefill cost is included. K8 is the qualified fidelity-first alternative; K6 remains the production default for its quality/bytes/throughput balance on 4×96 GiB.
Docker Compose
Prerequisites: Linux x86-64, four visible RTX PRO 6000 Blackwell GPUs, NVIDIA driver ≥ 590.48.01 / CUDA 13.2 compatibility, the NVIDIA Container Toolkit, and roughly 300 GiB free persistent storage for the checkpoint plus caches. PCIe P2P on this card family requires NVIDIA's open kernel modules; see the RTX 6000 Pro multi-GPU notes.
name: glm53-k6
services:
api:
image: ghcr.io/malaiwah/glm52-exl3-vast@sha256:5a0d4b370e9f6a2ef85fa8b8c213492122554b34ba18d630a3a78130758914cf
pull_policy: always
restart: unless-stopped
network_mode: host
ipc: host
shm_size: 32gb
stop_grace_period: 2m
ulimits:
memlock:
soft: -1
hard: -1
environment:
MODEL_PROFILE: glm53-k6
AUTH: key
VLLM_API_KEY: ${VLLM_API_KEY:?set VLLM_API_KEY to a long random secret}
HF_TOKEN: ${HF_TOKEN:-}
SSH_ENABLED: "0"
SOUL_ENABLED: "0"
VERIFY_HEALTH_TIMEOUT_S: "3600"
volumes:
- /srv/glm53-turnkey:/workspace
- /srv/glm53-cache:/cache
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 4
capabilities: [gpu]
sudo mkdir -p /srv/glm53-turnkey /srv/glm53-cache
export VLLM_API_KEY="$(openssl rand -hex 32)"
docker compose up -d
docker compose logs -f
First boot downloads about 237 GiB and can take substantial time. The container
is ready only after the log reports >>> Verified: serving; long-context retrieval verified. API: http://HOST:8000/v1; dashboard:
http://HOST:1111. The served model name is GLM-5.3-Flash-K6.
curl http://127.0.0.1:8000/v1/chat/completions \
-H "Authorization: Bearer $VLLM_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"GLM-5.3-Flash-K6","messages":[{"role":"user","content":"Reply with exactly READY"}],"max_tokens":256}'
Do not replace only the checkpoint path in another vLLM command. The profile, parent digest, runtime overlays, quantization, attention backend, DCP topology, KV calibration, scheduler, and graph widths are one qualified contract.
- Downloads last month
- 60
Model tree for malaiwah/GLM-5.3-Flash-TR3-6bpw
Base model
zai-org/GLM-5.3-Flash-BF16Datasets used to train malaiwah/GLM-5.3-Flash-TR3-6bpw
malaiwah/GLM-5.3-Flash-fidelity-suite-v1
Collection including malaiwah/GLM-5.3-Flash-TR3-6bpw
Evaluation results
- Mean tokenwise KLD (reference || candidate), nats on brandonmusic GLM-5.3-Flash sealed qualification panel v1 -- 25 final windows -- panel25 subsetquant-fidelity-registry0.014
- KLD attributable to quantization (same-lane floor removed), nats on brandonmusic GLM-5.3-Flash sealed qualification panel v1 -- 25 final windows -- panel25 subsetquant-fidelity-registry0.002
- Top-1 agreement with reference on brandonmusic GLM-5.3-Flash sealed qualification panel v1 -- 25 final windows -- panel25 subsetquant-fidelity-registry0.966
- Mean tokenwise KLD (reference || candidate), nats on brandonmusic panel v1, calibration-clean subset -- 17 of 25 final windows -- clean17 subsetquant-fidelity-registry0.012
- Mean tokenwise KLD (reference || candidate), nats on brandonmusic GLM-5.3-Flash sealed qualification panel v1 -- 25 final windows -- panel25 subsetquant-fidelity-registry0.014
- Mean tokenwise KLD (reference || candidate), nats on brandonmusic panel v1, calibration-clean subset -- 17 of 25 final windows -- clean17 subsetquant-fidelity-registry0.012