Bonsai 2 verscheen op Ollama voordat iemand aankondigde dat het zou komen.

ergens in de kleine uurtjes van 17 oktober 2026Ollamabegon met het aanbieden vanBonsai 2 — een bibliotheekitem met negen tags dat de volgende modellen omvat: Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B en Bonsai 2 27B, elk in twee verpakkingen plus een standaardalias. Prism ML heeft er niets over gezegd. Er staat geen bericht op de nieuwspagina van de leverancier, geen regel in de aankondiging van 15 oktober van de kleine modellen — die post noemt llama.cpp en MLX als de runtimes en een gehoste console als de demo, en noemt Ollama helemaal niet. De vermelding bestaat simpelweg, met alle negen tags die dezelfde, slechts enkele uren oude tijdstempel hebben, wat eruitziet als een verse push en niet als een geleidelijke uitrol.

Dus de eerlijke splitsing is deze. Nu al te weten, uit het register en de bestanden: de tags, hun namen, hun exacte bytegroottes, hun content-digests, en — omdat Ollama GGUF meelevert — de architectuur- en metadatastrings in de gewichten zelf. Niet bevestigd: wie ze heeft verpakt, waarom de aankondiging van de leverancier het platform weglaat, of de ternaire kernels upstream in Ollama's eigen engine zitten of vendored zijn, en of de cijfers van de leverancier de reis overleven. Dat zijn afzonderlijke vragen en dit stuk houdt ze gescheiden.

Wat staat er eigenlijk op de plank?

Negen tags, vier formaten, drie verpakkingen van dezelfde gewichten. Ollama's bibliotheekpagina vermeldt één standaardalias per formaat en een -q2_0 variant per formaat:

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

• bonsai-2:2b en bonsai-2:2b-q2_0 — 911 MB, dezelfde digest de2ccb4e7328

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

• bonsai-2:9b en bonsai-2:9b-q2_0 — 3,2 GB, dezelfde digest c8b5462f8688

• bonsai-2:27b en bonsai-2:27b-q2_0 — 8,3 GB, dezelfde digest f3c4f4208659

De naamgeving doet meer werk dan het lijkt. Twee tags per grootte die een digest delen is geen duplicaat — het is een uitspraak over welke packing Ollama heeft gekozen. Haal het manifest op voor bonsai-2:9b en de modellaag is 2,557 GB. Dat is het Q2_0-bestand van Ternary Bonsai 2 9B, gemeten op Hugging Face op 2,557 GB tot op de byte. De PQ2_0-pack is 2,417 GB en de PTQ1_0-pack — de kleinste met 1,997 GB — is hier helemaal niet.

Die keuze heeft een gevolg dat het waard is om ronduit te zeggen, want het is precies het soort ding dat uitmondt in een supportthread. Op de modelkaart van de leverancier draait upstream llama.cpp precies één van de drie packings: Q2_0, "recente master, die de Hadamard-activatieruntime bevat." Het verwerpt PQ2_0 en PTQ1_0 als onbekende typen, want die hebben de Prism ML llama.cpp-fork nodig. Ollama draait zijn eigen engine. Q2_0 is de pack die een standaard GGUF-consument aannemelijk kan laden — en Q2_0 is precies de pack die Ollama heeft geleverd. Of Ollama zijn eigen ternaire kernels heeft ontwikkeld of naar een vendored build routeert, vertelt het register je niet. Wat het je wel vertelt, is dat ze het bestand dat niet kan laden niet hebben geleverd.

De GGUF-metadata vertelt je meer dan de pagina doet

De pagina van Ollama rapporteert vier feiten per tag: een bytegrootte, een contextbadge van "256K", een invoertype van tekst-plus-afbeelding en een relatieve tijdstempel. Al het andere staat in het bestand. Het lezen van de GGUF-header van elke modellaag levert het volgende op, en het is om een specifieke reden de moeite waard om te lezen: het is het enige onderdeel van dit verhaal dat geen marketingclaim van iemand is.

• general.architecture — qwen35 op alle vier de formaten

• general.name — Ternary-Bonsai-2-2B, -4B, -9B op de kleine drie; de 27B-laag rapporteert de generieke string Hf met general.basename = folded

• general.file_type — 41 op alle vier, met general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, die overeenkomen met de tagnamen

• Tensor-aantallen — 320 voor de 2B, 426 voor de 4B, 427 voor de 9B, 851 voor de 27B

De architectuurstring is de interessante. qwen35 is de hybride-aandachtsbackbone van Qwen3.5, en hij bevestigt vanuit het artefact zelf wat de modelkaarten in proza zeggen: de drie kleine zijn Qwen3.5-2B, -4B en -9B, met de architectuur ongewijzigd en de gewichten vervangen. Hij legt ook een naad in de naamgeving bloot die de release notes van de leverancier zelf verdoezelen. De post van 15 oktober zegt dat de nieuwe modellen "gebaseerd zijn op Qwen3.5". De 27B is een heel andere basis — Qwen3.8-27B, aangekondigd op 17 september. Vier formaten, één familienaam, twee basismodellen. Alles wat je leest over het gedrag van "Bonsai 2" dat op de 27B is gemeten, is niet automatisch van toepassing op de 9B, en in de GGUF-header kun je zien waarom.

De metadata van de 27B is ook zichtbaar minder netjes dan de rest: general.name = Hf, een general.basename = folded, een general.version = v5, en één extra sampling-sleutel die de kleine drie niet hebben. Dat is hoe de tussenliggende uitvoer van een conversiepijplijn eruitziet wanneer die wordt gepusht zonder een laatste hernoemingsronde. Het is geen defect — de tensors zijn de tensors — maar het is een vingerafdruk, en het suggereert dat de 27B-tag via een ander pad is binnengekomen dan de kleine drie.

Wat de Ollama-cijfers niet betekenen

Hier gaat de meeste berichtgeving over een bibliotheekvermelding mis, dus het loont om even stil te staan. De bytegroottes op Ollama's pagina zijn containergroottes, en voor elke grootte zijn ze groter dan het modelbestand dat erin zit. De 2B-tag toont 911 MB tegenover een modellaag van 0,547 GB en een vision-projector van 0,365 GB. De 27B-tag toont 8,3 GB tegenover een modellaag van 7,626 GB en een projector van 0,629 GB. Tel de licentie- en parameter-blobs erbij op en de rekensom klopt: Ollama vermeldt het hele opgehaalde artefact, inclusief de vision-toren.

Dat betekent dat de 3,2 GB op de Ollama-pagina voor de 9B niet vergelijkbaar is met de "2GB"-opgave van de leverancier voor hetzelfde model, en het verschil is geen discrepantie om te melden — het zijn twee verschillende metingen van twee verschillende dingen. De 0,43 GB / 0,95 GB / 2 GB van Prism ML zijn alleen de taalmodellen. De visietoren wordt uitgeladen en pas geladen wanneer er daadwerkelijk een afbeelding binnenkomt, dus een implementatie voor alleen tekst betaalt er nooit voor, maar een ollama pull wel. Als je een apparaat afstemt op de cijfers van de leverancier en vervolgens van Ollama pullt, zit je 0,5 tot 1 GB over budget voordat je iets draait.

Dezelfde voorzichtigheid geldt voor de badge "256K". De onderliggende context is 262.144 tokens, geërfd van de Qwen3.5-backbone — 24 linear-attention- en 8 full-attentionlagen op de 9B — en Ollama's badge rondt dit naar beneden af voor weergave. De context is reëel en hij is geërfd, niet iets wat Ollama heeft toegevoegd. Wat niet op de pagina wordt vermeld, is hoeveel geheugen een lange context kost, en op een hybride attentionmodel met een full-attentioncache op een subset van lagen is dat geen klein aantal. Niets op de Ollama-pagina vertelt je of 262K daadwerkelijk past waar je het ook wilt draaien.

Wie heeft dit verpakt, en maakt dat uit?

Onbeantwoord, en het moet als onbeantwoord worden gemarkeerd in plaats van gegokt. Drie mogelijkheden: Prism ML heeft het gepusht, Ollama heeft het uit de openbare GGUF-repo's van de leverancier gehaald als onderdeel van hun eigen cataloguswerk, of een derde partij heeft het gedaan. Het register kan je niet vertellen welke.

Wat kan worden gecontroleerd, is de herkomst van het artefact, en die klopt. Ollama's eigen modelbeschrijving zegt: "Bonsai 2 van Prism ML is een familie van visiemodellen die zijn gebouwd voor ternaire gewichten (−1, 0 of +1): ongeveer half zo groot als standaard 4-bitmodellen, met een kwaliteit dicht bij volledige precisie" en linkt naar de Hugging Face-organisatie van de leverancier, de Bonsai 2 27B-whitepaper en Apache 2.0. De licentieblob die in elk van de vier grootte-manifesten is ingebed, is de letterlijke Apache 2.0-tekst. De parameterblob voor de 2B, 4B en 9B luidt {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — wat het door de leverancier aanbevolen denkmodus-samplingrecept uit de modelkaarten is, waarbij min_p precies zo is weggelaten als de 27B-kaart zegt dat de GGUF-bestanden het weglaten. Dat is geen gok die iemand heeft gedaan; dat is een conversie die de kaart heeft gelezen.

Wat geruststellend is en je nog steeds niets vertelt over het ding dat je ervaring daadwerkelijk bepaalt: of de ternaire kernels in de engine zitten die je draait. Het eerlijke standpunt is dat een geslaagde pull alleen bewijst dat het bestand een goed gevormde GGUF is, en niets meer. Verifieer het op je eigen hardware voordat je erop voortbouwt.

De beweringen van de leverancier, en wat er is gecontroleerd

Elk kwaliteitscijfer dat aan deze familie wordt toegeschreven, komt van Prism ML, op de eigen harness van Prism ML, en niets ervan is onafhankelijk gereproduceerd. Dat is normaal op deze leeftijd en het moet hardop worden gezegd in plaats van geïmpliceerd. Het bericht van 15 oktober rapporteert 19 benchmarks over zes vaardigheidsgebieden voor de kleine modellen, met retentie ten opzichte van full-precision Qwen3.5-baselines:

• 2B — agentisch 95,5%, wiskunde 107,8%, instructieopvolging 121,5%, programmeren 115,0%, kennis 82,9%, visie 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%

Verscheidene daarvan overschrijden 100%, wat geen typfout is en geen afrondingsartefact — het betekent dat het ternaire model in die categorie hoger scoorde dan het model met volledige precisie waarvan het was afgeleid. Instructieopvolging op 121,5% voor de 2B is het meest in het oog springende voorbeeld. Behandel dat met het wantrouwen dat het verdient: dat een gecomprimeerd model zijn eigen baseline verslaat op een benchmark die de leverancier heeft gekozen, zegt minstens evenveel over de training en het testharnas als over de representatie, en de scores in de categorie kleine modellen zijn een stuk ruisiger dan die van de 27B. De cijfers van de 27B zijn conservatiever en geloofwaardiger qua vorm — 84,78 tegenover 86,32 voor FP16, een behoud van 98,2% over 14 benchmarks in denkmodus, met wiskunde op 96,57 versus 97,06 en codeerniveau op 89,42 versus 89,07, en het verlies is geconcentreerd in kennis/redeneren en vision. Waar een familie capaciteit inlevert onder een 1,7-bits representatie, is dat het profiel dat je zou voorspellen.

De enige bewering in de post over kleine modellen die geen benchmark is, is degene die je het meest serieus moet nemen: de 9B "gebruikt ongeveer 40% minder tokens bij standaard instructieopvolging en alledaagse rekentaken." Dat is een bewering over breedsprakigheid, niet over vermogen, en het is iets dat je in een middag met je eigen prompts kunt controleren. Het hangt ook samen met een waarschuwing op de eigen modelkaarten van de leverancier — de denkmodus kan meer dan 3.000 tokens verbruiken voor een triviale vraag, dus stel ten minste 8.192 uitvoertokens in, en gebruik geen greedy decoding met de denkmodus ingeschakeld, omdat het kan blijven steken in het redeneren. Een model dat 40% minder breedsprakig is en nog steeds een budget van 8.192 tokens nodig heeft, vertelt je dat het op een specifieke plek breedsprakig is.

Wat dit voor jou betekent

Als je Ollama al draait en je een model van de 27B-klasse op een laptop wilde uitproberen zonder datacenter-GPU, dan zijn de vier tags op dit moment het kortste pad dat bestaat: één pull, geen fork, geen kernel-build. Als je de packing nodig hebt die daadwerkelijk het kleinst is, of de speculative-decoding-drafters die de leverancier meelevert voor de 4B en 9B, dan heeft de Ollama-listing ze niet — dat is een Hugging Face-download en de Prism ML llama.cpp-build, en dat is al zo sinds 15 oktober.

Het andere dat de moeite waard is om te weten, is dat lokaal niet de enige manier is om een low-bitmodel te gebruiken, en het is niet altijd de juiste. OrcaRouter zet één API voor meer dan 200 gehoste modellen met 0% markup — de lijstprijs van de provider wordt doorgegeven — plus automatische failover tussen providers, zodat je een model op een echte workload kunt evalueren voordat je besluit of het een plek op je laptop verdient. Geen van de Bonsai 2-formaten wordt vandaag via OrcaRouter aangeboden, en dit stuk beweert niet het tegendeel: de familie is een download die je zelf draait, en dat blijft zo totdat de leverancier een endpoint publiceert. Wat de routeringslaag je oplevert, is de andere helft van de beslissing — de gehoste modellen waarmee je het zult vergelijken, achter één sleutel, met de modelfusie en routerings-DSL beschikbaar wanneer één model niet genoeg is.

Wat in de gaten te houden, in volgorde van hoeveel het het beeld zou veranderen: een Ollama-tag die een ptq1_0-broertje krijgt, wat zou betekenen dat de dense-trit-kernels upstream zijn geraakt; een bericht van een leverancier waarin het platform wordt erkend, wat de herkomstvraag zou beantwoorden; en een onafhankelijke benchmark van de 9B of de 27B, het enige dat de retentiecijfers uit de door de leverancier gerapporteerde kolom zou halen. Totdat een van die dingen zich aandient, is de vermelding een aflevermechanisme, geen nieuw model — en het model dat het aflevert, is sinds 15 oktober openbaar.

Niets daarvan is hypothetisch: de gedocumenteerde AI-fouten en agent-incidenten achter releases zoals deze zijn verzameld in the OrcaRouter AI Incident Archive, waar elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en markering voor betwisting bevat.