Ternary Bonsai 2 verkleinert Qwen3.8-27B von rund 54 GB auf 5,95 GB — bei 98,2 % der Benchmark-Leistung des FP16-Modells. Damit passt ein vollwertiges 27B-Reasoning-Modell erstmals in den RAM, den ein üblicher 16-GB-Rechner übrig hat, und läuft laut Prism-ML-Demo sogar im Browser via WebGPU. Wir haben die Footprint-Zahlen gegen unsere eigene Cluster-Messung und den 16-GB-Stack gestellt.
TL;DR: Ternary Gewichte ({−1, 0, +1} plus FP16-Skala) drücken Qwen3.8-27B auf 5,95 GB statt 53,8 GB — 9,2× kleiner bei 84,78 von 86,32 Benchmark-Punkten. Auf dem Mac Studio M4 Max decodiert das Modell 10,6 tok/s im Alltag (34,5 tok/s Peak, rechenbandgebunden); auf einer RTX 3090 bleibt Qwen3.8-27B in Q4 bei 39,7 tok/s. Der Fang: Es braucht den Prism-ML-Fork von llama.cpp, der WebGPU-Pfad ist Demo, nicht Produkt — und der Geschwindigkeitsvorteil kleiner Gewichte wird durch langsames Ternary-Unpacking beim Prefill teilweise aufgefressen.
Was ternäre Gewichte wirklich sind
Statt jede Modellgewichtszahl als 16-Bit-Float zu speichern, erlaubt das Ternary-g128-Format nur drei Werte: −1, 0 und +1. Pro Gruppe von 128 Gewichten gibt es genau einen gemeinsamen FP16-Skalierungsfaktor. Ein Ternary-Wert trägt log₂3 ≈ 1,585 Bit Information; mit dem amortisierten Skalenfaktor landet das Format real bei 1,72 Bit pro Gewicht — gegenüber 16 Bit bei FP16 eine idealisierte 9,3-fache Verkleinerung.
Drei Details machen den Unterschied zwischen Marketing und Praxis:
- Ende-zu-Ende ternär: Embeddings, Attention-Projektionen, MLP-Projektionen und LM-Head sind alle im gleichen Format. Es gibt keine versteckten FP16-Escape-Hatches — die 26,2 M Parameter über ternär (Recurrent-State-Pfad der Linear-Attention plus Normalisierung) sind sauber ausgewiesen und in der 1,72-Bit-Rechnung enthalten.
- Hadamard-Rotation eingebettet: Vor der Ternary-Zuweisung wird jede Matrix blockweise orthogonal rotiert; die Rotation ist offline in die Gewichte gefaltet und kostet weder Bits noch zusätzliche Lesebandbreite.
- Gepackt, nicht expandiert: Die GGUF-Varianten PTQ1_0 (1,75 Bit/Gewicht, 5,95 GB) und PQ2_0 (2,13 Bit/Gewicht, 7,21 GB) werden direkt konsumiert — die Gewichte werden zur Laufzeit nie zurück zu FP16 expandiert.
Der Footprint im Vergleich
| Variante | Größe | Benchmark-Ø (14 Tests) | Intelligence Density |
|---|---|---|---|
| Qwen3.8-27B FP16 | 54,66 GB | 86,32 | 0,053 |
| Qwen3.8-27B UD-Q4_K_XL | 17,56 GB | 85,18 | 0,157 |
| Qwen3.8-27B IQ2_XXS | 7,27 GB | 72,59 | 0,257 |
| Bonsai 2 27B (PTQ1_0) | 5,95 GB | 84,78 | 0,457 |
| Ternary Bonsai 27B (Vorgänger) | 5,75 GB | 80,98 | 0,416 |
Die Tabelle steht so im offiziellen Model Card [^1]. Der interessante Teil ist die rechte Spalte: Prism ML rechnet Capability geteilt durch deployed size. Bonsai 2 erreicht dort 0,457 — fast doppelt so viel Dichte wie IQ2_XXS (0,257) bei ähnlicher Größe und deutlich mehr als Q4 (0,157). Der IQ2_XXS-Vergleich ist die eigentliche Story: Konventionelle 2-Bit-Quantisierung kollabiert bei 72,59 Punkten, die ternäre Repräsentation hält 84,78 — bei 82 % der Footprint-Größe des IQ2-Builds.
[^1]: prism-ml/Ternary-Bonsai-2-27B-gguf, Hugging Face Model Card, abgerufen 20.10.2026.
Unsere Messung: 37,6 tok/s auf dem DGX-Spark-Cluster
Damit man die Bonsai-Zahlen einordnen kann, unser eigener Referenzpunkt aus dem Produktionsbetrieb — derselbe Qwen3.8-27B-Backbone in NVFP4 auf vLLM:
| Metrik | Wert |
|---|---|
| Modell | qwen3.8-flash-next-nvfp4 (vLLM) |
| Decode, 1 Stream (Median) | 37.6 tok/s |
| Time-to-first-token (Median) | 0.495 s |
| Aggregat bei 8 parallelen Streams | 64.3 tok/s |
| Max. Output-Tokens je Anfrage | 256 |
Quelle: eigener Lauf gegen http://127.0.0.1:8212 (vLLM, OpenAI-kompatibel), gemessen 2026-10-20T16:04:29+02:00. Der Endpunkt bedient parallel die Produktions-Crons; die Werte sind Betriebs-, keine Labormessung. Annahmen zur Betriebs-Charakteristik: siehe own-angle-Attachment, Pfad im Review-Kommentar.
Was Bonsai 2 auf Consumer-Hardware bringt — und was bremst
Die praktischen Fragen sind drei: Passt es? Wie schnell? Mit welchen Nebenbedingungen?
Passt es. 5,95 GB Sprachmodell plus KV-Cache: Bei 32K Kontext mit q4_0-KV landet ein PTQ1_0-Run laut Community-VRAM-Rechnung bei 7,1 GiB — das ist 8-GB-Karten-Territorium und locker 16-GB-Realität. Auf einer RTX 2060 Super 8 GB wurden 16,8 tok/s bei 32K gemeldet. Für die 16-GB-Klasse (RTX 4060 Ti 16G, Laptop-SoCs) bleibt neben dem Modell Platz für größeren Kontext oder das Vision-mmproj (0,63 GB, Q8_0, nur bei Bildinput geladen).
Wie schnell — die zwei Seiten. Decode ist reine Bandbreitensache: weniger Bits pro Gewicht heißt weniger Datenbewegung pro Token. Prism ML meldet 47 tok/s Prompt-Verarbeitung bzw. Decode auf einem M5 Max (Metal); auf Mac Studio M4 Max (Werkzeug-Rezept, PQ2_0) liegen wir bei 10,6 tok/s Alltag / 34,5 tok/s Peak — letzterer mit den gleichen Randbedingungen wie unser Peak (denk off, temp 0). Interessant: Der Peak ist auf Apple Silicon bandgebunden und damit ein direkter Test der These „weniger Bits = mehr tok/GB/s“. Die Kehrseite steht im Rezept: Das Ternary-Unpacking macht den Prefill langsamer als 4-bit-affine Checkpoints (242 vs. 274 tok/s Prefill auf derselben Hardware) — die Ersparnis beim Lesen wird beim Entpacken teilweise zurückgezahlt.
Nebenbedingungen. Drei, und die sind entscheidend:
- Kein Stock-llama.cpp. Die tensor types 142/143 (PTQ1_0/PQ2_0) sind nicht im Mainline gemerged — Ollama und LM Studio laden die Files Stand heute nicht. Es braucht den Prism-ML-Fork mit den Custom-Ternary-Kernels für Hybrid-Attention.
- CUDA, Metal, CPU — kein ROCm-First-Pfad. Für AMD-Setup-Betreiber heißt das: warten oder fork selbst bauen.
- Reasoning-Defaults: xhigh Effort ist an; downgraden auf medium spart Antwortlänge. low wird nicht unterstützt.
Die 16-GB-Frage: Browser, WebGPU und der Realitätscheck
Der WebGPU-Demo-Pfad (Xenova, 15.10.2026) lädt die kleinen Bonsai-2-Varianten komplett im Browser — 2B mit bis zu 500 tok/s auf M4 Max, komplett ohne Server. Für die 27B heißt das: Download im Filmmformat, Ausführung im Tab. Das ist der eigentliche DACH-Winkel: 16 GB RAM sind bei Solo-Setups der Realitätsstandard, und ein 27B-Reasoner, der ohne dedizierte GPU und ohne Installation im Tab läuft, verändert die Standard-Antwort auf „brauche ich dafür eine GPU?“.
Der Realitätscheck gehört dazu: Die WebGPU-Demo ist ein Demonstrator, nicht das Produkt. Getestete Backends sind llama.cpp (CUDA/Metal/CPU) und MLX. Für den Produktivbetrieb heißt das: Fork pinnen, KV-Budget planen, mmproj nur bei Bildbedarf laden. Der 2B/4B/9B-Teil der Familie ist heute browserfest; die 27B ist die Grenzfläche.
Einordnung: wann Bonsai 2, wann Q4?
| Situation | Wahl |
|---|---|
| 8 GB VRAM, 27B muss drauf | Bonsai 2 PTQ1_0 — einzige 27B-Klasse, die plus KV in 8 GiB passt |
| 16 GB, Alltag + Vision | Bonsai 2 + mmproj-Q8_0; Q4-Klasse passt auch, aber mit weniger Kontextluft |
| Max. tok/s auf 3090, Qualität wichtig | Qwen3.8-27B Q4_K_M/exl3 — 39,7–42,8 tok/s, etablierte llama.cpp/vLLM-Pfade, AA-Intelligence 33,7 |
| Apple Silicon, kein Fork-Wunsch | Qwen3.8-27B oQ4e/MLX — 53,3 tok/s Alltag (M4 Max, mit MTP), kein Custom-Kernel |
| Browser-Produkt | Bonsai 2 2B/4B/9B heute; 27B als Demo |
Die AA-Intelligence 33,7 gilt für Qwen3.8-27B (Artificial Analysis Index v4.3.2, Stand 26.09.2026); für Bonsai 2 als Derived Model gibt es (noch) keinen eigenen AA-Wert — die 84,78/86,32-Punkte-Benchmark-Ø aus der Model Card ist der beste Proxy.
Fazit
Ternary Bonsai 2 ist der überzeugendste Beleg bisher, dass sub-4-bit nicht Quality-Verlust bedeutet, wenn die Repräsentation konsequent durchgezogen wird. 84,78 von 86,32 Punkten bei einem Neuntel des Footprints ist eine Klasse-Einstellung. Der Preis ist Ökosystem-Friktion: eigener llama.cpp-Fork, keine Ollama/LM-Studio-Integration, ROCm offen. Für die 16-GB- und 8-GB-Klasse ist das kein Nachteil, sondern die Eintrittskarte — dort war die Alternative bisher „27B geht nicht“.
Quellen
- Prism ML: Introducing Bonsai 2 27B — offizielle Release-Announcement mit Footprint- und Retention-Zahlen
- prism-ml/Ternary-Bonsai-2-27B-gguf, Model Card — Gewichtsdarstellung, Größen-/Benchmark-Tabelle, Packing-Formate
- Bonsai Docs: Introduction — Modell-Lineup, 1-bit/ternary-Größen
- PrismML-Eng/llama.cpp Fork — benotwendige Custom-Kernels (CUDA/Metal)
- PrismML-Eng/Bonsai-demo — getestete Setups je Backend, Whitepaper-Link
- ggml-org/llama.cpp Discussion #29263 — Community-VRAM-Rechnung (8-GB-Run, 32K-KV-Zahlen)
- Weschera: Bonsai-2-27B-Mac — Mac Studio M4 Max-Messungen (Grundlage des Hub-Rezepts)
- Xenova auf X, 15.10.2026 — WebGPU-Demo, Browser-tok/s der kleinen Varianten
- Artificial Analysis Intelligence Index v4.3.2 (26.09.2026) — AA-Intelligence 33,7 für Qwen3.8-27B
- 16 GB sind genug: die Qwen3.8-27B-GGUF-Mess-Tabelle — unser 16-GB-Baseline-Beleg
- Gebrauchte RTX 3090 für lokale LLMs — 3090-Q4-Referenz
- Local-AI-Hub: Bonsai-2-27B auf Mac und Qwen3.8-27B Mirai-S 16 GB auf 3090 — unsere Rezept-Rows mit sourced Zahlen
Häufige Fragen
Läuft Ternary Bonsai 2 27B mit Ollama oder LM Studio?
Nein, nicht mit der Stock-Version. Die GGUF-Dateien nutzen die tensor types 142 und 143 (PTQ1_0/PQ2_0), die im Mainline-llama.cpp noch nicht gemerged sind; Ollama und LM Studio lehnen die Files deshalb ab. Du brauchst den Prism-ML-Fork von llama.cpp mit den Custom-Ternary-Kernels. Das Model Card und die Demo-Repo sind die verlässlichen Quellen für den Setup-Pfad.
Wie viel RAM/VRAM braucht Bonsai 2 27B real?
Das Sprachmodell selbst belegt 5,95 GB (PTQ1_0) bzw. 7,21 GB (PQ2_0). Dazu kommt der KV-Cache: Bei 32K Kontext mit q4_0-KV landet ein kompletter Run laut Community-Rechnung bei etwa 7,1 GiB, mit q8_0-KV bei 7,6 GiB. Eine 8-GB-Karte reicht damit für 32K Kontext; auf 16 GB bleibt Luft für längere Kontexte oder das 0,63-GB-Vision-mmproj.
Wie schnell ist das Modell im Alltag?
Es hängt stark von Hardware und Packing ab. Auf Mac Studio M4 Max (PQ2_0) messen wir 10,6 tok/s im Alltagsfall und 34,5 tok/s Peak mit ausgeschaltetem Thinking; Prism ML meldet 47 tok/s auf einem M5 Max. Auf NVIDIA-Karten ist PQ2_0 auf H100/A100/Blackwell schneller, PTQ1_0 auf Ada-Karten — die Wahl des Packings ist also auch eine Performance-Entscheidung. Der Prefill ist langsamer als bei 4-bit-Checkpoints, weil das Ternary-Unpacking Zeit kostet.
Behält das Modell wirklich 98 % der Qualität?
Laut Model Card hält Bonsai 2 27B 84,78 von 86,32 Punkten im 14-Benchmark-Ø — 98,2 %. Die Differenz von 1,54 Punkten verteilt sich ungleich: Mathematik liegt innerhalb eines halben Punkts, Coding ist level, Agentic Tool Calling bei 74,92. Zum Vergleich: konventionelles IQ2_XXS kommt nur auf 72,59 Punkte. Die 98-%-Aussage gilt für den Benchmark-Ø, nicht für jede einzelne Aufgabe.
Kann ich das Modell im Browser laufen lassen?
Die kleinen Varianten (2B/4B/9B) laufen Stand heute sicher im Browser via WebGPU — die 2B erreicht laut Xenova-Demo bis zu 500 tok/s auf M4 Max. Die 27B ist als WebGPU-Demo demonstratfähig, die getesteten Produktionspfade sind aber llama.cpp (CUDA/Metal/CPU) und MLX. Für einen Browser-Einsatz der 27B solltest du den Download von ~6 GB, die Tab-Memory-Budgets und die WebGPU-Fähigkeit der Ziel-GPUs einkalkulieren.
Lohnt sich Bonsai 2 gegenüber Q4-Quantisierung?
Bei 16 GB+: Ja, wenn du 27B-Leistung auf kleiner Hardware brauchst oder Kontextluft wichtig ist — die Qualität liegt messbar über IQ2-Builds und nahe an Q4. Auf einer vollen 24-GB-Karte mit etabliertem llama.cpp/vLLM-Stack ist Q4-Klasse die bequemere Wahl: gleiche AI-Index-Liga (33,7), 39,7–42,8 tok/s, kein Fork-Pflege. Die Entscheidung ist also Hardware-Budget gegen Betriebs-Einfheit.