Bonsai 2 kom till Ollama innan någon hade annonserat att den skulle göra det

Någon gång under småtimmarna den 17 oktober 2026, Ollama började servera Bonsai 2 — en bibliotekspost med nio taggar som täcker Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B och Bonsai 2 27B, var och en i två packningar plus ett standardalias. Prism ML har inte sagt något om det. Det finns inget inlägg på leverantörens nyhetssida, ingen rad i tillkännagivandet av de små modellerna den 15 oktober — det inlägget nämner llama.cpp och MLX som körmiljöer och en hostad konsol som demo, och nämner aldrig Ollama överhuvudtaget. Listningen existerar helt enkelt, med alla nio taggar stämplade med samma ålder på några timmar, vilket är vad en färsk push ser ut som och inte vad en gradvis utrullning ser ut som.

Så den ärliga uppdelningen är denna. Vetbart just nu, från registret och filerna: taggarna, deras namn, deras exakta bytestorlekar, deras innehållsdigester, och – eftersom Ollama levererar GGUF – arkitektur- och metadatasträngarna inuti själva vikterna. Inte bekräftat: vem som paketerade dem, varför leverantörens tillkännagivande utelämnar plattformen, huruvida de ternära kärnorna finns uppströms i Ollamas egen motor eller är vendoriserade, och huruvida några av leverantörens siffror överlever resan. Det är separata frågor och den här artikeln håller dem åtskilda.

Vad finns det egentligen på hyllan?

Nio taggar, fyra storlekar, tre packningar av samma vikter. Ollamas bibliotekssida listar ett standardalias per storlek och en -q2_0-variant per storlek:

• bonsai-2:latest — 3,2 GB, motsvarar 9B (digest c8b5462f8688)

• bonsai-2:2b och bonsai-2:2b-q2_0 — 911 MB, samma digest de2ccb4e7328

• bonsai-2:4b och bonsai-2:4b-q2_0 — 1,6 GB, samma digest 93edd652c932

• bonsai-2:9b och bonsai-2:9b-q2_0 — 3,2 GB, samma digest c8b5462f8688

• bonsai-2:27b och bonsai-2:27b-q2_0 — 8,3 GB, samma digest f3c4f4208659

Namngivningen gör mer arbete än den verkar. Två taggar per storlek som delar en digest är inte en dubblett – det är ett påstående om vilken packning Ollama valde. Hämta manifestet för bonsai-2:9b och modellagret är 2,557 GB. Det är Ternary Bonsai 2 9B:s Q2_0-fil, uppmätt på Hugging Face till 2,557 GB, exakt på byten. Det PQ2_0paketet är 2,417 GB och det PTQ1_0paketet – det minsta på 1,997 GB – finns inte här alls.

Det valet har en konsekvens som är värd att säga rakt ut, eftersom det är den typ av sak som blir en supporttråd. På leverantörens modellkort kör upstream-versionen av llama.cpp exakt en av de tre packningarna: Q2_0, "senaste master, som inkluderar Hadamard-aktiveringsruntime." Den avvisar PQ2_0 och PTQ1_0 som okända typer, eftersom de kräver Prism ML:s llama.cpp-fork. Ollama tillhandahåller sin egen motor. Q2_0 är den packning som en vanlig GGUF-konsument rimligen kan ladda – och Q2_0 är exakt den packning som Ollama levererade. Huruvida Ollama har utvecklat egna ternära kärnor eller routar till en vendorad build är inte något som registret berättar för dig. Vad det däremot säger dig är att de inte levererade filen som inte kan laddas.

GGUF-metadatan säger dig mer än vad sidan gör.

Ollamas sida rapporterar fyra fakta per tagg: en bytestorlek, en kontextbricka med "256K", en indatatyp av text-plus-bild och en relativ tidsstämpel. Allt annat finns inuti filen. Att läsa GGUF-huvudet för varje modellager ger följande, och det är värt att läsa av en specifik anledning: det är den enda delen av den här historien som inte är någons marknadsföringspåstående.

• general.architecture — qwen35 i alla fyra storlekar

• general.name — Ternary-Bonsai-2-2B, -4B, -9B på de tre små; 27B-lagret rapporterar den generiska strängen Hf med general.basename = folded

• general.file_type — 41 på alla fyra, med general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, som matchar taggnamnen

• Tensorantal — 320 för 2B, 426 för 4B, 427 för 9B, 851 för 27B

Arkitektursträngen är den intressanta. qwen35 är Qwen3.5s hybrid-attention-backbone, och den bekräftar utifrån artefakten själv vad modellkorten säger i prosa: de tre små är Qwen3.5-2B, -4B och -9B med oförändrad arkitektur och utbytta vikter. Den blottar också en namngivningssöm som leverantörens egna release notes slätar över. Inlägget den 15 oktober säger att de nya modellerna är "baserade på Qwen3.5". 27B är en helt annan bas — Qwen3.8-27B, tillkännagiven den 17 september. Fyra storlekar, ett familjenamn, två basmodeller. Allt du läser om "Bonsai 2"-beteende som mättes på 27B överförs inte automatiskt ned till 9B, och GGUF-huvudet är där du kan se varför.

27B:s metadata är också synligt mindre städad än resten: general.name = Hf, general.basename = folded, general.version = v5, och en extra samplingsnyckel som de tre små inte har. Det är så en konverteringspipelines mellanliggande utdata ser ut när det pushas utan en slutlig namnändringsomgång. Det är inte en defekt – tensorerna är tensorerna – men det är ett fingeravtryck, och det tyder på att 27B-taggen kom via en annan väg än de tre små.

Vad Ollama-siffrorna inte betyder

Det är här som de flesta genomgångar av en bibliotekslista går fel, så det är värt att sakta ner. Bytestorlekarna på Ollamas sida är containerstorlekar, och för varje storlek är de större än modellfilen inuti. 2B-taggen visar 911 MB mot ett modellager på 0,547 GB och en visionsprojektor på 0,365 GB. 27B-taggen visar 8,3 GB mot ett modellager på 7,626 GB och en projektor på 0,629 GB. Lägg till licens- och parameterblobbarna och räkningen går ihop: Ollama anger hela den hämtade artefakten, inklusive visionstornet.

Det innebär att Ollama-sidans 3,2 GB för 9B inte går att jämföra med leverantörens ”2 GB” för samma modell, och gapet är inte en avvikelse att rapportera – det är två olika mätningar av två olika saker. Prism ML:s 0,43 GB / 0,95 GB / 2 GB är enbart språkmodellerna. Visionstornet avlastas och laddas endast när en bild faktiskt anländer, så en driftsättning med enbart text betalar aldrig för det, men en ollama pull gör det. Om du dimensionerar en enhet mot leverantörens siffror och sedan hämtar från Ollama, kommer du att ligga 0,5 till 1 GB över budget innan du kör något.

Samma varning gäller för "256K"-märket. Den underliggande kontexten är 262 144 tokens, ärvd från Qwen3.5-stommen — 24 linjära attentionlager och 8 full-attention-lager på 9B — och Ollamas märke avrundar det nedåt för visning. Kontexten är verklig och den är ärvd, inte något som Ollama har lagt till. Vad som inte anges någonstans på sidan är hur mycket minne en lång kontext kostar, och på en hybrid-attention-modell med en full-attention-cache på en delmängd av lagren är det inte ett litet tal. Inget på Ollama-sidan säger dig om 262K faktiskt får plats där du än tänker köra det.

Vem paketerade detta, och spelar det någon roll

Obesvarat, och det bör flaggas som obesvarat i stället för att gissas. Tre möjligheter: Prism ML pushade det, Ollama pullade det från leverantörens offentliga GGUF-repon som en del av sitt eget katalogarbete, eller så gjorde en tredje part det. Registret kan inte avgöra vilket.

Det som kan kontrolleras är artefaktens proveniens, och den stämmer. Ollamas egen modellbeskrivning säger "Bonsai 2 från Prism ML är en familj visionsmodeller byggda för ternära vikter (−1, 0 eller +1): ungefär halva storleken jämfört med vanliga 4-bitarsmodeller, med nära fullprecisionskvalitet" och länkar till leverantörens Hugging Face-organisation, Bonsai 2 27B:s whitepaper och Apache 2.0. Licensblobben som är inbäddad i vart och ett av de fyra storleksmanifesten är den ordagranna Apache 2.0-texten. Parameterblobben för 2B, 4B och 9B lyder {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — vilket är leverantörens rekommenderade tankeläges-samplingsrecept från modellkorten, med min_p utelämnat precis som 27B-kortet säger att GGUF-filerna utelämnar det. Det är inte en gissning som någon har gjort; det är en konvertering som läste kortet.

Vilket är lugnande och ändå inte säger dig något om det som faktiskt avgör din upplevelse: huruvida de ternära kärnorna finns i motorn du kör. Den ärliga hållningen är att en lyckad pull bevisar att filen är välformad GGUF, och inget mer. Verifiera på din egen hårdvara innan du bygger vidare på den.

Leverantörens påståenden, och vad som har kontrollerats

Varje kvalitetssiffra som är kopplad till den här familjen kommer från Prism ML, i Prism ML:s egen testrigg, och inget av det har reproducerats oberoende. Det är normalt i det här skedet och bör sägas rakt ut i stället för att antydas. Inlägget den 15 oktober rapporterar 19 benchmarks över sex kompetensområden för de små modellerna, med bibehållen prestanda mot fullprecisionsbaslinjer för Qwen3.5:

• 2B — agentisk 95,5 %, matematik 107,8 %, instruktionsföljning 121,5 %, kodning 115,0 %, kunskap 82,9 %, vision 89,0 %

• 4B — 90,0 % / 99,3 % / 106,0 % / 100,7 % / 90,9 % / 91,3 %

• 9B — 92,4 % / 98,2 % / 100,0 % / 100,1 % / 93,0 % / 92,5 %

Flera av dessa överstiger 100 %, vilket inte är ett stavfel och inte en avrundningsartefakt – det innebär att den ternära modellen fick högre resultat än den fullprecisionsmodell den härleddes från i den kategorin. Instruktionsföljning på 121,5 % för 2B är det mest slående exemplet. Behandla det med den misstänksamhet det förtjänar: att en komprimerad modell slår sin egen baslinje i en benchmark som leverantören valt säger minst lika mycket om träningen och utvärderingsramen som om representationen, och poängen i kategorin små modeller är avsevärt brusigare än 27B:ans. 27B:ans siffror är mer konservativa och mer trovärdiga till sin form – 84,78 mot 86,32 för FP16, en bibehållen prestanda på 98,2 % över 14 benchmarkar i tänkandeläge, med matematik på 96,57 mot 97,06 och kodningsnivå på 89,42 mot 89,07, och med förlusten koncentrerad till kunskap/resonemang och vision. När en familj gör avkall på förmåga under en 1,7-bits representation är det den profil man skulle förutse.

Det enda påståendet i inlägget om små modeller som inte är ett benchmark är det som bör tas på största allvar: 9B ”använder ungefär 40 % färre tokens på standarduppgifter för instruktionsföljning och vardagliga matematikuppgifter.” Det är ett påstående om utförlighet, inte om förmåga, och det är sådant man kan kontrollera på en eftermiddag med sina egna promptar. Det samspelar också med en varning på leverantörens egna modellkort – tankeläget kan bränna över 3 000 tokens på en trivial fråga, så ställ in minst 8 192 utdatatokens, och kör inte girig avkodning med tankeläget på eftersom den kan fastna i sitt resonerande. En modell som är 40 % mindre utförlig och fortfarande behöver en budget på 8 192 tokens säger dig att den är utförlig på ett specifikt ställe.

Var detta lämnar dig

Om du redan kör Ollama och vill prova en modell i 27B-klassen på en laptop utan datacenter-GPU, är de fyra taggarna den kortaste vägen som finns just nu: en pull, ingen fork, inget kernelbygge. Om du behöver den packning som faktiskt är minst, eller de draftmodeller för speculative decoding som leverantören levererar för 4B och 9B, finns de inte i Ollama-listningen — det är en nedladdning från Hugging Face och Prism ML:s llama.cpp-bygge, och så har det varit sedan 15 oktober.

Det andra som är värt att känna till är att lokalt inte är det enda sättet att använda en lågbitmodell, och det är inte alltid det rätta. OrcaRouter sätter ett API framför över 200 hostade modeller med 0 % påslag – leverantörens listpris förs vidare – plus automatiskt failover mellan leverantörer, så att du kan utvärdera en modell på en verklig arbetsbelastning innan du avgör om den förtjänar en plats på din bärbara dator. Ingen av Bonsai 2-storlekarna serveras via OrcaRouter i dag, och den här artikeln påstår inte något annat: familjen är en nedladdning du kör själv, och den förblir så tills leverantören publicerar en endpoint. Vad routningslagret ger dig är den andra halvan av beslutet – de hostade modeller du kommer att jämföra den mot, bakom en enda nyckel, med modellfusion och routnings-DSL tillgängliga när en enskild modell inte räcker.

Vad man bör hålla utkik efter, i ordning efter hur mycket det skulle förändra bilden: en Ollama-tagg som får ett ptq1_0-syskon, vilket skulle innebära att dense-trit-kärnorna tog sig in i upstream; ett leverantörsinlägg som bekräftar plattformen, vilket skulle besvara proveniensfrågan; och vilket oberoende benchmark som helst av 9B eller 27B, vilket är det enda som skulle flytta retentionssiffrorna ur kolumnen för leverantörsrapporterade siffror. Tills ett av dessa landar är listningen en leveransmekanism, inte en ny modell — och modellen den levererar har varit offentlig sedan 15 oktober.

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.