Model family← Models

Ternary-Bonsai-2-27B

PrismML's three-value version of Qwen3.8-27B, in a 5.9 GB file. It matched the 4-bit Qwen3.8 on answers and tool use at well under half the size, lost more than half its ability to say "I don't know", and was no faster.

Files tested: 4
Scored runs: 16
Smallest Mac: 16 GB for the file we kept

OverviewWhy we tested it · what happened · should you use it

How this page was made. The tests run automatically on our Mac Studio, and every score here comes straight from those runs. This overview was written by Claude, an AI model, from the lab's own records: the run log, notes kept at the time, and the working sessions where each decision was made. Quotes are Alan's words, with spelling fixed. How these pages are made.

Why we tested it

On 18 September Alan spotted it: "Oh snap, bonsai 2 did qwen 3.8 ternary". PrismML had rebuilt Qwen3.8-27B so that every weight takes one of three values. Qwen3.8-27B scored well on our tests but was slow and needed 15 GB at 4 bits, and the first Ternary-Bonsai had been weak at judgement.

Two questions: would it keep the 4-bit model's quality at half the size, and would it be faster? Alan had a Mac in mind: "if the m4 pro ends up being able to run a ternary model at 30tps+ without losing (much) quality I could end up in a really nice position".

What it took

PrismML's fork of llama.cpp, already built for the first Bonsai. We ran 8 of our 14 tests, chosen to compare with Qwen3.8-27B's earlier scores, on both of PrismML's files.

Chasing a claim of 64 tokens a second on an M4 Pro, with a draft model guessing tokens ahead, cost three hours. Neither community draft model would load here, and both were deleted that day.

What happened

Against Qwen3.8-27B at 4 bits, answers and tools held up. On turning tool results into an answer both scored 83.3% (50 of 60), and on our test of when to reach for a tool both scored 100% (60 of 60). On weighing evidence it scored 82.5% (33 of 40) against 80.0% (32 of 40), and on picking from a growing set of tools 39 of 40 against 40 of 40.
Saying "I don't know" fell sharply: 31.9% (23 of 72) against 69.4% (50 of 72). Finding an answer in a document and citing where it came from scored 66.4% (83 of 125), against 80.0% (100 of 125) for a different 4-bit build of Qwen3.8 tested earlier.
The two files are the same model. The 5.9 GB and 7.2 GB files gave byte-identical answers in 505 of 505 cases, so the smaller one costs nothing.
It was no faster. Its median speed over 381 test cases was 7.2 tokens a second, against 7.6 for Qwen3.8-27B at 4 bits. Alan: "man that's kind of depressing but at least the seat is smaller".
It moved to the M4 Pro Mac mini. At 128K tokens of conversation, the memory for holding the conversation (9.0 GB) outgrows the model itself, too much beside our other models on the Mac Studio. On the M4 Pro it ran at 14.5 tokens a second, and it was taken down there by 20 September. In a trial on the Mac Studio, Alan: "it's doing 14.2 tps on bonsai, that's totally acceptable".
In separate probes, it spotted 75% (24 of 32) of conflicting records, with no false alarms in 16 checks. But asked to pull facts out of a document as typed links, it turned a hedged future statement into a stated fact in all 4 such cases. Hedged statements become facts.

What it taught us

Three-value weights buy size, not speed. Here the loss sat almost entirely in answers forced into a fixed format. What a ternary Qwen3.8 costs.
For a model trained to three values, the packing makes no difference. The 1.75-bit and 2.13-bit files are the same weights. The smaller file is free.
Check what a speed claim ran on. The 64 tokens a second was a coding tool's own engine on its own 3-bit copy, with no server to plug into.

Should you use it?

If you want most of Qwen3.8-27B's answers and tool use in about 6 GB and can build PrismML's fork of llama.cpp, yes: use the 1.75-bit PTQ1_0 file. Don't rely on it to say "I don't know", to fill fixed formats or to extract facts unsupervised; at 4 bits Qwen3.8-27B was far better at the first, in more than twice the memory. It is no faster, and long conversations need room on top of the file. Check the smallest Mac for each file below.

The files4 tested · each has its own page

Ternary-Bonsai-2-27B PTQ1_0kept
The one we kept: PrismML's smaller 1.75-bit file, with identical answers. Briefly seated on the M4 Pro Mac mini; still on disk.
Prism-ml, 1.75 bpw · On disk · 5.9 GB · 8 scored runs · smallest Mac 16 GB
Ternary-Bonsai-2-27B PQ2_0
PrismML's 2.13-bit file, and the first we tested. Same answers as the smaller file; still on disk.
Prism-ml, prism fork · On disk · 7.2 GB · 8 scored runs · smallest Mac 16 GB
Ternary-Bonsai-2 + DFlash2 MLX pack
A community MLX copy with a built-in draft model. It never loaded; deleted the same day.
Nathansutton · Deleted 18 Sep 2026 · 8.2 GB · never scored
Bonsai-2-27B DFlash2 drafter Q8_0
A community draft model meant to speed it up. It wouldn't load on the Mac; deleted the same day.
ProCreations · Deleted 18 Sep 2026 · 2.0 GB · never scored

Corrections18 to the record published 21 October 2026

Build of llama.cpp on 17 runs was 0.4.0-dev (build 10893, commit c32d1dabe), now 0.2.0-dev (build 1, commit 6ac5eb0). Served by the PrismML llama.cpp fork (build 1, commit 6ac5eb0), as every run manifest records; the stamp named the stock binary instead.
Corrected 24 October 2026 · a mechanical fix
On the worldview run of 18 September 2026: voided. A partial run: the gauntlet was stopped with 9 of 40 cases written. The complete 40-case run follows it.
Corrected 24 October 2026 · a mechanical fix

The lab's recordEvery decision, with its date · the model's specification

Decisions, in order

2026-09-18 06:23Z, Alan: Qwen3.8 ternary exists. The assistant searched HF, found three candidates and chose prism's own GGUF (a trained ternary in a ternary container) over the third-party packs for the baseline. Alternatives set aside: the MLX pack (loader trap), TernaryQuench (a post-hoc build; not examined).
2026-09-18 06:29Z, coherence gate 12/12 at 0.99 before any suite ran. 06:32Z to 07:11Z, 8-suite gauntlet on PQ2_0 (run-log).
07:19Z, Alan's drafter question ("64tps would be possible on my m4 pro?"); the assistant measured serial first (17.1 tok/s) and found the 3x claim came from a different drafter.
07:34Z, PTQ1_0 gate 12/12; gauntlet to 08:07Z, paused for the chad test.
09:30Z to 11:29Z, the chad detour. Alan asked for an M4 Pro setup prompt, then "chad is a coding harness, not an llm how the heck did we end up installing it?", "it doesn't even serve over http", "we need to can it, it's not what we need". Outcome: chad, the pack and the drafter deleted (26 GB reported; 40 GB offered), PTQ1_0 gauntlet resumed 11:31Z.
11:49Z, 505/505 identical: deployment file is PTQ1_0.
11:59Z and 12:00Z, Alan: "man that's kind of depressing but at least the seat is smaller"; "so... this leaves me with small tool caller (k2 horizon?), the edge0 memory workers and a slower bonsai 2 ternary?". Board check: k2-horizon-3.7b is the tool caller, edge0 the grounding worker (89.6), btl-4 the best generalist; Bonsai-2's case is footprint and worldview 82.5.
12:31Z, Alan: "bonsai 2 can live elsewhere": the M4 Pro (24 GB) takes the seat.
2026-09-18 20:32Z and 20:42Z, contradiction and edgefill probes: conflict detection 75% with 0/4 on headerless, 16/20 on edge typing; routing consequence: Bonsai-2 is not a worker for claims or contradictions.
2026-09-19 01:14Z, feel test on the Mac Studio, then stopped for memory (see the PTQ1_0 file's page). 2026-09-19, permanent M4 Pro seat on prism's Bonsai-demo path, launchd (a lab note). 2026-09-20 17:33Z, Alan: "bonsai 2 has been taken down on [the M4 Pro Mac mini]", as the roster turned dynamic.
2026-09-28, the seat's future under a faster runtime: "thing is if the runtime is fast enough the bonsai seat possibly changes to either full fat 3.8 q4_0?".
2026-10-11, the fleetview roster carried bonsai2 as a swap-seat candidate. The sweep deleted every Bonsai-1 build and kept this directory; RESTORE-deleted-20261011-tiersAB.sh says "all superseded by bonsai2-27b (PTQ1_0, kept, 12G)".

What we learned, in the lab's words

The "Q4_0" column is qwen3.8-27b-q4_0 (five suites); the epistemics and grounding cells for Qwen3.8 come from qwen3.8-27b, the UD-Q4_K_XL runs of 2026-08-24 on an older llama.cpp:

suite	Bonsai-2 PQ2_0	Bonsai-2 PTQ1_0	Qwen3.8-27B Q4_0 (09-11)	Qwen3.8-27B UD-Q4_K_XL (08-24)	Bonsai-1 PQ2_0
nullschema	31.9 (n=72)	31.9 (n=72)	69.4 (n=72)	—	27.8 (n=72)
synthesis	83.3 (n=60)	83.3 (n=60)	83.3 (n=60)	—	66.7 (n=60)
toolcall	100.0 (n=60)	100.0 (n=60)	100.0 (n=60)	100.0 (n=60)	100.0 (n=60)
toolscale	97.5 (n=40)	97.5 (n=40)	100.0 (n=40)	—	100.0 (n=40)
worldview	82.5 (n=40)	82.5 (n=40)	80.0 (n=40)	—	42.5 (n=40)
screening	98.3 (n=60)	98.3 (n=60)	—	—	93.3 (n=60)
epistemics	100.0 (n=48)	100.0 (n=48)	—	100.0 (n=48)	85.4 (n=48)
grounding	66.4 (n=125)	66.4 (n=125)	—	80.0 (n=125)	68.8 (n=125)

Free-form work at a third of the bytes. Parity on synthesis (83.3), toolcall (100.0) and epistemics (100.0), +2.5 on worldview; Bonsai-1 on the same file family scored 66.7 synthesis, 42.5 worldview, 85.4 epistemics (A ternary-trained Qwen3.8-27B holds parity on free-form work at 55% of the size, and loses everything it loses on schema-constrained output).
The whole loss is in schema-constrained output: nullschema 31.9 vs 69.4 (-37.5) and grounding 66.4 vs 80.0 (-13.6, against the older UD-Q4_K_XL runs). The recomputed mean is -7.3 over the seven paired suites, the same number the 27B Bonsai-1 2x2 gave, which the finding presents as corroboration.
PTQ1_0 and PQ2_0 are the same weights packed differently: 505 of 505 responses byte-identical (PTQ1_0 and PQ2_0 produce byte-identical output on a ternary-trained model, so the smaller file is free).
Ternary buys footprint, not throughput. Suite median 7.2 tok/s vs 7.6 for Qwen3.8 Q4_0; clean decode 17.1 tok/s on the M1 Max, 14.5 on the M4 Pro seat; the assistant's summary: every route to more speed landed on the same number.
Drafters: the third-party GGUF drafter does not load on Metal; chad's 62.9 tok/s on an M4 Pro is chad's engine on chad's own 3-bit pack, and chad has no server. A lab note on the M4 Pro found the drafter's acceptance transfers (60 to 86%) while the speed does not.
Where it earns a seat: free-form authoring and aux roles, not schema work. Probes: contradiction/1 24/32 conflicts detected (75%) with controls 16/16; edgefill/1 16/20 with 0/4 on the hedged-statement distractor.
Memory: at 128K the KV cost (9.0 GB with q4_0 KV) exceeds the weights, so the 5.5 GB seat is 14.5 GB at that context.

Why it was tested, in the lab's words

Alan, 2026-09-18 06:23Z: "Oh snap, bonsai 2 did qwen 3.8 ternary", a few days after the Bonsai-1 board (family-ternary-bonsai-27b) and while Qwen3.8-27B was the board's quality leader but a speed laggard. The assistant's reason it mattered: the first model on the board that is a plausible substitute for something the fleet already runs, rather than a curiosity, as the finding put it.
Questions asked: does a Qwen3.8 ternary hold the Q4_0's quality at half the bytes; is it faster ("From memory was the ternary version faster or slower due to the unpack?"); can a drafter get an M4 Pro to 64 tok/s (Alan: "64tps would be possible on my m4 pro? Need to see the quality though but that’s encouraging").
Alan's stake: "if the m4 pro ends up being able to run a ternary model at 30tps+ without losing (much) quality I could end up in a really nice position".

Open questions

The full 14-suite gauntlet was never run: contract, enrichment, the tagger pair, tools and chainwalk have no Bonsai-2 rows.
Is Bonsai-2 faster than the M4 Pro's 14.5 tok/s with prism's Swift/MLX path (the vendor's fast path)? Not tested on this fleet.
Whether the M4 Pro seat still exists is not on record after 2026-09-20.
The grounding comparison needs a Q4_0 grounding row to finish the finding; none exists.

The model in detail

field	value
vendor	PrismML (`prism-ml`)
upstream repos	`prism-ml/Ternary-Bonsai-2-27B-gguf` (F16 53.81 GB, PQ2_0 7.21 GB, PTQ1_0 5.95 GB, mmproj BF16 0.93 and Q8_0 0.63 GB), `-mlx-2bit`, `-gguf-dev`
parent	Qwen3.8-27B (`family-qwen3.8-27b`): the card of the third-party pack gives `base_model: Qwen/Qwen3.8-27B`; the assistant's reading: Ternary-Bonsai-2-27B is Qwen3.8-27B in a Hadamard-rotated ternary basis
generation	Bonsai-2 (the earlier Ternary-Bonsai-27B is Qwen3.6-27B based, `family-ternary-bonsai-27b`)
release	2026-09-17 (a lab note); 98.2% of FP16 claimed, 262K context
containers	PQ2_0 2.13 bpw (group 128), PTQ1_0 1.75 bpw (group 128); both `model_ftype` strings confirmed from `/props`; MLX pack needs the Hadamard-aware loader
KV cost	256 KB per token at f16
licence	not on record (Qwen3.8-27B is Apache-2.0 per the pack card header)
runtime used here	PrismML fork `6ac5eb0` on the Mac Studio (`b1-6ac5eb0`); prism-b10709-9a9394a on the M4 Pro