Ternary Bonsai 2 27B vs Bonsai 27B: Twee maanden, twee basismodellen, één ontbrekende variant

Ternary Bonsai 2 27B verscheen op 17 september 2026, twee maanden nadat Bonsai 27B op 14 juli 2026 uitkwam, en de opvallendste vergelijking tussen beide is een enkel paar getallen: de eerste generatie behield ongeveer 95% van het benchmarkgemiddelde van zijn basismodel met volledige precisie, en de tweede behoudt 98,2%. Dat leest als een rechttoe rechtaan generatieverbetering, en dat is het grotendeels ook — maar de twee cijfers meten niet hetzelfde, omdat het basismodel eronder veranderde. De release van juli comprimeerde Qwen3.6-27B. De release van september comprimeert Qwen3.8-27B. Een deel van de kwaliteitswinst is toe te schrijven aan het compressierecept en een deel ervan aan het nieuwere Qwen3.8-27B, en geen enkel gepubliceerd cijfer maakt onderscheid tussen beide.

Er is een tweede verschil tussen de generaties dat veel minder aandacht heeft gekregen en voor een specifieke groep gebruikers belangrijker is: de eerste Bonsai kwam in twee varianten uit en de tweede in slechts één. De 3,9 GB-build die een model uit de 27B-klasse op een iPhone 17 Pro liet passen, heeft geen opvolger in deze release. Als die omvang de reden was dat je überhaupt in Bonsai geïnteresseerd was, dan is de nieuwere generatie geen upgrade — het is een ander product dat jouw situatie niet dekt.

Wat de eerste generatie daadwerkelijk uitbracht

Bonsai 27B werd op 14 juli 2026 uitgebracht onder Apache 2.0 als twee artefacten die op hetzelfde basismodel zijn gebouwd, en juist de splitsing tussen beide was het punt van de release.

• Ternary Bonsai 27B — ternaire {−1, 0, +1}-gewichten met FP16 groepsgewijze scaling, 1,71 effectieve bits per gewicht, een voetafdruk van 5,9 GB. De kwaliteitsgerichte build, gepositioneerd voor een alledaagse laptop met volledige redeneer-, tool-calling- en agentische capaciteiten.

• 1-bit Bonsai 27B — binaire {−1, +1}-gewichten met dezelfde groepsgewijze schaling, 1,125 effectieve bits per gewicht, een geheugenvoetafdruk van 3,9 GB. De op geheugenvoetafdruk gerichte build, gedimensioneerd om binnen het geheugenbudget van een iPhone 17 Pro te passen.

Beide hadden een context van 262K tokens, beide behielden een compacte 4-bit visiontoren zodat het model multimodaal bleef, en beide ondersteunden speculatieve decoding met een DSpark-drafter. De framing van Prism ML was destijds dat de low-bit-representatie end-to-end draaide — embeddings, attention, MLP's en de LM-head — zonder uitwijkmogelijkheden naar hogere precisie, en dat de 1-bit-build het eerste model uit de 27B-klasse was dat überhaupt op een telefoon draaide. De gerapporteerde doorvoer op de 1-bit-variant was ongeveer 11 tokens per seconde op een iPhone 17 Pro, 87 tok/s op een Apple M5 Max en 163 tok/s op een RTX 5090; voor de ternaire variant werd 58 tok/s op de M5 Max en 134 tok/s op de 5090 opgegeven.

Het kwaliteitsverlies werd samen met die cijfers vermeld in plaats van weggemoffeld. Op een suite van 15 benchmarks in denkmodus scoorde het full-precision-basismodel 85,0, de ternaire build 80,5 — ongeveer 95% — en de 1-bit-build 76,1, ongeveer 90%. De achteruitgang was geconcentreerd in agentische toolaanroepen, die op de 1-bit-build van 80,0 naar 66,0 daalden, en in visuele taken, die van 72,6 naar 59,6 daalden. Wiskunde en programmeren hielden zich in beide varianten aanzienlijk beter staande.

Wat de tweede generatie veranderde

Ternary Bonsai 2 27B behoudt het recept en verandert de invoer. De ternaire representatie is nog steeds {−1, 0, +1} met één FP16-schaal per groep van 128 gewichten, nu verpakt tot 1,76 bits per gewicht in een bestand van 5,93 GB, met 262K context en dezelfde aparte vision tower — 0,63 GB op 4-bit in deze release, alleen geladen wanneer er een afbeelding binnenkomt.

Twee dingen zijn echt nieuw, en beide worden genoemd als de reden dat het retentiecijfer verschoof.

Het eerste is selectieve precisie. Anders dan de juli-build, die vrijwel alles ternariseerde, houdt Bonsai 2 26.238.464 parameters in volledige precisie vast — 0,0976% van het taalmodel, ongeveer 52 MB bij bf16, geconcentreerd in het recurrente toestandspad van de linear-attention-lagen plus normalisatiegewichten. Dat is een kleine concessie in bytes en blijkbaar een grote in gedrag.

De tweede is een geroteerde gewichtenbasis. Gewichtsmatrices worden opgeslagen na een bloksgewijze Walsh–Hadamard-rotatie met blokgrootte 1.024, waarbij de overeenkomstige transformatie tijdens runtime op activaties wordt toegepast, op grond van de theorie dat het verspreiden van uitbijters over coördinaten een drie-niveau-benadering minder verliesgevend maakt. Het kost geen extra opslag omdat de rotatie in de gewichten is verwerkt, maar het zit wel op het computationele pad.

Dan is er de verandering die helemaal geen techniek is: het basismodel. Qwen3.8-27B is een ontwerp met hybride attention — ongeveer 75% lineaire attention, 25% volledige attention — terwijl zijn voorganger dat niet was. De door Prism ML gerapporteerde categoriescores laten zien wat die zet opleverde. Instructieopvolging staat op 82,66 voor Bonsai 2, tegenover 74,53 voor Qwen3.6-27B, het basismodel dat de eerste generatie comprimeerde. Redeneren en kennis komen uit op 83,95 tegen 84,71 voor het oudere basismodel, en coderen op 81,58 tegen 82,57. Het nieuwe basismodel is met een ruime marge beter in instructieopvolging en iets zwakker op twee andere categorieën, wat precies het soort profiel is dat retentiepercentages tussen generaties op zichzelf onbruikbaar maakt.

Waarom de twee retentiecijfers niet vergelijkbaar zijn

95% en 98,2% lijken twee aflezingen op één schaal. Dat zijn ze niet, om drie redenen die het waard zijn om uit elkaar te houden voordat je concludeert dat het recept met 3,2 punten is verbeterd.

• De noemers verschillen. De 95% van de eerste generatie werd gemeten op een suite van 15 benchmarks tegen Qwen3.6-27B. De 98,2% van de tweede komt uit een suite van 20 benchmarks tegen Qwen3.8-27B. Verschillende suites, verschillende baselines, verschillende moeilijkheidsmixen.

• De baselines bewogen onafhankelijk. Een deel van de winst in retentie komt doordat het gecomprimeerde model beter wordt in comprimeren, en een deel doordat het basismodel verandert op manieren die toevallig vriendelijker zijn voor ternaire gewichten. Geen enkele publicatie maakt onderscheid tussen die bijdragen.

• Retentie is relatief, dus die kan stijgen terwijl de absolute capaciteit in een categorie daalt. Een model dat 99% van een zwakkere voorganger behoudt, kan nog steeds achterblijven bij een model dat 96% van een sterkere behoudt.

De absolute vergelijking is informatiever dan de relatieve, en op die basis is het verhaal helderder. De geaggregeerde score van 83,9 voor Bonsai 2 ligt boven de 83,6 die Qwen3.6-27B in volledige precisie scoorde op de oudere suite — wat betekent dat de gecomprimeerde opvolger nu voorloopt op het ongecomprimeerde model dat hij een generatie eerder verving. De ternaire build van de eerste generatie scoorde 80,5 op zijn eigen suite. Beide cijfers zijn afkomstig van Prism ML, en de suites verschillen, dus kijk naar de volgorde, niet naar de decimalen.

De variant die niet terugkwam

Dit is het deel van de vergelijking dat een aankoopbeslissing verandert in plaats van een benchmarkgrafiek.

Er is geen 1-bit Bonsai 2. De septemberrelease levert een ternaire build, in twee verpakkingen — PTQ1_0 met 1,76 bits per gewicht en 5,93 GB, en PQ2_0 met 2,16 bits per gewicht en 7,25 GB — plus een MLX-container voor Apple Silicon. Er is geen binaire variant van 3,9 GB, en geen aankondiging daarvan. Het cijfer van 3,9 GB voor telefoonklasse dat in de huidige berichtgeving opduikt, verwijst nog steeds naar het julimodel.

De praktische consequentie is direct. Als je doel een iPhone of iPad is, of een apparaat waar een taalmodel van 5,9 GB plus een vision tower van 0,63 GB plus een contextbudget niet past, dan blijft de 1-bit-build van de eerste generatie de enige optie in deze familie, en dat blijft zo totdat er een 1-bit Bonsai 2 bestaat. Het upgraden van het ternaire pad upgradet dat pad niet. Iedereen die 'Bonsai 2 is beter' leest en opnieuw op een telefoon downloadt, zal merken dat het bestand niet past.

Als je op een laptop of desktop werkt, is de afweging precies omgekeerd: er is geen enkele reden om de ternaire build van juli te draaien, aangezien die van september kleiner is per eenheid kwaliteit, beter presteert op de benchmarks die ertoe doen en dezelfde 262K-context biedt.

Snelheid, waar de generaties echt moeilijk te rangschikken zijn

Doorvoer is het deel van deze vergelijking waar het eerlijke antwoord is dat de gepubliceerde cijfers geen eenduidige rangorde ondersteunen, en het is de moeite waard om dat te zeggen in plaats van het flatteuze paar te kiezen.

De gestandaardiseerde metingen van de tweede generatie bij batchgrootte 1, met de vision tower buiten beschouwing gelaten, zijn 142,5 tok/s decode op een RTX 5090 bij de PQ2_0-packing, 46,8 tok/s op een Apple M5 Max, 27,7 op een M5 Pro en 18,0 op een M4 Pro. De eerste generatie vermeldde 134 tok/s op een RTX 5090 en 58 tok/s op een M5 Max voor zijn ternaire build. Het cijfer voor de 5090 beweegt zich bescheiden in de verwachte richting. Het cijfer voor de M5 Max beweegt de andere kant op — van 58 naar 46,8 — en dat is niet hoe een generatiesprong van twee maanden eruit hoort te zien.

Twee kanttekeningen verhinderen dat dit een bevinding is. De meetgrondslagen verschillen tussen releases, en minstens één gepubliceerde M5 Max-waarde voor het nieuwere model is toegeschreven aan een build van vóór de rotatie-optimalisatie. Maar het is de moeite waard om dit als openstaande vraag aan te kaarten, want het mechanisme dat het zou verklaren, staat in de release notes: de geroteerde basis zet een transformatie op het kritieke pad van elke projectie bij batchgrootte 1, en Apple Silicon-decodering is het regime waar dat het meest pijn doet. De techniek die kwaliteit oplevert, kan ten koste gaan van decode-throughput, en op hardware met unified memory is die afweging het scherpst.

De MLX-container voegt een aparte complicatie toe voor Apple-gebruikers. Het is een affien 2-bitsformaat waarvan het blok voor elke groep van 128 gewichten zowel een schaal als een bias opslaat, maar ternaire gewichten hebben alleen de schaal nodig, dus de bias is overbodige ballast — het blok kost 36 bytes per 128 gewichten in plaats van 34, en de verpakkingsdichtheid komt uit op 2,25 bits per gewicht met een gemeten bestandsgrootte van 8,005 GiB. Het is een andere container die dezelfde waarden bevat, en het is het pakket dat de demonstratieopstelling standaard downloadt.

Het uitvoeren van een van beide generaties

Beide generaties delen één operationele beperking waaraan geen enkele versie van dit model is ontsnapt: geen van beide draait op standaard llama.cpp. De ternaire kernels voor deze architectuur leven in Prism ML's eigen fork, standaard llama.cpp verwerpt de huidige packings als onbekend, en — erger nog — het laadt het oudere ternaire formaat zonder klagen en produceert vloeiende onzin, omdat het de rotatie die de gewichten veronderstellen niet toepast. De MLX-build bevat Metal- en CPU-kernels maar geen CUDA-pad. Welke generatie je ook kiest, de runtime-vraag wordt beantwoord door Prism ML's eigen distributie of door een runtime die zijn kernels heeft overgenomen, niet door het ggml-ecosysteem in het algemeen.

Waar OrcaRouter in een beslissing als deze past, is één niveau hoger. Geen van beide Bonsai-generaties wordt hier gehost — het zijn downloads die je op je eigen hardware draait. Waar de routeringslaag nuttig voor is, is de grens: de verzoeken die je lokale model niet zou moeten beantwoorden. Definieer het escalatiebeleid één keer in de routeringsconfiguratie in plaats van in applicatiecode, zodat een lokaal aangeboden tier verzoeken met een lange context, veel beeldmateriaal of anderszins buiten het bereik doorgeeft aan een gehost model in plaats van ze te laten mislukken, en zodat de fallback blijft werken ongeacht welke generatie Bonsai je toevallig hebt geïnstalleerd. Zowel de lokale tier als de gehoste zitten dan achter één sleutel, en het beleid staat op één plek wanneer de volgende generatie Bonsai verschijnt en de grenzen van de tiers opnieuw verschuiven.

Wat te doen met dit

• Als je de ternaire build van juli op een laptop of desktop draait — stap dan over naar Ternary Bonsai 2 27B. Het is een beter model met ongeveer dezelfde voetafdruk, en de categoriescores waarin het wint, zijn precies de scores die ertoe doen voor agentisch en instructievolgend werk.

• Als je de 1-bit-build van juli op een telefoon draait — blijf erbij. Er is geen opvolger, en de ternaire build van 5,93 GB is geen directe vervanging voor een van 3,9 GB.

• Als je de familie voor het eerst beoordeelt — bepaal eerst de voetafdruk, dan de generatie. De variant die je nodig hebt, bepaalt in welke release je moet zijn, en die volgorde is omgekeerd aan hoe deze upgrade gewoonlijk wordt beschreven.

• Als je op basis van benchmarks kiest — beschouw 95% en 98,2% dan als twee verschillende metingen in plaats van als twee punten op een lijn, en beschouw elk cijfer in beide als afkomstig van de leverancier zelf totdat er een onafhankelijke evaluatie van het septembermodel verschijnt. Die evaluatie is het punt om in de gaten te houden, want het is de eerste die de twee generaties op een gemeenschappelijke basis zal kunnen vergelijken.