Ternary Bonsai 2 27B vs Qwen3.8-27B: What 47.9 Gigabytes of Precision Actually Buys

Ternary Bonsai 2 27B and Qwen3.8-27B are the same model in two numerical worlds. They share an architecture, a tokenizer, a training lineage and a 262,144-token context window. What separates them is how the weights are written down: Qwen3.8-27B stores each one as a 16-bit float and occupies 53.81 GB in its FP16 reference form, while Ternary Bonsai 2 27B stores each one as one of three symbols and occupies 5.93 GB. Prism ML announced the compressed build on 17 September 2026 and put it on Hugging Face under Apache 2.0; the original Qwen3.8-27B weights were published on 13 August 2026, also under Apache 2.0.

The comparison that matters is not which one is better. It is what the missing 47.9 GB costs you, and the honest answer is narrower and more specific than either camp will tell you. Prism ML reports that its build keeps 98.2% of the full-precision model's average across a 20-benchmark suite — 83.9 against 85.4. That number is the vendor's own, measured on the vendor's own harness, and one day after release nobody outside Prism ML has reproduced it. The aggregate also hides the part you should actually care about, because the 1.8 points are not distributed evenly. On the two benchmarks that stress sustained software engineering, the gap is not 1.8% — it is closer to 25%.

The same network, written down differently

Start with what compression does not touch, because it is the reason the comparison is interesting at all. The layer count, the hidden size, the vocabulary, the attention pattern and the vision tower are the base model's. Qwen3.8-27B is a hybrid-attention design: 48 Gated DeltaNet linear-attention layers interleaved with 16 full-attention layers, a roughly 3:1 split, over 64 layers with a hidden size of 5,120 and a 248,320-token vocabulary. That mostly-linear backbone is what makes a 262K context affordable in the first place, and it is the property Bonsai inherits unchanged.

What Prism ML changed is the representation of the language model's matrices, plus the kernels needed to compute on them. Its whitepaper splits the 27.36B parameters into 24.35B in the language backbone across 64 blocks, 2.54B in the embedding and LM head, and 0.47B in a 27-block vision tower. The vision tower ships as a separate 4-bit mmproj file of about 0.63 GB and is loaded only when an image actually arrives, so a text-only deployment never pays for it.

A practical consequence of that mostly-linear design is worth flagging before any benchmark discussion. Because the architecture is not a conventional transformer, the low-bit kernels had to be written for it specifically. Stock llama.cpp rejects both of Prism ML's packings as unknown types — and, more dangerously, loads an older ternary format without complaint and produces fluent nonsense, because it has no matching rotation applied to activations. If you run this model on a binary that does not know about it, you will not get an error. You will get confident, wrong output.

The comparison, category by category

Here is the vendor's 20-benchmark breakdown, with the full-precision base as the reference. Every figure in this list is Prism ML's; none of it is independently verified.

• Math — 96.57 for Ternary Bonsai 2 27B vs 97.06 for Qwen3.8-27B. Effectively level.

• Coding — 81.58 vs 82.17. Also close, and the category the whole technique is being argued on.

• Instruction following — 82.66 vs 81.25. The compressed model is ahead here, which is the one line in the table that is genuinely surprising.

• Knowledge and reasoning — 83.95 vs 86.66. A 2.7-point drop, and the single largest contributor to the missing 1.8 points.

• Agentic and tool calling — 77.57 vs 79.74, covering τ2-Bench at 80.22 and BFCL v3 at 74.92.

• Vision — 78.59 vs 81.64, the largest category loss. Note that the vision tower itself is not the compressed part; the language model reading its outputs is.

Read the shape rather than the average and a clearer story appears. Compression is nearly free on mathematics, coding and instruction following, and it is expensive on knowledge and vision. That is the opposite of the folk wisdom about low-bit models, which holds that surface knowledge survives and reasoning collapses. Here it is knowledge that erodes and reasoning that holds.

Where the 1.8 points actually live

The aggregate is a mean over twenty benchmarks, and means are where gaps go to hide. Pull the individual results out and two of them are much worse than the average implies.

• Terminal-Bench 2.1 — 52.8 for the ternary build against 69.7 for full precision

• SWE-bench Verified — 60.8 against 80.6

Both land near three-quarters of the full-precision score. Against that, AIME26 comes in at 95.83, LiveCodeBench at 90.07, and AA-LCR at 77.0 — within a point of the uncompressed model. This is the first time the Bonsai family has been evaluated on Terminal-Bench at all, and Prism ML is explicit in its own materials that the long-horizon software-engineering capability it promised in the first generation is partially, not fully, delivered.

So the practical question is not "does it retain 98.2%" but "what is my workload". If you are running a coding agent that holds a plan across dozens of tool calls and edits files over minutes, you are in the category with the 25% gap, and the aggregate number is actively misleading. If you are doing math, single-turn code generation, extraction, classification or chat, you are in the categories where the gap rounds away. The most useful thing about the vendor's own table is that it lets you make that distinction instead of guessing.

What each one actually needs to run

The hardware story is less symmetric than the size ratio suggests. A 53.81 GB FP16 model does not fit on a 16 GB laptop at all, which makes the comparison less "faster versus slower" and more "possible versus not". Prism ML's standardised measurements at batch size 1, vision tower excluded:

• NVIDIA RTX 5090 — 142.5 tok/s decode on the PQ2_0 packing, at 0.582 mWh per token

• Apple M5 Max — 46.8 tok/s decode, with prompt processing around 765 tok/s

• Apple M5 Pro — 27.7 tok/s decode

• Apple M4 Pro — 18.0 tok/s decode, with prompt processing near 125 tok/s becoming the binding constraint on very long contexts

The important caveat is that none of this is a single binary. The PTQ1_0 packing gets you 5.93 GB at 1.76 bits per weight; PQ2_0 costs 7.25 GB at 2.16 bits per weight and buys decode speed on hardware where instruction throughput, not memory bandwidth, is the limit. The MLX build for Apple Silicon is a third artifact with its own accounting — an affine 2-bit container that stores a bias the ternary weights do not need, landing at 2.25 bits per weight and 8.005 GiB on disk, with Metal and CPU kernels but no CUDA path. "It runs in 5.9 GB" is true of exactly one of those files on exactly the right runtime.

The cost comparison, honestly framed

There are two ways to pay for Qwen3.8-27B and only one way to pay for its compressed sibling. Ternary Bonsai 2 27B is a download: Apache 2.0, your hardware, no meter. Qwen3.8-27B is both a download and a hosted service, and if you take the hosted route the relevant figure is the one on the model page — $0.33 per million input tokens and $2.40 per million output tokens, served from OrcaRouter's own infrastructure rather than resold from someone else's.

That is where OrcaRouter earns a place in this comparison rather than a footnote. The routed build of Qwen3.8-27B carries the same 262K context, accepts text, images and video, and exposes the reasoning-effort control the model ships with. It sits behind the same key as 200-plus other models with no markup on top of provider list price, which matters more than it sounds: because list price is passed through rather than resold, a vendor price change shows up here the same day instead of at the next contract renewal. For a team that wants the full-precision base as the escalation tier above a local Bonsai, that is one endpoint and one key rather than two vendor relationships.

Which one to reach for

The decision is mostly about where the work happens, not about which model is better, because on most tasks they are the same model.

• Choose Qwen3.8-27B full precision when the task is long-horizon and agentic, when you are evaluating or fine-tuning, when you need the 1M-token YaRN context, or when vision accuracy is load-bearing. The Terminal-Bench and SWE-bench numbers are the reason.

• Choose Ternary Bonsai 2 27B when the work has to happen on hardware you own, when the alternative is not running a 27B model at all, or when the workload is math, coding, extraction or tool-free reasoning where the categories are level.

• Do not choose on the aggregate. 83.9 and 85.4 are close enough that a single benchmark swap could reorder them, and only one of the two numbers is independently verified.

What is genuinely new here is not that a 27B model fits in six gigabytes — the first Bonsai generation did that in July. It is that instruction following came out ahead of the parent and that math and coding came out level, which is a different claim from "small for its size". Whether it holds on your workload is exactly the thing that one day of age cannot tell you, and the first independent evaluation of this model is the result worth waiting for.

If you want to run the comparison on your own prompts rather than on a benchmark suite, the fastest path is to call the hosted Qwen3.8-27B through one endpoint and run the ternary build locally, then diff the outputs on the tasks you actually have. That is a morning's work and it will tell you more about the 1.8 points than any published table.