Ternary Bonsai 2 27B kort fortalt
PrismML har udgivet Ternary Bonsai 2 27B, en ternærvægtsvariant af Qwen3.8 27B, under Apache‑2.0. Modellen fylder omkring 5,93 GB i PTQ1_0 GGUF mod cirka 53,80 GB i FP16, ifølge PrismMLs dækning hos MarkTechPost. Den tager både tekst og billeder og understøtter en kontekstlængde på 262.000 tokens. Tallene er klare i materialet.
Den centrale påstand er tydelig: 98,2 procent gennemsnitlig performance‑retention over 20 benchmarks sammenlignet med Qwen3.8 27B i fuldpræcision. PrismML viser også demoer, hvor modellen styrer Cline‑kodningsagenter og generel computerbrug på en RTX 5090. Det hele kører via PrismMLs egen llama.cpp‑fork eller MLX‑runtime.
Hvorfor det er en nyhed, der rykker
Udgivelsen lander cirka to måneder efter den første Bonsai 27B, som beholdt omkring 95 procent af baseline. Et hop fra ~95 til 98,2 procent retention i samme vægtklasse er markant – hvis tallene holder ved uafhængig verifikation. Pointen er netop, at tallene kommer fra PrismML selv.
Arkitektur og parametre
Modellen bevarer Qwen3.8 27B‑arkitekturen og har 27,36 milliarder parametre. Ifølge kilden fordeler det sig i en sprog‑backbone på 24,35B, 2,54B i embeddings og LM‑head og cirka 0,47B i visiontårn. Backbonen bruger hybrid‑attention, omtrent 75 procent linear‑attention‑lag og 25 procent fuld‑attention‑lag. Arkitekturen er i forvejen optimeret mod effektiv kørsel.
I GGUF‑distributionen udskilles vision‑tårnet som en separat fil på omkring 0,63 GB, der kun indlæses ved billedinput. Det betyder, at man ikke betaler RAM/VRAM for vision, når det ikke bruges – en praktisk detalje, når hukommelsen er flaskehalsen.
Hvad ternærvægte betyder i praksis
Ternær betyder her, at hver vægt er −1, 0 eller +1. For hver 128 vægte deles én FP16‑skala, og visse tensorer (bl.a. normalisering og state‑sti) bevares i højere præcision. Når skalaer og de få ikke‑ternære dele medregnes, lander man effektivt omkring 1,71–1,72 bit pr. vægt. Det er sådan, 27B‑klassen presses ned i enkeltcifrede gigabyte.
Der er to GGUF‑pakninger: PTQ1_0, som pakker tritter tæt og rammer cirka 1,76 bit pr. vægt og 5,93 GB total, og PQ2_0, som placerer hver trit i et 2‑bit slot og lander omkring 7,25 GB – men er billigere at pakke ud ved kørsel. Forskellen mærkes på decode‑hastighed og energiforbrug, ikke kun på papiret.
Rotationer, skalaer og kernels
Før ternarisering bruger PrismML en blokvis Hadamard‑rotation med blokstørrelse 1.024. Ved kørsel anvendes den matchende transform på aktiveringerne før hver multiplikation. Inspirationen angives som SpinQuant. Rotationens formål er at gøre vægtfordelingen mere ternærvenlig og bevare signal i få bit.
Det koster dog ved runtime: aktiveringer roteres, skalaer håndteres, og nogle tensorer kører i højere præcision. Derfor peger PrismML på kompatible runtimes og egne kernels. Uden optimerede kernels får man ikke fuldt udbytte af den mindre model.
Hvad PrismML hævder om performance
Ifølge MarkTechPost siger PrismML, at Ternary Bonsai 2 27B holder 98,2 procent af Qwen3.8 27Bs gennemsnit på tværs af 20 benchmarks. Vision bevarer omkring 96,3 procent, knowledge og reasoning cirka 96,9 procent, mens tabene er større i langhorisont agentopgaver. Terminal‑Bench 2.1 nævnes med et tydeligt dyk: 52,8 mod 69,7 for baseline. På SWE‑bench Verified lyder det 60,8 mod 80,6 – omtrent 75 procent retention og uden for 20‑bench‑gennemsnittet.
Der er også en intern sammenligning med ekstrem lavbits‑kvantisering: en IQ2_XXS‑build af Qwen3.8 27B scorer gennemsnitligt 75,2 ved cirka 7,3 GB. Bonsai 2 ligger højere i flere tests, f.eks. AIME26 og LiveCodeBench v6. Det taler for ternær frem for 2‑bit i visse opsætninger – men alt stammer fra PrismMLs eget eval‑setup.
Hvorfor størrelsen faktisk betyder noget for drift
En 27B‑multimodal model i 6–7 GB gør RAM/VRAM mindre dominerende. Vægtene kan holdes tættere på cache, og IO‑ventetid skæres ned. Det sænker typisk latency ved små batch‑størrelser, fordi der flyttes mindre data pr. token.
Omkostninger falder både på compute pr. anmodning og på transport/lagring af modellen. On‑prem‑scenarier bliver mere realistiske, når data ikke må forlade et netværk. Det mindsker også compliance‑friktion i regulerede brancher. Projekter, der tidligere krævede en ekstern API, kan i nogle tilfælde flyttes hjem.
Hvad PrismML siger om runtime
PrismML hævder, at modellen kan køre i dag på en 16 GB laptop eller en enkelt 24 GB GPU via PrismMLs llama.cpp‑fork eller MLX. Demos viser brug på RTX 5090, og der opgives token‑hastigheder for flere GPU‑klasser samt Apple‑silicon. Det skal dog reproduceres uafhængigt: små forskelle i kernels, drivere og blandepræcision kan flytte resultaterne.
De to GGUF‑pakninger performer forskelligt afhængigt af hardware og fase (prompt‑behandling vs. decode). Benchmark begge på egen maskinpark; ellers risikerer man at vælge en langsommere pakning af vane.
Praktisk betydning for implementering
Når 27B presses ned i få gigabyte, frister bred udrulning – men start med en tjekliste. Mål realistisk latency og throughput på egen hardware og med egne prompts. Evaluer kvalitet: mål hallucinationer, og vær særligt opmærksom på lang kontekst og agentiske opgaver, hvor retentionen er svagere. Kend faldgruberne, ikke kun gennemsnittet.
Tag derefter compliance og drift: auditér tredjepartsafhængigheder (llama.cpp‑forks, MLX‑versioner), og sørg for logging, sandboxing og kontrollerede netværksadgange omkring værktøjskald. Multimodalitet giver værdi, men billedinput udvider angrebsfladen og kræver korrekt governance.
Hvem bør kigge på det nu
Tre scenarier skiller sig ud: dokumentassistenter, der tygger lange PDF‑sæt og billeder af tabeller; interne knowledge‑bots med stor kontekst og lav latency; og agent‑automatisering, hvor værktøjskald og UI‑kontrol betyder noget i driften. For de to første kan Bonsai 2 være “god nok” til POC allerede. For agentopgaver viser tallene, at man ikke skal antage paritet – test først.
Teams med stramme GPU‑kvoter eller on‑prem‑krav vil finde modellen særlig relevant. Det gælder også organisationer, som vil have multimodalitet on‑device uden en stor cloud‑stak. Vægte kan flyttes og opdateres i CI/CD uden at blive en logistisk øvelse.
Huller og åbne spørgsmål
Der mangler detaljer i den offentlige dokumentation. PrismML beskriver ikke præcist metoden til at tildele ternære værdier til vægte. Uden det er reproducerbarhed og vurdering af eventuelle sikkerhedsartefakter sværere.
Benchmarkresultaterne er heller ikke uafhængigt verificeret i de tilgængelige materialer. EvalScope, vLLM og H100 er opgivet som ramme, men uden ekstern replikation må man forvente variation. Samme for de anførte token‑hastigheder. Demos er fine; hverdagsdrift er målestokken.
Tekniske risici og operationelle checks
En kort tjekliste – som start, ikke slutpunkt:
- Mål latency, tokens/sekund og energi pr. token på målplatforme. Test begge GGUF‑pakninger.
- Evaluer hallucinationer på egne datasæt, især ved lange kontekster og kæde‑af‑tanker‑prompts.
- Kør sikkerhedstests: jailbreak‑forsøg, prompt‑injektion, og hold værktøjskald i sandbox med begrænsede rettigheder.
- Gennemgå licenser og afhængigheder for llama.cpp‑fork og MLX. Afklar support ved nedbrud.
- Test vision‑stakken separat. Indlæs kun vision‑modulet ved behov, og mål effekt på hukommelse og latency.
- Planlæg evt. fine‑tuning/adapters: afklar om finjustering sker i højere præcision før ny ternarisering.
Hvad modellen gør, og hvad den ikke gør
Modellen håndterer tekst og billeder og har 262k tokens kontekst. Den kan derfor holde lange samtaler, dokumentbunker og skærmbilleder i hukommelsen. Den kan også drive værktøjer og kodeagenter, demonstreret med Cline på 5090‑hardware. Det er lovende for semi‑autonomi i udviklerteams og IT‑support.
Men den matcher ikke baseline i langhorisont agentopgaver, hvis man tager tallene for pålydende. Terminal‑Bench og SWE‑bench‑forskellene er markante. Her vælger man enten tradeoffet for omkostningsbesparelsen – eller en tungere model til netop de flows. Robusthed er også et åbent punkt: hvordan reagerer ternære vægte på distribution‑skift i billeder og tekst over tid.
Spørgsmål til PrismML og til testhold
Til PrismML: Kan metoden for ternær tildeling beskrives mere detaljeret for reproducerbarhed og sikkerhedsvurdering? Kan der publiceres reference‑kernels eller profileringsdata, der dokumenterer omkostningen ved rotation og de‑pakning på tværs af hardware? Og kan benchmark‑scripts og seeds åbnes, så eksterne kan replikere 20‑bench‑gennemsnittet én‑til‑én?
Til testhold: Bed om rålogs, profileringsudskrifter og nøjagtige kernel‑versioner for de opgivne hastigheder. Kør egne evals på AgentBench‑varianter og Terminal‑Bench, og mål forskellen i “værktøjsudholdenhed” over længere kæder. En praktisk note: mål tokens/sekund ved batch‑1 og batch‑N, både ved prompt‑processing og decode.
Historisk kontekst og konkurrence
Det er to måneder siden den første Bonsai 27B‑ternarisering, der fastholdt cirka 95 procent af baseline. Springet op over 98 procent er derfor en klar forbedring i samme vægtklasse. I den bredere kontekst er ternær og ultra‑lavbits kvantisering fyldt med idéer som blokrotationer, delte skalaer og specialiserede kernels. Det særlige her er multimodaliteten og den lange kontekst i en vægtfil, der kan flyttes på en almindelig laptop uden drama.
Konkurrenter vil pege på, at 2‑bit‑kvantisering også giver stærke tradeoffs og ofte findes i værktøjskæder, der er lettere at drifte. Der vil også blive spurgt til standardisering: hvor mange runtimes kan faktisk udnytte ternær trit‑pakning effektivt i dag? Det er legitime spørgsmål og værd at teste i en POC.
Bundlinjen efter første gennemkig
Læst nøgternt peger tallene på et reelt skridt frem: 27B multimodal, 262k kontekst, cirka 6 GB og ~98 procent af baseline på tværs af 20 benchmarks – med tydelige svagheder i langhorisont agentik. Det er meget model for meget lidt plads. Det ændrer indkøbslisten for teams, der ellers regnede med flere high‑end GPU’er til basal dokumentforståelse og interne assistenter.
Men køb ikke katten i sækken. Uden uafhængige verificeringer bør man måle på egen hardware og reteste de svage domæner. Hvis tallene holder, sænker modellen barrieren for on‑device og on‑prem drift af noget, der ligger tæt på en fuldfed 27B. Forskellene bliver tydelige, når man tester på egne workloads.
