Bonsai-27B · file← Bonsai-27B
Bonsai-27B Q1_0
The only file: PrismML's 1-bit GGUF. Run through all 14 of our tests overnight; deleted on 11 October. Prism-ml 1-bit GGUF.
- Size
- 3.8 GB
- Status
- Deleted 11 Oct 2026
- Scored runs
- 14
- Smallest Mac
- 8 GB estimate, 8K context
Results14 scored · 95% intervals
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| chainwalkbonsai-27b-1bit | 0.0% | 0.0–65.8 | Passed 0/2 | llama.cppagentic-fast | 2026-09-15 |
| contractbonsai-27b-1bit | 25.0% | 14.9–38.8 | Passed 12/48 | llama.cppextraction | 2026-09-15 |
| enrichmentbonsai-27b-1bit | 79.6% | 67.1–88.2 | Passed 43/54 | llama.cppextraction | 2026-09-15 |
| epistemicsbonsai-27b-1bit | 87.5% | 75.3–94.1 | Passed 42/48 | llama.cppstudy-nothink | 2026-09-14 |
| groundingbonsai-27b-1bit | 67.2% | 58.6–74.8 | Passed 84/125 | llama.cppextraction | 2026-09-14 |
| nullschemabonsai-27b-1bit | 18.1% | 10.9–28.5 | Passed 13/72 | llama.cppextraction | 2026-09-14 |
| screeningbonsai-27b-1bit | 96.7% | 88.6–99.1 | Passed 58/60 | llama.cppextraction | 2026-09-14 |
| synthesisbonsai-27b-1bit | 35.0% | 24.2–47.6 | Passed 21/60 | llama.cppextraction | 2026-09-14 |
| taggerbonsai-27b-1bit | 85.4% | 80.4–89.3 | Passed 205/240 | llama.cppextraction | 2026-09-15 |
| tagger_nullablebonsai-27b-1bit | 90.8% | 86.5–93.9 | Passed 218/240 | llama.cppextraction | 2026-09-15 |
| toolcallbonsai-27b-1bit | 100.0% | 94.0–100.0 | Passed 60/60 | llama.cppextraction | 2026-09-14 |
| toolsbonsai-27b-1bit | 100.0% | 79.6–100.0 | Passed 15/15 | llama.cppagentic-fast | 2026-09-14 |
| toolscalebonsai-27b-1bit | 100.0% | 91.2–100.0 | Passed 40/40 | llama.cppagentic-fast | 2026-09-14 |
| worldviewbonsai-27b-1bit | 40.0% | 26.3–55.4 | Passed 16/40 | llama.cppextraction | 2026-09-14 |
Runs marked unenforced were measured on a suite that requires constrained decoding, on a server shown not to apply the schema: mlx_lm accepts it and ignores it, and a few other servers and models break it. Those numbers do not measure what the suite is designed to measure. They are kept and labelled rather than deleted.
The recordHow it was made · how it was served · what went wrong · what happened to it
Rebuilt from the lab's records by Claude, an AI model. The results above come straight from the automated runs. How these pages are made.
| File | Bonsai-27B-Q1_0.gguf, 3,803,452,480 B |
| Format | Q1_0 (1.125 bpw) GGUF |
| Where from | downloaded 2026-09-14 |
| Status | deleted 2026-10-11 |
| Hugging Face | https://huggingface.co/prism-ml/Bonsai-27B-gguf |
Where it came from
- Source:
prism-ml/Bonsai-27B-gguf, fileBonsai-27B-Q1_0.gguf, viahf_hub_download(hf_transfer) intomodels/bonsai-27b-1bit/. - Size: 3,803,452,480 bytes (HF API;
ls3.5G). Revision and sha256: not on record. - Downloaded: 2026-09-14 21:22Z, complete by 21:25Z.
- What the card says (as the assistant read it, 21:21Z): end-to-end binary weights, a sign bit plus one fp16 scale per 128 weights, 1.125 bits per weight; "a heavily quantized derivative of Qwen3.6-27B" and not a separately trained model; needs the PrismML fork (
Q1_0_g128hybrid-attention kernels); published 76.11 average over 15 thinking-mode benchmarks, 89.5% of FP16, against the ternary's 80.49 and 94.6%. - Runtime: the already-built PrismML fork
6ac5eb0(b1), no new build.
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
bonsai-27b-1bit | server up 21:35Z, gauntlet launched 21:36Z; run-log 22:41:07 BST (09-14) to 04:09:57 BST (09-15), i.e. 21:41Z to 03:09Z; 14 suites | llama.cpp-prism/build/bin/llama-server, b1-6ac5eb0 (manifests, run-log runtime_version); run-log llama_build named stock b10893 (stale) | 32768 total / 4 / q4_0 / on / on / not on the line (8192 per slot in the manifests; --cache-ram 1024 -ngl 999 --alias bonsai-27b-1bit) | extraction / agentic-fast / study-nothink | Alan, 21:21Z: "I guess we should probably complete this by testing the 1 bit afterwards to see where its strengths and weaknesses are". |
| (no label) first speed sample | 21:35Z | same | same | n/a | 3.8 tok/s, one run, four gauntlets running: later withdrawn. |
| (no label) matched-protocol speed | 2026-09-15, after the gauntlets cleared (about 04:10 BST) | same binary | not on record | n/a | 300-token decode x3, ~2,850-token prefill, box quiet: 20.0 tok/s decode, 117.8 prefill, 4.8 GB resident. |
The gauntlet ran next to the 8B 1-bit gauntlet, the Mac Studio MLX gauntlet and the M4 Pro re-run, with Ornith resident: 34.6 GB of models, memory free near 1 GB at launch, swap flat at 1.6 GB. Scores are temperature-0; the speed rows from that period were thrown away.
Seats held: none. The server was killed by the overnight script after the gauntlets cleared.
Decisions
- Pre-registered (assistant, 2026-09-14 21:25Z): from the finding Quantisation damage is proportional to the capability present: abstention should degrade first (nullschema below 27.8) and mechanical tool use should hold (toolcall near 100). The script text called it a falsifiable call worth writing down before the run.
- Outcome, 2026-09-15 06:38Z (assistant): half right. toolcall held at exactly 100.0 and nullschema fell to 18.1. Abstention was not the first thing to go:
contractfell 50 points andsynthesis31.7, "five times what nullschema lost"; structured compliance and reconciling conflicting sources are what 1-bit destroys. - Alan, run-time questions: the box was loaded, so "Accept contention, we aren’t testing speed (well other than first test but it will be indicative) you can probably test the 8b 1bit and 27b 1bit together without too much contention?". Later "is it worth pausing the 1bit runs?"; the assistant measured aggregate throughput rising 51% with all four running and advised against pausing. And on the speed theory: "so 1bit decode heavier than ternary with more to unpack?": the theory pointed the other way; the clean number later showed the 1-bit 27B is faster than the ternary (20.0 vs 17.3).
- Verdict as first published: keeps tool use perfectly, loses structured compliance, "three suites improved, unexplained". The status was set by the assistant when the write-up was drafted; no Alan statement rejecting it is on record.
What went wrong
- Contended speed number (withdrawn): 3.8 tok/s from one run with four gauntlets running produced a theory ("1-bit unpacking is dearer per weight", 4.6x slower, kernel maturity) that the clean number overturned; the assistant wrote that it was off by 5.3x.
- Chainwalk n=2: 0 of 2 passed; mean case score 45.5 (not a score).
- Stale build stamp: run-log
llama_buildwas stock b10893 while the server was the forkb1-6ac5eb0. Partial runs: none: every result file holds as many rows as its suite has cases. Missing flags:--jinjaon; no--reasoning-format.
What happened to it
Downloaded 2026-09-14 → benched 2026-09-14/15 → speed-tested 2026-09-15 → deleted 2026-10-11 (bonsai-27b-1bit, 3.5 GB, tiers A/B sweep). Re-downloadable from prism-ml/Bonsai-27B-gguf.