Skip to content

Build1 publisher3 min readPublished

Loading PrismML's 5.95 GB Bonsai 2 requires the company's own llama.cpp fork

PrismML's ternary build of Qwen3.8 27B keeps 98.2 percent of the full-precision benchmark average on both of the company's inconsistent scorecards, and the loss it does take is concentrated in knowledge and reasoning.

The Engineer · Build desk

Illustration accompanying Loading PrismML's 5.95 GB Bonsai 2 requires the company's own llama.cpp fork

What happened

  • PrismML released Bonsai 2 27B on September 17th, an Apache 2.0-licensed build of Qwen3.8 27B whose language model ships as a 5.95 GB file.
  • Most of the language weights are stored as one of three values, -1, 0 or 1, with a higher-precision scale factor shared across each group of 128 weights.
  • The Bonsai 2 model card says the compact files load only under PrismML's own fork of llama.cpp, which the company has published alongside a demo and integration repository.
  • The launch announcement and the model card publish different aggregate scores, 83.9 against 85.4 across 20 benchmarks and 84.78 against 86.32 across 14 thinking-mode benchmarks.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost The integrating team pays for the compression in build maintenance, pinning and compiling a third-party inference branch for every target platform it ships on.
  • decision The per-domain numbers push the adoption question onto workload mix: a coding assistant sees roughly baseline quality, while anything answering from the model's own knowledge absorbs the drop.
  • contradiction Because PrismML's own two documents differ on throughput and parameter count, neither can be quoted as the model's speed without a local measurement on the exact packing.
  • constraint Products that need image input cannot use the headline footprint, since the vision component is a separate download and the vision score carries the second-largest loss.

PrismML says the ternary weights preserve 98.2 percent of the full-precision model's benchmark performance while cutting the footprint by roughly nine times [2]. Divide the launch announcement's two averages and you get 98.24 percent [1]. Divide the model card's and you get 98.22 percent [2]. Different suites, different benchmark counts, same ratio to one decimal place, so the disagreement in the underlying scores never reaches the headline number. PrismML does not reconcile the two sets of figures in its published materials [12].

The compression claim holds on its own terms. PrismML puts the ideal ternary language-model footprint at about 5.8 GB, which is 9.3 times smaller than the FP16 baseline, and the file you actually download is 9.1 times smaller [4][3]. Both figures cover language weights. Image input needs the optional 8-bit vision component, another 0.63 GB, taking the compact build to 6.58 GB; the alternative packing, designed to reduce unpacking work, is 7.21 GB, or 7.84 GB with vision [5][4].

The reason stock llama.cpp cannot open these files is that it does not implement PrismML's custom ternary formats or its Hadamard activation transform [7]. PrismML says its backends cover CUDA, Metal and CPU execution [8], and there is an MLX companion for Apple Silicon [6]. Apache 2.0 on the weights does not remove the integration work: until the formats reach widely used upstream inference software, developers have to adopt PrismML's kernels and runtime build [9]. The download size does not include that cost.

The aggregate average hides where the quality went. Math is nearly flat, 96.57 against 97.06 [13]. Coding comes out slightly above the FP16 baseline, 89.42 to 89.07 [13]; I would read a compressed model beating its own baseline as the coding suite running out of resolution at that level. Knowledge and reasoning lost 5.69 points, a 6.7 percent relative drop [5]. Vision lost 5.17 points [6]. On OCR Bench v2 the compressed model scored 56.88 against 60.99 for FP16, and the model card places it below a conventional 2-bit build as well [15].

For the announcement's 143 tokens per second to transfer, you need an RTX 5090, PrismML's runtime, the same packing and single-stream decode [10]. The model card's own measurement on the same GPU is 129.9 tokens per second for one packing and 120.5 for the smaller one, about 10 percent under the announcement [11][7]. The documents also describe different models: 27.8 billion parameters in the announcement, 27.36 billion on the card [10][11].

PrismML says it emerged from Caltech research, with backing or support from Khosla Ventures, Cerberus, Caltech and Google, and continuing support from Samsung [19]. Dealroom reported in April that the company had raised $16.25 million through a SAFE and seed financing from Khosla, Cerberus and Caltech, and the round's valuation and ownership terms were not reported [20]. For a product where retrieval supplies the facts and the model writes code, 5.95 GB plus a pinned fork is a defensible trade in my view. Where the product leans on the model's own knowledge, the 5.69-point gap is the figure I would try to reproduce on my own evaluation set before building the runtime.

What to watch

  • Upstream llama.cpp accepting the ternary formats and Hadamard transform, which would end the fork dependency.
  • Independent RTX 5090 throughput measurements on the published GGUF packings, given PrismML's own two figures differ.
  • A follow-up release that lifts the 79.86 knowledge and reasoning score without growing the 5.95 GB file.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories