Ternary Bonsai 2 27B Requirements: 5.9GB, VRAM & GPU (2026)
Ternary Bonsai 2 27B (PrismML, Sep 2026): Qwen3.8-27B at 1.76-bit weights, 5.9GB, 16GB RAM or a 24GB GPU, 98.2% of FP16 score. Apache 2.0, updated Sep 2026.
Ternary Bonsai 2 27B is a ternary-quantized derivative of Qwen3.8-27B that PrismML released on September 17, 2026, needing just 5.9GB of memory at 1.76 effective bits per weight — it runs on a 16GB-RAM laptop or a single 24GB GPU such as an RTX 4090. That's more than a 9x reduction from the 54GB FP16 reference, yet the official benchmark shows it retains 98.2% of Qwen3.8-27B's (FP16) accuracy.
This article is a requirements at-a-glance guide plus a comparison against the previous release (PrismML Bonsai 27B) and the base model (Qwen3.8-27B).
Requirements At a Glance
| Item | Detail |
|---|---|
| Release date | September 17, 2026 (official announcement; HF release Sep 17–18) |
| License | Apache 2.0 |
| Base model | Qwen3.8-27B (hybrid attention: ~75% linear, ~25% full) |
| Total parameters | 27.36B (24.35B backbone + 2.54B embedding/LM head + 0.46B vision tower) |
| Input modalities | Text + image (multimodal) |
| Context length | 262,144 tokens |
| Max output | 32,768 tokens |
| Tool calling | Yes (function calling / JSON-schema structured output) |
| Quantization scheme | Ternary {-1, 0, +1} weights with FP16 group-wise scaling (group size 128) |
| Effective bits | 1.76 bits/weight (official) |
| Total footprint | 5.9GB (official, more than 9x smaller than FP16) |
| Minimum practical setup | 16GB RAM, or a single 24GB GPU |
What Ternary Bonsai 2 27B Is — a Successor Built on Qwen3.8-27B
In July 2026, PrismML released Bonsai 27B, a post-hoc ternary quantization of Qwen3.6-27B (1.71 effective bits, 5.9GB, 94.6% of FP16 retained). Ternary Bonsai 2 27B is version 2 of that line, rebuilt on top of Qwen3.8-27B — a newer base with hybrid linear/full attention, a 262K context window, and native multimodal input.
Beyond the newer base model, PrismML also refined its quantization method. The official announcement reports an "intelligence density" (a performance-per-GB metric) improvement from 0.416 to 0.457, a +9.9% gain, while the footprint stays in essentially the same 5.9GB range as before — same size class, more capable inside.
Quantization Scheme — Ternary Weights with FP16 Group Scaling
Weights are quantized to three values, {-1, 0, +1}, with one FP16 scale factor shared across each group of 128 weights. This group-wise scheme preserves more information than a naive 2-bit quantization, landing at an official effective bit-width of 1.76 bits/weight. The model card also documents quantization of the vision tower (the image-input encoder) separately.
Distribution Packages (GGUF / MLX) by Size
| Package | Scheme | Bits/weight | Size |
|---|---|---|---|
| PTQ1_0 (GGUF) | Dense ternary packing | 1.75 bpw | 5.95GB |
| PQ2_0 (GGUF) | 2-bit slot packing | 2.13 bpw | 7.21GB |
| Vision tower (optional, Q8_0) | Image-input encoder | — | +0.63GB |
| MLX 2-bit build | For Apple Silicon (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) | ~2-bit equivalent | Comparable to GGUF PQ2_0 |

PTQ1_0 is closest to the theoretical minimum at 1.75 bpw, but PQ2_0's 2-bit slot packing is sometimes preferred for runtime or hardware compatibility reasons. If you use image input, add the vision tower's roughly 0.63GB (Q8_0) on top of the base file.
Benchmarks — How Much Accuracy Survives
| Metric | Ternary Bonsai 2 27B | Qwen3.8-27B (FP16) | Retention |
|---|---|---|---|
| Overall (official) | 83.9 | 85.4 | 98.2% |
| Overall (model card, 14-benchmark thinking-mode average) | 84.78 | 86.32 | 98.2% |
| Math | 96.57 | 97.06 | 99.5% |
| Coding | 89.42 | 89.07 | 100.4% (exceeds) |
| Knowledge & Reasoning | 79.86 | 85.55 | 93.3% |
Math and Coding land at or slightly above FP16 parity, while Knowledge & Reasoning shows the largest drop. That's a familiar pattern for ternary quantization: procedural reasoning survives better than broad factual recall. Compared against IQ2_XXS (72.59), a similarly low-bit format, Ternary Bonsai 2 27B beats it by more than 12 points while sitting at roughly 82% of its size — a large gap versus naive ultra-low-bit quantization.
Speed — Up to 143 tok/s on RTX 5090, Practical on Apple Silicon Too
| Hardware | Metric | Value |
|---|---|---|
| RTX 5090 | Generation speed (official peak) | 143 tok/s |
| RTX 5090 | TG128 (model card, PQ2_0) | 129.9 tok/s |
| Apple M5 Max | TG128 | 47 tok/s |
| Apple M5 Pro | TG128 | 28.1 tok/s |
| L4 (72W) | TG128 | 29.8 tok/s |
| RTX PRO 6000 Blackwell | PP512 (prompt processing) | 4,020 tok/s |
| Apple M5 Max | PP512 (prompt processing) | 765 tok/s |
| RTX 4090 | Power draw | 0.714 mWh/token |
Generation speed (TG128) and prompt-processing speed (PP512) are separate metrics — check PP512 if your workload involves long input prompts. Apple Silicon (M5-series) already reaches practical speeds, making a Mac-only offline setup a realistic option.
Runtime Requirements — 16GB RAM or a 24GB GPU, More Headroom for Long Context
PrismML's announcement and independent reporting both describe the model as running on "16GB of RAM, or a single 24GB GPU." That guidance covers the model weights (roughly 5.9GB) plus typical runtime overhead — it does not account for the KV cache growth that comes with using the full 262K context window**, which will require additional memory beyond that baseline. No official figures break down memory use by context length, so treat the 16GB tier as a floor for short prompts and plan for more headroom if you run long conversations or documents.
Comparison — Previous Bonsai 27B and Qwen3.8-27B
| Model | Base | Quantization | Size | Accuracy vs FP16 |
|---|---|---|---|---|
| Qwen3.8-27B (BF16) | — | None | ~56GB | 100% (baseline) |
| Qwen3.8-27B (Q4_K_M, GGUF reference) | — | 4-bit | ~17GB (details) | — |
| PrismML Bonsai 27B (previous, ternary) | Qwen3.6-27B | 1.71-bit (5.9GB) | 5.9GB | 94.6% |
| Ternary Bonsai 2 27B (this article) | Qwen3.8-27B | 1.76-bit (5.9GB) | 5.9GB | 98.2% |
The footprint stays in essentially the same 5.9GB class, but a newer base model plus quantization refinements lift accuracy retention from 94.6% to 98.2%. The core value proposition — a 27B-class model in 5.9GB — hasn't changed; what's inside it got meaningfully better.
Running It — llama.cpp Fork / MLX / Ollama / API
- llama.cpp: requires PrismML's own fork with ternary kernels (CUDA/Metal/CPU support). Upstream llama.cpp cannot correctly unpack ternary weights
- MLX (Apple Silicon): prism-ml/Ternary-Bonsai-2-27B-mlx-2bit is available for Mac, iPhone, and iPad
- Ollama: not an official distribution, but community uploads exist. See our Ollama vs LM Studio comparison for tool selection guidance
- API (OpenRouter): available without self-hosting at $0.075/M input tokens and $0.50/M output tokens
FAQ
Can I estimate requirements with the VRAM calculator tool?
Not currently. Our free VRAM calculator assumes the standard "total parameters × bits/weight" formula, which doesn't account for ternary quantization with FP16 group scaling. Use this article's published footprint (roughly 5.9GB) as your reference instead.
Does it run on stock llama.cpp?
No. Unpacking ternary weights correctly requires PrismML's own fork with ternary kernels (CUDA/Metal/CPU). Whether ternary support lands upstream in llama.cpp is not yet determined.
Should I choose this over Qwen3.8-27B FP16 or Q4_K_M?
If you have ample memory (32GB+ VRAM) and don't want the hassle of a ternary-kernel runtime, Qwen3.8-27B at Q4_K_M (~17GB) is the simpler path. If you're memory-constrained around 16GB, or want a 27B-class model on a laptop, Mac, or small GPU, Ternary Bonsai 2 27B is the stronger option.
Is it worth upgrading from the original Bonsai 27B?
The footprint stays in the same roughly 5.9GB class, but the base model moved from Qwen3.6-27B to Qwen3.8-27B and accuracy retention improved from 94.6% to 98.2%. For the same memory budget, that's a meaningful upgrade.
What extra is needed for image input (multimodal)?
The vision tower (about 0.63GB at Q8_0 quantization) is a separate file from the main ternary weights. It can be skipped for text-only use.
Can I try it as a cloud API instead of self-hosting?
Yes, via OpenRouter at $0.075 per million input tokens and $0.50 per million output tokens — a way to evaluate the model before setting up a self-hosted environment.
Related free tools (no sign-up, instant results)
Feel free to contact us
Contact Us