Ternary Bonsai 2 27B vs. Bonsai 27B: Zwei Monate, zwei Basismodelle, eine fehlende Variante

Ternary Bonsai 2 27B erschien am 17. September 2026, zwei Monate nachdem Bonsai 27B am 14. Juli 2026 erschienen war, und der Schlagzeilen-Vergleich zwischen ihnen besteht aus einem einzigen Zahlenpaar: Die erste Generation behielt etwa 95 % des Benchmark-Durchschnitts ihres Vollpräzisions-Basismodells, die zweite behält 98,2 %. Das liest sich wie eine geradlinige Generationenverbesserung, und größtenteils ist es das auch – doch die beiden Zahlen messen nicht dasselbe, weil sich das Basismodell darunter geändert hat. Die Juli-Version komprimierte Qwen3.6-27B. Die September-Version komprimiert Qwen3.8-27B. Ein Teil des Qualitätszuwachses geht auf das Kompressionsrezept zurück, ein Teil auf das neuere Qwen3.8-27B, und keine veröffentlichte Zahl trennt beides.

Es gibt einen zweiten Unterschied zwischen den Generationen, der weit weniger Beachtung gefunden hat und für eine bestimmte Nutzergruppe wichtiger ist: Das erste Bonsai wurde in zwei Varianten ausgeliefert, das zweite in einer. Der 3,9-GB-Build, mit dem ein Modell der 27B-Klasse auf ein iPhone 17 Pro passte, hat in diesem Release keinen Nachfolger. Wenn dieser Footprint der Grund war, warum Sie sich überhaupt für Bonsai interessiert haben, ist die neuere Generation kein Upgrade – sie ist ein anderes Produkt, das Ihren Anwendungsfall nicht abdeckt.

Was die erste Generation tatsächlich ausgeliefert hat

Bonsai 27B wurde am 14. Juli 2026 unter Apache 2.0 als zwei Artefakte veröffentlicht, die auf demselben Basismodell aufbauen, und die Aufteilung zwischen ihnen war der eigentliche Punkt der Veröffentlichung.

• Ternary Bonsai 27B — ternäre Gewichte {−1, 0, +1} mit gruppenweiser FP16-Skalierung, 1,71 effektive Bits pro Gewicht, 5,9 GB Speicherbedarf. Die qualitätsorientierte Variante, positioniert für einen Alltags-Laptop mit voller Reasoning-, Tool-Calling- und Agentic-Fähigkeit.

• 1-bit Bonsai 27B — binäre Gewichte {−1, +1} mit derselben gruppenweisen Skalierung, 1,125 effektive Bits pro Gewicht, 3,9 GB Speicherbedarf. Die auf Speicherbedarf ausgelegte Build-Variante, dimensioniert für das Speicherbudget eines iPhone 17 Pro.

Beide hatten einen 262K-Token-Kontext, beide behielten einen kompakten 4-Bit-Vision-Tower bei, sodass das Modell multimodal blieb, und beide unterstützten spekulative Dekodierung mit einem DSpark-Drafter. Die damalige Darstellung von Prism ML war, dass die Low-Bit-Darstellung durchgängig lief – Embeddings, Attention, MLPs und der LM-Head – ohne Fluchtmöglichkeiten zu höherer Präzision, und dass der 1-Bit-Build das erste Modell der 27B-Klasse war, das überhaupt auf einem Smartphone lief. Der berichtete Durchsatz für die 1-Bit-Variante lag bei rund 11 Token pro Sekunde auf einem iPhone 17 Pro, 87 Tok/s auf einem Apple M5 Max und 163 Tok/s auf einer RTX 5090; für die ternäre Variante wurden 58 Tok/s auf dem M5 Max und 134 Tok/s auf der 5090 angegeben.

Die Qualitätseinbußen wurden zusammen mit diesen Zahlen genannt, statt verschwiegen zu werden. In einer Thinking-Mode-Suite mit 15 Benchmarks erzielte die Full-Precision-Basis 85,0, der Ternary-Build 80,5 – etwa 95 % – und der 1-Bit-Build 76,1, etwa 90 %. Die Verschlechterung konzentrierte sich auf agentisches Tool-Calling, das beim 1-Bit-Build von 80,0 auf 66,0 fiel, und auf Vision, das von 72,6 auf 59,6 fiel. Mathematik und Coding hielten sich in beiden Varianten deutlich besser.

Was die zweite Generation verändert hat

Ternary Bonsai 2 27B behält das Rezept bei und ändert die Eingaben. Die ternäre Darstellung ist weiterhin {−1, 0, +1} mit einer FP16-Skala pro Gruppe von 128 Gewichten, jetzt auf 1,76 Bit pro Gewicht in einer 5,93 GB großen Datei gepackt, mit 262K Kontext und demselben separaten Vision-Tower — in diesem Release 0,63 GB bei 4 Bit, der nur geladen wird, wenn ein Bild eintrifft.

Zwei Dinge sind wirklich neu, und beide werden als Grund dafür genannt, dass sich die Bindungsquote verändert hat.

Das erste ist selektive Präzision. Anders als der Juli-Build, der im Wesentlichen alles ternarisierte, hält Bonsai 2 26.238.464 Parameter in voller Präzision – 0,0976 % des Sprachmodells, etwa 52 MB bei bf16 –, konzentriert im rekurrenten Zustandspfad der Linear-Attention-Schichten plus Normalisierungsgewichte. Das ist ein kleines Zugeständnis in Bytes und offenbar ein großes im Verhalten.

Das Zweite ist eine rotierte Gewichtsbasis. Gewichtsmatrizen werden nach einer blockweisen Walsh-Hadamard-Rotation bei Blockgröße 1.024 gespeichert, wobei die passende Transformation zur Laufzeit auf Aktivierungen angewendet wird, basierend auf der Theorie, dass das Verteilen von Ausreißern über Koordinaten eine dreistufige Approximation weniger verlustbehaftet macht. Es verursacht keinen zusätzlichen Speicherbedarf, da die Rotation in die Gewichte eingefaltet wird, aber es liegt im Berechnungspfad.

Dann gibt es da die Veränderung, die gar keine Technik ist: das Basismodell. Qwen3.8-27B ist ein Hybrid-Attention-Design – etwa 75 % lineare Attention, 25 % vollständige Attention – was auf seinen Vorgänger nicht zutraf. Die von Prism ML gemeldeten Kategorie-Scores zeigen, was dieser Wechsel gebracht hat. Instruction-Following steht bei 82,66 für Bonsai 2, gegenüber 74,53 für Qwen3.6-27B, das Basismodell, das die erste Generation komprimiert hat. Reasoning und Wissen liegen bei 83,95 gegenüber 84,71 beim älteren Basismodell, Coding bei 81,58 gegenüber 82,57. Das neue Basismodell ist beim Instruction-Following deutlich besser und bei zwei anderen Kategorien leicht im Rückstand, was genau die Art von Profil ist, die generationsübergreifende Retention-Prozentsätze für sich genommen unbrauchbar macht.

Warum die beiden Retention-Kennzahlen nicht vergleichbar sind

95 % und 98,2 % sehen aus wie zwei Messwerte auf einer Skala. Das sind sie nicht, und zwar aus drei Gründen, die man klar auseinanderhalten sollte, bevor man schlussfolgert, dass das Rezept um 3,2 Punkte besser geworden ist.

• Die Nenner sind unterschiedlich. Die 95 % der ersten Generation wurden auf einer Suite aus 15 Benchmarks gegen Qwen3.6-27B gemessen. Die 98,2 % der zweiten stammen aus einer Suite aus 20 Benchmarks gegen Qwen3.8-27B. Unterschiedliche Suites, unterschiedliche Baselines, unterschiedliche Schwierigkeitsmischungen.

• Die Baselines haben sich unabhängig voneinander verändert. Ein Teil des Zugewinns bei der Retention ist darauf zurückzuführen, dass das komprimierte Modell besser darin wird, zu komprimieren, und ein Teil darauf, dass sich das Basismodell auf Weisen ändert, die zufällig freundlicher für ternäre Gewichte sind. Keine veröffentlichte Arbeit trennt diese Beiträge.

• Retention ist relativ, daher kann sie steigen, während die absolute Leistungsfähigkeit in einer Kategorie sinkt. Ein Modell, das 99 % der Fähigkeiten eines schwächeren Vorgängermodells beibehält, kann dennoch hinter einem Modell zurückbleiben, das 96 % der Fähigkeiten eines stärkeren Vorgängermodells beibehält.

Der absolute Vergleich ist aussagekräftiger als der relative, und auf dieser Grundlage ist die Darstellung klarer. Bonsai 2 erzielt mit einem Gesamtwert von 83.9 mehr als die 83.6, die das vollpräzise Qwen3.6-27B in der älteren Suite erreichte — das heißt, der komprimierte Nachfolger liegt nun vor dem unkomprimierten Modell, das er eine Generation zuvor ersetzt hatte. Der Ternary-Build der ersten Generation erzielte in seiner eigenen Suite 80.5. Beide Werte stammen von Prism ML, und die Suiten unterscheiden sich, daher sollte man die Reihenfolge statt der Nachkommastellen lesen.

Die Variante, die nicht zurückkam

Dies ist der Teil des Vergleichs, der eher eine Kaufentscheidung als ein Benchmark-Diagramm verändert.

Es gibt kein 1-Bit-Bonsai 2. Die September-Version liefert einen ternären Build in zwei Packungen — PTQ1_0 mit 1,76 Bit pro Gewicht und 5,93 GB sowie PQ2_0 mit 2,16 Bit pro Gewicht und 7,25 GB — plus einen MLX-Container für Apple Silicon. Es gibt keine binäre 3,9-GB-Variante und keine Ankündigung einer solchen. Die 3,9-GB-Angabe der Smartphone-Klasse, die in der aktuellen Berichterstattung auftaucht, bezieht sich weiterhin auf das Juli-Modell.

Die praktische Konsequenz ist unmittelbar. Wenn Ihr Zielgerät ein iPhone oder iPad ist oder irgendein Gerät, auf dem ein 5,9 GB großes Sprachmodell plus ein 0,63 GB großer Vision-Tower plus ein Kontextbudget nicht hineinpassen, dann bleibt der 1-Bit-Build der ersten Generation die einzige Option in dieser Familie, und das wird so bleiben, bis es ein 1-Bit-Bonsai 2 gibt. Ein Upgrade des ternären Pfads ist kein Upgrade für diesen Pfad. Wer liest, dass „Bonsai 2 besser ist“, und erneut auf ein Smartphone herunterlädt, wird feststellen, dass die Datei nicht passt.

Wenn Sie einen Laptop oder Desktop verwenden, ist die Rechnung umgekehrt: Es gibt keinen Grund, den ternären Build vom Juli zu nutzen, wenn der vom September pro Qualitätseinheit kleiner ist, bei den Benchmarks, auf die es ankommt, besser abschneidet und denselben 262K-Kontext mitbringt.

Geschwindigkeit, bei der die Generationen wirklich schwer einzuordnen sind

Beim Durchsatz ist der ehrliche Teil dieses Vergleichs der, dass die veröffentlichten Zahlen keine eindeutige Rangfolge stützen, und das sollte man auch sagen, statt das schmeichelhafteste Paar herauszupicken.

Die standardisierten Messungen der zweiten Generation bei Batch-Größe 1 unter Ausschluss des Vision-Towers ergeben 142,5 tok/s Decode auf einer RTX 5090 beim PQ2_0-Packing, 46,8 tok/s auf einem Apple M5 Max, 27,7 auf einem M5 Pro und 18,0 auf einem M4 Pro. Die erste Generation gab für ihren ternären Build 134 tok/s auf einer RTX 5090 und 58 tok/s auf einem M5 Max an. Der 5090-Wert bewegt sich moderat in die erwartete Richtung. Der M5-Max-Wert bewegt sich in die andere Richtung – von 58 auf 46,8 –, was nicht so aussieht, wie ein zweimonatiger Generationsschritt aussehen sollte.

Zwei Vorbehalte verhindern, dass daraus ein Befund wird. Die Messgrundlagen unterscheiden sich zwischen den Releases, und mindestens ein veröffentlichter M5-Max-Wert für das neuere Modell wurde einem Build zugeschrieben, das vor der Rotationsoptimierung entstand. Es lohnt sich jedoch, dies als offene Frage zu kennzeichnen, denn der Mechanismus, der es erklären würde, steht in den Release Notes: Die rotierte Basis legt eine Transformation auf den kritischen Pfad jeder Projektion bei Batch-Größe 1, und Apple-Silicon-Decode ist der Bereich, in dem das am stärksten schadet. Die Technik, die Qualität erkauft, kann Decode-Durchsatz kosten, und auf Hardware mit Unified Memory ist dieser Trade-off am schärfsten.

Der MLX-Container fügt für Apple-Nutzer eine zusätzliche Besonderheit hinzu. Es ist ein affines 2-Bit-Format, dessen Block sowohl einen Skalierungsfaktor als auch einen Bias für jede Gruppe von 128 Gewichten speichert, aber ternäre Gewichte benötigen nur den Skalierungsfaktor, daher ist der Bias Ballast – der Block kostet 36 Bytes pro 128 Gewichte statt 34, und die gepackte Rate liegt bei 2,25 Bits pro Gewicht bei einer gemessenen Dateigröße von 8,005 GiB. Es ist ein anderer Container, der dieselben Werte trägt, und es ist das Paket, das das Demonstrations-Setup standardmäßig herunterlädt.

Ausführen einer der beiden Generationen

Beide Generationen teilen eine Betriebseinschränkung, der keine Version dieses Modells entkommen ist: Keine von beiden läuft auf Standard-llama.cpp. Die ternären Kernel für diese Architektur leben in Prism MLs eigenem Fork, Standard-llama.cpp weist die aktuellen Packings als unbekannt zurück, und – schlimmer noch – es lädt das ältere ternäre Format ohne Beanstandung und erzeugt flüssigen Unsinn, weil es die Rotation nicht anwendet, die die Gewichte voraussetzen. Der MLX-Build enthält Metal- und CPU-Kernel, aber keinen CUDA-Pfad. Welche Generation Sie auch wählen, die Frage nach der Laufzeitumgebung wird von Prism MLs eigener Distribution beantwortet oder von einer Laufzeitumgebung, die seine Kernel übernommen hat, nicht vom ggml-Ökosystem insgesamt.

Wo OrcaRouter in eine solche Entscheidung passt, ist eine Ebene höher. Keine der Bonsai-Generationen wird hier gehostet – es sind Downloads, die Sie auf Ihrer eigenen Hardware ausführen. Wofür die Routing-Schicht nützlich ist, ist die Grenze: die Anfragen, die Ihr lokales Modell nicht beantworten sollte. Definieren Sie die Eskalationsrichtlinie einmal in der Routing-Konfiguration statt im Anwendungscode, damit eine lokal bereitgestellte Stufe Anfragen mit langem Kontext, starkem Bildanteil oder anderweitig außerhalb des Zuständigkeitsbereichs an ein gehostetes Modell weiterreicht, anstatt sie fehlschlagen zu lassen, und damit der Fallback überlebt, welche Bonsai-Generation Sie auch immer installiert haben. Sowohl die lokale Stufe als auch die gehostete stehen dann hinter einem einzigen Schlüssel, und die Richtlinie bleibt an einer Stelle, wenn die nächste Bonsai-Generation erscheint und sich die Stufengrenzen erneut verschieben.

Was soll man damit machen?

• Wenn du den Juli-Ternary-Build auf einem Laptop oder Desktop ausführst — wechsle zu Ternary Bonsai 2 27B. Es ist ein besseres Modell bei ungefähr gleichem Platzbedarf, und die Kategoriebewertungen, in denen es gewinnt, sind genau die, die für agentische und instruktionsbefolgende Arbeit relevant sind.

• Wenn du den 1-Bit-Build vom Juli auf einem Smartphone laufen lässt — bleib dabei. Es gibt keinen Nachfolger, und der 5,93 GB große Ternär-Build ist kein direkter Ersatz für einen 3,9-GB-Build.

• Wenn Sie die Familie zum ersten Mal bewerten — entscheiden Sie zuerst über den Footprint, dann über die Generation. Die Variante, die Sie benötigen, bestimmt, in welchem Release Sie sich umsehen, und diese Reihenfolge ist die Umkehrung davon, wie dieses Upgrade üblicherweise beschrieben wird.

• Wenn Sie anhand von Benchmarks auswählen — behandeln Sie 95 % und 98,2 % als zwei verschiedene Messungen und nicht als zwei Punkte auf einer Linie, und behandeln Sie jede Zahl in beiden als Angabe des Anbieters selbst, bis eine unabhängige Evaluierung des September-Modells erscheint. Diese Evaluierung ist der Punkt, den man im Auge behalten sollte, denn sie ist die erste, die die beiden Generationen auf einer gemeinsamen Grundlage vergleichen kann.