PQ2_0

• Verdict corrected. 96.2/97.9 were mean case scores; the board's pass rates for the same runs are 85.8 and 90.0.

  What it said before

  Verdict: The only model on this board at 100% toolcall. Also the best tagger of the small seats (96.2/97.9 at n=240) and best on contract (75.0). Weak where it matters for a driver: nullschema 27.8, worldview 42.5, and 0/8 on superseded. A tool executor, not a thinker. 17.3 tok/s -- dense, so it reads all 26.9B parameters per token.

  Corrected 24 October 2026 · a headline fix

Where it came from

• Source: prism-ml/Ternary-Bonsai-27B-gguf, file Ternary-Bonsai-27B-PQ2_0.gguf, via hf_hub_download into models/ternary-bonsai-27b-pq2/.
• Downloaded: 2026-09-14, started 16:23Z, complete before 16:29Z. Revision and sha256: not on record.
• Header facts: 26.90 B parameters, 2.13 bits per weight, ggml tensor type id 142 on 498 tensors plus 353 f32 tensors. Type id 142 is the "PQ2_0" layout; the older id-42 "Q2_0" layout is what the 8B ternary file turned out to be (see family-ternary-bonsai-8b).
• Runtime this needs: the PrismML fork. PrismML-Eng/llama.cpp, branch prism, commit 6ac5eb0, cloned with --depth 1 on 2026-09-14 16:18Z and built with cmake -B build -DGGML_METAL=ON -DLLAMA_CURL=OFF -DCMAKE_BUILD_TYPE=Release; Metal kernels for the type are in ggml-metal. The binary reports 0.2.0-dev (build 1, commit 6ac5eb0). Fork HEAD was dated 2026-09-13. Upstream cannot load PQ2_0 (type ids past upstream's table).

How it was served

The gauntlet ran while the M4 Pro MLX gauntlet, driven from the Mac Studio, ran alongside it from 16:59Z; the assistant checked CPU, memory, slots and logs for truncation or errors and found none. Scores are temperature-0 and contention-proof; throughput numbers taken in that period were not used.

Seats held: none from this label; the server was killed at 19:58Z to free memory for the MLX leg.

Decisions

• Why this file: the card says the group-128 PQ2_0 pack is what the fork's hybrid-attention Metal kernels are built for. The assistant predicted "~34 t/s" from bandwidth before building the fork. The measured 17.4 tok/s falsified it.
• Alan, on seat importance: "a decent 27b or a questionable 9b distill are contending for the seat just now"; on whether to test the MLX build as well as the GGUF: "yes, we have to, this is an important seat". Earlier that day: "27b bonsai might make a good reasoner and maybe even a daily driver".
• What the board said (2026-09-14, run-log): toolcall, tools, toolscale 100, contract 75.0, and 85.8 / 90.0 on the two 240-case tagger suites; last on abstention and attribution (nullschema 27.8, worldview 42.5). The assistant's seat comparison against the Qwen3.8-9B distill split the roles: bonsai decides (toolcall) and the 9B processes. Alan then sketched a fleet: "so this might end up being a 35b + gemma 4 (tagger) + 9b synthesis + 27b ternary fleet?", and the assistant priced bonsai as the tool executor.
• Superseded by Bonsai-2 on 2026-09-18 once the Qwen3.8-based Ternary-Bonsai-2 measured parity on free-form work at a third of the size (family-ternary-bonsai-2-27b). The 2026-10-11 sweep records "all superseded by bonsai2-27b (PTQ1_0, kept, 12G)" (RESTORE-deleted-20261011-tiersAB.sh).

What went wrong

• Void-looking toolcall: the harness flags toolcall runs whose responses are all empty. This build's toolcall is real: all 60 result rows have outcome called, and the empty string is what a tool-calling answer looks like in response (same shape as the Q4_0 baselines; result file read 2026-10-23; the same check was made on the Bonsai-2 runs).
• Stale build stamp (standing check): the run-log llama_build for these 14 rows is 0.4.0-dev (build 10893, commit c32d1dabe), the stock build. The manifests record b1-6ac5eb0 from /props, and runtime_version in the run log is 6ac5eb0. The stamp is wrong; the version is right.
• Mixed metric in published text (published-data mismatch): the write-up verdict and the 2026-09-15 finding quoted tagger 96.2 and tagger_nullable 97.9. Those are the mean score over the 240 cases. The board's pass-rate for the same files is 85.8 and 90.0, and chainwalk is 0.0 (0 of 2 passed) against a mean score of 94.0. Recomputed from the result files on 2026-10-23.
• Chainwalk n=2: the 94.0 quoted in chat is the mean score of two cases and the run-log accuracy is 0.0; the assistant itself called it "not a score" within the hour.
• Comparison caveat on the speed prediction: the 26.2 tok/s M5 Pro figure came from prism's MLX card, not the GGUF, so the first cross-machine efficiency comparison was invalid.
• Partial runs / missing flags (standing checks): all 14 result files hold as many rows as the suite has cases (manifest attempted equals rows). The server line has --jinja, no --reasoning-format and no explicit chat-template kwargs; the harness sent enable_thinking: false in every request.

What happened to it

Downloaded 2026-09-14 → benched 2026-09-14 (14 suites) → speed-tested 2026-09-15 → shut down 2026-09-14 19:58Z, never seated → deleted 2026-10-11 with the rest of the Bonsai-1 family (a lab note; RESTORE-deleted-20261011-tiersAB.sh lists it as ternary-bonsai-27b-pq2 6.7 GB never benched under this name, which is wrong: every run under label ternary-bonsai-27b is this file). Re-downloadable from prism-ml/Ternary-Bonsai-27B-gguf; the prism fork is still built at llama.cpp-prism.