Retour au blog

Par Tamsi Besson ·

Ternary Bonsai 2 27B — un Qwen3.8 dans 6 Go, 98 % du FP16

PrismML recompresse Qwen3.8-27B en poids ternaires vrais (1,72 bit). 5,95 Go, 98,2 % du FP16, ~47 tok/s sur M5 Max. Le catch : ça ne tourne pas dans llama.cpp stock.

7 min de lecture
  • Bonsai
  • Qwen
  • Local LLM
  • Ternary
  • Quantization

J’ai écrit Qwen 3.8 27B parce que le dense open est enfin assez bon pour rester en local, et DFlash 2 parce que le plafond suivant c’est le débit. Le 17 septembre 2026, PrismML pousse Ternary Bonsai 2 27B : le même Qwen3.8-27B, poids {−1, 0, +1}, 5,95 Go au lieu de ~54 Go FP16. Pas un « 2-bit » marketing à 9 Go. Un ternaire vrai à 1,72 bit/poids, qui tient 98,2 % de la moyenne thinking du FP16.

PrismML — Bonsai, intelligence density for local models
PrismML — Bonsai 2 27B : Qwen3.8-27B en ternaire g128, Apache 2.0, 16–17 septembre 2026.

La model card GGUF →

Pourquoi ça m’intéresse

Le 3.8 en MLX 4-bit tenait déjà sur un laptop. Bonsai 2 change l’équation mémoire : un 27B reasoning + 262k de contexte dans l’enveloppe d’un petit 7B. Le premier Bonsai 27B (juillet, base Qwen3.6) gardait ~95 % du FP16. Celui-ci annonce 98,2 % — et surtout, il ne s’écroule pas là où les quants 2-bit classiques meurent (AIME, LiveCodeBench).

  • 5,95 Go (PTQ1_0) ou 7,21 Go (PQ2_0) pour le language model. Vision en mmproj Q8_0 optionnel (~0,63 Go).
  • MLX : prism-ml/Ternary-Bonsai-2-27B-mlx-2bit — 8,60 Go disque, tour vision incluse.
  • Apache 2.0, archi inchangée : hybrid attention ~75 % linéaire, 27,36B, thinking xhigh par défaut.

Ternaire, pas « 2-bit »

Chaque poids ∈ {−1, 0, +1}, un scale FP16 par groupe de 128. Information : log₂3 ≈ 1,585 bit, plus le scale amorti → ~1,71, 1,72 en comptant les quelques tenseurs laissés plus haut (norme + état récurrent du linear attention, 0,1 % du modèle). Les embeddings, l’attention, les MLP et la LM head sont ternaires. Pas de tour de passe-passe « 2-bit sur le papier, 2,8 en moyenne ».

Le détail qui bloque les runtimes stock : une rotation de Hadamard par bloc de 1024, pliée dans les poids. Au load, le runtime applique la transformée miroir sur les activations — ou refuse le fichier. llama.cpp upstream ne connaît ni PTQ1_0 ni PQ2_0. Pire : un Q2_0 Bonsai 1 chargé sans Hadamard sort du garbage sans warning.

  • PTQ1_0 — trits denses, 1,75 bpw, 5,95 Go. Plus rapide en decode sur Ada / L4 (moins de poids à bouger).
  • PQ2_0 — un trit dans un slot 2-bit, 2,13 bpw, 7,21 Go. Gagne le prefill partout, et le decode sur H100 / A100 / Blackwell.
  • Ni l’un ni l’autre n’est « le plus rapide ». Tu choisis selon la carte, pas selon le label.

Les benches qui comptent

EvalScope + vLLM, H100, thinking mode, 14 benches, même infra. Chiffres vendeur — plafond, pas une repro indépendante — mais le protocole est au moins aligné entre les variantes :

  • Qwen3.8-27B FP16 : 86,32 avg · 54 Go · 16 bpw
  • UD-Q4_K_XL (« 4-bit ») : 85,18 · 17,6 Go · 5,2 bpw réels
  • IQ2_XXS (« 2-bit ») : 72,59 · 9,4 Go · 2,8 bpw réels
  • Bonsai 2 : 84,78 · 5,9 Go · 1,72 bpw → 98,2 % du FP16

L’IQ2_XXS a l’air correct sur MMLU-Redux (88,9) et s’effondre dès que la chaîne de raisonnement s’allonge : AIME26 57,5, LiveCodeBench 56,4. Bonsai 2 tient 95,83 et 90,07. Math 96,57 vs 97,06 FP16. Coding au niveau du baseline (89,42 vs 89,07). Le trou restant est surtout knowledge / vision. C’est pour ça qu’un smoke test « ça a l’air 2-bit » rate le collapse.

Le débit, une fois que ça tient en RAM

Mesures Prism, llama-bench, batch 1, pas de tour vision. PQ2_0 sauf mention :

  • RTX 5090 : 130 tok/s decode · ~1,95 J/tok
  • RTX 4090 : 81 (PQ2_0) / 91 (PTQ1_0)
  • L4 72 W : ~30 tok/s
  • M5 Max (mesure pre-rotation, à refaire) : ~47 tok/s · M5 Pro ~28 · M4 Pro ~18
  • M5 Pro : 27,5 W rail GPU — le 27B qui ne rentre même pas en FP16

Le lancer — et le catch

Source of truth : PrismML-Eng/Bonsai-demo. Binaries du fork llama.cpp. Ollama / llama.cpp stock / MLX ordinaire : non. Un loader MLX sans le runtime bundlé (model_type: prism_hadamard_qwen35) ne throw pas — il répond faux.

hf download prism-ml/Ternary-Bonsai-2-27B-gguf \
  Ternary-Bonsai-2-27B-PQ2_0.gguf --local-dir .

./bin/llama-cli -m Ternary-Bonsai-2-27B-PQ2_0.gguf \
  -ngl 99 -fa on -c 32768 \
  --temp 1.0 --top-p 0.95 --top-k 20 \
  -p "Explain quantum computing in simple terms." -n 256
  • Thinking : temp=1.0, top_p=0.95, top_k=20. Instruct : temp=0.7, top_p=0.8, presence_penalty=1.5.
  • reasoning_effort=low n’est pas supporté — ça se comporte comme xhigh. Utilise medium pour raccourcir.
  • Déjà des packs communautaires DFlash 2 (GGUF / MLX) le jour J — le drafter sur un ternaire, à mesurer, pas à croire.

Où ça se branche chez moi

Sur le Mac 32 Go, le 3.8 en 4-bit était déjà le daily. Bonsai 2 est le cran où le 27B n’est plus un compromis VRAM : tu gardes de la RAM pour le contexte, un second modèle, ou le drafter. Le jour où le fork Prism (ou l’upstream) est dans Studio / Ollama, c’est le poids que je tenterais en premier pour un agent local. Tant que le runtime est un fork, c’est un outil, pas encore le défaut.

Takeaway

Bonsai 2 n’invente pas un 27B. Il rend le 3.8 déployable là où le FP16 ne rentre pas, sans le collapse des vrais 2-bit. 98 % du thinking avg à 6 Go, c’est le chiffre. Le contrat, c’est le runtime : Hadamard + types PTQ1_0 / PQ2_0, ou tu n’as pas le modèle. Chiffres Prism, à prendre comme plafond. Les poids, eux, sont déjà sur le Hub.