Ez a cikk az AI model co-design sorozat harmadik része. A szerzők a spekulatív dekódolás (speculative decoding) használatával bemutatják, hogyan gyorsítható fel az autoregresszív LLM-dekódolás úgy, hogy a kimenet pontossága változatlan maradjon. Öt irányelvet adnak arra, hogyan válasszuk meg a draft hosszát és a draft mechanizmust a throughput–interaktivitás Pareto-frontján elhelyezkedő üzempontokhoz.
Mit csinál a spekulatív dekódolás?
A spekulatív dekódolás során egy kisebb „draft” modell előre megjósol több egymást követő tokent (D token), majd a nagyobb, célmodell egyszerre ellenőrzi ezeket egyetlen előrehaladással. A célmodell sorban elfogadja a javasolt tokeneket, amíg el nem akad a legelső eltérésnél; onnan folytatódik a következő kör. Ha az elfogadási szabályokat nem lazítjuk fel, a végső kimenet megegyezik a standard dekódoláséval.
A két fontos mennyiség:
- draft length (D): a cél iterációnként javasolt tokenek száma
- acceptance length (AL): az egy target iteráción elfogadott tokenek száma; AL értéke 1 és 1+D között mozog
A spekulációs gyorsulás (speedup) a szerzők képlete szerint a célmodellnek AL token soros előállításához szükséges idő, valamint a D token párhuzamos ellenőrzésére és a draft elkészítésére fordított idő hányadosa:
speedup = T_verif(B) * AL / (T_verif(B*(1+D)) + T_draft(B,D))
ahol B a batch méret, T_verif(x) a verifikációs idő x tokenre, T_draft(b,y) pedig a draft generálásához szükséges idő.
Hogyan válasszuk a draft hosszát?
Egyszerűsítve, ha a draft modell latenciáját elhanyagoljuk, a spekuláció akkor ad sebességnövekedést, ha
T_verif(B*(1+D)) / T_verif(B) < AL.
A verifikáció számítási igénye (compute) D növelésével arányosan nő, de a memória-hozzáférés nem; ezért cél a D növelése addig, amíg T_verif nem marad közel állandó — ez gyakran a memóriakötött (memory-bound) üzemmódról a számításkötött (compute-bound) üzemmódra való átmenetig tart. Az optimális D függ a batch mérettől és a Pareto-front helyétől.
Draft hossz és lineáris rétegek (GEMM)
Spekuláció esetén a célmodell egy-egy lineáris rétegénél a GEMM-M hatékonyság M-ről M*(1+D)-re nő. A példában bemutatott 6144x6144-es GEMM esetén a normalizált teraflop/sec értékek azt mutatják, hogy nagyobb D értékekkel a csúcs teljesítmény kisebb effektív batch mellett elérhetővé válik. Például D=7 esetén nyolcad annyi batch szükséges ahhoz, hogy a GEMM számításkötött legyen, mint D=0 esetén. Miután a mixture-of-experts (MoE) modellek sparsifikálódnak és a hosszú kontextusok megnövelik a KV kapacitásra nehezedő nyomást, az effektív párhuzamosság per expert csökken, így nagyobb D értékek vonzóbbá válnak.
Guideline 1: Növeljük a spekulatív draft hosszát, hogy a GEMM-ek a számításkötött tartományba kerüljenek anélkül, hogy növelnénk a KV cache kapacitásnyomását.
Draft hossz és attention teljesítmény
Tudásintenzív vagy agentikus munkaterheléseknél az attention gyakran uralja a futási időt a throughput-orientált tartományban. A dekódolási attention aritmetikai intenzitása körülbelül 2G, ahol G a query head-ek száma, amelyek egy KV head-et osztanak meg. Spekulációval ez 2G*(1+D)-re emelkedik, mert a spekulált tokenek újrahasználják ugyanazt a KV cache-t. Az effektív attention GEMM-M érték G*(1+D). Jelen GPU-ken az attention kernel jó kihasználtságot ér el GEMM-M=128 környékén, ezért az optimális induló D = 128/G – 1 képlettel adható meg, ha az attention dominál.
Guideline 2: Ha az attention a dekódolási idő fő komponense, kezdjük D = 128/G – 1 értékkel.
Az attention futási ideje továbbá függ a tile mérettől. Ahogy G*(1+D) átlépi a 128 többszöröseit, a runtime lépcsősen növekszik: ha G*(1+D) két tile határ között esik, az utolsó tile részben kihasznált lesz, de költsége közelítőleg megegyezik egy teljes tile költségével.
Guideline 3: Ha D-t a 128/G – 1 érték fölé választjuk, részesítsük előnyben azokat a D értékeket, amelyeknél G*(1+D) 128 többszöröse, hogy elkerüljük a tile alulkihasználtságát.
A Guideline 1 relatív súlya a 2. és 3. irányelvvel szemben attól függ, hogy az adott üzempontban mekkora rész időt tölt a modell FFN-ekben ahelyett, hogy attention-ben töltené. A kommunikáció is növeli a verifikációs költséget D növekedésével, bár a számítás és kommunikáció átfedése mérsékelheti a többletet.
A Pareto görbe jobb szélén (nagyon kis B)
A jobb oldal felé haladva a Pareto görbén B nagyon kicsivé válik; ott a fix kernel setup és post-processz overheadek dominálnak. Ezek a fix költségek nem nőnek jelentősen a verifikált tokenek számával, így a verifikációs többletköltség viszonylag invariáns marad D növelésével. MoE-knél több expert aktiválódhat D növelésével, de model sharding és hatékony kernel technikák (például Grouped GEMMs) alacsonyan tarthatják az overheadet.
Alacsony latenciánál a sorozatos kernel indítások száma határozza meg a késleltetést; mivel a kernel indítások a rétegszámmal arányosan skálázódnak, egy autoregresszív draft modell esetén, melynek rétegstruktúrája hasonló a célmodellhez, a sebességnövekedés közelítése:
speedup = (L_target * AL) / (L_target + D * L_draft)
definiálva a draft_depth_ratio-t rho = L_draft / L_target: speedup = AL / (1 + rho D), draft overhead O_d = rho D.
Guideline 4: Nagyon alacsony késleltetésnél növeljük D-t csak addig, amíg az AL növekedése igazolja a draft költségét.
Draft mechanizmusok és kompromisszumok
A D meghatározása után válasszuk meg, hogyan generáljuk a draft tokeneket. Több technika ismert, különböző költségekkel: külső (external) draft modell, MTP, EAGLE-3, DFlash, DSpark, illetve model-független suffix/n-gram módszerek. A szerzők összefoglaló táblázatban hasonlítják össze ezeket a megközelítéseket a bemenetek, generálási mód, serve-time memória és draft költség szerint.
Főbb megállapítások a példák alapján:
- Külső draftok általában magasabb AL-t érnek el D>3 esetén, de nagyobb serve-time költséggel járnak. Egy nagy külső draft akkor éri meg, ha D jelentősen nagy.
- MTP kis többletparaméterrel működik, de soros (D lépés) végrehajtást igényel; ezért kis D-nél olcsó lehet, nagy D-nél túl lassú.
- DFlash és DSpark párhuzamosan generálhatják D tokent egyetlen előrehaladással, így kisebb O_d, ezért alacsony latenciás kis modelleknél előnyösebbek.
- Suffix/n-gram módszerek gyakorlatilag nullköltségűek futásidőben, de AL-juk alacsonyabb és inkább ismétlődő munkaterhelésekre alkalmasak.
A SPEED-Bench mérések alapján (Qwen 3.5 122B A10B célmodellel, 32K split) például Qwen 3.5 35B A3B draft AL=6-ot ér el D=9-nél, míg egy 4B külső draft AL>5-öt ad. DFlash és DSpark AL-jei korábban ellaposodnak, de alacsonyabb draft overheadjük miatt bizonyos üzempontokban jobbnak bizonyulhatnak.
Guideline 5: Válasszuk azt a draft mechanizmust, amely a konkrét munkaterhelésen és hardveren a legjobb dekódolási gyorsulást adja, figyelembe véve AL-t, draft latenciát és a képzés/deploy költségeit. Méréseket érdemes reális promptokkal és több feladattípussal végezni (pl. SPEED-Bench és magas teljesítményű inferencia keretrendszerek használatával).
Tréning és karbantartás
A draftek betanítási környezete és költsége eltérő. MTP-t a célmodellel együtt kell tréningezni vagy utólag újrahangolni; EAGLE-3, DFlash, DSpark post-train fejként hozzáadhatók a végső checkpointhoz; külső draftok lehetnek scratch-ből, tudásdesztillációval vagy adaptációval előállítottak. Fontos újramérni az AL-t, ha a célmodell finomhangoláson esik át, mert a draftek — különösen a target-attached megoldások — elveszíthetik elfogadottságukat a megváltozott kimeneti eloszlás miatt.
Összegzés: öt irányelv
- Növeljük a spekulatív draft hosszát, hogy a GEMM-ek számításkötötté váljanak anélkül, hogy növelnénk a KV cache igényt.
- Ha az attention dominál, kezdjünk D = 128/G – 1 értékkel.
- Ha D nagyobb ennél, válasszuk azokat a D értékeket, amelyeknél G*(1+D) 128 többszöröse a tile-kihasználtság optimalizálásához.
- Nagyon alacsony késleltetésnél csak addig növeljük D-t, amíg az AL-növekedés igazolja a draft overheadet; használjunk gyors draft mechanizmust.
- Válasszuk a draft mechanizmust a munkaterhelés és hardver ismeretében, mérjünk AL-t és draft költséget reális körülmények között, és fontoljuk a tréning- és deploy-költségeket.
A bejegyzés gyakorlati példákat, benchmark ajánlásokat (SPEED-Bench) és javaslatokat ad a post-trained draftek beállításához (NVIDIA/Model-Optimizer példák EAGLE-3, DFlash, DSpark esetén). Köszönetnyilvánításként a cikk megemlít számos NVIDIA-szerzőt és közreműködőt.
