Bonsai-2-27B-HybridRMD-Satellite-Ternary
A ternary (1-bit / 2-bit) tier for the Satellite decision model. This is the work-in-progress repo for it — the files present today do NOT decode.
Lineage: Bonsai 2 27B
→ from Qwen3.8-27B (27B hybrid attention) → Heretic → Satellite (laya
decision-distilled). The same lineage as
HybridRMD/Ternary-Bonsai-2-27B-Heretic-Satellite,
re-quantised to ternary.
The name states the goal, not the current state. The files below are a documented negative result, published so the failure is reproducible rather than rediscovered.
⚠️ DO NOT USE — these files DO NOT DECODE
These GGUFs quantise cleanly and then produce token soup. There is no working
1-bit tier for this model yet. The usable Satellite model is
HybridRMD/Ternary-Bonsai-2-27B-Heretic-Satellite.
What these files are
| file | format | bits/weight | size | status |
|---|---|---|---|---|
Ternary-Bonsai-2-27B-Heretic-Satellite-PTQ1_0.gguf | ternary, dense trits | 1.75 | 6.6 GiB | ❌ does not decode |
Ternary-Bonsai-2-27B-Heretic-Satellite-PQ2_0.gguf | ternary, trit per 2-bit slot | 2.13 | 7.7 GiB | ❌ does not decode |
They are produced by the same
PrismML-Eng/llama.cpp fork
(branch prism) that the upstream prism-ml/Ternary-Bonsai-2-27B-gguf requires.
Stock llama.cpp cannot load these types at all — it rejects PTQ1_0/PQ2_0
(ggml types 143/142) as unknown. These files are only readable by the fork, so
even a working one would be locked to a single runtime.
The observed failure
Served with the Prism fork's own llama-server (the build that has the Hadamard
activation runtime), on a plain factual continuation prompt:
The capital of France is Paris. The capital of Japan is Tokyo. The capital of Italy is
The F16 and Q2_K tiers of the same weights answer coherently. The ternary tiers return:
ειαautantypestworosse寸onselirkenius彬nets.tell新世纪_initializerasso说吧栩…
llama-server rejects the output with
500: The model produced output that does not match the expected Content-only format. Reproduced on both bake 3 and bake 4 weights.
Root cause (identified, not fixed)
The ternary quantiser does not run Prism's pipeline for this architecture. Two concrete findings from inspecting the emitted files:
-
No rotation metadata. Prism's own card states the mechanism: "the packed model declares its rotation as metadata, so a runtime either applies the matching transform or refuses to load the file." These files contain zero rotation/hadamard/ternary metadata keys (42 KV keys, none relevant). The weights have a folded orthogonal transform that the runtime has no way to know about, so it cannot apply the matching activation transform.
-
Embeddings and the LM head are not ternarised.
token_embd.weightisQ4_Kandoutput.weightisQ6_K, whereas the documented coverage is "embeddings, attention projections, MLP projections, LM head". Only 496 of 851 tensors arePTQ1_0; the rest areF32norms and state-path tensors.
So the quantiser accepts PTQ1_0 as a target and stamps the custom ggml types,
without performing the rotation-and-declare step the format depends on. Stock
gguf 0.19.0 correctly rejects the types as unknown, which confirms the types
are right and the method never ran.
What was tried and ruled out
- Hadamard basis mismatch (quantise rotated, rotate back the wrong way): the
normalised Hadamard is symmetric (
H = Hᵀ), so this hypothesis is untestable in that form and was discarded. - Naive ternary on our weights (measured): relative error 0.573 with 61% of weights driven to exactly zero — catastrophic, consistent with the historical note that ~80% of weights quantise to zero at these settings.
- A blockwise Hadamard(1024) rotation (measured): relative error 0.5715 vs 0.5730 unrotated — a 1.0× improvement, i.e. no benefit. So the rotation is not where the loss comes from; the missing piece is the metadata and the real quantiser path.
- Q2_K as the practical low-bit tier: works, and is what the main repo ships at 10.0 GiB.
The honest bottom line
The 98.2%-of-FP16 figure quoted for prism-ml/Ternary-Bonsai-2-27B-gguf does
not transfer to this model. That number is a measurement of their base model
under their pipeline. We did not reproduce that pipeline for this lineage, and
until we do, any 1-bit claim for this model would be false.
These files are kept so the failure is inspectable and reproducible rather than rediscovered by someone else.
Citation for the upstream method, which is the thing worth studying:
@techreport{bonsai2_27b, title = {Bonsai 2 27B: A 27B Ternary Reasoning Model}, author = {Prism ML}, year = {2026}, month = {September}, url = {https://prismml.com}}