A PrismML új modellje, a Ternary Bonsai 2 27B azt ígéri, hogy a Qwen3.8 27B tudásának 98,2%-át hozza, mindezt 54 GB helyett 5,9 GB-on. A szám igaz, csak nem mindegy, mire nézzük. Átnéztük a hivatalos adatokat, egy független mérést és a közösség kritikáit is, hogy kiderüljön: kinek való ez a modell, és kinek nem.
Mi az a ternáris kvantizáció?
Egy nyelvi modell lényegében milliárdnyi számból, úgynevezett súlyból (weight) áll. A teljes pontosságú (FP16/BF16) modellben minden súly 16 biten tárolódik. A hagyományos kvantizáció (a súlyok kisebb pontosságú tárolása) ezt jellemzően 8, 4 vagy 2 bitre csökkenti, általában utólag, a már betanított modellen. A ternáris megoldás radikálisabb: minden súly csak három értéket vehet fel (-1, 0 vagy +1), és ehhez csoportonként egy közös skálázó szám tartozik. A Bonsai 2 így súlyonként átlagosan 1,76 bitre jön ki.
Miért jó ez? Egyrészt drasztikusan kisebb a memóriaigény: a modell elfut egy 16 GB-os laptopon vagy egy 24 GB-os GPU-n. Másrészt a -1/0/+1 értékeknél a szorzások nagy része egyszerű összeadássá vagy kihagyássá egyszerűsödik, ami gyorsabb és energiatakarékosabb futást tesz lehetővé. A PrismML szerint egy RTX 4090-en tokenenként mindössze 0,714 mWh-t fogyaszt.
A dolog szépséghibája, hogy ekkora tömörítésnél a modell általában a legkényesebb képességeiből veszít először. A ternáris súlyok ráadásul egyedi kernelt (a hardveren futó számítási rutint) igényelnek, ezért a Bonsai csak a PrismML saját llama.cpp forkjával vagy MLX runtime-mal fut, és közösségi visszajelzések szerint a megszokott gyorsítási trükkök egy része, például a spekulatív dekódolás (egy kis draft modellel gyorsított generálás), egyelőre nem működik vele. Fontos kiemelni azt is, hogy a PrismML nem publikálja pontosan, hogyan rendeli hozzá a ternáris értékeket.
Mit mondanak a hivatalos számok?
A PrismML 20 benchmarkon mérte a modellt thinking módban: a Bonsai 2 átlaga 83,9 pont, a teljes Qwen3.8 27B-é 85,4. Matekban (96,57 vs. 97,06) és kódolásban (81,58 vs. 82,17) szinte nincs különbség, instrukciókövetésben pedig a tömörített modell még jobb is. A legnagyobb veszteség a tudás/reasoning (83,95 vs. 86,66) és a vision (78,59 vs. 81,64) kategóriában van.
Ami igazán erős érv a Bonsai mellett: a hagyományos 2 bites kvantizáció (IQ2_XXS) ugyanabból a Qwenből 7,3 GB-on csak 75,2 pontos átlagot hoz, a LiveCodeBench v6-on pedig 70,05 pontot a Bonsai 90,07-ével szemben. Vagyis kisebb méretben lényegesen jobb, mint amit eddig az utólagos tömörítés tudott.
A 98,2% apró betűs része
A gond ott kezdődik, ahol a modellnek sok lépésen át, önállóan kell dolgoznia. A whitepaper szerint a SWE-bench Verified teszten (valós GitHub-hibák javítása) a Bonsai 60,8 pontot ér el a Qwen 80,6-jával szemben, a Terminal-Bench 2.1-en pedig 52,8-at 69,7 helyett. Ez 17-20 pontos esés, ami köszönő viszonyban sincs az átlagos 1,8%-kal. A hivatalos agentic kategória (77,57 vs. 79,74) azért néz ki jól, mert a τ²-bench és a BFCLv3 inkább rövidebb, néhány lépéses tool calling feladatokat mér.
Az X-en emiatt többen tisztességtelen marketinget kiáltottak, de ez túlzás: a számok benne vannak a whitepaperben, nem titkolták el őket. Az viszont igaz, hogy a launch posztban és a fő táblázatban nem szerepelnek, pedig egy cég számára gyakran éppen ezek a legfontosabbak.
Független mérés: 27B reasoning, 12B kód
A lab.net-sphere.ai egyetlen RTX PRO 6000-en, azonos harness-szel és 0-s hőmérsékleten futtatta le a Bonsai 2-t (itt a nagyobb, 7,2 GB-os PQ2_0 csomagolást), a teljes Qwen3.8 27B-t, valamint a Gemma 4 12B-t és a Gemma 4 E4B-t. Az eredmény egy mondatban: reasoningben 27B, kódban inkább 12B szint.
| Teszt | Qwen3.8 27B BF16, 55 GB |
Bonsai 2 27B ternáris, 7,2 GB |
Gemma 4 12B Q4_0, 7,0 GB |
Gemma 4 E4B Q4_0, 4,3 GB |
|---|---|---|---|---|
| GSM8K (matek) | 480/500 | 480/500 | 479/500 | 462/500 |
| Tű a szénakazalban (32K kontextus) | 40/40 | 40/40 | 29/40 | 29/40 |
| AIME 2025 (versenymatek) | 27/30 | 25/30 | 15/30 | 10/30 |
| HumanEval (kódolás) | 157/164 | 147/164 | 154/164 | 143/164 |
| MBPP (kódolás) | 401/500 | 372/500 | 402/500 | 355/500 |
| Nehezebb repók (81 feladat) | 78/81 | 70/81 | 69/81 | 71/81 |
| „Csapda” feladatok (34 db) | 25/34 | 15/34 | 15/34 | 9/34 |
| Sebesség (token/s) | 95 | 182 | 415 | 1086 |
Forrás: lab.net-sphere.ai, egyetlen RTX PRO 6000, azonos harness, 0-s hőmérséklet.
Ezzel egybevágnak a közösségi tapasztalatok is: egyszerű chatben és egy-két lépéses feladatokban a modell jól teljesít, de 3-4 lépés után hajlamos elveszíteni a fonalat, és tool calling közben időnként hibás JSON-t ad vissza (főleg hosszú stringeknél), amit a szerver nem tud feldolgozni. Egyes elemzések szerint a lemaradás nagy része ilyen „mechanikai” hibákból fakad, nem butaságból, de egy automatizált workflow-ban ez gyakorlatilag mindegy: a hibás JSON megállítja a folyamatot. A megjelenés utáni napokban egyes Mac gépeken (pl. M5 Max) a futtatással is akadtak gondok.
Mit jelent ez egy cégnek?
Ha lokális, adatvédelmi szempontból biztonságos AI-t szeretnél, a Bonsai 2 izgalmas opció: Apache 2.0 licenc, 262K tokenes kontextus, képértés, és elfut egy jobb laptopon is. Belső dokumentumok elemzésére, összefoglalásra, RAG rendszerekben kérdés-válaszra vagy egylépéses kódsegédként kifejezetten jó választás lehet, különösen ha a hardver a szűk keresztmetszet.
Ha viszont hosszú, több lépésből álló agentic folyamatokat vagy komoly kódoló agentet építenél, jelenleg jobban jársz a teljes Qwen3.8 27B egy 4 bites kvantizált változatával (ha van rá elég VRAM), vagy ha a sebesség számít, a Gemma 4 12B-vel, amely hasonló méretben kódolásban ugyanazt vagy többet hoz, több mint kétszer gyorsabban.
A Bonsai 2 27B tehát nem csalás, hanem valódi technikai bravúr, amit csak egy kicsit túl lelkesen árulnak. A kérdés inkább az, mikor éri utol a hosszú feladatokban is a nagy testvérét, mert ha ez megtörténik, a lokális AI gazdaságossága alapjaiban változik meg.
Forrás: PrismML, MarkTechPost, OrcaRouter, lab.net-sphere.ai (független mérés), közösségi visszajelzések az X-ről