Andy5k/Qwen3.5-0.8B-hand-quant

The human here: EVERYTHING was done by agents, exept this little paragraph. The whole hand quantisation was performed by Opus 5.5. the idea was inspired by Weight Space Programming but from what i understand it was actually not used. my session with Opus was also stopped in the end by Anthropic for "it seems to violate Anthropic's Terms of Service restrictions on reverse engineering or duplicating model outputs". Not sure if that is fair on a model that has a Apache 2.0 license... anyway.

Qwen3.5-0.8B — hand-rounded GGUF (498.5 MB)

A quantised version of Qwen/Qwen3.5-0.8B where every precision decision was made by measurement, not by a fixed recipe.

No quantisation tool was used: no llama-quantize, no llama-imatrix, no calibration file, no published per-tensor recipe. The rounding was written from scratch in NumPy, and the bit budget per weight table was chosen from a measured sensitivity map. The result uses only stock llama.cpp formats, so it loads and runs in unmodified llama.cpp.

Result: milestone M3. At 498.5 MB it reaches a mean KL divergence of 0.015704 on a held-out judging set — 5.9× lower than Unsloth's UD-Q3_K_XL at the same size (0.092486), and better than UD-Q4_K_XL at 558.8 MB (0.027323). It does not reach the UD-Q5_K_XL quality bar (0.010375): it misses by 1.51×. See METHOD.md for what worked, what did not, and why the last gap was not closed.

Measured results

All numbers from stock llama.cpp b11928 (commit 7eed6b768), Metal, -c 2048, reference = the BF16 file. The judging set is text the rounding never saw; the tuning set is what the decisions were made on.

File	Bytes	Mean KLD	99% KLD	Same top word	PPL	Generate tok/s	Prompt tok/s
this file (hq-c2-mix-full)	498,454,560	0.015704 ± 0.000212	0.108148	93.196%	9.1579	77.8	1202.1
UD-Q5_K_XL (the quality bar)	606,585,088	0.010375 ± 0.000103	0.066944	94.550%	9.1145	61.7	1087.5
UD-Q4_K_XL	558,772,480	0.027323	0.173759	91.222%	9.2735	76.6	1269.1
IQ4_XS (best stock file under 500 MB)	492,605,696	0.059359	0.394602	87.737%	9.6680	63.7	880.8
UD-Q3_K_XL (same size class)	492,216,576	0.092486	0.579284	84.883%	10.0755	67.0	806.1

This file was timed in the same paired run as UD-Q5_K_XL: generation ratio 1.11×, prompt ratio 0.95×. The other rows were timed separately, so read them as approximate.

On the tuning set this file measures 0.011749 mean KLD. That number is in-sample — the rounding statistics were taken from the same text — so treat 0.015704 as the number to believe. Temperature-0 answers matched the BF16 reference on 3 of 40 questions, with the first differing token at position 9 on average (UD-Q5_K_XL: 4 of 40, first difference at 13).

Pass criteria against the Q5_K_XL bar: size pass, speed generation pass, speed prompt pass (0.95×), loads in stock llama.cpp pass, mean KLD fail, 99% KLD fail, same-top-word fail.

How it was made, in one paragraph

The model was run in float on a second copy of itself to measure, for every weight table, how much signal actually flows through each input column. Rounding error was then minimised where that signal is strong, using a weighted least-squares fit for the block scales followed by an integer coordinate descent over the stored codes and scales. Each table's damage was measured on its own, which produced a sensitivity map, and a budget optimiser spent the 485.5 MB available for weights across IQ4_XS (4.25 bits), Q5_K (5.5) and Q6_K (6.56) to minimise total damage. Statistics came from half the tuning text and measurements from the other half, so the design choices were checked out of sample. Full write-up: METHOD.md.

What is inside the file

Weight group	Formats	Tables	MB
token_embd (vocabulary, also the output head — tied)	IQ4_XS	1	135.1
attn_qkv (18 linear-attention layers)	IQ4_XS ×9, Q5_K ×8, Q6_K ×1	18	69.8
ffn_down	Q5_K ×9, Q6_K ×15	24	67.9
ffn_up	Q5_K ×18, Q6_K ×6	24	63.5
ffn_gate	IQ4_XS ×3, Q5_K ×20, Q6_K ×1	24	59.3
ssm_out	Q5_K ×1, Q6_K ×17	18	30.7
attn_gate	IQ4_XS ×3, Q5_K ×14, Q6_K ×1	18	25.2
attn_q	Q5_K ×6	6	17.3
attn_output / attn_k / attn_v	Q6_K	18	15.5
norms, ssm_* and other small tensors	F32 / BF16, unchanged	133	3.3

Per-tensor detail: data/tensor-types.csv. The exact budget plan: data/alloc-c1.json. All measurements: data/scores.csv.

Using it

Any llama.cpp build from b11928 or newer, or anything that reads GGUF:

llama-cli  -m Qwen3.5-0.8B-hq-mix.gguf
llama-server -m Qwen3.5-0.8B-hq-mix.gguf

Measured on a MacBook Air M4 (16 GB): 77.8 tokens/s generation, 1202 tokens/s prompt processing. Average bits per weight: 5.18 across all 752,393,024 weights, or 5.16 counting only the weight matrices (the 1.06 million norm and state-space weights stay at full precision, costing 3.1 MB).

Caveats worth reading before you use it

• It is not Q5 quality. It is roughly Q4-XL quality in a file 60 MB smaller than UD-Q4_K_XL.
• The vocabulary table is the bottleneck. It is 33.8% of this model's weights and, because the embeddings are tied, it also scores the next word. It alone accounts for about 0.010 of the 0.0157 mean KLD. Giving it 5.5 bits needs 39.8 MB more, and the optimiser says the rest of the network loses more than that gains — which is why this file stops where it does.
• Metadata is inherited. general.quantized_by still says Unsloth and general.repo_url still points at the Unsloth account, because the 16-bit source file was a Unsloth conversion and the writer keeps all 45 metadata fields and the chat template untouched. The quantisation itself was done by hand; see METHOD.md.
• One sibling file exists locally and is not published here: hq-c1-mix-even (same size, rounded from half the tuning text only) measures 0.014124 on the tuning set and 0.016955 on the held-out half. It is the more conservative design; it has no sealed-set score.

Reproducing it

scripts/ holds the whole pipeline: packers.py (the format encoders, with test_packers.py verifying them bit-for-bit against gguf-py's dequantiser), mlxmodel.py (a float copy of the model used for measurement), rounding.py (the rounding itself), sens.py and inventory.py (the measurements behind the decisions), alloc.py (the budget optimiser), and build_final.py (the file builder). They need NumPy and gguf-py, plus MLX for the measurement steps. Nothing in them calls a quantisation tool.

Provenance

The quantisation was carried out on 7 November 2026 over about three and a half hours on a single 16 GB MacBook, by an agent working from a written challenge brief: build a sub-500 MB file from the 16-bit weights only, with no quantisation tool and no copied recipe. Every number in this card was measured locally with stock llama.cpp; the sealed judging set was used once and never read. The card and the write-up were assembled afterwards from the run's work log, so the two should agree — if they ever disagree, trust the measurements in data/scores.csv.

Licence and attribution

Apache-2.0, inherited from Qwen/Qwen3.5-0.8B. Model weights derive only from the BF16 file of that model (sha256 cedf89af…26ee5). No other model's weights, scales or per-tensor choices were read.