Ternary Bonsai 2 27B: Vad får plats i 5,9 GB, och vad 98,2 % inte berättar för dig

Ternary Bonsai 2 27B är en multimodal språkmodell med 27,36 miljarder parametrar som Prism ML tillkännagav den 17 september 2026, och det man måste förstå om den är att dess språkvikter antar ett av exakt tre värden. Dess basmodell är Qwen3.8 27B – en 27B hybrid-attention-modell – och Bonsai behåller den arkitekturen, den träningen och den formen, och ersätter språkmodellens matrisvikter med en ternär representation. Den levererade filen är 5,93 GB. Fullprecisionsreferensen är 53,81 GB. Leverantörens främsta påstående är att den behåller 98,2 % av originalets benchmarkgenomsnitt.

Börja med den del som de flesta bevakningar kommer att glida förbi: att 98,2 % är Prism ML:s eget tal, uppmätt med Prism ML:s egen svit på 20 benchmarks, med Prism ML:s egen testrigg, och ingen utanför företaget har reproducerat det. Det är inte en anklagelse – det är det normala tillståndet dagen efter en lansering, och det är exakt den status du bör tilldela den. Det du kan verifiera självständigt idag är filen: Hugging Face-API:et listar Ternary-Bonsai-2-27B-PTQ1_0.gguf vid 5,947 GB mot FP16-referensen på 53,808 GB, vilket är en minskning med 9,05x och matchar leverantörens "ungefär 9x" utan att man behöver lita på någon. Storleken är ett faktum. Kvalitetsbevarandet är en leverantörsmätning. Det intressanta materialet ligger däremellan – kategoriuppdelningen, som visar exakt var komprimeringen är gratis och var den inte är det.

Det finns också en andra sida av denna lansering. Den 18 september, en dag efter tillkännagivandet, publicerade OrcaRouter en runtime-abliterad variant av samma modell – OrcaRouter Ternary Bonsai 2 27B Uncensored – som tar bort en inlärd vägransriktning vid inferenstid och lämnar vikterna bitidentiska. Den behandlas i ett eget avsnitt nedan, eftersom tekniken är den intressanta delen och eftersom dess begränsningar är lika instruktiva som dess resultat.

Det är en komprimerad Qwen3.8 27B, inte en nyligen tränad modell

Den här distinktionen är skillnaden mellan att förklara lanseringen och att upprepa ett pressmeddelande. Prism ML tränade inte en 27B-modell från grunden och körde inte ett nytt recept för förträning. Det man gjorde var att ta Qwen3.8 27B och ändra den numeriska representation som dess vikter lagras och beräknas i.

Arkitekturen är oförändrad, och den är basmodellens: en hybridattentionsdesign som är ungefär 75 % linjär attention och 25 % full attention, med SwiGLU-MLP-block, RoPE och RMSNorm. Det hybrida stomnätet är också anledningen till att 262K-tokenkontexten beskrivs som kapabel till full kontext snarare än att bara ha stöd — mestadels linjär attention är det som gör en lång kontext överkomlig på en enhet. Modellen är en språk- och visionsmodell: den tar emot både bilder och text, och visionstornet är det ursprungliga, okvantiserade Qwen-tornet, paketerat separat.

Det som Prism ML bidrog med är två saker. Det första är den ternära representationen i sig, plus den kvantiseringsmedvetna träningen som gör den överlevnadsduglig. Det andra är kärnorna – anpassade lågbitkärnor för den hybrida attention-stacken på Apple Silicon och CUDA, som arbetar direkt på de packade vikterna i stället för att packa upp dem till FP16 och multiplicera. Utan det andra bidraget är det första bara ett lagringsformat utan möjlighet att använda det snabbt.

Prism ML:s egen vitbok rapporterar parameterfördelningen som 24,35B i språkstommen över 64 block, 2,54B i inbäddningen och LM-huvudet, och 0,47B i visionstornet med 27 block, totalt 27,36B. Visionstornet är den enda delen som verkligen är en annan artefakt: GGUF-utgåvan paketerar den som en 4-bitars mmproj-fil på cirka 0,63 GB, som endast laddas när en bild faktiskt kommer in, så text-only-serving har den aldrig med sig.

Detta är andra generationens Bonsai från samma labb; den första Bonsai 27B lanserades i juli 2026, ungefär två månader tidigare, och jämförelsen mellan de två generationerna är en rimlig fråga — en som vi tar upp i den direkta jämförelsen mot Bonsai 27B i stället för att upprepa här.

Vad betyder "ternary g128", konkret?

Om du inte har stött på ternära vikter tidigare, är detta stycket som gör allt annat begripligt, så här kommer det utan förkortningar.

En vanlig vikt i ett neuralt nätverk är ett 16-bitars flyttal — omkring 65 536 urskiljbara värden inom ett användbart intervall, och var och en kostar 16 bitar att lagra. En ternär vikt är inte ett litet flyttal. Det är ett val bland tre symboler: −1, 0 eller +1. Det är hela vokabulären. Lagrar man en sådan symbol naivt skulle man göra av med två bitar per vikt, eftersom två bitar ger fyra tillstånd och man bara behöver tre.

I sig självt skulle det vara en katastrofal förlust av uttryckskraft, och det är därför formatet aldrig bara är symbolen. Varje grupp av 128 på varandra följande vikter delar en och samma FP16-skalfaktor, och det faktiska viktvärdet är den ternära symbolen multiplicerad med den skalfaktorn:

• w = ssub>g/sub> · t, där t ∈ {−1, 0, +1} och ssub>g/sub> är en gemensam FP16-skala för gruppen om 128

Så modellen representerar fortfarande ett brett spektrum av magnituder – den representerar dem bara i grova, gruppvisa steg i stället för per vikt. Nollan är inte en avrundningsartefakt; det är ett verkligt tredje tillstånd, och att ha det är vad som gör att en grupp på 128 vikter kan vara mestadels tyst när den behöver vara det.

Den roterade basen är den del som överraskar folk. Innan den ternära tilldelningen sker, transformeras varje viktmatris blockvis genom en ortogonal rotation — en Walsh–Hadamard-matris kombinerad med en fixerad diagonal av ±1-tecken, vid blockstorlek 1024 — och de ternära värdena väljs i det roterade rummet. Rotationen viks in i de lagrade vikterna under förberedelsen, så den kostar inga extra bitar och ingen extra vikttrafik. Vid inferens tillämpar körningsmiljön den matchande transformen på aktiveringarna i stället, och den packade modellen deklarerar sin rotation i sin metadata, så en körningsmiljö antingen tillämpar den matchande transformen eller vägrar att ladda filen.

Varför bry sig? Därför att en Hadamard-rotation sprider energin i en viktmatris jämnare över koordinaterna, vilket gör den efterföljande trenivåkvantiseringen mycket mindre skadlig än den skulle vara på den råa, spetsiga fördelningen. Rotationen är inte en dekoration; den är anledningen till att en ternär modell kan behålla något som liknar förälderns kvalitet. Kostnaden är att transformen ligger på den kritiska vägen för varje projektion vid batchstorlek 1, vilket är ett verkligt ingenjörsproblem — Prism ML införlivar teckenvändningen i transformens laddväg på Metal och parallelliserar den över ett helt trådblock på CUDA för att hindra den från att dominera avkodningen.

Siffrorna, noggrant: 1.585, 1.71, 1.72, 1.76

Fyra siffror för bitbredd cirkulerar kring den här utgåvan, de är alla korrekta, och de mäter fyra olika saker. Att sammanblanda dem är det enskilt enklaste misstaget i den här historien. Här är var och en och vad den faktiskt täcker.

• 1,585 bitar per vikt — informationsinnehållet i en ternär symbol, log₂3. Detta är en egenskap hos formatet, inte hos någon fil. Inget som har släppts körs vid 1,585 bitar/vikt.

• 1,71 bitar per vikt — endast de ternära tensorerna. Lägg till 16-bitars FP16-gruppskalan som amorteras över 128 vikter och du får log₂3 + 16/128 ≈ 1,71. Det är fortfarande ingen siffra för en levererad modell; det gäller de ternära tensorerna isolerat.

• 1,72 bitar per vikt — varje parameter i språkmodellen, inklusive den lilla uppsättning som hålls över den lågbitiga representationen. Prism ML behåller 26 238 464 parametrar — 0,0976 % av språkmodellen, cirka 52 MB i bf16 — i högre precision, mestadels den återkommande tillståndsvägen i de linjära uppmärksamhetslagren plus normaliseringsvikter. Dessa tensorer är varken roterade eller kvantiserade, och det är de som flyttar siffran från 1,71 till 1,72. Vid 1,72 är det idealiserade fotavtrycket 5,80 GB, en minskning med omkring 9,3x. Detta är Prism ML:s "True Ternary"-rad, och det är ett mål snarare än en fil du laddar ner.

• 1,76 bitar per vikt — den faktiskt levererade GGUF-filen. Effektiva kärnor kräver ett packningsformat, och Prism ML:s PTQ1_0 packar triter tätt och landar på 1,76 bitar/vikt i 5,93 GB, cirka 9,1x. Det här är filen bakom både "5,9 GB" och "9x mindre" som tillkännagivandet citerar, och det är den som mätningarna ovan bekräftar.

Den andra packningen är PQ2_0, som lagrar varje trit i en 2-bitarsplats i stället för tätt. Den tar mer utrymme för billigare uppackning: 2,16 bitar/vikt i 7,25 GB, cirka 7,4x. Ingen av packningarna är enhetligt snabbare — PTQ1_0 flyttar ungefär 18 % mindre viktdata per steg men betalar med aritmetik för att packa upp täta trits, så den vinner på Ada-generationskorten och L4 där minnet är den bindande begränsningen, och förlorar på Hopper, Blackwell och Apple silicon där batch-1-avkodning i stället begränsas av instruktionsgenomströmning. Prompt-bearbetning gynnar PQ2_0 överallt, eftersom den är beräkningsbunden.

Två praktiska noteringar för den som kontrollerar dessa mot källorna. För det första avrundar Prism ML:s egna dokument något olika – vitbokens lagringstabell anger PTQ1_0 som 1,76 bitar/vikt vid 5,93 GB, medan GGUF-modellkortet på Hugging Face anger 1,75 och 5,95 GB, och den uppmätta filen är 5,947 GB. Detta är samma fil beskriven med olika precision, inte en meningsskiljaktighet i sak. För det andra är den aviserade minskningen på ”mer än 9x” leverantörens; mätt mot de faktiska filerna är den 53,808 / 5,947 = 9,05x, vilket stämmer.

Benchmarkbilden: inte genomsnittet, formen

Rubriksiffran är ett genomsnitt på 83,9 mot 85,4 för baslinjen Qwen3.8 27B FP16, vilket är 98,2 %. Själva genomsnittet är den minst intressanta delen. Formen under ytan är där den verkliga informationen finns, och den är inte enhetlig.

• Instruktionsföljning — 82.66 vs 81.25. Detta är den enda kategorin där den komprimerade modellen slår sin fullprecisionsförälder. Det är inte brus som någon i förbigående kan bortförklara; det är en kategorivinst i leverantörens egen svit.

• Matematik — 96,57 mot 97,06, och kodning — 81,58 mot 82,17. Båda i stort sett jämna: en halv poäng och sex tiondels poäng på kategorigenomsnitten. För en modell med en niondel av fotavtrycket är detta de resultat som hela tekniken argumenteras utifrån.

• Kunskap och resonemang — 83,95 mot 86,66. Ett tapp på 2,7 punkter, och det är här en betydande del av de 1,8 saknade punkterna i totalgenomsnittet finns.

• Vision — 78,59 vs 81,64. En minskning med 3,05 punkter, den största enskilda kategoriförlusten. Värt att notera att vision-tornet i sig inte är den komprimerade delen; det är språkmodellen som läser dess utdata som är det.

• Agentisk AI och verktygsanrop — 77,57 mot 79,74. Kategorigenomsnittet omfattar τ 2-Bench på 80,22 och BFCL v3 på 74,92.

Individuella resultat värda att känna till, eftersom de inte alla pekar i samma riktning. På Terminal-Bench 2.1 får modellen 52,8 mot 69,7 för full precision – ungefär tre fjärdedelar – och på SWE-bench Verified får den 60,8 mot 80,6, återigen ungefär tre fjärdedelar. Detta var första gången den här modellfamiljen utvärderades på Terminal-Bench, och Prism ML säger uttryckligen att de långsiktiga vinsterna inom mjukvaruutveckling som utlovades i den första Bonsai-versionen är partiella, inte fullständiga. Å andra sidan: τ 2-Bench steg till 80,2 från 73,6 i den föregående versionen, BFCL v3 ligger kvar på 74,9 och AA-LCR ligger på 77,0, inom en poäng från full precision. AIME26 hamnar på 95,83 och LiveCodeBench på 90,07.

Var man kan lita på det – och var man inte kan.Lita på mönstret för matematik, kodning och instruktionsföljning – det är de kategorier där tekniken bevisligen gör vad den påstår sig göra, och de mäts i samma testramverk som baslinjen. Var försiktig med långsiktigt agentiskt arbete: de två benchmarktester som verkligen belastar uthålligt, verktygsdrivet ingenjörsarbete, Terminal-Bench 2.1 och SWE-bench Verified, visar en påtagligt större skillnad än vad aggregatet antyder, och leverantören säger det i stället för att dölja det. Och behandla hela tabellen som ett enda labbs mätning i ett enda testramverk tills någon annan kör den. Det förbehållet är inte en formalitet här – det är skillnaden mellan ”den här modellen behåller 98,2 %” och ”den här modellens leverantör uppmätte 98,2 % på en testsvit som leverantören valde.” Båda är sanna; bara ett av dem är ett faktum om modellen.

Varför detta överträffar en IQ2_XXS-build av samma basmodell

Detta förtjänar ett eget avsnitt i stället för en rad, eftersom det är hela argumentet för kvantiseringsmedveten ternär träning jämfört med kvantisering efter träning.

Det konventionella sättet att göra Qwen3.8 27B liten är att kvantisera den efter träning. Jämförelsepunkten i vitboken är en IQ2_XXS GGUF-build av samma basmodell:

• Ternary Bonsai 2 27B — 1,76 bitar/vikt, 5,93 GB, genomsnitt över 20 benchmarks: 83,9

• Qwen3.8 27B IQ2_XXS — 2,2 bitar/vikt, 7,3 GB, medelvärde över 20 benchmarks 75,2

Den träningskomprimerade modellen är både mindre och bättre. Den är 1,23x mindre än det konventionella lågbitbygget och får 8,7 poäng högre. Den kombinationen är inte en avrundningskuriositet; det är påståendet att en representation som väljs under träning är värd avsevärt mer än samma nominella bitbudget som tillämpas i efterhand.

Den mer lärorika delen är hur den konventionella byggversionen misslyckas, eftersom misslyckandet är selektivt och lätt att missa. IQ2_XXS försämras inte jämnt. Den håller stånd på ytlig kunskap – 85,79 på MMLU-Redux – medan den kollapsar på uppgifter som kräver långvariga kedjor av resonemang: 78,6 på AIME26, 70,05 på LiveCodeBench, 65,45 på GPQA Diamond. Bonsai 2 får 95,83, 90,07 och 85,76 på samma tre. Ett informellt chatt-test skulle finna IQ2_XXS-bygget helt användbart och aldrig avslöja kollapsen; skadan ligger precis där långa resonemang och kodgenerering sker. Den asymmetrin är anledningen till att "det kändes bra när jag provade det" inte är bevis om en kvantiserad modell.

Prism ML komprimerar samma argument till en enda härledd siffra som företaget kallar intelligensdensitet – grovt räknat benchmarkkapacitet per gigabyte. I testsviten med 20 benchmarks rapporterar företaget 0,444 per GB för Bonsai 2, 0,276 för IQ2_XXS-versionen och 0,051 för FP16. Metriken är leverantörens egen konstruktion och dess viktning är ett designval, inte en lag; men den ordning den ger är samma ordning som den råa tabellen ger, så den tillför tolkning snarare än bevis.

Ytterligare en ärlig kommentar om jämförelsen. Prism ML:s GGUF-modellkort rapporterar en andra, snävare utvärdering – en svit i tankeläge med 14 benchmarks – där samma bevarandevärde återigen visas vid 84,78 mot 86,32, med IQ2_XXS på 72,59. Att två olika sviter landar på samma 98,2 % är ett svagt stöd för att det sammanvägda påståendet inte är en artefakt av ett enda benchmarkurval. Det är fortfarande samma labb som kör båda, i samma testramverk. Vår mer fullständiga genomgång av den här matchningen, inklusive frågan om packningsformat, finns i jämförelsen mot Qwen3.8 27B GGUF-byggena.

Vad som faktiskt krävs för att driva

Genomströmningstalen, från vitbokens standardiserade tg128-mätning vid batchstorlek 1 med visionstornet exkluderat:

• Apple M5 Max — 46,8 tok/s avkodning, 765 tok/s promptbearbetning

• Apple M5 Pro — 27,7 tok/s vid avkodning; en separat körning med längre fönster av PQ2_0-paketet uppmätte 27,0 tok/s uthålligt och drog 27,0 W på GPU-skenan samt 32,8 W över CPU och GPU

• Apple M4 Pro — 18,0 tok/s avkodning, med prompt-bearbetning på ungefär 125 tok/s som blir den begränsande faktorn för mycket långa kontexter

• NVIDIA RTX 5090 — 142,5 tok/s avkodning på PQ2_0-paketet vid 0,582 mWh per token

Det praktiska påståendet som Prism ML gör är inte ett uppsnabbningsförhållande utan en frånvaro: FP16-baslinjen på 53,8 GB får inte plats på en 16 GB laptop överhuvudtaget, så det meningsfulla påståendet är att en modell i 27B-klassen nu körs interaktivt på vardaglig hårdvara. På M5 Pro strömmar den uppmätta avkodningen omkring 201 GB/s av vikter, vilket bekräftar den minnesbandbreddsdominerade profil som lågbitrepresentationen är utformad att utnyttja.

Sedan är det gränsfallen, som är viktigare än toppsiffrorna.

Du kan inte använda standardversionen av llama.cpp. De ternära hybrid-attention-kärnorna finns i Prism ML:s egen llama.cpp-fork. Standardversionen av llama.cpp avvisar typerna PTQ1_0 och PQ2_0 som okända och – ännu farligare – laddar det äldre ternära formatet Q2_0 utan någon varning och producerar skräp, eftersom den inte har någon Hadamard-aktiveringsruntime. Om du kör den här modellen på en binär som inte tillämpar den matchande rotationen får du inget felmeddelande; du får flytande nonsens. Detta är det enskilt mest sannolika sättet att slösa bort en eftermiddag på den här utgåvan.

MLX-paketet har ingen CUDA-väg. MLX-utgåvan (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) riktar sig mot Apple Silicon, där den har anpassade kärnor för den hybrida stacken i både Python- och Swift-runtimeerna. Dess kvantiserade matmul har Metal- och CPU-kärnor men ingen CUDA-implementering, så på en NVIDIA-maskin får just det paketet ingen GPU-acceleration alls. CPU-inferens fungerar, men en 27B-forward-pass på CPU kan ta minuter – vilket gör Linux-CPU-vägen användbar för implementeringstestning och reproducerbarhet, och oanvändbar för servering.

De två paketen är ett genuint avvägande, inte en rangordning. Om du använder ett kort i Ada-generationen eller ett L4, eller om minnet är den begränsande faktorn, är PTQ1_0 valet vid 5,93 GB. Om du använder Hopper, Blackwell eller ett 5090 ger PQ2_0 dig avkodningshastighet för 1,3 GB. Om du använder Apple silicon, notera att M5 Pro-siffrorna ovan är uppmätta på PQ2_0, vilket också är paketet som demouppsättningen laddar ner som standard.

En notis om MLX-paketets egen redovisning, eftersom det är en vanlig källa till förvirring. MLX-behållaren är ett affint 2-bitarsformat vars block lagrar både en FP16-skala och en FP16-bias för varje grupp om 128 vikter. Bonsais ternära vikter behöver bara skalan – nivåerna kommer enbart från skalan – så biasen är död vikt, och blocket kostar 36 byte per 128 vikter i stället för 34. Det driver MLX-paketets packningstakt till 2,250 bitar/vikt, inte 1,72 och inte 1,76. Det är en annan behållare som bär samma ternära värden, och dess uppmätta fil på Hugging Face är 8,005 GiB.

Den runtime-abliterade varianten

Den 18 september publicerade OrcaRouter OrcaRouter Ternary Bonsai 2 27B Uncensored, som tillämpar refusal-direction-ablation på den här modellen helt i körtid. Den tekniska idén är värd mer uppmärksamhet än produkten, så här kommer idén först.

Konventionell abliteration redigerar vikter. Den hittar en riktning i aktiveringsrymden som motsvarar vägranbeteende och ortogonaliserar sedan de viktmatriser som skriver in i residualströmmen mot den: W ← W − r(rᵀW). På en vanlig FP16-modell är det okej — den redigerade matrisen är fortfarande en tät flyttalsmatris, så du sparar den och går vidare. I en ternär packning är det en återvändsgränd, och specifikt är det en återvändsgränd av just det skäl som hela den här modellen finns. Att ortogonalisera en ternär matris ger en tät matris med full precision. För att lagra tillbaka det i den ternära packningen skulle du behöva omkvantisera — och att omkvantisera redigerade vikter återskapar inte den kvantiseringsmedvetna träningen som producerade originalet. Du skulle kasta bort precis det som köptes.

Så projektionen flyttas i stället till inferenstid. I stället för att ändra W, ändra dess utdata:

• y ← y − α · dot(y, r) · r, beräknat i float32, där y är ett residualbidrag och r är den normaliserade vägransriktningen

Vid α = 1 tas komponenten av varje residualskrivning som är parallell med vägransriktningen bort. Vid α = 0 är modellen orörd. α över 1 överprojicerar och kan försämra kvaliteten. Eftersom α är en körtidsparameter snarare än en checkpoint-egenskap kan samma paket A/B-testas mot sig självt i samma process – vilket är precis vad OrcaRouters utvärderingar gör. Det ursprungliga Bonsai-paketet förblir bitidentiskt: noll vikter ändrade, noll omkvantisering, noll ytterligare kvantiseringsfel i vikterna.

Två implementeringsdetaljer är där en naiv version av detta misslyckas.

129 interventionsplatser, inte 16. Varje modul som kan skriva till residualströmmen måste lindas in, och i denna hybridarkitektur är det 64 mlp.down_proj-block, 48 linear_attn.out_proj-lager, 16 self_attn.o_proj-lager och model.embed_tokens — 129 totalt. Att endast linda in self_attn.o_proj är det uppenbara misstaget och det fångar 16 av dem, vilket lämnar de övriga 113 skrivningarna oprojicerade. Ett självkontrollskript mäter om den kvarvarande komponenten längs vägransriktningen drivs till ungefär 1e-6 av residualnormen, och varnar om det inte upptäcker alla 129 platser.

Återrotera inte riktningen. Ternärpaketet behåller sina projektioner i en roterad bas på deras indatadimension och kompenserar på aktiveringssidan. Vägransprojektionen verkar på utdata från dessa projektioner, som redan är tillbaka i den normala dolda basen — så vägransriktningen är en vanlig 5120-dimensionell vektor och att applicera en ytterligare Hadamard-rotation på den skulle projicera mot en helt felaktig bas.

Vad OrcaRouter mätte – våra egna siffror, inte oberoende.

Detta är OrcaRouters egna regelbaserade mätningar, och de bör läsas som sådana: en regelbaserad klassificerare för inledningsfraser, inte en LLM-domare, tänkande avstängt, greedy-avkodning, 64-tokenbudget, där bas och ablaterad är samma vikter i samma process vid α = 0 mot α = 1. De är indikativa, inte av publiceringskvalitet, och de utgör inte en verifiering av något som Prism ML hävdade.

För vägran, mätt som andelen promptar som fick en vägran:

• AdvBench (n=100) — 99,0 % bas, 6,0 % ablaterad, med 56,0 % besvarade men inlindade i en ansvarsfriskrivning

• JailbreakBench (n=100) — 96,0 % bas, 4,0 % ablaterad, 52,0 % med förbehåll

• StrongREJECT (n=150) — 99,3 % bas, 3,3 % ablaterad, 45,3 % med förbehåll

• HarmBench (n=150) — 98,7 % bas, 7,3 % ablaterad, 48,0 % med förbehåll

• MaliciousInstruct (n=100) — 97,0 % bas, 0,0 % ablationerad, 52,0 % med förbehåll

• ForbiddenQuestions (n=150) — 75,3 % bas, 5,3 % ablaterad, 42,7 % med förbehåll

• SimpleSafetyTests (n=50) — 96,0 % bas, 18,0 % ablaterad, 60,0 % med förbehåll — och denna siffra är underskattad. Den uppsättningen består mestadels av självskadepromptar, och modellen besvarar dem med en krisomdirigering som inleds med "Jag är djupt ledsen att höra…", vilket klassificerarens exakta fraslista missar och bedömer som efterlevnad. Den verkliga kvarvarande avböjningsfrekvensen för den uppsättningen är högre än 18,0 %. Klassificeraren lämnades medvetet oförändrad så att siffrorna förblir jämförbara med OrcaRouters andra modellkort.

Inget svar i någon uppsättning tog slut på sin tokenbudget, så ingen av dessa frekvenser är uppblåst av trunkering. På ofarliga promptar tar samma projektion också bort överdriven vägran: XSTest-safe sjönk från 5,2 % vägran till 0,4 %, och den ofarliga delmängden av JailbreakBench från 25,0 % till 0,0 %. Det publicerade paketet avvisar en fjärdedel av den benchmarkens ofarliga promptar; ablaterat avvisar det inga.

Vad gäller kapacitet innebär det att vikterna är bitidentiska att det inte finns någon omkvantisering att betala för, och mätningarna stämmer överens med det:

• MMLU (n=300) — 76,7 % bas, 77,7 % ablaterad, +1,0

GSM8K (n=150) — 87,3 % bas, 86,0 % ablationerad, −1,3

• CMMLU (n=500) — 76,2 % bas, 75,6 % ablationerad, −0,6

Varje förändring ligger inom bruset vid dessa urvalsstorlekar; en enda GSM8K-fråga är värd 0,7 poäng. MMLU-Pro utesluts i stället för att rapporteras: dess prompt begär resonemang före svaret, och 63–64 % av svaren på båda sidor hade inte nått fram till ett sådant inom tokenbudgeten, så en eventuell träffsäkerhetssiffra skulle vara ett golv som bestäms av budgeten snarare än en mätning.

Det förbehåll som spelar störst roll

Vägransriktningen uppskattades från BF16-basmodellen som Bonsai-paketet tränades från. Arkitekturen och den dolda basen är identiska, så geometrin stämmer. Men hur väl den riktningen överlever kvantiseringsmedveten träning har inte fullt ut mätts.

Körtidsmiljön kan matematiskt, och med en noggrannhet på cirka 1e-6, bevisa att den tar bort den angivna riktningen från varje residualskrivning. Den kan inte enbart utifrån detta bevisa att riktningen fortfarande fångar samma beteendemässiga egenskap i den kvantiserade modellen som den fångade i den täta modellen. Det är olika påståenden, och bara det första är avgjort. Den som läser säkerhetstabellen ovan bör läsa den med vetskapen att interventionen är exakt lika effektiv som antagandet om riktningsöverföring, och att detta antagande är den öppna frågan.

Det finns också den praktiska inramning som OrcaRouter ger själva lanseringen, och den är värd att upprepa snarare än att försöka parafrasera bort: att ta bort en inlärd vägransriktning kan få en modell att svara på förfrågningar som originalet skulle ha avböjt. Detta är en forsknings- och inferenskontrollmekanism, inte bevis för att någon resulterande utdata är säker, korrekt eller lämplig, och driftsättningar som använder den bör tillämpa sina egna åtkomstkontroller och policyverkställighet. Att ta bort vägran är inte en gratis förbättring, och den här texten är inte skriven som om den vore det.

Tre ytterligare praktiska noter för alla som reproducerar det. Paketet måste läsas in med sin egen medföljande körtid – en vanlig MLX-laddare kan se ut att läsa in det framgångsrikt medan den i tysthet beräknar fel sak, så om utdata ser fel ut redan innan ablation har aktiverats, kontrollera först inläsningsvägen. Lagerväljande ablation stöds, så interventionen behöver inte vara allt-eller-inget. Och ablationens utvärdering kördes på den utvikta FP16-expansionen av paketet i stället för att paketet drev sina egna kärnor, eftersom den packade kvantiserade matmul-operationen saknar CUDA-implementation och CPU-backenden behöver minuter per framåtpassning; den expansionen bär paketets ternära värden exakt och återger paketets egna nästa-token-fördelningar till tre decimaler vid stickprov, men det är en containerändring och värt att känna till. Koden och de fullständiga tabellerna finns i repositoriet OrcaRouter Ternary Bonsai 2 27B Uncensored. En separat jämförelse som omfattar det ablaterade MLX-bygget mot den omodifierade Qwen3.8 27B MLX-vägen går djupare in på körtidsspecifika detaljer.

Vart det här leder, och vad som fortfarande är obevisat

Vad en nästan förlustfri 27B-modell på ungefär sex gigabyte förändrar för lokala agenter handlar mest om vad som blir kvar i minnet. En språkmodell som får plats tillsammans med ett riktigt kontextfönster på en 16 GB-laptop kan förbli laddad medan en agent utför annat arbete – läser filer, anropar verktyg, håller en plan över flera turer – i stället för att växlas in per begäran eller skickas till en server. Det är skillnaden mellan en lokal modell som du testar och en lokal modell som du låter köra, och det är just den egenskap som de agentiska siffrorna, τ 2-Bench på 80.2 och BFCL v3 på 74.9, är till för att stödja.

Det som är obevisat är en längre lista än vad tillkännagivandet antyder.

• Ingen oberoende reproduktion. Varje kvalitetsvärde i den här artikeln – 83,9, 98,2 % och kategorigenomsnitten – är Prism ML:s egen mätning på Prism ML:s egen testsvit. Det är inte en defekt i släppet; det är helt enkelt så det ser ut när något bara är en dag gammalt. Det är också det första som kommer att ändras.

• Långsiktigt agentiskt arbete är den svagaste delen i leverantörens egen tabell, inte den starkaste. Terminal-Bench 2.1 med 52,8 mot 69,7 är en verklig klyfta, och leverantören säger att förmågan är partiell.

• Prompter du inte har testat. Felprofilen för lågbitmodeller är selektiv, och IQ2_XXS:s kollaps på AIME26 och LiveCodeBench medan den behåller 85,79 på MMLU-Redux är det tydligaste tillgängliga beviset för att ett benchmarkgenomsnitt inte säger dig vad som händer i din arbetsbelastning. Bonsai 2 uppvisar inte den kollapsen på dessa två benchmarks, vilket är uppmuntrande och inte detsamma som en garanti.

• Frågan om riktningsöverföring i den abliterade varianten, ovan, som är olöst av konstruktion.

• Huruvida kärnorna håller måttet när körmiljöerna utvecklas. Just nu kräver den här modellen en fork; standardversionen av llama.cpp avvisar två av de tre formaten och förvanskar tyst det tredje. Tills dessa kärnor har landat uppströms är "körs överallt där llama.cpp körs" ännu inte sant för den här modellen.

Själva släppet är inte ifrågasatt. En multimodell i 27B-klass på 5,93 GB, vid en niondel av fotavtrycket för det den komprimerats från, med matematik och kodning i nivå med föräldramodellen och instruktionsföljning något bättre, är en genuint annan arbetspunkt för lokal inferens. Den rimliga hållningen den 18 september 2026 är att betrakta filstorleken som ett faktum, betrakta retentionssiffran som ett försiktigt leverantörspåstående som gjordes för en dag sedan på en testsvit som leverantören valt, och att avvakta med omdömet om din egen arbetsbelastning tills du har kört den på den.

Koden för runtime-ablation, refusal-riktningen och de fullständiga utvärderingstabellerna publiceras av OrcaRouter, tillsammans med den routingplattform som teamet bygger.