Bonsai 2 vs Ternary Bonsai 2 27B: The Family Name Is Doing Two Jobs

Search for Bonsai 2 and you will land on roughly five different artefacts with footprints spanning an order of magnitude, and it is not obvious from the name which one a given article is talking about. Ternary Bonsai 2 27B is the specific one — a single 27B-class ternary model built on Qwen3.8-27B, announced 17 September 2026 and shipped as a 5.95 GB dense-trit pack or a 7.21 GB 2-bit-slot pack. Bare Bonsai 2 is the umbrella: the same name covers Ternary Bonsai 2 2B, Ternary Bonsai 2 4B and Ternary Bonsai 2 9B, three much smaller models built on Qwen3.5 and announced on 15 October 2026, and it now also covers an Ollama library entry that serves all four sizes under one tag family.

So this is not the usual head-to-head. One side is a subset of the other, and the useful question is not which is better but which of them a reader who typed "Bonsai 2" into a search box actually wants. The answer turns on something the naming conceals: the family is two families, split by base model, and the split does not fall where the size numbers suggest.

Two families wearing one name

Read the GGUF headers of the published files and the seam is right there in a metadata field. Every Bonsai 2 artefact — 2B, 4B, 9B and 27B alike — reports general.architecture = qwen35. That string is the Qwen3.5 hybrid-attention backbone, and for the small three it is exactly right: the model cards list Qwen3.5-2B, Qwen3.5-4B and Qwen3.5-9B as base models with the architecture unchanged. The 27B is a different animal. Its base is Qwen3.8-27B, a newer and stronger 27B hybrid-attention model, and it happens to share the architecture string because Qwen3.8 keeps the same family of backbone.

The vendor's own release notes make the split visible if you read them side by side and invisible if you read either alone. The 15 October post for the small models says they are "based on Qwen3.5" and describes them as joining Bonsai 2 27B — which is framed accurately as a different thing. The 17 September post for the 27B says Qwen3.8-27B. Two announcements, two base models, one family name, and a third-party article that says "Bonsai 2 is based on Qwen3.5" is wrong about the 27B while looking perfectly well-sourced.

That matters because base-model generation is not a detail here. It sets the capability ceiling, it sets what the retention percentages are percentages of, and it means the small models' benchmark numbers and the 27B's benchmark numbers are not two points on one curve — they are two separate reports against two separate baselines. Treat any table that lines them up in one column with suspicion.

The numbers, side by side

All figures vendor-reported by Prism ML; none reproduced independently.

• Base model — Ternary Bonsai 2 2B / 4B / 9B: Qwen3.5-2B, -4B, -9B respectively; Ternary Bonsai 2 27B: Qwen3.8-27B

• Announced — 15 October 2026 for the small three; 17 September 2026 for the 27B

• Smallest language-model pack — 0.429 GB PTQ1_0 at 2B; 1.997 GB PTQ1_0 at 9B; 5.947 GB PTQ1_0 at 27B

• Default pack — PQ2_0 for all of them: 0.517 GB, 1.146 GB, 2.417 GB and 7.206 GB respectively

• Bits per weight — ~1.83 at 2B, ~1.81 at 4B, ~1.78 at 9B, 1.72 ideal / 1.75 packed at 27B

• Context — 262,144 tokens across the whole family, inherited from the Q​wen backbone

• Vision — a separate mmproj pack on every size, loaded only when an image arrives

• Licence — Apache 2.0 throughout

• Retention as reported — 27B: 98.2% of Qwen3.8-27B FP16 across 14 benchmarks; small models: 19 benchmarks across six skill areas, reported as per-category retention against their own Qwen3.5 baselines

One line in that list is the reason the 27B costs 5.95 GB where the 9B costs 2.00 GB, and it is not just the parameter count. The 27B is described as "end-to-end ternary" across embeddings, attention projections, MLP projections and the LM head, with a decisive detail: a small set of tensors — the recurrent state path of the linear-attention layers plus the normalisation weights, about 26.2 million parameters, 0.0976% of the language model — stays in higher precision, and that remainder is what moves the headline figure from 1.71 to 1.72 bits per weight. On the 9B the same machinery gives ~1.78. The larger model is more efficient per weight, not less, because the fixed high-precision overhead is amortised over ten times as many parameters. If you are reasoning about which size to pick from a bits-per-weight table, that is the one direction the table points.

Where the small models actually win

Not on quality — on the shape of the claim. The small-model release is the only one in this family that publishes a verbosity claim, and it is the most checkable thing either announcement contains: Prism ML reports that the 9B uses roughly 40% fewer tokens on standard instruction-following and everyday math tasks. That is a statement about output length, not ability, and you can verify it against your own prompts in an afternoon. The same post lists avoiding repetitive loops and controlling verbosity as explicit development priorities, which is the kind of thing you write when your previous generation had a problem.

It is also the only release that reports retention above 100% on several categories — 121.5% on instruction following for the 2B, 107.8% on math, 115.0% on coding, against the full-precision Qwen3.5 baselines. Those are the vendor's own numbers on the vendor's own suite, and a compressed model outscoring its source model on a hand-picked benchmark is a claim about training and harness at least as much as about ternary arithmetic. The 27B's report is shaped more conservatively — 84.78 against 86.32, with math at 96.57 versus 97.06 and coding level at 89.42 versus 89.07, and the loss concentrated in knowledge/reasoning and vision — which is the profile a 1.7-bit representation should produce. When one report's losses land exactly where theory predicts and another's gains land on the categories the vendor chose to headline, that asymmetry is information.

Packaging: the 27B's quiet advantage

Since 17 October 2026 all four sizes are pullable as bonsai-2:2b, :4b, :9b and :27b from Ollama — nine tags in total, each size also carrying a -q2_0 alias. That is recent, it is unannounced by the vendor, and it is worth knowing what it actually serves. Ollama's tags resolve to the Q2_0 packing, the only one upstream llama.cpp can load. The dense-trit PTQ1_0 packs — the smallest files in the family — are not on the registry at all. So the convenient path and the small path are different paths, for all four sizes equally.

Where the 27B differs is in what it does not ship. The 4B and 9B each come with two optional speculative-decoding drafters: an MTP head built into the 2-bit-slot pack, and a DFlash2 block drafter that helps on copy-heavy work and is slower than plain decoding on general chat. The 2B ships without one deliberately — the vendor's note is that at that size a decode step is already cheap and swept-depth drafting measured slower on everyday prompts than plain decoding. The 27B's generation dropped the equivalent drafter that its first-generation predecessor carried.

That is a real capability difference between the sizes, and it does not appear on the Ollama page at all.

Deciding, and what to do with the answer

The 27B is the one to reach for if the workload is long-horizon reasoning: code, mathematics, agentic tool chains, long documents held in a 262K context. It is the only size in the family with a base model from the Qwen3.8 generation, and the vendor's category breakdown says the compression costs it almost nothing in math and coding while taking its toll in knowledge recall and vision.

The 9B is the one to reach for if the constraint is memory rather than difficulty: laptop-resident assistants, phone deployments, anything where 2 GB versus 6 GB is the difference between shipping and not. Its published profile is strongest exactly where the 27B's is weakest relative to baseline — instruction following and verbosity control — which is what a small local assistant actually spends its tokens on. The 2B and 4B exist for tighter budgets still, and at those sizes the retention numbers get noisy enough that your own prompts are a better guide than the vendor's table.

A note on the comparison most readers will actually make, which is against hosted models rather than against each other. Neither Bonsai 2 size is served through OrcaRouter, and this piece is not suggesting otherwise — they are weights you download. But the question "is a 2 GB local model good enough for this task" is answered by measuring against something, and OrcaRouter puts one API in front of 200-plus hosted models at 0% markup with provider list price passed through, plus automatic failover between providers and a routing DSL for composing several models into a single call. Establish the bar with a hosted model, then test whether the local one clears it on your hardware. That ordering saves the weeks people lose tuning a download that was never going to be sufficient.

One caution to carry out of this piece. Both releases report retention percentages, both are vendor-measured on the vendor's own harness, and as of today no third party has reproduced either. The one thing you can verify yourself is the artefact — the file sizes, the packings, the GGUF metadata, the licence, and the throughput on your own machine. That is where to start, and it is also where the two announcements stop resembling each other: the 27B's standalone pack sizes are published per file on Hugging Face, and the small models' word-of-mouth footprint of 0.43 GB, 0.95 GB and 2 GB refers to the language model alone with the vision tower excluded. Compare them on the same basis or the 9B will look like it lost an argument it never had.

None of that is hypothetical: the documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.