Qwen3.5-9B · file← Qwen3.5-9B
Q8_0
The Q8_0 made again from itself, as the sweep's 8-bit point. Speed tests only. Re-rounded here from the Q8_0, "quantlab".
- Size
- 9.5 GB
- Status
- Deleted 12 Sep 2026
- 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.
| File | _quantlab/qwen35-9b-Q8_0.gguf |
| Format | Q8_0 re-rounded from Q8_0, 9.53 GB |
| Where from | made here, same pass |
| Status | deleted 2026-09-12 |
How it was made
- File:
models/_quantlab/qwen35-9b-Q8_0.gguf(9.53 GB; 8.9G bydu, equal in size to the downloaded Q8_0). Made from the downloaded Q8_0 (Qwen3.5-9B Q8_0 (unsloth GGUF)), which is why it carries a second rounding; the near-identical size to the downloaded Q8_0 is expected for the same tensors in the same format and is not evidence that this is the downloaded file. - Command:
.local/bin/llama-quantize --allow-requantize models/qwen3.5-9b/Qwen3.5-9B-Q8_0.gguf models/_quantlab/qwen35-9b-Q8_0.gguf Q8_0 8(loop over Q4_0, Q5_0, Q6_K, Q8_0). - Date / who asked: 2026-09-11 21:01-21:09Z; the assistant, to answer Alan's question about making sub-4-bit models ("Can we ternary models ourselves or do you need the actual training data") and Alan's two questions of 13:31Z and 13:34Z: "also I wonder if q5_0 or q6_0 become the sweet spot?" and "so q6 being divisible by 2 won't help?". The
_quantlabdirectory was created by this command. - sha256: not on record. Exact bytes: not on record (only the rounded sizes shown).
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
| (no run-log label) | 2026-09-11 21:02-21:11 | .local/bin/llama-cli / llama-perplexity (symlink to llama.cpp, b10893 by reconstruction) | -c 4096 -ngl 99 -n 192 --temp 0 -st (speed); -c 512 -ngl 99 --chunks 12 (PPL) | n/a | alignment sweep: speed per byte |
Seats held: none.
Decisions
- Made to test whether decode speed tracks bit width or byte alignment. The answer was alignment: 8, 4 and 2 bits divide a byte; 5 and 6 do not.
- Kept for the evidence on 2026-09-11 22:28Z (small outputs, F16 intermediates removed); deleted with the family next morning on Alan's "Kill qwen 3.5 9b and everything to do with it". Not published.
What went wrong
- The source was the Q8_0, so "requantising from Q8_0 compounds error -- this measures SPEED/alignment only, not quality. Quality comparison needs a BF16 source" (the BF16 GGUF was never fetched).
- It is a Q8_0 re-rounded to Q8_0; the assistant did not comment on whether the file differs from its source.
- Standing checks: no suite ran, so partial-run, build-stamp and flag checks do not apply.
What happened to it
Made 2026-09-11 -> speed-probed -> deleted 2026-09-12 07:45:56Z. No RESTORE-deleted-*.sh entry exists for it. Re-creatable from the Q8_0 (itself deleted) or from a fresh BF16 download.