Ternary Bonsai 2 27B vs Bonsai 27B: Två månader, två basmodeller, en saknad variant

Ternary Bonsai 2 27B anlände den 17 september 2026, två månader efter att Bonsai 27B landade den 14 juli 2026, och huvudjämförelsen mellan dem är ett enda par siffror: den första generationen behöll omkring 95 % av det genomsnittliga benchmarkresultatet för sin fullprecisionsbasmodell, och den andra behåller 98,2 %. Det låter som en enkel generationsförbättring, och det är det till största delen – men de två siffrorna mäter inte samma sak, eftersom basmodellen förändrades under dem. Juliversionen komprimerade Qwen3.6-27B. Septemberversionen komprimerar Qwen3.8-27B. En del av kvalitetsvinsten tillhör komprimeringsreceptet och en del tillhör den nyare Qwen3.8-27B, och ingen publicerad siffra skiljer de två åt.

Det finns en andra skillnad mellan generationerna som har fått betydligt mindre uppmärksamhet och spelar större roll för en specifik grupp användare: den första Bonsai släpptes i två varianter och den andra släpps i en. 3,9 GB-bygget som fick en modell i 27B-klass att rymmas på en iPhone 17 Pro har ingen efterföljare i den här utgåvan. Om det utrymmesavtrycket är anledningen till att du överhuvudtaget var intresserad av Bonsai, är den nyare generationen inte en uppgradering — den är en annan produkt som inte täcker ditt fall.

Vad den första generationen faktiskt levererade

Bonsai 27B släpptes den 14 juli 2026 under Apache 2.0 som två artefakter byggda på samma basmodell, och uppdelningen mellan dem var själva poängen med lanseringen.

• Ternary Bonsai 27B — ternära vikter {−1, 0, +1} med FP16-gruppvis skalning, 1,71 effektiva bitar per vikt, ett minnesavtryck på 5,9 GB. Den kvalitetsinriktade versionen, positionerad för en vardagslaptop med full resonemangsförmåga, verktygsanrop och agentisk kapacitet.

• 1-bit Bonsai 27B — binära vikter {−1, +1} med samma gruppvisa skalning, 1,125 effektiva bitar per vikt, ett minnesavtryck på 3,9 GB. Bygget inriktat på minnesavtryck, dimensionerat för att rymmas inom minnesbudgeten för en iPhone 17 Pro.

Båda hade en kontext på 262K tokens, båda behöll ett kompakt 4-bitars visionstorn så att modellen förblev multimodal, och båda stödde spekulativ avkodning med en DSpark-drafter. Prism ML:s framställning vid den tiden var att lågbitrepresentationen kördes från början till slut – embeddings, attention, MLP:er och LM-huvudet – utan några flyktvägar till högre precision, och att 1-bitarsbygget var den första 27B-klassmodellen som överhuvudtaget kördes på en telefon. Rapporterad genomströmning för 1-bitarsvarianten var omkring 11 tokens per sekund på en iPhone 17 Pro, 87 tok/s på en Apple M5 Max och 163 tok/s på en RTX 5090; den ternära varianten angavs till 58 tok/s på M5 Max och 134 tok/s på 5090.

Kvalitetskostnaden rapporterades vid sidan av dessa siffror i stället för att döljas. I en svit med 15 benchmarktester i tankeläge fick basmodellen med full precision 85,0, ternärbygget 80,5 – cirka 95 % – och 1-bitarsbygget 76,1, cirka 90 %. Försämringen var koncentrerad till agentiskt verktygsanrop, som sjönk från 80,0 till 66,0 i 1-bitarsbygget, och till vision, som sjönk från 72,6 till 59,6. Matematik och kodning klarade sig betydligt bättre i båda varianterna.

Vad den andra generationen förändrade

Ternary Bonsai 2 27B behåller receptet och ändrar indata. Den ternära representationen är fortfarande {−1, 0, +1} med en FP16-skala per grupp om 128 vikter, som nu packar till 1,76 bitar per vikt i en fil på 5,93 GB, med 262K kontext och samma separata visionstorn — 0,63 GB vid 4-bit i den här utgåvan, och laddas endast när en bild anländer.

Två saker är verkligen nya, och båda beskrivs som orsaken till att retentionstalet förändrades.

Det första är selektiv precision. Till skillnad från julibygget, som ternariserade i stort sett allt, håller Bonsai 2 26 238 464 parametrar i full precision – 0,0976 % av språkmodellen, cirka 52 MB i bf16, koncentrerade till den återkommande tillståndsvägen i de linjära uppmärksamhetslagren plus normaliseringsvikter. Det är en liten eftergift i byte och uppenbarligen en stor sådan i beteende.

Den andra är en roterad viktbas. Viktmatriser lagras efter en blockvis Walsh–Hadamard-rotation vid blockstorlek 1 024, med motsvarande transform tillämpad på aktiveringar vid körning, enligt teorin att sprida utliggare över koordinater gör en approximation med tre nivåer mindre förlustbehaftad. Det kostar ingen extra lagring eftersom rotationen viks in i vikterna, men den ligger faktiskt på beräkningsvägen.

Sedan finns den förändring som inte är någon teknik alls: basmodellen. Qwen3.8-27B är en hybrid-attentionsdesign – ungefär 75 % linjär uppmärksamhet, 25 % full uppmärksamhet – till skillnad från sin föregångare. Prism ML:s rapporterade kategoripoäng visar vad den ändringen gav. Instruktionsföljning ligger på 82,66 för Bonsai 2, mot 74,53 för Qwen3.6-27B, basmodellen som den första generationen komprimerade. Resonemang och kunskap ligger på 83,95 mot 84,71 för den äldre basmodellen, och kodning på 81,58 mot 82,57. Den nya basmodellen är klart bättre på instruktionsföljning och något sämre i två andra kategorier, vilket är precis den typ av profil som gör att bevarandeprocent mellan generationer inte är till någon hjälp var för sig.

Varför de två retentionstalen inte är jämförbara

95 % och 98,2 % ser ut som två avläsningar på en och samma skala. Det är de inte, av tre skäl som är värda att hålla reda på innan man drar slutsatsen att receptet förbättrades med 3,2 punkter.

• Nämnarna skiljer sig. Den första generationens 95 % mättes på en svit med 15 benchmarks mot Qwen3.6-27B. Den andras 98,2 % kommer från en svit med 20 benchmarks mot Qwen3.8-27B. Olika sviter, olika baslinjer, olika svårighetsmixer.

• Baslinjerna rörde sig oberoende av varandra. En del av vinsten i retention kommer från att den komprimerade modellen blir bättre på att komprimera, och en del från att basmodellen förändras på sätt som råkar vara vänligare mot ternära vikter. Inget publicerat skiljer dessa bidrag åt.

• Retention är relativ, så den kan stiga samtidigt som den absoluta förmågan sjunker inom en kategori. En modell som behåller 99 % av en svagare förälder kan fortfarande ligga efter en modell som behåller 96 % av en starkare.

Den absoluta jämförelsen är mer informativ än den relativa, och på den grunden är berättelsen renare. Bonsai 2:s sammanvägda resultat på 83,9 ligger över de 83,6 som Qwen3.6-27B med full precision fick i den äldre testsviten – vilket innebär att den komprimerade efterföljaren nu ligger före den okomprimerade modellen som den ersatte en generation tidigare. Första generationens ternära version fick 80,5 i sin egen testsvit. Båda dessa siffror är Prism ML:s, och testsviterna skiljer sig åt, så tolka ordningen snarare än decimalerna.

Varianten som inte kom tillbaka

Det här är den del av jämförelsen som förändrar ett köpbeslut snarare än ett benchmarkdiagram.

Det finns ingen 1-bitars Bonsai 2. Septemberutgåvan innehåller en ternär build i två packningar – PTQ1_0 med 1,76 bitar per vikt och 5,93 GB, och PQ2_0 med 2,16 bitar per vikt och 7,25 GB – plus en MLX-container för Apple Silicon. Det finns ingen binär variant på 3,9 GB, och inget tillkännagivande om en sådan. Siffran på 3,9 GB för telefonklass som förekommer i aktuell bevakning avser fortfarande julimodellen.

Den praktiska konsekvensen är direkt. Om ditt mål är en iPhone eller iPad, eller någon enhet där en språkmodell på 5,9 GB plus ett visionstorn på 0,63 GB plus en kontextbudget inte får plats, förblir första generationens 1-bitarsbygge det enda alternativet i den här familjen, och det kommer att förbli så tills en 1-bitars Bonsai 2 finns. Att uppgradera den ternära vägen uppgraderar inte den vägen. Den som läser "Bonsai 2 är bättre" och laddar ner igen till en telefon kommer att upptäcka att filen inte får plats.

Om du använder en bärbar eller stationär dator är kalkylen den motsatta: det finns ingen anledning att köra juli-ternärbygget när septemberversionen är mindre per kvalitetsenhet, bättre på de benchmarks som spelar roll och har samma 262K-kontext.

Hastighet, där generationerna är genuint svåra att rangordna

Genomströmning är den del av den här jämförelsen där det ärliga svaret är att de publicerade siffrorna inte stöder en entydig rangordning, och det är värt att säga det i stället för att välja det smickrande paret.

Den andra generationens standardiserade mätningar vid batchstorlek 1 med visionstornet exkluderat är 142,5 tok/s dekodning på ett RTX 5090 med PQ2_0-packningen, 46,8 tok/s på en Apple M5 Max, 27,7 på en M5 Pro och 18,0 på en M4 Pro. Den första generationen angav 134 tok/s på ett RTX 5090 och 58 tok/s på en M5 Max för sin ternära build. 5090-siffran rör sig måttligt i den förväntade riktningen. M5 Max-siffran rör sig åt andra hållet – 58 ner till 46,8 – vilket inte är vad ett två månader långt generationssteg ska se ut som.

Två förbehåll hindrar det från att vara ett fynd. Mätbaserna skiljer sig mellan utgåvorna, och åtminstone en publicerad M5 Max-siffra för den nyare modellen har tillskrivits en build som föregår rotationsoptimeringen. Men det är värt att flagga som en öppen fråga, eftersom mekanismen som skulle förklara den finns i versionsanteckningarna: den roterade basen lägger en transform på den kritiska vägen för varje projektion vid batchstorlek 1, och Apple Silicon-avkodning är den regim där det skadar mest. Tekniken som köper kvalitet kan kosta avkodningsgenomströmning, och på hårdvara med enhetligt minne är den avvägningen som skarpast.

MLX-containern tillför en särskild komplikation för Apple-användare. Det är ett affint 2-bitarsformat vars block lagrar både en skala och en bias för varje grupp om 128 vikter, men ternära vikter behöver bara skalan, så biasen är dödvikt — blocket kostar 36 byte per 128 vikter i stället för 34, och packningstakten landar på 2,25 bitar per vikt med en uppmätt filstorlek på 8,005 GiB. Det är en annan container som innehåller samma värden, och det är paketet som demonstrationsuppsättningen hämtar som standard.

Kör endera generationen

Båda generationerna delar en operativ begränsning som ingen version av den här modellen har undkommit: ingen av dem körs på standardversionen av llama.cpp. De ternära kärnorna för den här arkitekturen finns i Prism ML:s egen fork, standardversionen av llama.cpp avvisar de nuvarande packningarna som okända, och – värre – den laddar det äldre ternära formatet utan att klaga och producerar flytande skräp, eftersom den inte tillämpar den rotation som vikterna förutsätter. MLX-bygget har Metal- och CPU-kärnor men ingen CUDA-väg. Vilken generation du än väljer besvaras frågan om runtime av Prism ML:s egen distribution eller av en runtime som har antagit dess kärnor, inte av ggml-ekosystemet i stort.

Var OrcaRouter passar in i ett beslut som detta är en nivå upp. Ingen av Bonsai-generationerna är värdbaserad här – de är nedladdningar som du kör på din egen hårdvara. Det som routningslagret är användbart för är gränsdragningen: de förfrågningar som din lokala modell inte bör besvara.Definiera eskaleringspolicyn en gång i routningskonfigurationen i stället för i applikationskoden, så att en lokalt serverad nivå skickar vidare förfrågningar som har lång kontext, är visionsintensiva eller på annat sätt ligger utanför omfånget till en värdbaserad modell i stället för att misslyckas med dem, och så att reservlösningen överlever vilken generation av Bonsai du än råkar ha installerad. Både den lokala nivån och den värdbaserade ligger bakom en enda nyckel, och policyn finns på ett och samma ställe när nästa Bonsai-generation landar och nivågränserna flyttas igen.

Vad ska man göra med detta

• Om du kör juli-ternärbygget på en bärbar dator eller stationär dator – byt till Ternary Bonsai 2 27B. Det är en bättre modell med ungefär samma resursavtryck, och kategoripoängen där den vinner är de som spelar roll för agentiskt och instruktionsföljande arbete.

• Om du kör 1-bitsbygget från juli på en telefon – stanna kvar. Det finns ingen efterträdare, och det ternära bygget på 5,93 GB är inte en drop-in-ersättning för ett på 3,9 GB.

• Om du utvärderar familjen för första gången – bestäm först fotavtrycket, sedan generationen. Varianten du behöver avgör vilken utgåva du handlar i, och den ordningen är den omvända mot hur den här uppgraderingen vanligtvis beskrivs.

• Om du väljer utifrån benchmarks – behandla 95 % och 98,2 % som två olika mätningar snarare än två punkter på en linje, och behandla varje siffra i båda som leverantörens egen tills en oberoende utvärdering av septembermodellen finns. Den utvärderingen är den man bör hålla ögonen på, eftersom den är den första som kommer att kunna jämföra de två generationerna på en gemensam grund.