malaiwah/GLM-5.3-Flash-TR3-partsbin-v1

GLM-5.3-Flash TR3 parts bin v1 — K6 + K8 payload stores under one transform seed

This dataset is the parts bin for the GLM-5.3-Flash TR3 quantization campaign (2026-08-27/28): the complete per-choice payload stores of the two published uniform quants, plus the preparation artifacts and provenance receipts that produced them.

• —malaiwah/GLM-5.3-Flash-TR3-6bpw (uniform K6)
• —malaiwah/GLM-5.3-Flash-TR3-8bpw (uniform K8)

What a parts bin is

TR3 (trellis) encoding is expensive: every matrix is quantized on a GPU against calibration data. Normally, wanting a mixed-precision build (say, 8-bit down_proj with 6-bit gate/up) means re-running that GPU encode for a third time.

Both campaigns here were deliberately encoded with the same transform seed and the same calibration — transform-seed.json is byte-identical in k6/ and k8/ (transform_seed_sha256 = 560ab697…). Because the transform basis is shared, the per-matrix payloads of the two stores are interchangeable parts: any matrix can take its K6 payload or its K8 payload, and the result is still a coherent checkpoint.

That turns mixed-precision assembly into offline CPU work, forever:

1. 1.pick a per-matrix precision plan (e.g. K8 down_proj, K6 gate_proj/up_proj);
2. 2.resolve each matrix's choice record from k6/payload-store/choices/ or k8/payload-store/choices/;
3. 3.copy the referenced content-addressed objects out of the corresponding objects/ tree and materialize shards.

No GPU, no re-encode, no calibration data needed. This dataset exists so that step is possible without ever re-running the encode fleet.

Disclosed caveat for mixed builds

There is one known second-order interaction: during encoding, `down_proj` conditioning assumed its own K's `gate_proj`/`up_proj` decode (K6 down_proj was conditioned behind K6 gate/up, K8 behind K8). A mixed build breaks that pairing slightly. The effect is expected to be small, but it is not measured — any mixed K6K8 assembly must be re-measured on the sealed panel before quoting fidelity numbers. Do not extrapolate the uniform numbers below to a mix.

Sealed fidelity numbers (uniform builds)

Both measured on the same sealed 25-window panel against the same teacher logits; lane details and every intermediate hash live in the model repos.

Structure

k6/
  payload-store/
    choices/    37,152 choice records (JSON), one per matrix:
                36,288 main (42 routed layers x 288 experts x gate/up/down)
                +  864 MTP  (288 experts x gate/up/down)
                keyed by choice_id, e.g. L021.E148.gate_proj.K6
                sharded <first-2-hex-of-sha256>/<sha256>.json
    objects/    content-addressed payloads, 256-way fan-out;
                filename == sha256 of the file's bytes (.bin)
  preparation/  per-layer GSS / normalization artifacts (K-specific)
  *.json        campaign provenance at the root: contract.json,
                transform-seed.json, profile-selection.json, main-receipt.json,
                mtp-adapter-receipt.json, launch plans, inventories, receipts
k8/             same layout for the K8 campaign

Total: 223,389 files, ~549 GB.

One layout note. In the campaign's on-disk store, choices/ is a single flat directory. The Hub caps a repository directory at 10,000 files, so here each choices/ is sharded by the first two hex characters of its sha256 — the same 256-way fan-out the store already uses for objects/, applied one level up. To reconstruct the original flat layout, move every choices/<xx>/<sha>.json up to choices/<sha>.json; nothing else differs, and no file content was changed. The internal .layer-NNN.staging-PID directories left behind by the preparation loop are omitted: they are hardlink duplicates of the corresponding layer-NNN directories.

Each choice record carries the decoder metadata needed to consume its payloads (codec family exl3-mcg, MCG multiplier, reader-ABI hash, object paths and byte counts), so the store is self-describing. Preparation is K-specific (GSS targets the codebook); moments/calibration are shared between the two campaigns.

Codec and runtime, plainly

These artifacts are TR3 (trellis codec family). They are not loadable by stock exllamav3 — the encoding reuses turboderp's exllamav3 trellis kernels and on-disk framing (exl3-mcg schema strings appear in the artifacts), but GLM-5.3-Flash is not a stock-exllamav3 architecture and the checkpoints require the campaign's own reader. The model cards state the codec-vs-runtime distinction in full.

Related repositories

• —Fidelity measurements: malaiwah/GLM-5.3-Flash-fidelity-suite-v1
• —Cross-quant registry: malaiwah/quant-fidelity-registry
• —Tools and harness: github.com/malaiwah/glm53-flash-fidelity-suite

Credits

• —zai-org — the base model, zai-org/GLM-5.3-Flash-BF16 (quantized from revision a6c167b62691b2bac901344b65cb651a70f53e43).
• —brandonmusic — quantization pipeline, calibration captures, teacher logits and the sealed-window measurement protocol (pipeline, teacher logits).
• —turboderp — the exllamav3 trellis kernels the encode runs on.

License: MIT for the artifacts in this dataset; the model weights derived from them remain subject to the upstream model license (see the model repos).