Test av Ternary Bonsai 27B lokalt på RTX 4090

Ternary Bonsai 27B presser 27 milliarder parametere ned i en modellfil på rundt 7,2 GB. På min RTX 4090 leverte den 83-85 token i sekundet, samtidig som den beholdt nok praktisk kapasitet til å gjøre langt mer enn vanlig chat.

Modellen og runtime brukte omtrent 7,7-7,8 GB ekstra VRAM over maskinens hvilenivå. Enda viktigere: Den leverte gyldig JSON, hentet dokumenterte fakta med kontrollerbare tekstbevis fra et langt dokument, kalte verktøy, leste og skrev filer, laget manus til korte videoer og brukte en ekstern bildetjeneste gjennom vertsmaskinen.

Dette er likevel ingen mirakelmodell. Engelsk var klart bedre enn norsk, OCR-testen var bare delvis vellykket, og DSpark ga ingen fartsgevinst på mitt oppsett. Det interessante er hvor mye reelt arbeid som overlevde den voldsomme komprimeringen – og hvor anvendelig en så liten 27B-modell faktisk kan være lokalt.

Hva er Ternary Bonsai 27B?

Ternary Bonsai 27B er en komprimert utgave av en Qwen3.6-27B-basert modell der vektene i hovedsak har tre mulige verdier: -1, 0 eller +1. Prism ML oppgir en distribuert størrelse på rundt 7,2 GB, mot omtrent 54 GB for FP16-utgaven. Lisensen er Apache 2.0.

Enkelt forklart er modellvektene alle de små tallene modellen har lært under trening. Vanlige modeller lagrer disse med langt flere mulige verdier. Ternary begrenser språkdelen til tre: negativ, null eller positiv. Det reduserer plassen kraftig, men krever et format og beregningskjerner som faktisk forstår hvordan de tre verdiene er pakket.

Det siste er avgjørende. Filen heter riktignok GGUF og Q2_0, men dette er ikke det samme som en tilfeldig vanlig 2-bit-kvantisering du kan mate inn i enhver GGUF-kompatibel app. Den anbefalte filen, Ternary-Bonsai-27B-Q2_0.gguf, bruker grupper på 128 vekter og Prism sine egne lavbit-kjerner. Dette er også en annen tilnærming enn NVFP4-kvantiseringen jeg har sett nærmere på med Qwen3.6-27B. Modellen må derfor ikke blandes sammen med den mindre 1-bit-varianten eller de separate DSpark-filene.

Prism hevder at den ternære utgaven beholder omtrent 95 prosent av FP16-resultatet i deres samling av tester. Det er interessant, men ikke min målestokk her. Jeg ville finne ut om den kunne gjøre arbeid jeg faktisk har bruk for, på min egen maskin, uten at en benchmarktabell fikk skrive konklusjonen på forhånd.

Slik kjørte jeg Ternary Bonsai 27B på Windows

BF16 gikk ikke inn via Ollama i mitt oppsett, så jeg gikk videre med Prism ML sin egen llama.cpp-fork med CUDA 12.4. Den native kjøringen fungerte. Den aktuelle Prism-releasen har ferdigbygde Windows-filer, og Bonsai-demoen dokumenterer Windows-oppsett, server og modellvalg.

Her ligger det enda en liten felle. Release-lenken med filnavnet llama-prism-b9591-62061f9-bin-win-cuda-12.4-x64.zip ga 404 i testen. Den faktiske binærpakken het llama-prism-b1-62061f9-bin-win-cuda-12.4-x64.zip. I tillegg trengte jeg CUDA-pakken cudart-llama-bin-win-cuda-12.4-x64.zip, med blant annet cudart64_12.dll, cublas64_12.dll og cublasLt64_12.dll.

Dette er den korte PowerShell-stien, med en nøytral lokal mappe. Last ned de to ZIP-filene fra release-siden, legg dem i C:\AI\bonsai\downloads, og hent modellfilen fra Hugging Face:

$Root = "C:\AI\bonsai"
New-Item -ItemType Directory -Force "$Root\bin", "$Root\models" | Out-Null
Expand-Archive "$Root\downloads\llama-prism-b1-62061f9-bin-win-cuda-12.4-x64.zip" -DestinationPath "$Root\bin"
Expand-Archive "$Root\downloads\cudart-llama-bin-win-cuda-12.4-x64.zip" -DestinationPath "$Root\bin"
hf download prism-ml/Ternary-Bonsai-27B-gguf `
  Ternary-Bonsai-27B-Q2_0.gguf `
  --local-dir "$Root\models"

Pass på at llama-server.exe og CUDA-DLL-filene ender i samme kjørbare mappe. Nøyaktig undermappestruktur kan avhenge av hvordan ZIP-pakkene blir pakket ut. Deretter kan serveren startes lokalt slik:

& "C:\AI\bonsai\bin\llama-server.exe" `
  -m "C:\AI\bonsai\models\Ternary-Bonsai-27B-Q2_0.gguf" `
  -ngl 99 -c 8192 --host 127.0.0.1 --port 8080

Serveren eksponerer et OpenAI-lignende endepunkt på http://127.0.0.1:8080/v1. To CLI-detaljer sparer også tid: Denne bygningen godtok ikke llama-cli -i; samtalemodus måtte startes med -cnv. For en enkelt oppgave var llama-completion et bedre valg. llama-server -sys var heller ikke støttet, så systemmeldingen måtte sendes i API-kallet.

Prism anbefaler temperatur 0,7, top-p 0,95 og top-k 20. Modellen kan kjøres med reasoning av eller på, og et eget reasoning-budsjett. I jobbtestene slo jeg reasoning av for å få renere og mer forutsigbar utdata. I chat er synlig tenking nyttig til feilsøking, men det blir fort mye engelsk metatekst før selve svaret.

Hvor rask var den, og hvor mye VRAM brukte den?

På RTX 4090 målte jeg vanligvis 83-85 token i sekundet under generering. llama-bench ga rundt 84,7 token i sekundet på tg128, og den første korte completion-testen lå rundt 68 token i sekundet etter omtrent fire sekunders innlasting. Dette er responsivt nok til at modellen føles rask i vanlig bruk.

Maskinen brukte omtrent 1 720 MiB VRAM i hvile. Med serveren og modellen lastet steg forbruket til rundt 9 470 MiB. Forskjellen er cirka 7,7-7,8 GB for modell, KV-cache og runtime i oppsettet med 8 192 tokens kontekst. VRAM-forbruket holdt seg omtrent flatt rundt 9,5 GB mens serveren sto oppe.

Det gir svært god margin på et kort med 24 GB VRAM. Det betyr ikke at alle kan forvente samme fart; resultatet mitt gjelder Windows, denne Prism-bygningen, RTX 4090, full GPU-offload og den konkrete Q2_0-filen. Rå tokenfart bør heller ikke leses uten maskinvare og oppsett; testen min av DeepSeek V4 Flash på fire RTX 2080 Ti er et godt eksempel på hvor forskjellige lokale oppsett kan være. Men størrelsen er ikke bare et tall på disken. Modellen var faktisk liten nok til å dele maskinen med andre programmer uten at alt måtte ryddes ut av GPU-minnet.

Dette er en annen kategori enn vanlige 27B-modeller i fire eller flere bit. Det spesielle formatet krever riktig runtime, men gevinsten er at en 27B-modell kan ligge rundt 9,5 GB total VRAM-bruk på maskinen og fortsatt gi svært responsiv generering.

Engelsk var bra, norsk var ikke publiseringsklart

Min faste chat-test begynner på engelsk med en forespørsel om hjelp til en artikkel om AI-historien fra 1970 til 1990. Bonsai forsto tidsrommet, foreslo en ryddig struktur, identifiserte relevante temaer og ga konkrete neste steg. Svaret var vennlig og praktisk, og genereringen lå rundt 83 token i sekundet.

I neste runde ga jeg kontekst om en norsk teknologiside, min interesse for AI siden 1996 og hvorfor jeg bruker ordet AI. Modellen skjønte at den burde bytte språk. Problemet var gjennomføringen: Den blandet norsk og engelsk, dro inn svenskaktige former og produserte ord som ikke hører hjemme noe sted. Forsøket var trivelig, men teksten var ikke i nærheten av å kunne publiseres uten hard redigering.

Dette er en viktig begrensning for norske brukere. Modellen kan forstå norsk kontekst og svare på norsk, men min test gir ikke grunnlag for å anbefale den som ferdig norsk skribent. Jeg ville brukt engelsk som arbeidsspråk og behandlet norsk tekst som råmateriale. Lengre og vanskeligere norske oppgaver er heller ikke testet systematisk ennå.

JSON og dokumentarbeid var den klare styrken

Den første strukturerte oppgaven var å lage en artikkelpakke som streng JSON. Resultatet kunne parses direkte, inneholdt alle nødvendige nøkler, seks punkter i disposisjonen og fem påstander. Oppgaven tok omtrent 17,7 sekunder og ga 1 455 completion-tokens. Det er akkurat den typen kjedelig, nyttig arbeid lokale modeller må mestre for å være mer enn en chatdemo.

Deretter ga jeg modellen hele teksten fra en fagartikkel om BitNet b1.58. Med 8 368 tokens i prompten og 2 687 tokens i svaret tok uttrekket rundt 37 sekunder. Modellen leverte 12 fakta, 10 samtalepunkter, seks forbehold og åtte ordlistepunkter i gyldig JSON. Konteksten måtte økes fra 8 192 til 16 384 fordi dokumentet ellers ble for langt.

Den mest overbevisende testen krevde at hvert faktapunkt skulle ha et dokumentert tekstbevis og plassering. Resultatet inneholdt 14 fakta, og alle de 14 oppgitte sitatbitene kunne finnes igjen i originaldokumentet. En enklere variant ga 13 av 13 treff. Det beviser ikke at modellen aldri hallusinerer, men akkurat denne testen viste solid dokument-grounding når oppgaven og skjemaet var stramt formulert.

Her var Bonsai mer interessant enn i vanlig chat. Den behandlet et langt dokument raskt, fulgte en struktur og ga et maskinlesbart resultat jeg kunne kontrollere automatisk. For lokale arbeidsflyter med dokumentuttrekk, sortering og klargjøring av materiale er det reell nytte.

Tool calling fungerte – men vertsmaskinen gjorde jobben

Via serverens OpenAI-lignende API fikk modellen først tilgang til et enkelt get_time-verktøy. Den returnerte riktig tool call med tomt argumentobjekt, verten hentet lokal tid, og modellen brukte resultatet i runde to. Det samme mønsteret fungerte med read_file og write_file.

I en filtest ba modellen verten lese et dokument og skrive ti punkter til en JSON-fil. Hele kjeden brukte rundt 15,6 sekunder og endte med gyldig utdata. I en annen oppgave leste den researchnotatene og skrev fem engelske manus til korte videoer på omtrent 14,9 sekunder. Manusene var litt kortere enn modellen selv oppga, men resultatet var likevel veldig bra.

Jeg testet også bildegenerering ved å eksponere et generate_image-verktøy som kalte Kie z-image på vertsmaskinen. Bonsai leste researchen, laget et verktøykall for et 16:9-bilde og fikk tilbake filresultatet etter omtrent 52,5 sekunder. Modellen genererte altså ikke bildet selv. Den valgte og kalte et eksternt verktøy, mens verten håndterte tjenesten og API-nøkkelen.

Det skillet er viktig både praktisk og sikkerhetsmessig. Bonsai har ikke internett, filtilgang eller bildegenerering innebygd. Det er applikasjonen rundt modellen som bestemmer hvilke verktøy den kan be om å få brukt. API-nøkkelen lå i brukerens sesjon på vertsmaskinen og ble aldri lagt inn i modellprompten.

Vision forsto motivet, men OCR var bare delvis god

Vision krevde en separat multimodal prosjektor og llama-mtmd-cli. Prism publiserer prosjektorfiler på omtrent 0,6-0,9 GB i tillegg til språkmodellen. Med Q8_0-projektoren og minst 1 024 bildetokens brukte de enkle testene omtrent fem til sju sekunder.

På et enkelt bilde av et eple identifiserte modellen motivet korrekt. Det er en beskjeden test, men den avklarer at vision-kjeden faktisk var koblet riktig og at modellen ikke bare svarte ut fra filnavn eller prompt.

Den krevende testen var test.png, en plakat med en mann i grønn hettegenser, laptop, hjernevisualisering, hologramelementer og mye norsk tekst. Modellen beskrev scenen godt og fanget den store overskriften grovt. Den identifiserte også Claude- og J-space Research-logoene.

Som OCR-verktøy var den langt mindre pålitelig. «AI» ble tolket som «Al», og norske ord ble feillest. Min dom er derfor at modellen kan forstå hva en plakat handler om, men ikke bør brukes som fasit for nøyaktig avskrift. Tolking av motiv og grov sammenheng fungerte; sitater og småtekst må kontrolleres manuelt.

DSpark virket, men gjorde modellen mye tregere hos meg

DSpark er en separat draftermodell som foreslår flere tokens før hovedmodellen kontrollerer dem. Ideen er å få samme resultat raskere, fordi hovedmodellen kan godkjenne flere forslag i én omgang. Prism leverer en Q4_1-drafter på omtrent 2 GB og oppgir fartsløft i egne CUDA-målinger.

Den tekniske mekanismen fungerte i min test. API-kjøringen viste 216 foreslåtte og 144 godkjente tokens, omtrent 67 prosent. I llama-speculative-simple var godkjenningsgraden rundt 82 prosent. Problemet var farten: Vanlig API-kjøring lå rundt 84 token i sekundet, mens API med DSpark falt til omtrent 5,5. Den enklere speculative-klienten lå rundt 20.

Dette kan være avhengig av bygg, arbeidslast og innstillinger. Prism sin målte gevinst på andre oppsett er ikke nødvendigvis feil, men den dukket ikke opp på min RTX 4090 i denne testen. DSpark måtte også kjøres med én parallell strøm, større kontekst og ny prefill. Jeg ville derfor latt funksjonen være eksperimentell til en konkret arbeidslast faktisk viser gevinst.

Er Ternary Bonsai 27B verdt bryet?

Ja, hvis målet er å få mest mulig praktisk modellkapasitet inn i lite minne. Rundt 7,2 GB på disk, cirka 7,8 GB ekstra VRAM og 83-85 token i sekundet er en svært god kombinasjon på min maskin. JSON, dokument-grounding, filarbeid og tool calling gjorde den relevant for ekte arbeidsflyter.

Nei, hvis du først og fremst vil ha en god norsk chatmodell. Norsk var den tydeligste svakheten. Vision fungerte, men OCR-resultatet krevde kontroll, og DSpark var en kraftig nedbremsing i stedet for en akselerasjon på mitt oppsett.

For meg er dette en vellykket test. Ikke fordi modellen slo en bestemt benchmark, men fordi den behandlet dokumenter, skrev kontrollerbar JSON, brukte verktøy, laget videomanus og fikk en vert til å generere et artikkelbilde. Ternary Bonsai 27B viser at en 27B-modell rundt 7 GB kan være langt mer enn en teknisk kuriositet.

Ofte stilte spørsmål