Bonsai 2 vs Bonsai 27B: En av dem kan du hämta, den andra kan du inte

Den mest konkreta skillnaden mellan Bonsai 2 och Bonsai 27B har ingenting med benchmarks att göra. Den 17 oktober 2026 publicerades en Ollama-bibliotekspost som täcker hela Bonsai 2-familjen — Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B och Bonsai 2 27B — och det finns ingen motsvarande post för den första generationen. Sök efter bonsai-27b, ternary-bonsai-27b eller något variantnamn i det registret och du får en 404. Bonsai 27B, som släpptes av Prism ML den 14 juli 2026, måste laddas ner från leverantörens Hugging Face-repositorier och köras mot Prism ML:s llama.cpp-fork. Bonsai 2 har en enradsinstallation.

Den asymmetrin utgör hela den praktiska formen av valet, och den är lätt att missa eftersom de två namnen ser ut som en produktlinje med en versionsuppdatering. De är två generationer, två basmodeller, två olika uppsättningar packningar och – från och med den här veckan – två olika leveransmekanismer. Det som följer är vad som faktiskt förändrades mellan dem, var den äldre fortfarande vinner, och den ena konfigurationen där svaret är ingetdera.

Vad var och en är

Båda är ternära komprimeringar av en Qwen hybrid-attention-modell. Ingen av dem är en nytränad modell – arkitekturen, vikterna och den kvantiseringsmedvetna träningen kommer från Qwen-basen, och det som Prism ML bidrar med är den ternära representationen och de kärnor som använder den.

• Generation — Bonsai 2 (september 2026, utökad oktober 2026) vs Bonsai 27B (14 juli 2026)

• Basmodell i 27B-storlek — Qwen3.8-27B vs Qwen3.6-27B

• Basmodeller i hela familjen — Qwen3.5-2B, -4B, -9B och Qwen3.8-27B under Bonsai 2; en enda Qwen3.6-27B i den första generationen

• Storlekar som erbjuds — fyra (2B, 4B, 9B, 27B) mot en (27B)

• Två driftpunkter vid 27B — nej, en: Bonsai 2 27B levereras endast i ternär form, medan Bonsai 27B levererades i både ternär och binär form

• Minsta fotavtryck i 27B-klassen — 5,95 GB PTQ1_0 i Bonsai 2 mot 3,9 GB i första generationens 1-bitarsbygge

• Kontext — 262 144 tokens ärvda från Q​wen-backbonen på båda

• Licens — Apache 2.0 på båda

• Leverans — Ollama-taggar och Hugging Face för Bonsai 2; Hugging Face plus Prism ML:s llama.cpp-fork för Bonsai 27B

Raden som avgör fler driftsättningar än de övriga är den femte. Bonsai 27B levererades i två varianter för minnesanvändning: en ternär version på cirka 7,2 GB och en binär version på 3,9 GB. Bonsai 2 27B levereras i en — en ternär version på 5,95 GB i dense-trit-packning eller 7,21 GB i 2-bit-slot-packning — och det finns ingen binär motsvarighet i den här generationen. Om du körde den första generationens 3,9 GB-version och förväntade dig en likvärdig efterföljare finns det ingen sådan på 27B.

Vad generationen faktiskt köpte

Prism ML:s egna siffror, i Prism ML:s egen testrigg, utan någon tillgänglig oberoende reproduktion: den första generationens ternära Bonsai 27B rapporterade ett genomsnitt i tankeläge på 80,49 mot 85,07 för sin Qwen3.6-27B FP16-referens — 94,6 % bibehållet över 15 benchmarks. Bonsai 2 27B rapporterar 84,78 mot 86,32 för Qwen3.8-27B FP16 — 98,2 % över 14 benchmarks. I absoluta tal ökade den komprimerade modellen med cirka 4,3 punkter på leverantörens skala.

Två förbehåll hör hemma i samma andetag, eftersom rubriken inbjuder till en renare läsning än vad dataunderlaget stöder. För det första är benchmark-sviterna inte samma uppsättning – 15 för den ena, 14 för den andra – och baslinjen flyttades från Qwen3.6-27B till Qwen3.8-27B, som i sig var en starkare modell. Tillverkarens eget modellkort för 27B gör den andra punkten explicit genom att räkna om den tidigare versionen på den nya sviten med 14 benchmarkar för en likvärdig rad: på den gemensamma grunden får den tidigare versionen 80,98 och Bonsai 2 27B får 84,78. Så den ärliga tolkningen av förändringen är ungefär 3,8 punkter mot samma benchmark-uppsättning, där en del kommer från basmodellen och en del från den ternära träningen. Retention-andelen steg från 94,6 % till 98,2 %, delvis därför att nämnaren ändrades.

För det andra är förlustens form mer informativ än det aggregerade måttet. I samma svit med 14 benchmarks tappar Bonsai 2 27B nästan ingenting där uthålligt resonerande visar sig: matematik 96,57 mot 97,06, kodning 89,42 mot 89,07 – i nivå, marginellt före – och instruktionsföljning 82,66 mot 81,25, före. Kunskap och resonemang faller från 85,55 till 79,86, och vision från 71,36 till 66,19. Det är profilen man kan förvänta sig av en representation med 1,72 bitar per vikt: resonemangskärnan överlever, faktaminnet och bildförståelsen får ta smällen. Om din arbetsbelastning är kod och matematik är komprimeringen nästan gratis. Om den är retrievalformad frågebesvarande över en korpus, är den inte det.

3,9 GB-platsen är där det här blir intressant

Här är delen som tvågenerationsinramningen döljer. Den första generationens mest utmärkande artefakt var den binära versionen: en 27B-modell på 3,9 GB som enligt leverantören behöll 89,5 % av FP16 i ett genomsnitt över 15 benchmarks på 76,11. Bonsai 2 har ingen binär 27B-modell. Men Bonsai 2 har en 9B-modell på 1,997 GB i dense-trit-packningen och 2,42 GB i 2-bit-slot-packningen – ungefär halva fotavtrycket jämfört med den binära 27B, från den nyare generationen och den nyare basmodellen.

Är 9B bättre än 1-bitars 27B? Tillverkaren rapporterar inte någon siffra som besvarar den frågan, och du bör inte konstruera en. De två modellerna utvärderades på olika sviter – 19 riktmärken över sex färdighetsområden för de små Bonsai 2-modellerna, 15 för första generationens 27B – mot olika baslinjer, och de små modellernas utgivningsrapporter redovisar kategoribibehållning mot deras egna Qwen3.5-motparter i full precision snarare än ett enda absolut genomsnitt som är jämförbart med 27B:ans 76.11. De jämförelser som finns är per riktmärke och pekar i båda riktningarna. Enligt tillverkarens siffror får 9B 71.81 på BFCLv3 och 73.02 på Tau2Bench, medan den binära 27B:n noterade 74.41 på BFCL v3 – så nära att skillnaden mellan sviterna slukar den.

Det som kan sägas utan att gå för långt är snävare och ändå användbart: den fotavtrycksklass som den binära 27B tidigare ägde ensam har nu en billigare nykomling från nästa generation, och de två ligger tillräckligt nära varandra för att ingen bör välja mellan dem utifrån en leverantörstabell. Det är ett argument för att mäta på dina egna prompter, inte för att lita på en siffra. Det är också den enda platsen i den här jämförelsen där svaret verkligen är ingendera av de två modellerna i titeln.

Att köra dem: siffrorna och haken

Genomströmningssiffror är leverantörsmätta och har inte tagits fram på en gemensam maskin, så läs dem som storleksordningar snarare än en rangordning.

• Bonsai 2 27B på en Apple M5 Max — cirka 47 tok/s på det tidigare pre-rotationsbygget, i avvaktan på ommätning på den nuvarande stacken

• Bonsai 2 27B på en M5 Pro – 28,1 tok/s med 2-bit-slot-packning, vid ungefär 27,5 W på GPU-skenan

• Bonsai 2 27B på ett RTX 5090 — 129,9 tok/s i 2-bit-slot-packningen, 120,5 i dense-trit-packningen

• Första generationens ternära Bonsai 27B på en M5 Max — 44,0 tok/s; på en H100, 98,0 tok/s, som ökar till omkring 131,8 med sin DSpark-drafter

• Första generationens binära Bonsai 27B på en iPhone 17 Pro Max — cirka 11 tok/s, termiskt begränsad

Haken är paketeringen, och den slår på samma sätt för båda generationerna. Ingen av generationernas ternära kärnor finns i uppströmsversionen av llama.cpp. Den första generationen kräver Prism ML-forken för varje fil. Bonsai 2 levererar tre packningar av samma vikter och uppströms llama.cpp kör exakt en av dem – Q2_0, i nyare master – medan den avvisar den mindre PTQ1_0 och den snabbare PQ2_0 som okända typer. Så den täta trit-packningen som ligger närmast de teoretiska 1,72 bitarna per vikt är också den som kräver ett forkat bygge.

Det är värt att stanna upp vid, eftersom det förklarar Ollama-listningen. Ollama-taggarna för Bonsai 2 levererar Q2_0: 9B-taggens modellager mäter 2,557 GB, byte för byte samma som Q2_0-filens storlek på Hugging Face, och det minsta PTQ1_0-paketet saknas helt i registret. Vad den listningen än är, så är den inte en väg till den minsta artefakten. Här görs en avvägning mellan bekvämlighet och fotavtryck, och avvägningen är osynlig om man inte läser filstorlekarna.

Att ta sig till någon av dem

Om du använder Ollama är valet redan gjort åt dig: Bonsai 2, fyra storlekar, ollama pull bonsai-2:27b eller :9b, ungefär 8,3 GB respektive 3,2 GB på disk inklusive vision-projektorn. Om du behöver dense-trit-packningen, draftarna för spekulativ avkodning eller något från första generationen, är det en nedladdning från Hugging Face och en fork-build, och leverantörens demorepositorium är den testade referensen för den vägen.

Där ett routningslager verkligen hjälper till här är på andra sidan av frågan. Du kan inte routa till någon av dessa – de är lokala vikter, och OrcaRouter erbjuder ingen Bonsai-storlek i dag. Det OrcaRouter ger dig är jämförelsebaslinjen: ett API framför över 200 hostade modeller utan påslag, leverantörens listpris förs vidare, med automatisk failover mellan leverantörer. Den kloka sekvensen för de flesta team är att fastställa på en hostad modell vad en uppgift faktiskt behöver, och sedan avgöra om en lokal modell på 2 GB, 3,9 GB eller 6 GB klarar den ribban – i stället för att gissa utifrån en retention-procent.

Vilken, rent konkret?

• Du vill ha den senaste ternära generationen på 27B och en installation med ett enda kommando – Bonsai 2 27B via Ollama, och accepterar Q2_0-packningen och den större storleken på disken.

• Du vill ha de minsta möjliga artefakterna i 27B-klassen, eller så förlitar du dig på DSpark-draftaren – först generationens Bonsai 27B från Hugging Face, med fork-bygget. Inget i Bonsai 2 ersätter den vid 27B.

• Du körde den 3,9 GB stora binära byggversionen och behöver att det utrymmet håller — anta inte att Bonsai 2 har en efterträdare. Antingen stannar du kvar, eller så mäter du Bonsai 2 9B mot dina egna prompter; den är hälften så stor och en generation nyare, och leverantören har inte publicerat någon jämförelse som avgör saken.

• Du behöver fyra storleksklasser från en och samma runtime — Bonsai 2 är den enda generationen som erbjuder det.

En sak att hålla utkik efter som skulle förenkla allt detta: en ptq1_0-tagg som dyker upp i Ollama-listningen. Det skulle innebära att dense-trit-kärnorna har nått motorn som Ollama levererar, att kravet på fork försvinner för den minsta paketeringen, och att avvägningen mellan bekvämlighet och utrymmesbehov upphör att vara en avvägning.

Inget av detta är hypotetiskt: de dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, tillförlitlighetsgrad och omtvistad flagga.