K2-Horizon-36B-A4B · file← K2-Horizon-36B-A4B

Q5_0

A format experiment: one test, then deleted. Requantised here from the local Q4_K_M.

Size: 24.0 GB
Status: Deleted 11 Sep 2026
Scored runs: 1
Smallest Mac: 48 GB estimate, 8K context

Results1 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
nullschemak2-36b-Q5_0	56.9%	45.4–67.7	Passed 41/72	llama.cppextraction	2026-09-11

Runs marked unenforced were measured on a suite that requires constrained decoding, on a server shown not to apply the schema: mlx_lm accepts it and ignores it, and a few other servers and models break it. Those numbers do not measure what the suite is designed to measure. They are kept and labelled rather than deleted.

The recordHow it was made · how it was served · what went wrong · what happened to it

Rebuilt from the lab's records by Claude, an AI model. The results above come straight from the automated runs. How these pages are made.

File	`K2-36B__Q5_0.gguf`
Format	Q5_0, ~24 GB
Where from	made here 2026-09-11 from the Q4_K_M
Status	deleted 2026-09-11

How it was made

Command:

llama.cpp-k2horizon/build/bin/llama-quantize --allow-requantize \
K2-Horizon-36B-A4B-Q4_K_M.gguf models/_q40test/K2-36B__Q5_0.gguf Q5_0

Tool: k2horizon fork @ 35999d1 (build 20); bench with the fork's llama-bench -p 0 -n 64 -ngl 99 -r 3.
Date: 2026-09-11.
Size: ~24 GB (du -h 24G); 24.1 GB in the ladder table. Exact bytes never recorded; sha256 not on record.
Who asked / why: part of the format ladder that followed Alan's "we have a lever, chase it, measure it, prove it". The hypothesis was written into the script at the time: "If exact scales are the mechanism, Q5_0 should close most of the remaining gap at ~24 GB instead of Q8_0's 37 GB".

How it was served

label	dates (UTC)	binary and version	ctx / -np / KV / -fa / `--jinja` / `--reasoning-format`	harness profile	why this label exists
`k2-36b-Q5_0`	2026-09-11, finished 13:35:56 (run-log 14:35:56 BST)	fork `llama-server`, `0.3.0-dev (build 20, commit 35999d1)`	131072 / 1 / q8_0 / on / not on the line / deepseek	extraction; `--model-id` = the file path; nullschema only	the exact-fp16-scales hypothesis, at ~24 GB instead of Q8_0's 37 GB

Seats held: none.

Run-log runtime: llama.cpp b20 (35999d1) (runtime_source "props"). Never seated.

Decisions

Made only to test a mechanism. It was never a serving candidate.
Outcome: Q4_1 falsified the "exact fp16 scales" explanation for Q4_0's nullschema gain. The assistant then offered symmetric quantisation as a hypothesis "I'd hold... loosely". Finding Quantisation format changes output CONVENTIONS, not abstention judgement (revised) later attributed the gain to fewer malformed responses, not judgement.
Deleted 2026-09-11 13:38Z, after its result was verified on disk.

What went wrong

Disk pressure drove the deletion: 30 GB free before it and 54 GB after.
The run-log llama_build field names upstream build 10893 rather than the fork (same issue as every K2 entry).
The manifest records the full _q40test path as the model id; that directory no longer exists.
Missing flag (standing check): the server line had no --jinja; build 20's default is not on record. Partial runs: none (72 rows).

What happened to it

Requantised here 2026-09-11 → nullschema + speed 2026-09-11 → deleted 2026-09-11 13:38Z, after its result was verified on disk. No RESTORE-deleted-*.sh entry. Re-creatable only via BF16 → Q4_K_M → Q5_0 (K2-Horizon-36B-A4B Q4_K_M (quantised here from IFM's BF16) + the command above). The run-log result survives.