Coding Horizon

Coding Horizon · video not yet published

These are the working notes behind the film: every figure, where it came from, and what could not be verified.

Everything below was read from primary sources on 2026-07-26. Every figure used in the video comes from this page and nowhere else.

Primary source

https://huggingface.co/prism-ml/Bonsai-27B-gguf — model card, README, discussions. Secondary: docs.prismml.com/models/bonsai-27b, the two llama.cpp forks, and one genuinely independent benchmark (below).

What it is

1-bit GGUF build of Qwen3.6-27B. The intelligence is Qwen’s, the compression is Prism’s.
Apache 2.0. ~27.3B weights. Hybrid attention, about 75 percent linear.
Quant format Q1_0_g128: one sign bit per weight, plus one FP16 scale shared across each group of 128 weights. 1.125 bits per weight true cost.
Context 262,144 tokens. Multimodal, text and image in.
Released ~14 July 2026. Downloads last month 2,114,963. Org followers 2.37k.

Size and memory (card’s own table)

Build	Weights	4K ctx	10K	100K
1-bit Bonsai	3.79 GB	5.2 GB	5.6 GB	11.6 GB
Q4_K_XL	17.6 GB	19.2	19.6	25.6
FP16	51.25 GB	52.6	53.3	59.3

Deployed footprint quoted as ~3.9 GB. Card states 14.2x smaller than FP16. Note the card is internally inconsistent: the prose says “from ~54 GB”, the table says 51.25 GB. The video uses the table’s figure, and the 14x comparison.

Separate downloads, not in the 3.9 GB: DSpark drafter 1.79 GB (Q4_1), vision tower 0.63 GB (HQQ 4-bit). Full stack is nearer 6.3 GB.

Throughput (all vendor measured, llama-bench)

Platform	TG128	PP512
Apple M5 Max	66.4 tok/s	874
Apple M5 Pro	44.2	421
Apple M4 Pro	26.0	133
H100	104.8	2755

MLX build: ~11 tok/s on iPhone 17 Pro Max.

There is no published CPU only number anywhere. Every figure above is Metal or CUDA, and the card’s own run command passes -ngl 99, which offloads every layer to the GPU. The “no GPU” framing means no discrete card and no VRAM ceiling. It does not mean the numbers were produced on a CPU.

Benchmarks — the whole point of the video

Prism’s own 15 benchmark suite, thinking mode. Average 85.07 → 76.11, which is the 89.5 percent headline.

Benchmark	FP16	1-bit	Lost
MATH-500	99.40	98.00	1.4
GSM8K	95.30	92.80	2.5
MBPP+	83.33	79.60	3.7
AIME25	93.29	88.75	4.5
HumanEval+	95.12	89.63	5.5
AIME26	93.33	87.08	6.3
BFCL v3	77.10	70.72	6.4
OCR Bench v2	65.28	58.65	6.6
IFEval	88.91	79.11	9.8
MMLU-Redux	93.42	82.75	10.7
MuSR	72.88	64.02	8.9
LiveCodeBench	87.77	76.40	11.4
IFBench	68.03	52.36	15.7
MMMU-Pro	79.94	60.48	19.5
τ²-Bench	82.90	61.34	21.6

The shape: saturated benchmarks lose nothing and drag the average up. Anything needing precise discrimination collapses. τ²-Bench is multi step tool use and loses a quarter of its score. The card itself concedes: “agentic coding workflows remain underdeveloped in this release.”

Ternary companion — the actual recommendation

prism-ml/Ternary-Bonsai-27B-gguf. 1.71 bits per weight, ~7.2 GB deployed (5.9 GB ideal). Average 80.49.

	FP16	Ternary	1-bit
Average	85.07	80.49	76.11
HumanEval+	95.12	93.90	89.63
MBPP+	83.33	81.22	79.60
LiveCodeBench	87.77	82.75	76.40
τ²-Bench	82.90	73.61	61.34

Memory: 8.4 GB at 4K, 14.7 GB at 100K. Throughput M5 Pro 26.2 tok/s (vs 44.2 for 1-bit), H100 98.0. So ternary costs 3.3 GB and roughly 40 percent of the speed, and buys back 6.3 points of LiveCodeBench and 12.3 points of tool use.

The install is not one line

Official run path, from the card:

git clone https://github.com/PrismML-Eng/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build -j
hf download prism-ml/Bonsai-27B-gguf Bonsai-27B-Q1_0.gguf --local-dir .
./build/bin/llama-cli -m Bonsai-27B-Q1_0.gguf ... -ngl 99

It needs a fork, built from source. The 1-bit kernels are not in upstream ggml-org/llama.cpp. There is also a second, unofficial fork, Mintplex-Labs/prism-ml-llama.cpp, 72 stars, whose own readme says: “This is not an official fork and is not supported by the Prism-ML team.”

Consequences reported in the repo discussions:

Ollama 500 error loading the GGUF, on the dspark architecture.
An open LM Studio thread.
An open tokenizer error thread.
“Severe Russian language degradation and English code-switching.”
One flat “Totally garbage” with no detail.

Independent testing — the only one found

Saiyam Pathak, blog.kubesimplify.com, on an RTX PRO 6000 (hardware sponsored by Utho Cloud) and a DGX Spark. His own measurements:

RTX PRO 6000: 1-bit 145.5 tok/s generation, 3600 pp. Ternary 120.7 tok/s.
DGX Spark: ternary 28.5 tok/s, still 31.5 tok/s at 16K context depth.
Ternary held 90.2 tok/s at 64K context on the RTX.
Quality smoke tests including code. On longest palindromic substring the 1-bit build exhausted its token budget before reaching the final answer.
Speculative decoding was workload dependent and counterintuitive: +33 percent on the RTX, −37 percent on the DGX Spark, same test.

Everything else found in search (wavect.io, aitooltier, regolo, localclaw, rohitraj.tech) is a rewrite of the model card. rohitraj.tech does the same “the average hides it” analysis independently, but runs nothing.

Benchmark methodology dispute

HF discussion 7. User Green-Sky argues the intelligence density metric is broken because raw percentages do not subtract the noise floor: on four way multiple choice, guessing scores 25, so a one byte model would post an absurd density. Scores “need to be corrected down, so the noise floor becomes 0.”

Prism ML (Pashak) partly conceded: density “makes less sense” at very small sizes and they should probably compare only above a threshold. They did not commit to correcting the published numbers.

What was not checked

I did not build the fork or run the model. No timing, quality or long context figure in this video is mine.
No independent party has re-run the 15 benchmark suite. Every quality number in the video is Prism measuring Prism.
The FP16 baseline column is Prism’s own measurement of Qwen3.6-27B, not Qwen’s published figures.
Downloads last month is a file pull counter across many variants, not users.

Source history · every edit to this page, timestamped.