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

Qwen3.8-9B-Distill · file← Qwen3.8-9B-Distill

Q4_0 stub

Our attempt at a faster Q4_0. The conversion was refused and left a broken 10 MB file; never a model. Failed requantisation from the Q8_0.

Size
0.0 GB
Status
On disk
Scored runs
0
ResultsNever scored

This file never completed a scored run. Its record below says why.

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.

FileQwen3.8-9B-Q4_0.gguf
Formatbroken output of a refused requantisation, 10,968,384 B
Where frommade here 2026-09-14 14:26Z; not a valid GGUF
Statuson disk (stub, undeleted by instruction)

How it was made

.local/bin/llama-quantize Qwen3.8-9B-Q8_0.gguf Qwen3.8-9B-Q4_0.gguf Q4_0
  • Tool: stock llama.cpp 0.4.0-dev (build 10893, commit c32d1dabe).
  • Result: [ 1/ 442] output.weight... type = q8_0, llama_model_quantize: failed to quantize: requantizing from type q8_0 is disabled and failed to quantize model from 'Qwen3.8-9B-Q8_0.gguf'; a 10M file was left. The command had no --allow-requantize.
  • Date / who asked: 2026-09-14 14:26Z; the assistant, as part of the plan stated at 14:17Z.
  • Size: 10,968,384 B, mtime 2026-09-14 15:27 BST (stat, 2026-10-23). sha256 not applicable.

How it was served

labeldates (UTC)binary and versionctx / -np / KV / -fa / --jinja / --reasoning-formatharness profilewhy this label exists
none (never scored)2026-09-14 ~14:27Z, load attempt only.local/bin/llama-server, b10893-c 4096 -np 1 -ngl 999 -fa on, no --jinjanonea load probe of the new Q4_0; it failed

The same command line tried to load the stub with -c 4096 -np 1 -ngl 999 -fa on and failed: error loading model: llama_model_loader: failed to load model. Seats held: none.

Decisions

  • The assistant left the stub in place: "broken 10M artefact left in place (not deleting without your say)", per the standing no-delete rule.
  • No retry with --allow-requantize is on record. On 2026-09-14 15:46Z the assistant wrote that llama.cpp "refuses to requantise from Q8, so that needs the 18.4 GB BF16", which is wrong for this build: the refusal is a default that --allow-requantize overrides, as used for the Q4_0 builds of other families (e.g. K2-Horizon-36B-A4B's Q4_1).

What went wrong

  • Misdiagnosis on 2026-09-17. A path check showed "Qwen3.8-9B-Q4_0.gguf (10M)" and the assistant called it "a 10 MB stub — a truncated download". It was not a download; it was the 14:26Z llama-quantize output.
  • The 2026-10-05 disk inventory lists it at 0.0 GB.

What happened to it

Created by a failed command 2026-09-14 14:26Z → still on disk on 2026-10-23 (10,968,384 B) → safe to delete (nothing refers to it; it does not load), but not deleted here. No RESTORE entry is needed: it carries no weights.