A mobilon futó nyelvi modellek gyors és energiahatékony működése kulcsfontosságú ahhoz, hogy a telefon alapú funkciók — például értesítés-összegzések vagy helyben történő szövegellenőrzés — adatot nem küldve is valós idejűek legyenek. A nagyobbrészt a felhasználó készülékén futó modellek, mint a Gemini Nano és Gemma család, lehetővé teszik ezt, ugyanakkor a mobil környezet szigorú energia- és memória-korlátai komoly kihívást jelentenek.
A hagyományos autoregresszív generálásnál minden egyes tokenhez egy-egy előrecsatolást (forward pass) kell végrehajtani a nagy modellen, ami alulhasználja a processzort és megterheli a memória-sávszélességet. Ennek csökkentésére a Multi-Token Prediction (MTP) architektúrát illesztették meglévő, "lefagyasztott" (frozen) Gemini Nano v3 modellekhez: egy kisméretű, könnyű Transformer fej (az MTP head) kapcsolódik a fő modell utolsó rétegeihez, és a már számított rejtett állapotokat felhasználva több tokent jósol autoregresszívan.
A késői kilépés ("late exit") és a spekulatív dekódolás
MTP az evolúciója a spekulatív dekódolásnak: klasszikus megközelítésben egy kisebb, különálló "drafter" előállít rövid jelöltsorozatokat (pl. 3 token), majd egy nagyobb "verifier" párhuzamosan ellenőrzi ezeket. A különálló drafterek memóriaversenyt és információhiányt okoznak, mert nem férnek hozzá a fő modell belső állapotához, csak a szöveg előzményt használják. Az MTP ehelyett a drafter funkciót a végső rejtett aktivációkra támaszkodó fejként valósítja meg, így kihasználja a backbone által már elvégzett számításokat.
Lefagyasztott backbone előnyei
Ahelyett, hogy a drafter head-et a pretraining folyamattal együtt képezték volna — ahogy például bizonyos Gemma 4 kiadásoknál történt — a mostani megoldás célja meglévő, már telepített on-device alapmodellek hatékonyságjavítása. A munkamenet során a teljesen betanított Gemini Nano v3 súlyait lefagyasztják, és csak az MTP fej (egy dense transformer stack) paramétereit tanítják a jövőbeli tokenek előrejelzésének minimalizálására. Mivel a backbone változatlan marad, az MTP bevezetése nem rontja az alapmodell képességeit vagy biztonsági beállításait, és rossz draftok eldobásakor a végső kimenet bit‑per‑bit megegyezik a fő modellével, így teljes visszafelé kompatibilitás tartható.
Zero-copy architektúra a dinamikus memória megtakarításáért
A mobilon az igazán szűk erőforrás a dinamikus memória (RAM). A hagyományos megoldásoknál még megosztott paraméterek mellett is a drafter gyakran saját key-value (KV) cache-t tart fenn, ami memóriapazarláshoz vezet. Ennek elkerülésére a bevezetett zero-copy architektúra lehetővé teszi, hogy az MTP fej közvetlenül kereszt‑attendoljon a fő modell lefagyasztott KV cache-ére, így nem kell külön előtöltenie vagy duplikálnia a történéseket.
Ez két gyakorlati előnyt hoz: nincs külön drafter prefill késleltetés (mivel az MTP fej azonnal hozzáfér a már számított cache-hez), és jelentősen csökken a futásidejű memóriaigény. A tesztek szerint ez például körülbelül 130 MB megtakarítást hoz példányonként összehasonlítva egy különálló drafterrel, mivel elmaradnak a drafter embedding táblák, prefill attention variánsok és egyes alkalmazás-specifikus hangolási paraméterek.
Pontosság és teljesítmény
A kísérletek szerint az MTP fej által készített draftok jellemzően pontosabb token‑előrejelzéseket adnak, ami a Pixel 9 készülékeken feladatfüggően 50% vagy annál nagyobb gyorsulást eredményezett a hasonló paraméterméretű, különálló drafterekkel összehasonlítva. Az MTP előnye abból fakad, hogy hozzáfér a végső aktivációkban lévő gazdag reprezentációkhoz:
- Instrukciókövetés: összegzés vagy újraírás jellegű, komplex megkötéseket tartalmazó feladatoknál az MTP jelentősen jobb volt a különálló fine-tuned drafternél.
- Megjósolható szövegszerkezetek: struktúrált válaszoknál (például gyors válaszok) az MTP fej a fő modell szintaktikai mintázatait elsajátítva akár 55%-os javulást ért el a token elfogadásban.
A Pixel 9 és 10 sorozatokra telepített MTP megoldás a gyártásban futó munkaterhelésekben (például AI Notification Summaries és Proofread) átlagosan majdnem két extra tokent helyesen jósol egy inference lépésben, és kevesebb verifikációs lépés miatt rövidebb ideig kell ébreszteni a nagy teljesítményű processzorokat, ami csökkenti az energiafelhasználást és javítja az akkumulátor-élettartamot.
Jövőbeli irányok
A fejlesztők a jövőben további Pixel modelleken tervezik az MTP integrálását, és alternatív architektúrákat is vizsgálnak — például párhuzamos dekódolást vagy segédfejek nélküli paradigmákat — a további késleltetéscsökkentés és egyidejű tokenverifikáció növelése érdekében. Emellett dolgoznak a nyelvi generálás bizonytalanságának hatékonyabb kezelési módjain: a jelenlegi spekulatív dekódolás alapfeltevése egyetlen legjobb jövőpálya feltételezése, ezt bővítenék párhuzamos elágazások vizsgálatával, illetve a verifikáció szigorúságának lazításával bizonyos felhasználási esetekben, hogy még nagyobb hatékonyság érhető el az élen.
Köszönetnyilvánítás
A munkába közreműködők között szerepelnek Filippo Galgani, Omri Homburger, Pooja Consul, Matthew Markwell és Vivek Kumar. Egyes elemek a Gemini csapat (Google DeepMind) fejlesztésein alapulnak: Tal Schuster, Ziwei Ji, Ivan Korotkov és Ganesh Jawahar. További visszajelzésekért és támogatásért köszönet Nadav Bar‑nak, Utku Evci‑nek, Nir Shabat‑nak, Joe Zou‑nak, valamint a Google Research, Google DeepMind és Platforms & Devices csapatainak.
