FreshContextA context lab · Fife
Drawing
02 · Benchmarks
Sheet
2 of 3
Rev
A · 2026-10-01

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
Results7 scored · 95% intervals
SuiteScore95% interval PassedRuntime · profileRecorded
chainwalkkolibri-1-q4_050.0%9.5–90.5Passed 1/2llama.cppextraction2026-10-05
nullschemakolibri-1-q4_054.2%42.7–65.2Passed 39/72llama.cppextraction2026-10-05
screeningkolibri-1-q4_095.0%86.3–98.3Passed 57/60llama.cppextraction2026-10-05
synthesiskolibri-1-q4_063.3%50.7–74.4Passed 38/60llama.cppextraction2026-10-05
toolcallkolibri-1-q4_0100.0%94.0–100.0Passed 60/60llama.cppextraction2026-10-05
toolscalekolibri-1-q4_0100.0%91.2–100.0Passed 40/40llama.cppextraction2026-10-05
worldviewkolibri-1-q4_060.0%44.6–73.7Passed 24/40llama.cppextraction2026-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.

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.

FileKolibri-1-Q4_0.gguf (44.19 GB)
FormatGGUF Q4_0
Where frommade here from the Q8_0 above
Statusbenched; on disk; not seated
Hugging Facenone (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.sh on 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, build 0.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 8 at 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.weight Q6_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.

labeldates (UTC)binary and versionctx / -np / KV / -fa / --jinja / --reasoning-formatharness profilewhy this label exists
kolibri-1-q4_02026-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 setextraction (thinking off, 2048 cap), model-id kolibri-1-78bthe seven-suite seat board, the same single configuration the K2-36B board ran
— (no label; window aborted)2026-10-11 12:37-12:38Zllama.cpp-kolibri/build-master/bin/llama-server, 0.6.0-dev (build 11533, commit 769ced466)262144 / 4 / q4_0 / on / on / not setextractionintended 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:48Zbuild/ b11396 on Oct 5; build/ vs build-master/ on Oct 9; build-master/ b11533 on Oct 11llama-bench -ngl 99; batched-bench -fa on -c 8192nonespeed 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-quantize without --allow-requantize failed 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 upstream 2e7c58c54 plus 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 branch fc/kolibri1-b11396 was kept for that).
  • Build-directory corruption (2026-10-09). A target was rebuilt into build/ after the worktree had moved to master, so build/ 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 long before any suite started. The fleet was down about 8 minutes, the batched step ran, and no kolibri-1-q4_0-np4-b11533 rows 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 --jinja and -fa on but no --reasoning-format; profile extraction sets 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.