senn-techBonsai 2 27B: Ein Ternär-Modell mit 6 GB passt in unsere Lane
Am 17. September 2026 hat PrismML Bonsai 2 27B veröffentlicht: eine ternär quantisierte Fassung von Qwen3.8-27B unter Apache 2.0. Das ist kein Laborprodukt, sondern Kompression der Grundgewichte eines Modells, das bei uns läuft: Qwen3.8-27B FP8 auf 4× RTX 5090 ist seit dem 18. August unser Arbeitsmodell. Ich habe die Modellkarte, das Whitepaper und die Repos gelesen; die Zahlen des Repos habe ich am 22. September selbst abgerufen und sortiert, was davon verifiziert ist und was der Anbieter behauptet.
Was PrismML verkauft
PrismML ist eine Ausgründung aus dem Caltech-Umfeld (CEO Babak Hassibi, Kompressionsforscher), finanziert mit 22,25 Millionen Dollar Seed, beraten unter anderem von Ion Stoica. Die Vorgängermodelle der Bonsai-Familie brachte das Team seit März heraus; TechCrunch beziffert deren kumulierte Downloads auf über 11 Millionen und berichtet zudem von Gesprächen mit Apple. Letzteres bleibt Gerücht, von der CEO-Seite unbestätigt.
Relevant für uns ist weniger die Firma als die Technik. Ternäre Gewichte waren bisher Laborware, weil frühe Binär- und Ternär-Ansätze genau dort kollabierten, wo das Reasoning wohnt. PrismML behauptet, diese Wand mit rotierter Ternär-Darstellung unterschritten zu haben. Bei einem Modell, das wir von unserer eigenen Strecke bis in die KV-Cache-Rechnung kennen.
Die Zahlen, die ich selbst sehen kann
Dateigrößen aus dem Repo, gemessen an den HF-LFS-Metadaten am 22. September, nicht am Marketing:
Dazu die Community-Seite: 2.227.879 Downloads und 1.768 Likes beim GGUF-Repo am 22. September, fünf Tage nach Release. Und ein Ökosystem, das in 48 Stunden gewachsen ist: CRACK-, Abliterated- und Uncensored-Varianten stapeln sich bereits im Hub. Das ist ein Rückspiegel der Szene, keine Empfehlung. Für einen Betrieb mit Datenschutzpflicht ist eine abweichselte Variante dieser Datei kein Modell, sondern ein Risiko ohne Ticketnummer.
Was der Anbieter behauptet
Alles unter dieser Linie stammt aus dem Whitepaper, nicht von uns gemessen:
- 84,78 Punkte Mittel über 14 Thinking-Benchmarks gegen 86,32 im FP16-Referenzmodell. Das sind die vielzitierten 98,2 %.
- Konventionelle 2-Bit-Bauten kollabieren selektiv: IQ2_XXS hält MMLU-Redux (88,93), fällt aber bei AIME26 auf 57,5 und bei LiveCodeBench auf 56,4. Bonsai 2 soll genau dort halten (95,83 respektive 90,07).
- Round-trip auf unserer Kartenklasse: rund 130 tok/s Decode auf einer einzelnen RTX 5090 (PQ2_0, Batch 1), 120,5 mit PTQ1_0. Auf einem 72-Watt-L4 noch rund 30 tok/s.
- Auf dem Laptop: 47 tok/s auf M5 Max, 27,5 W GPU-Leistungsaufnahme auf M5 Pro.
Bemerkenswert an der Tabelle ist nicht der Spitzenwert, sondern das Muster: Der konventionelle IQ2_XXS-Bau verliert nicht gleichmäßig, sondern verliert das Denken. MMLU-Redux als Wissensspeicher bleibt heil, Mathematik und Code brechen weg. Genau deshalb ist eine Zahl wie 98,2 % ohne die Aufschlüsselung wertlos. Wir haben denselben Effekt bei FP8-Umbauten unserer vLLM-Strecke schon gesehen; Quantisierung ist kein Gleichmaß, sie ist eine Auswahl davon, welche Fähigkeiten bleiben.
Die Gegenprobe fehlt. Fast.
Eine unabhängige Terminal-Bench-Messung existiert bereits, aber für die erste Bonsai-Generation (Juli, vor dem Thinking-Fokus): 7,9 % auf Terminal-Bench 2.0 mit einer 8-GB-Laptop-GPU. Hinter einem Qwen3.5-9B (9,2 %), deutlich hinter Qwen3.6-35B-A3B (24,3 %). Und der VRAM-Vorteil schrumpfte im Alltag: 7,29 GB belegt die 2-Bit-Datei bei 16k Kontext, das 9B-Modell in Q4 braucht 5,68 GB. Der Thread auf r/LocalLLaMA dokumentiert die Frage, die wir uns auch stellen: Wie schlägt sich aggressive Kompression gegen ein kleineres Modell bei normaler Quantisierung? Für Bonsai 2 steht die Antwort im Agenten-Harness noch aus. PrismML selbst nannte Long-Horizon-Coding als Schwäche der ersten Version und misst für Version 2 bislang nur Tool-Calling (BFCL v3: 74,92 gegen 76,74 FP16, abermals Anbieterangabe).
Was das für unsere Strecke bedeutet
Unsere 5090-Lane streamt im FP8-Decoding die Gewichte mit bis zu 1.790 GB/s über den Bus. Bandbreite ist das Limit, das hatten wir selbst gemessen. Genau da dreht Bonsai die Rechnung: Bei 5,9 GB Gewichtstrom pro Token liegt der Flaschenhals auf Blackwell-Karten laut Anbietertabelle nicht mehr an der Bandbreite, sondern am Instruction-Durchsatz und am Launch-Overhead. Deshalb schlägt dort PQ2_0 die dichtere PTQ1_0-Variante; auf Ada-Karten ist es umgekehrt. Die möglichen Konsequenzen:
- Laptops und randständige Hardware: ein 27B-Agent mit 262k Kontext auf einem normalen Notebook. Offline, ohne Datenverkehr nach außen.
- Nebendiener: ein L4 mit 72 Watt als Dauer-Endpunkt für Cron-Jobs und Sprachagenten. Die Stromrechnung kennt den Unterschied zwischen 30 und 450 Watt.
- Freischaufeln: 21 GB VRAM pro Karte zurück für KV-Cache, Batch oder ein zweites Modell.
Drei Punkte bleiben offen, bevor das Produktion sieht. Der Fork ist ein Betriebsrisiko: gepinnte Binaries, eigener Spiegel, Update-Takt eines einzigen Herstellers; unser Hausmuster dafür ist das Procurement mit SHA256 aus den Vier Dateien vor der Installation. Die Durchsatzwerte der Tabelle sind Batch-1-Messungen, unsere Lane fährt 64 parallele Sequenzen, und ternäres Verhalten unter Batching ist Neuland. Und schließlich: Den vLLM-Pfad unserer Standardstrecke gibt es für die ternären Typen nicht. Bonsai heißt llama.cpp-Fork, gewollt oder nicht.
Der eine Test, der fehlt
Der Plan steht auf unserer Liste: PQ2_0 auf einer einzelnen 5090 in einer eigenen LXC. Zuerst stock llama.cpp, damit wir die Ablehnung der neuen Typen mit eigenen Augen sehen. Dann das Fork-Binary mit unserem Pinning-Muster, dann die 34 Arbeitsaufgaben aus dem Eigenbetrieb-Beitrag im A/B gegen die laufende FP8-Lane. Gemessen werden Genauigkeitsdelta, tok/s bei Batch 1 und bei 32, und der Strom der Lane insgesamt. Erst danach reden wir über Einsatz; und wenn das Ergebnis gegen Bonsai ausfällt, ist auch das ein Beitrag wert.
Weiterführende Quellen
- Modellkarte prism-ml/Ternary-Bonsai-2-27B-gguf: Größen, Bitzahlen, Benchmarks, Fork-Hinweis
- Whitepaper Bonsai 2 27B (PDF): Methodik und Messtabelle
- Bonsai-demo auf GitHub: laut Modellkarte die maßgebliche Anlaufstelle, 2.978 Sterne
- PrismML-Eng/llama.cpp: der Fork mit den ternären Kerneln
- TechCrunch über PrismML: Finanzierung, Hintergrund, Downloads der Familie
- Gegenprobe auf r/LocalLLaMA: Terminal-Bench 2.0 mit Bonsai 1, anderer Kontext
- Aus dem Haus: Qwen3.8-27B im Eigenbetrieb, llama.cpp & GGUF
Was heißt ternäre Quantisierung konkret?+
Jedes Gewicht verliert seinen Zahlenwert und behält nur noch drei Möglichkeiten: minus 1, 0 oder plus 1. Die Information stecken die Autoren in die Struktur. Vor der Zuweisung rotieren sie jede Matrix blockweise per Hadamard-Transformation, die Laufzeit wendet die Gegenrechnung auf die Aktivierungen an. Zusammen mit je einem FP16-Skalierungsfaktor pro 128 Gewichte ergibt das 1,72 Bit je Gewicht, ausgewiesen als GGUF-Typen PTQ1_0 und PQ2_0.
Braucht Bonsai 2 eine eigene llama.cpp-Version?+
Ja, und die Modellkarte sagt das deutlich. Die Kernel für die ternären Typen leben im Fork PrismML-Eng/llama.cpp (CUDA, Metal). Stock llama.cpp lehnt PTQ1_0 und PQ2_0 als unbekannte Typen ab und lädt Q2_0-Dateien ohne Warnung, mit unbrauchbarem Ergebnis. Wer Bonsai 2 im Betrieb einsetzen will, pinnt und spiegelt ein Fork-Binary wie sonst nur Experiment-Software.
Stimmt die Zahl: 2,2 Millionen Downloads in einer Woche?+
Halb. Das GGUF-Repo von prism-ml steht am Morgen des 22. September bei 2.227.879 Downloads und 1.768 Likes, fünf Tage nach Release. Der Downloadzähler von Hugging Face hat aber kein sauber definiertes Zeitfenster, eine Wochenbehauptung ist damit nicht messbar. Die Größenordnung ist trotzdem eindrucksvoll; das Repo führte die Trend-Liste der Woche an.