Kísérleti napló · 2026-06-04
Létezik ez a modell
egyáltalán?
Egy ismerős ledob egy HuggingFace-linket: gemma-4-26B 'TurboQuant'. „Lefuttatunk pár perftesztet?” Mire eldől, mi valódi belőle, egy egészen más felfedezésig jutunk.
A felkérés, ami egyszerűnek tűnt
„Tudunk futtatni pár perftesztet az otthoni gépen ezzel a modellel?” — és egy link egy gemma-4-26B-A4B-TurboQuant nevű HuggingFace-repóra.
A gép Aemie: egy otthoni Ryzen AI 9 box, AMD Radeon 890M iGPU-val, ami a saját privát Claude-asszisztensemet és egy egész inference-stacket futtat. Nem egy eldobható homokozó.
Szóval az első reflex nem a letöltés volt, hanem egy kérdés: tényleg az, aminek látszik?
A név gyanúsan csengett
Több apró jel együtt: a majentik egy ismeretlen feltöltő; a „TurboQuant” mint kész termék-csomag; és az ígéret, hogy egy pip-csomagot meg egy llama.cpp-forkot kell telepíteni hozzá.
Az aranyszabály: mielőtt bármit letöltesz vagy futtatsz a gépen, ami az asszisztensedet üzemelteti, ellenőrizd a forrást. Egy ismeretlen pip-csomag tetszőleges kódot futtat — a te gépeden, a te jogaiddal.
Verifikáció
Mi valódi, és mi marketing-zaj
A base modell valódi. google/gemma-4-26B-A4B — tényleg a Google adta ki (2026-03), ~130 000 letöltés, valódi súlyokkal.
A technika valódi. A TurboQuant egy publikált Google-kutatás (ICLR 2026): véletlen forgatás + skalár kvantálás a KV-cache-en.
De a repó üres. A 'majentik/...-TurboQuant' nem tartalmaz egyetlen súlyfájlt sem — csak egy README-t. 0 byte tárhely, 0 letöltés. Doc-repó, nem modell.
A körítés túloz. „Bit-azonos a 4-biten” — a paper ezzel szemben ~3,5 bit/csatorna minőség-semlegességet mond. A 18 felsorolt 'variáns' mind üres.
Supply-chain szünet
Elolvasni, mielőtt lefuttatod
A turboquant pip-csomagot nem telepítettem — letöltöttem és statikusan átolvastam. 926 sor, tiszta Python/torch.
Tiszta
- · Nincs hálózati hívás
- · Nincs subprocess / shell / eval
- · Nincs install-time hook
- · A paper hű implementációja
De
ismeretlen kiadó (back2matching), brand-new csomag, semmi homepage. Tiszta forrás ≠ örök bizalom — csak azt jelenti, hogy ezt a verziót elolvastam.
A felépítés szép: véletlen ortogonális forgatás, per-koordináta optimális kvantáló, KIVI-stílusú residual ablak a friss tokeneknek.
A hardver-fal: nincs CUDA
Aemie egy AMD iGPU Vulkan-on. A turboquant csomag viszont CUDA-default és transformers-alapú: itt csak CPU-n futna, bf16-ban (~52 GB) — ami be sem fér.
A planar3 KV-cache (a TurboQuant llama.cpp-útja) ráadásul nincs az upstreamben — egy ellenőrizetlen forkot kéne buildelni hozzá. Vagyis a single, ami ténylegesen az iGPU-t terhelné, egyben a legkockázatosabb is.
Döntés: a megbízható úton megyünk. A valódi base modellt benchmarkoljuk egy reputábilis GGUF-kvanttal (ggml-org), a stock Vulkan llama.cpp-vel — és megnézzük, mit ad az upstream KV-quant, amit a TurboQuantnak meg kéne vernie.
A csavar
gemma-4 = nagyrészt sliding-window attention
A GGUF-metaadatból: 30 rétegből csak 5 full-attention, a többi 25 SWA (1024 tokenes ablak). A SWA rétegek akármilyen hosszú a kontextus, csak 1024 tokent cache-elnek.
Réteg-minta (S = sliding, F = full)
Következmény: a KV-cache — a legtöbb modell memória-fájdalompontja hosszú kontextuson — itt alig nő. És pont a KV-cache az, amin a TurboQuant segítene. A csavar: a kísérlet tárgya saját magát teszi feleslegessé.
A KV-memória, számolva
A SWA-t is figyelembe véve, 64k kontextuson, három KV-formátumra. (A 25 SWA réteg ebből végig csak ~0,2 GiB.)
| kontextus | KV f16 | KV q8_0 | KV q4_0 |
|---|---|---|---|
| 16k | 1.45 GiB | 0.77 GiB | 0.41 GiB |
| 65k | 5.20 GiB | 2.76 GiB | 1.46 GiB |
65k-n f16-ban is csak 5,2 GiB — egy 45 GB szabad RAM-os gépen ez semmi. És a stock upstream q4_0 ezt fork nélkül 1,46 GiB-re viszi. Itt egyszerűen nincs memória-probléma, amit meg kéne oldani.
Sebesség 1 — prefill
gemma-4-26B-A4B-it Q4_K_M (15.63 GiB), Radeon 890M / Vulkan, prompt-feldolgozás (t/s). Az érdekes: a KV-kvantálás nem segít — hosszú kontextuson kifejezetten ront.
| KV | pp512 | pp16384 | pp65536 |
|---|---|---|---|
| f16 ★ | 467 | 372 | 240 |
| q8_0 | 449 | 312 | 172 |
| q4_0 | 433 | 333 | 185 |
Prefillben az f16 a leggyorsabb mindenhol. A KV-kvantálás compute-overhead, ami 65k-n q8_0-nál már 28%-ot is elvisz (240 → 172).
Sebesség 2 — decode mélységben
Token-generálás (t/s) a kontextus-mélység függvényében. Itt megfordul a kép: decode-ban a q4_0 a leggyorsabb, és az előnye nő a mélységgel.
| KV | @ 0 | @ 16k | @ 65k |
|---|---|---|---|
| f16 | 24.6 | 20.7 | 16.4 |
| q8_0 | 24.3 | 21.4 | 17.6 |
| q4_0 ★ | 25.5 | 21.9 | 18.5 |
Miért fordul meg? A deep-context decode memóriasáv-limitált a KV-olvasáson: a kisebb (q4_0) cache kevesebb bájtot mozgat → gyorsabb. 65k-n +13% (16,4 → 18,5). De ezt is megadja az upstream — fork nélkül.
Kontextus
Hogy áll a mostani házi modellünkhöz?
Fontos: a házi Qwen-ünk nem a gyári 35B — egy korábbi kísérletben expert-pruninggal K=187-re vágtuk (256→187 expert, 21,3→15,9 GiB), és 2026 májusa óta ez fut élesben. Tehát a gemma-4-et a már megnyirbált házi modellhez mérjük — ami történetesen pont ugyanakkora.
| Qwen3.6-A3B · aemie K=187 | gemma-4-26B-A4B | |
|---|---|---|
| Aktív / összes | 3B / ~26.6B | 4B / 26B |
| GGUF (Q4) | 15.9 GiB | 15.6 GiB |
| Decode | ~21.9 t/s | ~24.6 t/s |
Majdnem azonos méreten (15,6 vs 15,9 GiB) a gemma-4 ~12%-kal gyorsabban dekódol — és ezt a már pruneolt házi modellünkhöz képest. Amiért nálunk egy éjszakányi expert-sebészet kellett (a méret), azt a gemma dobozból hozza. Komoly jelölt a házi stackbe.
A decode pruning-független (csak 8 expert aktív/token), ezért K=187 ≈ K=192 sebesség. A gyári MTP-variáns speculative decodinggal 25,8 t/s-ig megy, de a deployolt pruned edition nem MTP. A decode-számok llama-bench tg-futásokból valók → tájékoztató.
Verdikt
A TurboQuant-fork itt nem éri meg
SWA miatt a KV eleve kicsi. 65k-n f16-ban is csak 5,2 GiB. Nincs megoldandó memória-probléma.
Az upstream q4_0 már lefedi a hasznot. Fork nélkül: 1,46 GiB KV @65k és a leggyorsabb decode mélységben (+13%).
A korábbi Qwen-mérésünk ugyanezt mondta. „Egyetlen tuning-kapcsoló sem ver rá az upstream defaultra 1%-nál többet.” A fal a memóriasáv (LPDDR5x ~120 GB/s), nem a KV-formátum.
Tanulság
A jó válasz nem az volt, amit kerestünk
Az eredeti kérdés az volt: „gyorsít-e a TurboQuant ezen a modellen?” A valódi válasz: a kérdés rosszul van feltéve — ezen az architektúrán (SWA) ezen a hardveren (memóriasáv-limit) nincs mit gyorsítania.
A két igazi hozadék pedig nem a benchmark-számokból jött: (1) egy gyanús repót érdemes átvilágítani, mielőtt bármit a gépedre engedsz — és (2) egy modell architektúrája (itt: a sliding-window attention) többet mond a viselkedéséről, mint a neve a marketing-lapon.
Ja, és a gemma-4 dobozból gyors és kicsi. Lehet, hogy a következő házi modell.