Ternary-Bonsai-8B · file← Ternary-Bonsai-8B
Q2_0
The file PrismML's card recommended, in an older layout their fork no longer reads. It never loaded; deleted on 11 October. Legacy Prism layout.
- Size
- 2.2 GB
- Status
- Deleted 11 Oct 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 | Ternary-Bonsai-8B-Q2_0.gguf, 2,182,184,672 B |
| Format | legacy type-42 GGUF |
| Where from | downloaded 2026-09-11 |
| Status | deleted 2026-10-11 |
| Hugging Face | https://huggingface.co/prism-ml/Ternary-Bonsai-8B-gguf |
Where it came from
- Source:
prism-ml/Ternary-Bonsai-8B-gguf, fileTernary-Bonsai-8B-Q2_0.gguf, the file the card calls recommended (2.03 GiB). - Size: 2,182,184,672 bytes (2.18 GB). Header: arch
qwen3,file_type 41, 254 tensors of type id 42 and 145 of type id 0. - Downloaded: 2026-09-11 19:45Z, four range streams by
hfpull.sh, intomodels/ternary-bonsai-8b/, finished with the MTP file about 20:12Z. It was pulled "as a cheap-seat candidate" (assistant) after Alan's "Read all of the docs for squish, also look for more ternary models online, bonsai was impressive". Revision and sha256: not on record. - Why it cannot load: the file uses the legacy Prism Q2_0 layout (group size 128 stored as ggml type id 42); the fork built on 2026-09-14 reads type 142 and says so: "use the PQ2_0 version of this model". On 2026-09-15 the assistant diagnosed the failure as an architecture/type combination (
qwen3+ type 42), since the 27B Q2_g64 used type 42 withqwen35and loaded on the stock build; the real error was not shown because the log was read at default verbosity. (reconstructed) Because both 8B files are 2,182,184,672 bytes, the two may differ only in the type id the tensors are stored under; this was not compared.
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
ternary-bonsai-8b (void, no run-log rows) | 2026-09-15: queued in a one-off script at 06:41Z; started by hand 08:03Z; failed load 08:08Z; stray rows retired 10:13Z | llama.cpp-prism fork; stock .local/bin/llama-server b10893 | 32768 / 4 / q4_0 / on / on / not on the line (--cache-ram 1024 --alias ternary-bonsai-8b); stock test -c 4096 -np 1 | extraction (all suites) | Alan, 2026-09-15 08:03Z: "Is it worth kicking off 8b then?": the 8B was run while a 20 GB BTL-4 download blocked the next stage. |
Seats held: none (it never loaded).
Decisions
- Stopped the failed run and diagnosed the types. The assistant's note that the 2x2 had only three corners stood until 2026-09-17.
- 2026-09-15 10:13Z: the assistant called the run "Void, as suspected" (1,032 rows, 2 scored) and the files were moved to
_retired. - 2026-09-17 07:45Z: the load error was re-read at
-lv 4, naming the layout; the PQ2_0 file replaced this one. - Published? No.
What went wrong
- The detour cost two days: the 8B ternary corner of the 2x2 was reported as "BLOCKED" on 2026-09-15 and finished on 2026-09-17; ten minutes at verbose logging would have found the layout (assistant's own account).
- Void run under a live label (standing check): the same label is now used by the valid PQ2_0 run; a reader of
results/_retiredmust not mix the two. Stale build stamps / partial runs / missing flags: no run-log rows; the server never became healthy. - RESTORE script attribution:
RESTORE-deleted-20261011-tiersAB.shliststernary-bonsai-8b 2.0 GB benched: 14 rows; RETIRED 2026-09-19 seat; no run-log row was ever produced by this file.
What happened to it
Downloaded 2026-09-11 → parked → failed loads 2026-09-15 → void rows retired 2026-09-15 → superseded by the PQ2_0 file 2026-09-17 → deleted 2026-10-11 (ternary-bonsai-8b, 2.0 GB, tiers A/B sweep). Re-downloadable from prism-ml/Ternary-Bonsai-8B-gguf.