The takeaway: Bonsai 27B — the release that topped Hacker News yesterday with the claim of "a 27B-class model that runs on a phone" — is genuinely notable engineering, and the 3.9GB memory footprint is simple arithmetic you can trust. Everything else deserves precision: the ~90% quality-retention figure is the vendor's own evaluation, run on datacenter GPUs; the only shipping path today requires an iPhone 17 Pro or Pro Max; nobody outside the company has published a benchmark run of the shipped models, or a working run on an actual phone; and the company's own tables show where the compression bites. Here's the claim, taken apart carefully.

What was actually released

Bonsai 27B is not a new model. It's a pair of extreme low-bit builds of Qwen3.6-27B, the dense 27-billion-parameter open-weight model Alibaba's Qwen team released in April — a strong base, and Apache 2.0, which makes the rebuild licence-clean. PrismML, a Caltech spin-out that came out of stealth in March with 1-bit builds of smaller models, ships two variants: a ternary build (weights restricted to −1, 0 or +1, with FP16 group-wise scaling — 1.71 effective bits per weight, 5.9GB) and a 1-bit build (weights −1 or +1 — 1.125 effective bits, 3.9GB). Both keep the base model's multimodality and 262K context, and both are Apache 2.0.

The phone claim rests entirely on the 1-bit build. PrismML's page says the 3.9GB variant "fits within the memory budget of an iPhone 17 Pro" — and its own Hugging Face documentation notes the ternary build, as currently deployed, exceeds iOS's roughly 6GB per-app memory ceiling. The one third-party iOS app that lists the model requires an iPhone 17 Pro or Pro Max. So "runs on a phone" means, today: the only shipping path requires an iPhone 17 Pro or Pro Max, and only for the 1-bit variant.

The numbers, precisely

PrismML's headline is that the compressed models keep "95%" and "90%" of the original's benchmark performance. The precise figures, from its own Hugging Face model cards: the FP16 Qwen3.6-27B baseline scores 85.07 across the company's 15-benchmark suite; the ternary build scores 80.49 (94.6%); the 1-bit build 76.11 — which is 89.5%, rounded up to 90% in the marketing.

Three things about those numbers. First, they are vendor-run: the model cards state the evaluation used EvalScope and vLLM on an NVIDIA H100 — datacenter hardware, not a phone (a disclosure that appears on the model cards but not in the announcement post). Second, the averages hide uneven damage: in PrismML's own per-category table, the 1-bit build's maths cluster holds up well (91.7 vs the ternary's 93.4) while tool-calling falls from the base model's 80.0 to 66.0, and vision from 72.6 to 59.6 — fourteen and thirteen points; the compression bites hardest exactly where agentic, on-device use would need it. Third, the speed figure everyone is quoting — ~11 tokens per second, on an iPhone 17 Pro Max — is also PrismML's own measurement.

What independent testing shows so far

As of this morning: no independent reproduction of the benchmark numbers, and no published working run on a phone — the one phone attempt reported in the thread, on Android, produced strings of exclamation marks for answers. A broken phone run, if anything, underlines the point.

What has surfaced is early and mixed. One evaluator, running his own harness against a 4-bit Bonsai variant — not the shipped 1-bit or ternary builds — found wikitext perplexity roughly doubling and a GSM8K result so broken he flagged it himself: "0/0 (eval bug?)". His own conclusion: "I'm also not sure what is up with the gsm8k, their benchmarks show something different, but they are using another eval tool… Also why I'm building a setup instead of taking model devs word for benchmarks." That's suggestive, not a verdict — wrong variant, self-flagged possible bug — and a byteiota piece citing "one independent evaluation" of GSM8K irregularities appears to be describing this same run. One datapoint, not two.

The hands-on reports are friendlier on Macs than anywhere else. One user ran the model on an M1 Pro MacBook with 16GB of RAM inside VS Code and reported throughput of "100 at beginning, 69 by the end" of the editor's 24,000-token system prompt (units unstated) — "honestly I'm super impressed." A desktop-CPU benchmark tells a different story: on a Ryzen 7 5700X, the binary build managed 6 tokens per second generation, while the ternary build crawled at 0.7 — "CPU inference for ternary hasn't been optimized yet," as the tester put it. And the toolchain is young: Simon Willison reported both the GGUF and MLX builds failing in LM Studio; runs currently want PrismML's own llama.cpp fork. PrismML's account has engaged helpfully on these compatibility issues in the thread — but had not, at the time of writing, publicly addressed the benchmark discrepancy.

The question PrismML's page doesn't answer

There's a technical ambiguity at the centre of this release that determines how seriously to take it, and PrismML's announcement doesn't resolve it: how were these weights produced? Coverage disagrees — one outlet describes the model as trained natively in low-bit from the start, another states flatly it's "a low-bit representation of Qwen3.6-27B, not a new pretrain". PrismML's page says neither, deferring to a whitepaper.

Why it matters: the reason extreme quantization is plausible at all is the "BitNet" line of research — Microsoft's 1.58-bit work showed ternary models can match full-precision quality when trained that way from scratch, but demonstrated it at around 3B parameters. Naive post-training quantization this aggressive typically collapses on hard reasoning. If PrismML has a conversion recipe that gets BitNet-class results on an existing 27B model, that's the genuinely new contribution — and it's exactly the claim that needs the whitepaper, and independent evals of the shipped artifacts, to stand up.

What to watch

Independent benchmark runs of the actual released builds (not 4-bit conversions); a public tokens-per-second run on an iPhone 17 Pro from someone who doesn't work at PrismML; the whitepaper's answer on the training recipe; and a head-to-head against Google's Gemma QAT builds, which several practitioners in the thread regard as the current on-device standard to beat. One more strand worth noting with its provenance attached: CNBC reported that Apple is "in talks" with PrismML — sourced to PrismML's own chief executive, and unconfirmed by Apple.

The compression is real. The 3.9GB is arithmetic. The quality claim is, for now, one company's homework awaiting a marker.