Ternary Bonsai 2 27B gegen Qwen3.8-27B IQ2_XXS GGUF: Weniger Bits, bessere Ergebnisse

Ternary Bonsai 2 27B ist kleiner als der IQ2_XXS-GGUF-Build von Qwen3.8-27B und, gemessen an den dazu veröffentlichten Zahlen, auch besser – was nicht möglich sein sollte, wenn alles, was sie trennte, ein Bit-Budget wäre. Der Bonsai-Build weist 1,76 Bit pro Gewicht in einer 5,93 GB großen Datei auf. Die konventionelle 2-Bit-Quantisierung desselben Basismodells weist etwa 2,2 Bit pro Gewicht in einer Datei von rund 7,3 GB auf. Prism ML, das den ternären Build am 17. September 2026 angekündigt hat, meldet einen Durchschnitt über 20 Benchmarks von 83,9 für sein Modell gegenüber 75,2 für den IQ2_XXS-Vergleichspunkt – eine Lücke von 8,7 Punkten zugunsten des Modells, das weniger Bits verwendet.

Diese Umkehrung ist die ganze Geschichte, und sie ist kein Trick. Die beiden Dateien entstehen durch unterschiedliche Prozesse in unterschiedlichen Phasen der Lebensdauer des Modells, und der Unterschied zwischen diesen Prozessen wiegt mehr als der Unterschied in der Bitbreite. Es ist außerdem der Vergleich, bei dem der gängige Ratschlag – „nimm einfach eine 2-Bit-Quantisierung, die sind mittlerweile gut“ – auf sein klarstes Gegenbeispiel trifft und bei dem hinter dem Gegenbeispiel eine unabhängige Messung steht statt des Wortes eines Anbieters.

Das Paradox ist der Mechanismus.

IQ2_XXS ist ein Post-Training-Quantisierungsformat. Das Modell wird in voller Präzision bis zur Konvergenz trainiert und anschließend werden seine Gewichte in eine niedrigbitige Darstellung gerundet, die durch ein Anpassungsverfahren gewählt wird. Das Modell erhält nie die Chance, sich anzupassen; es wird im Nachhinein vermessen und angenähert. Die i-quant-Familie verbessert ältere k-quants durch die Verwendung einer Wichtigkeitsmatrix – ein Kalibrierungsdurchlauf, der entscheidet, welche Gewichte mehr von der verfügbaren Präzision verdienen –, aber die grundlegende Reihenfolge der Operationen bleibt unverändert. Trainieren, dann komprimieren.

Bonsai kehrt diese Reihenfolge um. Prism MLs Beschreibung seiner eigenen Methode besagt, dass diese die Post-Training-Quantisierung vollständig aufgab und die ternäre Beschränkung während des Trainings durchsetzte: Der Forward-Pass rechnet mit Gewichten, die auf {−1, 0, +1} beschränkt sind, während der Backward-Pass weiterhin Gradienten in voller Präzision führt. Das Modell verbringt sein Training damit, Repräsentationen zu lernen, die die Beschränkung überleben, statt dass die Beschränkung Repräsentationen auferlegt wird, die sie nie erwartet haben. Der Algorithmus wird als proprietäres geistiges Eigentum beschrieben, aber seine Gestalt wird jedem bekannt vorkommen, der die BitNet-Arbeiten gelesen hat.

Zwei Verfeinerungen sitzen obendrauf, und beide sind in der Arithmetik sichtbar. Die erste ist selektive Präzision: 26,2 Millionen Parameter – etwa 0,098 % des Modells, rund 52 MB bei bf16, hauptsächlich der Pfad des rekurrenten Zustands der Linear-Attention-Schichten plus Normalisierungsgewichte – werden in voller Präzision gehalten statt ternarisiert. Die zweite ist eine blockweise Rotation. Jede Gewichtsmatrix wird durch eine Walsh-Hadamard-Rotation bei Blockgröße 1.024 transformiert, bevor die ternären Werte gewählt werden, was Ausreißer über die Koordinaten verteilt und eine dreistufige Approximation weniger destruktiv macht. Die Rotation wird in die gespeicherten Gewichte eingefaltet, sodass sie keine zusätzlichen Bytes kostet; die entsprechende Transformation wird stattdessen zur Laufzeit auf Aktivierungen angewendet.

Dieses letzte Detail hat eine Konsequenz, auf die man schon beim ersten Versuch stößt, die Sache laufen zu lassen, und das ist der eigentliche Preis des Ansatzes.

Welches IQ2_XXS du meinst und was es tatsächlich für Werte erzielt

Bevor man die Qualität vergleicht, eine Korrektur, die die meisten Darstellungen auslassen: „IQ2_XXS“ ist nicht ein einzelnes Artefakt. Es ist ein Quantisierungstyp von llama.cpp, und derselbe Typ, von verschiedenen Toolchains auf dasselbe Basismodell angewendet, erzeugt Dateien, die sich in der Größe deutlich und in der Qualität erheblich unterscheiden.

Der klarste öffentliche Beleg ist ein unabhängiger Vergleich, der am 15. August 2026 von einem Nutzer veröffentlicht wurde, der untersuchte, ob es sich überhaupt lohnte, ein Sub-2-Bit-Qwen3.8-27B zu bauen. Der Test ist eine wikitext-2-KL-Divergenzmessung, 100 Chunks bei 512 Kontext, gegen eine lokal erstellte Q8_0-Referenz mit einer Perplexität von 6.7500, wobei jeder Kandidat dieselbe Importance-Matrix, dasselbe Korpus, dieselbe Baseline und denselben llama.cpp-Build in einem Durchgang verwendete. Die Ergebnisse:

• unsloth UD-IQ2_XXS — 8,39 GiB, Perplexität 7,6528, mittlere KLD 0,146, Median-KLD 0,076, Top-1-Übereinstimmung 82,98 %

• bartowski IQ2_XXS — 8,75 GiB, Perplexität 8,5352, mittlere KLD 0,301, Median-KLD 0,162, Top-1-Übereinstimmung 76,53%

Die dynamische Variante ist 0,36 GiB kleiner als die statische und beim mittleren KLD etwa 2,1-mal besser — bei 1,13-facher Baseline-Perplexität. Zwei Dateien mit derselben Bezeichnung, getrennt durch einen Faktor zwei bei der Metrik, die misst, wie weit die Ausgabeverteilung abgedriftet ist. Derselbe Test ergab, dass jeder Kandidat unter 2 Bit schlechter war als beide veröffentlichten IQ2-Optionen, weshalb die praktische Untergrenze für dieses Basismodell bei IQ2 statt darunter liegt.

Das ist für den Vergleich wichtig, denn es ändert, worauf sich „der 7,3-GB-IQ2_XXS-Build“ bezieht. Die Zahl von Prism ML stammt aus der eigenen Quantisierung des Basismodells mit 2,2 Bit pro Gewicht. Ein dynamischer Build von unsloth aus derselben Familie hat eine Größe von 8,39 GiB. Ein Build von bartowski hat eine Größe von 8,75 GiB. Die Größenlücke zwischen Bonsai und „IQ2_XXS“ liegt daher irgendwo zwischen 1,4x und 1,5x, je nachdem, welchen Build man meint — größer als der Faktor 1,23, den die Schlagzeile nahelegt, und das alles, bevor der Qualitätsvergleich beginnt.

Wo der Post-Training-Build bricht und warum er leicht zu übersehen ist

Die aggregierte Lücke von 8,7 Punkten ist die am wenigsten aussagekräftige Art, den Unterschied zu benennen, weil die Verschlechterung im IQ2_XXS-Build nicht gleichmäßig ist. Sie ist selektiv, und das Muster ist das Gegenteil dessen, was die meisten erwarten würden.

• MMLU-Redux — der Post-Training-Build schlägt sich respektabel, im mittleren bis hohen 80er-Bereich

• GPQA Diamond — rund 65,5 gegenüber 85,76 für den ternären Build

• AIME26 — im Bereich von 57,5 bis 78,6 je nach Build, gegenüber 95,83 für den ternären Build

• LiveCodeBench — im Bereich von 56,4 bis 70,05, gegenüber 90,07 für den ternären Build

Die genauen IQ2-Werte schwanken zwischen den Test-Suiten von Prism ML und den Messungen aus der Community, und die obigen Bereiche umfassen beides, doch die Form ist über jede Quelle hinweg konsistent: Oberflächenwissen bleibt erhalten, und alles, was eine längere Argumentationskette erfordert, verschlechtert sich stark. Genau das ist der Fehlermodus, den ein beiläufiger Test nicht findet. Bittet man einen 2-Bit-Build, ein Dokument zusammenzufassen oder eine Faktenfrage zu beantworten, verhält er sich wie ein viel größeres Modell. Bittet man ihn, eine mehrstufige Herleitung durchzuhalten oder nicht trivialen Code zu erzeugen, ist der Zusammenbruch plötzlich statt allmählich. Deshalb ist „es fühlte sich gut an, als ich es ausprobiert habe“ kein Beleg über ein quantisiertes Modell – es ist ein Beleg über die Prompts, die du zufällig ausprobiert hast.

Der Ternär-Build weist diesen Kollaps bei denselben Benchmarks nicht auf. Prism ML meldet AIME26 mit 95,83 gegenüber 94,58 für seine Full-Precision-Basis und LiveCodeBench mit 90,07 gegenüber 90,05 – praktisch gleichauf und die mit Abstand nützlichste Aussage in der Veröffentlichung, weil sie besagt, dass der Trainingszeit-Constraint genau das erkauft hat, was der Post-Training-Constraint verliert.

Das Gegenargument, das real ist und das die Qualitätstabelle nicht erfasst

Alles oben Genannte spricht bei der Qualität pro Byte für den ternären Build. Es gibt jedoch eine Dimension, in der das herkömmliche GGUF eindeutig gewinnt, und das ist keine unbedeutende: Es läuft auf der Software, die Sie bereits haben.

Der IQ2_XXS-Build von Qwen3.8-27B ist ein Standard-Artefakt von llama.cpp. Er lädt in llama.cpp, Ollama, LM Studio, Jan und allem anderen, das ggml einbindet, auf jeder von ggml unterstützten Plattform – ganz ohne Fork und ohne spezielle Kernel. Seine Importance-Matrix kann neu erstellt oder ersetzt werden. Er verhält sich wie jedes andere quantisierte Modell, das Sie auf der Festplatte haben.

Bei Ternary Bonsai 2 27B ist das nicht der Fall. Die ternären Kernel für die hybride Attention dieser Architektur befinden sich in Prism MLs eigenem llama.cpp-Fork. Das unveränderte llama.cpp lehnt PTQ1_0 und PQ2_0 als unbekannte Typen ab – und hat keine Ahnung, was mit der rotierten Basis anzufangen ist, die diese Packs voraussetzen. Der MLX-Build für Apple Silicon hat Metal- und CPU-Kernel, aber keinen CUDA-Pfad, also fällt er auf einer NVIDIA-Maschine auf einen CPU-Forward-Pass zurück, der Minuten dauern kann. Prism ML listet zwar Integrationen mit mehreren Runtimes auf, doch der eigentliche Punkt bleibt: Die Nutzbarkeit dieses Modells ist dadurch begrenzt, ob die Runtime Ihrer Wahl über es Bescheid weiß.

Das ist der ehrliche Kompromiss. Du wählst zwischen einem Build, der 1,4-mal größer, messbar schlechter bei genau den Aufgaben ist, für die du höchstwahrscheinlich ein 27B-Modell willst, und universell lauffähig ist — und einem Build, der kleiner und besser ist, auf einem Ökosystem, das derzeit aus dem Fork eines Labors plus den Laufzeitumgebungen besteht, die ihn übernommen haben.

Was nötig ist, um eines von beiden zu betreiben

Die Speicherrechnung fällt enger aus, als die Dateigrößen vermuten lassen, denn die Dateien sind nicht das Einzige im VRAM.

• IQ2_XXS-Build — 8,39 bis 8,75 GiB an Gewichten, wodurch auf einer 16-GB-Karte etwa 7,5 GB für Kontext und Draft-Modelle frei bleiben. Der obige unabhängige Test stellt ausdrücklich fest, dass ein 8,39-GiB-Build daneben bereits ein 2,1-GB-Draft-Modell aufnehmen kann.

• Ternary Bonsai 2 27B — 5,93 GB für das PTQ1_0-Sprachmodell, plus der 0,63 GB große Vision-Tower, falls Sie überhaupt Bilder verwenden, plus Kontext. Das PQ2_0-Packing von Prism ML kostet 7,25 GB und ist die schnellere Option auf Hardware, die durch Instruktionsdurchsatz statt Bandbreite begrenzt ist.

Geschwindigkeit: Die gemeldeten ternären Werte liegen bei 142,5 tok/s beim Decode auf einer RTX 5090 und 46,8 tok/s auf einem Apple M5 Max; die Berichterstattung Dritter zum IQ2-Build ist dünner, mit einer Vulkan-Messung auf zwei Radeon-Karten von etwa 3,8 tok/s bei der Generierung, wobei diese Zahl mehr über dieses spezifische Backend als über die Quantisierung aussagt. Betrachten Sie Durchsatzwerte auf beiden Seiten als stark hardwareabhängig.

Wo OrcaRouter passt – und wo nicht

Keine dieser Dateien ist etwas, das ein Router ausliefert. Es sind lokale Artefakte, und die ehrliche Einordnung ist, dass OrcaRouter keine von beiden hostet – dies ist ein Vergleich darüber, was auf Ihrer eigenen Hardware läuft. Was auf unserer Seite liegt, ist das Modell, von dem beide abgeleitet wurden. Qwen3.8-27B in voller Präzision ist über OrcaRouters eigene Infrastruktur verfügbar für $0,33 pro Million Eingabe-Tokens und $2,40 pro Million Ausgabe-Tokens, mit dem nativen 262K-Kontext des Modells und seiner intakten Steuerung des Reasoning-Aufwands (niedrig/mittel/hoch).

Das ergibt ein hybrides Setup, bei dem es sich lohnt, konkret zu werden. Führen Sie den komprimierten Build lokal für die Aufgaben aus, für die er gut geeignet ist, und leiten Sie die gelegentliche Anfrage, die vollständige Präzision erfordert, über denselben Schlüssel an das gehostete Basismodell weiter – kein zweiter Anbietervertrag, keine Codeänderung, da beide Seiten dieselbe API sprechen. Wenn sich der lokale Build für eine Arbeitslast als ungeeignet erweist, kann die fehlschlagende Anfrage automatisch ein Failover durchlaufen statt als Fehler zurückgegeben zu werden, was eine kostengünstigere Möglichkeit ist, festzustellen, dass eine Quantisierung ungeeignet ist, als sie in der Produktion zu entdecken.

Die Kurzfassung

• Bezogen auf die veröffentlichte Qualität pro Byte gewinnt der ternäre Build klar, und dieser Vorsprung konzentriert sich auf Reasoning und Code – die Kategorien, in denen der Post-Training-Build am stärksten an Qualität verliert.

• Was die Portabilität angeht, gewinnt der IQ2_XXS-Build ebenso deutlich. Überall Standard-Runtimes, kein Fork, keine speziellen Kernel, kein stiller Fehlermodus mit Müllausgabe.

• Der Vergleich lautet nicht „1,76 Bit gegenüber 2,2 Bit“. Es ist „eine während des Trainings gewählte Repräsentation gegenüber einer nachträglich angepassten“, und der Unterschied von 0,44 Bit ist daneben ein Rundungsfehler.

• Jede Qualitätskennzahl für den Ternär-Build in diesem Artikel ist Prism MLs eigene Messung auf einer von Prism ML gewählten Test-Suite. Die KLD-Ergebnisse für die IQ2-Builds sind unabhängig, basieren auf einem einzelnen Durchlauf und beziehen sich speziell auf ein Basismodell und einen Testsatz; sie sind die stärksten Drittanbieter-Belege in diesem Vergleich und sagen nichts über Bonsai aus.

Die Lücke wird sich auch von der anderen Seite schließen, und wahrscheinlich bald. Wenn die ternären Kernel upstream in llama.cpp landen, verflüchtigt sich der eine ernsthafte Einwand gegen Bonsai, und die Wahl wird einfach. Bis dahin behält der IQ2_XXS-Build einen echten Vorteil, der nichts damit zu tun hat, wie gut er ist.

Wenn Sie sich diese Woche entscheiden, dauert der Test, der die Sache endgültig klärt, einen Nachmittag: Nehmen Sie zwanzig Prompts aus Ihrem eigenen Arbeitspensum, die mehr als einen Denkschritt erfordern, führen Sie beide Builds aus und bewerten Sie die Antworten blind. Die veröffentlichten Tabellen sagen Ihnen, wo Sie nachsehen müssen. Sie können Ihnen nicht sagen, ob Ihre Arbeit dort angesiedelt ist.