malaiwah/glm-moe-dsa-tiny-cpu-repro-v1

Tiny GLM MoE DSA: two CPU captures, forced zero-KL replay

Reproducibility evidence for malaiwah/glm-moe-dsa-tiny-random-bf16, checkpoint/config/tokenizer revision 45563636ef723acfb826755493447dc40c7a0c37.

This is a synthetic pipeline test, not a quality benchmark, quantization measurement, qualified production reference, or registry submission. The model is random-init. No GPU or paid cloud job was used.

Observed result

• —Two fresh capture processes, two CPU threads each, distinct cold-run labels.
• —Four windows x 64 tokens, 252 scored positions across the complete synthetic panel.
• —Both capture trees pass QFS tensor verification and strict dataset validation.
• —Identical checkpoint, output-head, runtime-stack and capture-content identities.
• —Full-vocabulary FP64 KL estimator with NumPy CPU FP32 head replay.
• —--self-compare --force-compute: KL = 0.0 nats, 252 literal positive float64 zeros, force_compute_agreed: true; reported top-1 agreement 1.0.
• —Peak capture RSS 367,374,336 bytes. Full driver, including eight fresh Python commands and their import/validation overhead: 34.86 seconds on the recorded Intel Xeon X5570. This is not an HF CPU Basic latency benchmark.

Both captures' tensor-content digest:

d3a8907faca213c298b4ff9e77dd5f041bba4353603447a30457e33c33386d39

QFS keeps the reproduction hash-proof result even when forced numerical replay is requested. The receipt therefore retains short_circuited: true; the separate self_compare.force_compute_agreed: true attests that the numerical KL array was actually computed and matched. Its top-1 value is an identity-proof result. The generic receipt determinism block counts one comparison, not the two capture processes; see the separate evidence summary for their process IDs and equal digests.

Contents and identities

This repository is an evidence bundle, not one root-format fidelity dataset. first/ and repeat/ are individually sealed fidelity dataset trees. Their original files are preserved unchanged, including local execution paths and timestamps as provenance. Load the bundle as files and pass those local subdirectories to QFS. Do not treat the repository root as a single hf:// fidelity dataset.

Re-run from the model, not from a fabricated zero

Follow the model card's complete commands. verify_cpu.py runs the unmodified QFS capture entrypoint twice, validates both captures, forces the numerical comparison, checks the tokenwise array, and fails on any divergence or invalid result. Its outputs must be a new directory.

The source checkout is quant-fidelity-suite at a903cddb078c2eda8c65d6e6c875a09ac932df49. The lane is the schema's other, explicitly disclosed as CPU—not a CUDA lane. The normal generation sanity probe is enabled and checks for nondegenerate logits; no Paris continuation is required from a random model.

Download and inspect the already captured evidence

hf download malaiwah/glm-moe-dsa-tiny-cpu-repro-v1 --repo-type dataset --local-dir evidence
python qfs/bin/fidelity_dataset.py verify evidence/first --verify-tensors
python qfs/bin/fidelity_dataset.py verify evidence/repeat --verify-tensors
python qfs/bin/fidelity_dataset.py compare \
  --reference evidence/first --candidate evidence/repeat \
  --self-compare --force-compute --device cpu --replay-device numpy \
  --replay-dtype float32 --verify-tensors --out replay-check

Use the pinned CPU requirements and QFS source above. Comparing these already saved captures verifies replay, not a new independent model capture. Use verify_cpu.py for the latter. Results are scoped to this fixture, panel, dtype, runtime and hardware; no cross-hardware bitwise guarantee or general model-quality conclusion is made.