Qwen3.5-9B · file← Qwen3.5-9B
TQ2_0
Our home-made ternary model. Fast, but it no longer worked as a model. Ternarised here, quantlab.
- Size
- 3.2 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-tern-TQ2_0.gguf |
| Format | TQ2_0 + fallback tensors, 3.19 GB |
| Where from | made here from the ternarised F16 |
| Status | deleted 2026-09-12 |
How it was made
- File:
models/_quantlab/qwen35-9b-tern-TQ2_0.gguf(3.19 GB bygetsize; 3.21 GB in the 2026-09-12 listing; 3.0G bydu; 2.85 bits per weight). Made from the ternary F16. 56% of the file is TQ2_0 tensors (1.78 GB); 44% is fallback tensors (Q6_K 0.83 GB, Q4_K 0.57 GB) because llama-quantize refuses to take the 248k-vocab embedding and output below 4 bits. - Command:
.local/bin/llama-quantize models/_quantlab/qwen35-9b-tern-f16.gguf models/_quantlab/qwen35-9b-tern-TQ2_0.gguf TQ2_0 8(quantize time 17.4 s) - 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 as the proof of whether a home-made ternary is usable. Verdict: "mechanically yes, usefully no"; the format is fast, but naive ternarisation destroys the model. (The packing is lossless by the kernel's arithmetic; the exact round-trip test on the DFlash drafter produced no output, so exactness was not demonstrated on any file.)
- Alan's reaction, 21:18Z: "I’m surprised the ternary isn’t going faster tbh but it’s a size thing right?"; the assistant's decomposition above was the answer.
- Deleted 2026-09-12 07:45:56Z. 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).
- The assistant's first bit-share check reported "0% ternary" because it matched type names against numeric ids; it was a bug in the check, not a result.
- 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.