Ha helyben futtatsz LLM-et a gépeden, ismerős lehet az érzés: a modell okos, csak épp ráérős. A Gemma 4 most egy olyan gyorsítást kapott, ami nem új hardvert kér, hanem okosabban használja azt, ami már ott van.

Mi történt

A Gemma 4 nyílt (helyben futtatható) AI modellekhez megjelentek a Multi-Token Prediction (MTP) „drafter” modellek. Ezek kísérleti kiegészítők, amelyek a szöveg következő darabjait (tokenjeit) előre „megtippelik”, és ezzel a generálást a hagyományos működéshez képest akár többszörösére gyorsíthatják.

A Gemma 4 technológiai alapjai ugyanabból a családból jönnek, mint a Geminié, csak a Gemma úgy van hangolva, hogy helyben fusson. A gond az, hogy a helyi futtatás tipikusan nem olyan környezetben történik, mint a nagy adatközpontok: nincs óriási memóriasávszélesség és villámgyors összeköttetés a számítás és a memória között. Emiatt a gép sokszor nem számol, hanem „pakol”: a modell paramétereit (súlyait) mozgatja a memóriából a számolóegységekhez tokenről tokenre.

Miért fontos

Az LLM-ek (nagy nyelvi modellek) többnyire úgynevezett autoregresszív módon írnak: mindig csak egy tokent generálnak, majd abból lépnek a következőre. Gondolj a tokenre úgy, mint a szöveg apró építőkockáira (szótöredékekre/szavakra/írásjelekre). A bökkenő: minden egyes token előállítása nagyjából ugyanannyi „kör” a gépnek, függetlenül attól, hogy épp egy töltelékszót („és”, „hogy”) vagy egy kulcsfontosságú állítást készít. Ha a hardvered memóriája lassabb (különösen a vállalati gyors memóriákhoz, például HBM-hez képest), akkor a rendszer sok időt veszít az adatok mozgatásán, és a számolóegységek részben tétlenül várnak.

Itt jön képbe az MTP: a nagy, „nehéz” modell várakozási idejét kitölti egy kisebb „drafter” modell, amely spekulatív tokeneket gyárt előre. A nagy modell aztán ellenőrzi/validálja ezeket, és ha elég jók, több lépést lehet „egyben” letudni. A drafterek ráadásul több trükköt is használnak a gyorsításhoz: megosztják a key–value cache-t (ez lényegében a modell „munkamemóriája”, amiben a beszélgetés/kontextus feldolgozott lenyomata van), így nem kell újraszámolniuk azt, amit a fő modell már kiszámolt. Emellett a kisebb E2B/E4B drafterek ritkított (sparse) dekódolást is alkalmaznak: ahelyett, hogy minden lehetséges következő tokent egyformán mérlegelnének, előszűkítik a valószínű jelöltek körét.

Mire figyelj

  1. Melyik gépen mennyit gyorsul? Az „akár 3×” tipikusan erősen hardver- és beállításfüggő. Érdemes külön nézni a késleltetést (time-to-first-token) és az átlagos token/másodperc értéket.
  2. Minőség vs. sebesség csere: A spekulatív dekódolás lényege, hogy gyorsan tippel, majd validál. Ha a tippek gyakran mellémennek, a nyereség csökkenhet.
  3. Integráció a helyi stackbe: A key–value cache megosztása és a sparse dekódolás implementációs részletei számítanak. Ars Technica AI értelmezése alapján itt nem egy „varázskapcsolóról” van szó, hanem egy olyan optimalizációról, ami akkor hoz sokat, ha a memória és a kiszolgálási útvonal a szűk keresztmetszet.