A 27-billion-parameter model used to mean a proper GPU or nothing. Bonsai 2 27B, PrismML’s ternary-quantised compression of Qwen3.8-27B, brings that down to roughly 6GB, small enough to sit on the same laptop GPU I use for client calls. I ran it myself on an HP ZBook with an 8GB dedicated GPU before I trusted a word of the compression claims, and it’s genuinely usable, with one very clear boundary on what “usable” means here.
In short
- Bonsai 2 27B is PrismML's ternary-quantised version of Qwen3.8-27B, compressed from 53.8GB down to roughly 6GB under an Apache-2.0 licence, using 1.76-bit weights instead of the usual 16.
- It runs on modest hardware: I ran it on an HP ZBook with an 8GB dedicated GPU without trouble. Without a GPU, running it in RAM alone is far too slow to be usable.
- It's built for short, scoped jobs, not long multi-step tasks: independent benchmarks show it holding up well on things like image description and coding, and dropping hard on long-horizon agentic work.
What Bonsai 2 27B actually is
PrismML took Qwen3.8-27B, the same base model behind a few of the writing-focused fine-tunes doing the rounds right now, and compressed it using ternary quantisation: every weight becomes one of three values, -1, 0, or +1, with a single scaling factor shared across each block of 128 weights. That works out to roughly 1.76 bits per weight instead of the usual 16, a 9x reduction in file size for a model that, according to PrismML’s own benchmark suite, keeps 98.2% of the original’s performance.
It ships under an Apache-2.0 licence, free to run and use commercially. One catch worth knowing before you download it: stock llama.cpp won’t run these files. PrismML built a custom fork with ternary-specific kernels, so you’re tied to their tooling rather than whatever inference stack you already run.
Two packing formats are available: PTQ1_0, the dense version at roughly 5.9GB, and PQ2_0, a looser 2-bit packing at around 7.2GB. Both keep the 262,144-token context window from the base model.
Running a 27B model on an 8GB laptop GPU
I tested this on my HP ZBook, which has an 8GB dedicated GPU, nothing exotic, the kind of machine plenty of marketers and consultants already carry. It ran without issue. That’s the whole point of ternary quantisation: a model this size used to need proper server hardware, and PrismML’s compression puts it within reach of a decent work laptop instead.
The catch is what happens without a GPU. Run it in RAM alone and it’s terribly slow, slow enough that I wouldn’t use it that way for anything real. The GPU isn’t optional here, it’s the difference between a usable tool and a technical curiosity.
What it’s actually good at
Here’s where I’d place this model honestly: it isn’t the best model in the world, and PrismML doesn’t claim it is either. What it’s good for is short, well-scoped jobs where you don’t need much context or many steps to get to the answer.
My own test case is SEO image renaming. I run a local image-renaming workflow that connects to LM Studio and a chosen model: it looks at an image before I upload it to a site and renames the file based on what’s actually in the photo, which is a small, free SEO win most people skip. I’d compare Bonsai 2 27B here to Google’s Gemma line. I’ve noticed before how much the output quality jumps between Gemma’s 2B and 4B versions, and Bonsai 2 27B, despite being compressed down to a fraction of its original size, still produces noticeably more precise, on-point descriptions than Gemma 4B does. That’s the parameter count showing through the compression: even ternary weights carry more signal at 27B than a small model carries at full precision.
Where it falls apart
The benchmark PrismML leads with, 98.2% of full-precision performance, is PrismML’s own number, run on PrismML’s own twenty-benchmark suite, and it hasn’t been independently reproduced.
MarkTechPost’s coverage and a more sceptical breakdown from OrcaRouter both flag the same thing worth knowing before you rely on this for anything serious: that average hides a real split. Instruction-following and coding hold up close to full precision, some even edge ahead. Long-horizon agentic work does not.
| Benchmark | Full precision | Bonsai 2 27B |
|---|---|---|
| Instruction-following | 81.25 | 82.66 |
| Terminal-Bench 2.1 | 69.7 | 52.8 |
| SWE-bench | 80.6 | 60.8 |
Roughly three-quarters of the original capability survives on exactly the tasks that require holding context and reasoning across many steps. That matches my own instinct about it: fine for a single-shot job like renaming an image, not something I’d trust to carry a long agentic workflow unsupervised.
The verdict, and why compression is its own kind of specialisation
Bonsai 2 27B isn’t trying to be a frontier model, and it shouldn’t be judged as one. What it’s actually doing is trading long-horizon capability for a footprint small enough to run on hardware people already own. For short copywriting, image description, and the kind of single-pass jobs that make up most of an average day, that trade is a good one, and it’s a similar trade to what I found testing Hemmingway-1 a few weeks back: a model built to do less, done properly, often beats a general model doing everything adequately.
If you’ve got a modest GPU sitting idle and a stack of short, well-scoped jobs, it’s worth the download: try it on Hugging Face. If your work leans on long agentic tasks, save yourself the disappointment and keep using a full-precision model for those.