Kolibri-1 78B-A3.5B · file← Kolibri-1 78B-A3.5B
Q4_0
The one we made and scored, 44.2 GB. Still on disk, not in use. Made here from the Hob-forge Q8_0, --allow-requantize.
- Size
- 44.2 GB
- Status
- On disk
- Scored runs
- 7
- Smallest Mac
- 96 GB estimate, 8K context
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| chainwalkkolibri-1-q4_0 | 50.0% | 9.5–90.5 | Passed 1/2 | llama.cppextraction | 2026-10-05 |
| nullschemakolibri-1-q4_0 | 54.2% | 42.7–65.2 | Passed 39/72 | llama.cppextraction | 2026-10-05 |
| screeningkolibri-1-q4_0 | 95.0% | 86.3–98.3 | Passed 57/60 | llama.cppextraction | 2026-10-05 |
| synthesiskolibri-1-q4_0 | 63.3% | 50.7–74.4 | Passed 38/60 | llama.cppextraction | 2026-10-05 |
| toolcallkolibri-1-q4_0 | 100.0% | 94.0–100.0 | Passed 60/60 | llama.cppextraction | 2026-10-05 |
| toolscalekolibri-1-q4_0 | 100.0% | 91.2–100.0 | Passed 40/40 | llama.cppextraction | 2026-10-05 |
| worldviewkolibri-1-q4_0 | 60.0% | 44.6–73.7 | Passed 24/40 | llama.cppextraction | 2026-10-05 |
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.
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 | Kolibri-1-Q4_0.gguf (44.19 GB) |
| Format | GGUF Q4_0 |
| Where from | made here from the Q8_0 above |
| Status | benched; on disk; not seated |
| Hugging Face | none (local) |
How it was made
- Input: the two-part Hob-forge Q8_0 (Kolibri-1 Q8_0 (Hob-forge two-part GGUF; quantisation source and PPL reference)), pulled with
pardl.shon 2026-10-05; both parts verified against HF. Reason for this route, from the download script header: Q8_0 is near-lossless "so Q8_0 -> Q4_0 is effectively BF16 -> Q4_0", and nothing larger fits the disk (models/kolibri-1-gguf/download-q8.sh). - Tool:
llama.cpp-kolibri/build/bin/llama-quantize, build0.5.0-dev (build 11396, commit 2e7c58c54)with the Hob-forge patch. - First attempt (silently failed):
nohup.../llama-quantize Kolibri-1-Q8_0-00001-of-00002.gguf Kolibri-1-Q4_0.gguf Q4_0 8at 10:47Z. It stopped at tensor 1 with a failed-to-quantize line that contained no occurrence of the word error, so the waiter written to grep for error slept for an hour. - Command that worked (11:48Z):
rm -f Kolibri-1-Q4_0.gguf && nohup llama.cpp-kolibri/build/bin/llama-quantize --allow-requantize Kolibri-1-Q8_0-00001-of-00002.gguf Kolibri-1-Q4_0.gguf Q4_0 8. 59 seconds, 903 tensors. - Size: 44,193,185,472 B (stat,
models/kolibri-1-gguf/); 41.15 GiB, 4.53 bpw per llama-bench;output.weightQ6_K. sha256 not on record. - Who asked: Alan, 2026-10-05 09:59Z, "4_0 works better", after "k m quants are slower on m1". Nobody had published a Q4_0.
- Imatrix: none for this file. A separate imatrix was later computed from it on 2026-10-11; it fed no shipped file.
How it was served
Every row of the run log for this variant carries the label below; the other rows are unlabelled work that never reached the run log.
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
kolibri-1-q4_0 | 2026-10-05 12:44-12:56Z (run log local 13:44:16-13:56:23) | llama.cpp-kolibri/build/bin/llama-server, 0.5.0-dev (build 11396, commit 2e7c58c54) + Hob-forge patch (manifest build b11396-2e7c58c54) | 65536 / 1 / default (f16) / on / on / not set | extraction (thinking off, 2048 cap), model-id kolibri-1-78b | the seven-suite seat board, the same single configuration the K2-36B board ran |
| — (no label; window aborted) | 2026-10-11 12:37-12:38Z | llama.cpp-kolibri/build-master/bin/llama-server, 0.6.0-dev (build 11533, commit 769ced466) | 262144 / 4 / q4_0 / on / on / not set | extraction | intended label kolibri-1-q4_0-np4-b11533: the serving-config gauntlet; produced no suite rows (see Incidents) |
| — (no label; speed windows) | 2026-10-05 12:42Z (llama-bench); 2026-10-09 ~16:12Z (A/B); 2026-10-11 13:43-13:48Z | build/ b11396 on Oct 5; build/ vs build-master/ on Oct 9; build-master/ b11533 on Oct 11 | llama-bench -ngl 99; batched-bench -fa on -c 8192 | none | speed and cache-type measurements, below |
Seats held: none. Kolibri was never registered with fleetview or the router; it ran on a loopback test port with the seats unloaded for each window.
Decisions
- Made to get a fast GGUF of a model with no published Q4_0, on Alan's Q4_0-over-K_M preference.
- Not seated. After the seat board the 2026-10-05 verdict was "a measured no" on consolidation and the role "on-demand generalist on a second host". Alan, 10:09Z: "trying to figure out if this is a good or a bad move, the fleet I have just now is pretty versatile".
- Kept on disk through the 2026-10-11 sweeps: the sweep note flags it as the biggest single directory and leaves it as "Alan's call" (a lab note).
What went wrong
- Silent quantise failure (2026-10-05).
llama-quantizewithout--allow-requantizefailed on tensor 1 without the word error in its message; the waiter missed it and the session lost an hour. Fixed by the flag and by grepping for fail. - Stale or mislabelled build stamp (standing check). The run-log label says
llama.cpp b11396 (2e7c58c54), which reads as upstream. The binary was upstream2e7c58c54plus an uncommitted Hob-forge patch, so the stamp names the base but not the patch; the directory was later corrupted, so the exact binary cannot be rebuilt from the stamp alone (a branchfc/kolibri1-b11396was kept for that). - Build-directory corruption (2026-10-09). A target was rebuilt into
build/after the worktree had moved to master, sobuild/carried 0.6.0 libraries under b11396 binaries; the 2026-10-09 A/B compared 0.6.0 with 0.6.0 (a lab note changelog). It voids the 125.3 t/s four-stream cell as a b11396 figure. - Aborted serving-config gauntlet (2026-10-11 12:37Z). The window script died at 12:38:21Z with
xargs: command line cannot be assembled, too longbefore any suite started. The fleet was down about 8 minutes, the batched step ran, and nokolibri-1-q4_0-np4-b11533rows exist. Cost: the six unrun extraction suites. The rewritten scheduler was first used for Sakura. - PPL comparison trap. Two different Q4_0 perplexities (8.31 on 20 GPU chunks, 7.35 on 10 CPU chunks) are both quoted in the lab's notes; only the CPU pair against Q8_0 is like-for-like.
- Missing flags (standing check): the board server line has
--jinjaand-fa onbut no--reasoning-format; profileextractionsets thinking off, so the reasoning-effort question (low vs high) does not apply to these rows.
What happened to it
Q8_0 pulled 2026-10-05 -> quantised 11:48Z -> loaded and answered 11:50Z (133 t/s prefill, 64 t/s decode on a tiny request) -> PPL, llama-bench, seat board 12:42-12:57Z -> source Q8_0 deleted 12:42Z -> Oct 9 and Oct 11 speed work -> on disk 2026-10-23 (44,193,185,472 B, mtime 2026-10-05 12:49 local). No RESTORE script entry. Re-creatable: Hob-forge Q8_0 plus the command above, on a Hob-forge-patched llama-quantize.