Ternary Bonsai 2 27B vs Qwen3.8-27B: Wat 47,9 gigabyte aan precisie daadwerkelijk oplevert

Ternary Bonsai 2 27B en Qwen3.8-27B zijn hetzelfde model in twee numerieke werelden. Ze delen een architectuur, een tokenizer, een trainingsafkomst en een contextvenster van 262.144 tokens. Wat hen scheidt, is hoe de gewichten worden opgeschreven: Qwen3.8-27B slaat elk gewicht op als een 16-bits float en neemt 53,81 GB in beslag in zijn FP16-referentievorm, terwijl Ternary Bonsai 2 27B elk gewicht opslaat als een van drie symbolen en 5,93 GB in beslag neemt. Prism ML kondigde de gecomprimeerde build op 17 september 2026 aan en zette die op Hugging Face onder Apache 2.0; de originele Qwen3.8-27B-gewichten werden op 13 augustus 2026 gepubliceerd, eveneens onder Apache 2.0.

De vergelijking die ertoe doet, is niet welke beter is. Het is wat de ontbrekende 47,9 GB je kost, en het eerlijke antwoord is smaller en specifieker dan welk kamp dan ook je zal vertellen. Prism ML meldt dat zijn build 98,2% van het gemiddelde van het volledige-precisiemodel behoudt over een suite van 20 benchmarks — 83,9 tegenover 85,4. Dat cijfer is van de leverancier zelf, gemeten op de eigen testopstelling van de leverancier, en een dag na de release heeft niemand buiten Prism ML het gereproduceerd. Het geaggregeerde cijfer verbergt bovendien het deel waar je je echt zorgen over zou moeten maken, want de 1,8 punten zijn niet gelijkmatig verdeeld. Op de twee benchmarks die langdurige software-engineering op de proef stellen, is het verschil geen 1,8% — het ligt dichter bij 25%.

Hetzelfde netwerk, anders opgeschreven.

Begin met wat compressie niet aanraakt, want dat is de reden dat de vergelijking überhaupt interessant is. Het aantal lagen, de hidden size, het vocabulaire, het attentionpatroon en de visietoren zijn die van het basismodel. Qwen3.8-27B is een hybrid-attentionontwerp: 48 Gated DeltaNet linear-attentionlagen, afgewisseld met 16 full-attentionlagen, een ruwweg 3:1-verdeling, over 64 lagen met een hidden size van 5.120 en een vocabulaire van 248.320 tokens. Die grotendeels lineaire backbone is wat een 262K-context überhaupt betaalbaar maakt, en het is de eigenschap die Bonsai ongewijzigd erft.

Wat Prism ML heeft veranderd, is de representatie van de matrices van het taalmodel, plus de kernels die nodig zijn om erop te rekenen. In zijn whitepaper worden de 27,36 miljard parameters opgesplitst in 24,35 miljard in de taalbackbone verdeeld over 64 blokken, 2,54 miljard in de embedding en LM-head, en 0,47 miljard in een vision tower van 27 blokken. De vision tower wordt geleverd als een apart 4-bit mmproj-bestand van ongeveer 0,63 GB en wordt alleen geladen wanneer er daadwerkelijk een afbeelding binnenkomt, dus een implementatie met alleen tekst draait er nooit voor op.

Een praktisch gevolg van dat grotendeels lineaire ontwerp is het waard om te signaleren voordat er ook maar over benchmarks wordt gesproken. Omdat de architectuur geen conventionele transformer is, moesten de low-bit-kernels er specifiek voor worden geschreven. De standaardversie van llama.cpp verwerpt beide packings van Prism ML als onbekende typen — en, nog gevaarlijker, laadt een ouder ternair formaat zonder klagen en produceert vloeiende onzin, omdat er geen passende rotatie op de activaties wordt toegepast. Als je dit model uitvoert op een binary die er niets van weet, krijg je geen foutmelding. Je krijgt zelfverzekerde, onjuiste output.

De vergelijking, categorie per categorie

Hier is de uitsplitsing van de leverancier over 20 benchmarks, met de basis op volledige precisie als referentie. Elk cijfer in deze lijst is van Prism ML; niets ervan is onafhankelijk geverifieerd.

• Wiskunde — 96,57 voor Ternary Bonsai 2 27B tegenover 97,06 voor Qwen3.8-27B. Vrijwel gelijkwaardig.

• Coderen — 81,58 vs 82,17. Ook dicht bij elkaar, en de categorie waarop de hele techniek wordt betwist.

• Instructieopvolging — 82,66 vs 81,25. Het gecomprimeerde model loopt voorop op dit punt, wat de enige regel in de tabel is die echt verrassend is.

• Kennis en redeneren — 83,95 vs 86,66. Een daling van 2,7 punten, en de grootste enkele bijdrage aan de ontbrekende 1,8 punten.

• Agentisch en toolaanroepen — 77,57 vs 79,74, met τ2-Bench op 80,22 en BFCL v3 op 74,92.

• Vision — 78,59 vs 81,64, het grootste categorieverlies. Merk op dat de vision tower zelf niet het gecomprimeerde deel is; het taalmodel dat de output ervan leest, is dat wel.

Lees de vorm in plaats van het gemiddelde, en er verschijnt een duidelijker verhaal. Compressie kost bijna niets voor wiskunde, programmeren en het opvolgen van instructies, en is duur voor kennis en visie. Dat is het tegenovergestelde van de volkswijsheid over low-bitmodellen, die stelt dat oppervlakkige kennis blijft behouden en redeneren instort. Hier is het kennis die afbrokkelt en redeneren dat standhoudt.

Waar de 1,8 punten daadwerkelijk zitten

Het totaalcijfer is een gemiddelde over twintig benchmarks, en gemiddelden zijn waar verschillen zich schuilhouden. Haal de individuele resultaten eruit en twee ervan zijn veel slechter dan het gemiddelde doet vermoeden.

• Terminal-Bench 2.1 — 52,8 voor de ternaire build tegenover 69,7 voor volledige precisie

• SWE-bench Verified — 60,8 tegen 80,6

Beide komen in de buurt van driekwart van de score bij volledige precisie. Daar staat tegenover dat AIME26 op 95,83 uitkomt, LiveCodeBench op 90,07 en AA-LCR op 77,0 — binnen één punt van het ongecomprimeerde model. Dit is de eerste keer dat de Bonsai-familie überhaupt op Terminal-Bench wordt geëvalueerd, en Prism ML is in zijn eigen materialen expliciet dat het langetermijn-software-engineeringvermogen dat het in de eerste generatie beloofde, gedeeltelijk en niet volledig wordt geleverd.

Dus de praktische vraag is niet "behoudt het 98,2%" maar "wat is mijn werklast". Als je een codingagent draait die een plan over tientallen toolaanroepen heen vasthoudt en gedurende enkele minuten bestanden bewerkt, val je in de categorie met de kloof van 25%, en het geaggregeerde cijfer is ronduit misleidend. Als je wiskunde doet, codegeneratie in één beurt, extractie, classificatie of chat, val je in de categorieën waarin de kloof wegvalt. Het nuttigste aan de eigen tabel van de leverancier is dat je dat onderscheid kunt maken in plaats van te gokken.

Wat elk van hen daadwerkelijk nodig heeft om te draaien

Het hardwareverhaal is minder symmetrisch dan de grootteverhouding doet vermoeden. Een FP16-model van 53,81 GB past helemaal niet op een laptop van 16 GB, waardoor de vergelijking minder "sneller versus langzamer" en meer "mogelijk versus niet" is. De gestandaardiseerde metingen van Prism ML bij batchgrootte 1, visiontoren uitgesloten:

• NVIDIA RTX 5090 — 142,5 tok/s decodering op de PQ2_0-packing, bij 0,582 mWh per token

• Apple M5 Max — 46,8 tok/s bij het decoderen, met promptverwerking rond 765 tok/s

• Apple M5 Pro — 27,7 tok/s decoderen

• Apple M4 Pro — 18,0 tok/s decoderen, waarbij promptverwerking nabij 125 tok/s bij zeer lange contexten de beperkende factor wordt

Belangrijke voorbehoud is dat niets hiervan één enkele binary is. De PTQ1_0-packing levert 5,93 GB bij 1,76 bits per gewicht; PQ2_0 kost 7,25 GB bij 2,16 bits per gewicht en levert decodesnelheid op hardware waar instructiedoorvoer, niet geheugenbandbreedte, de beperkende factor is. De MLX-build voor Apple Silicon is een derde artefact met een eigen boekhouding — een affiene 2-bits container die een bias opslaat die de ternaire gewichten niet nodig hebben, uitkomend op 2,25 bits per gewicht en 8,005 GiB op schijf, met Metal- en CPU-kernels maar geen CUDA-pad. "Het draait in 5,9 GB" geldt voor precies één van die bestanden op precies de juiste runtime.

De kostenvergelijking, eerlijk gepresenteerd

Er zijn twee manieren om voor Qwen3.8-27B te betalen en slechts één manier om voor het gecomprimeerde broertje te betalen. Ternary Bonsai 2 27B is een download: Apache 2.0, jouw hardware, geen verbruiksmeter. Qwen3.8-27B is zowel een download als een gehoste service, en als je de gehoste route neemt, is het relevante cijfer dat op de modelpagina — $0,33 per miljoen inputtokens en $2,40 per miljoen outputtokens,aangeboden vanuit OrcaRouter's eigen infrastructuur in plaats van doorverkocht vanaf die van iemand anders.

Dat is waar OrcaRouter een plaats in deze vergelijking verdient in plaats van een voetnoot. De gerouteerde build van Qwen3.8-27B heeft dezelfde 262K-context, accepteert tekst, afbeeldingen en video, en biedt de reasoning-effort-regeling die het model standaard heeft. Het zit achter dezelfde sleutel als 200-plus andere modellen, zonder opslag bovenop de lijstprijs van de provider, wat meer uitmaakt dan het klinkt: omdat de lijstprijs wordt doorgegeven in plaats van doorverkocht, verschijnt een prijswijziging van een leverancier hier dezelfde dag in plaats van bij de volgende contractverlenging. Voor een team dat de full-precision-basis wil als escalatielaag boven een lokale Bonsai, is dat één endpoint en één sleutel in plaats van twee leveranciersrelaties.

Welke moet je pakken?

De beslissing gaat vooral over waar het werk gebeurt, niet over welk model beter is, want bij de meeste taken zijn het hetzelfde model.

• Kies Qwen3.8-27B in volledige precisie wanneer de taak een lange horizon heeft en agentisch is, wanneer je evalueert of fine-tunt, wanneer je de YaRN-context van 1M tokens nodig hebt, of wanneer visienauwkeurigheid van cruciaal belang is. De cijfers van Terminal-Bench en SWE-bench zijn de reden.

• Kies Ternary Bonsai 2 27B wanneer het werk moet gebeuren op hardware die je bezit, wanneer het alternatief is om helemaal geen 27B-model te draaien, of wanneer de werkbelasting wiskunde, coderen, extractie of redeneren zonder tools is, waar de categorieën gelijkwaardig zijn.

• Kies niet op basis van het geaggregeerde cijfer. 83,9 en 85,4 liggen dicht genoeg bij elkaar dat één enkele benchmarkwissel hun volgorde kan veranderen, en slechts één van de twee cijfers is onafhankelijk geverifieerd.

Wat hier echt nieuw is, is niet dat een 27B-model in zes gigabyte past — de eerste Bonsai-generatie deed dat in juli. Het is dat het volgen van instructies beter uitviel dan bij het moedermodel en dat wiskunde en coderen op hetzelfde niveau uitkwamen, wat een andere bewering is dan 'klein voor zijn formaat'. Of het standhoudt op jouw workload is precies wat een leeftijd van één dag je niet kan vertellen, en de eerste onafhankelijke evaluatie van dit model is het resultaat dat het wachten waard is.

Als je de vergelijking op je eigen prompts wilt uitvoeren in plaats van op een benchmarksuite, is het snelste pad de gehoste Qwen3.8-27B via één endpoint aan te roepen en de ternaire build lokaal te draaien, en dan de outputs te diffen op de taken die je daadwerkelijk hebt. Dat is werk van een ochtend en het zal je meer over de 1,8 punten vertellen dan welke gepubliceerde tabel dan ook.