A vLLM adaptív ellenőrzéssel javítja a spekulatív dekódolást

A fix tokenmennyiség problémája

A vLLM 2026. augusztus 14-i bejegyzése szerint a spekulatív dekódolás kevesebb dekódolási lépést tesz lehetővé, cserébe további számításokat igényel az előre generált tokenekhez. Egyetlen kérésnél ez kedvező lehet, mivel a GPU memóriasávszélessége korlátozhatja a teljesítményt, miközben marad szabad számítási kapacitás.

Magas, például 256-os kötegméretnél azonban az előre generált tokenek ugyanazért a számítási kapacitásért versenyeznek, mint a tényleges tokenek. Ha sok token kiesik az ellenőrzés során, a teljesítmény jelentősen romolhat. A vLLM példája szerint a DeepSeek-V4-Pro-0813 modellen egy hét tokenből álló blokk első tokenje több mint 70 százalékos, az utolsó tokenje viszont 10 százaléknál kisebb eséllyel marad meg.

A DSpark a bizalom alapján osztja el a keretet

A DSpark minden előre generált tokenhez bizalmi értéket számol egy tanult bizalmi fej segítségével. A rendszer ezekből túlélési valószínűségeket képez, majd az egyes kérések tokenjei között választja ki a legígéretesebb lehetőségeket. Így egy magabiztos kérés ötödik pozícióban lévő tokenje is megelőzheti egy kevésbé magabiztos kérés első tokenjét.

A vLLM alapértelmezett keret helyett minden lépésben meghatározza, mennyi előre generált tokent érdemes ellenőrizni. A döntés az adott lépés várható tokenhozamát és profilozott futási költségét hasonlítja össze. A profilozás az indításkor történik, a rendszer külön költségtáblát készít az ellenőrzéshez és az előállításhoz. A mérések alakját monotonitással simítják, miközben figyelembe veszik a CUDA-grafikonok kitöltéséből adódó lépcsőzetes költségeket.

A keret méretezése a CPU-n zajlik, miközben a GPU az előző lépést futtatja. A konkrét kérésekhez tartozó kiosztás a GPU-n, az aktuális bizalmi értékek alapján történik. A kiválasztást PyTorch-ban írták meg, majd a torch.compile Triton-kódra fordítja, és a folyamat nem olvassa vissza az adatokat a gazdagépre.

Változó méretű CUDA-grafikonok támogatása

Az adaptív ellenőrzéshez a vLLM változó méretű dekódolási CUDA-grafikonokat is bevezetett. Egy grafikon egy kéréshez 1 és a num_speculative_tokens + 1 közötti tokenmennyiség bármely keverékét képes kezelni. A megoldás a DeepSeek ritka MLA-kerneljeire és a DeepGEMM-ben közzétett, változó hosszúságú indexelő kernelre támaszkodik.

A fejlesztés a vLLM main ágába a 47808-as pull requestben került be, az engedélyezéshez az enable_adaptive_verification beállítás használható. A bemutatott konfigurációban a num_speculative_tokens értéke 7 volt.

A mérés szerint 256-os konkurenciáig is működik

A vLLM a tesztet DeepSeek-V4-Pro-0813 modellel, TP=8 beállítással, 8 darab B300 GPU-n, SM100-on, expert parallel módban és FP8 KV-gyorsítótárral végezte. A mérésben 880, 1,0 hőmérsékleten futtatott kérés szerepelt, legfeljebb 2048 kimeneti tokennel, a konkurenciát 1 és 256 között változtatva.

A vállalat szerint az adaptív ellenőrzés a teljes vizsgált tartományban a teljesítmény és a válaszidő közötti Pareto-fronton maradt. Alacsony konkurencián hosszabb fix blokkhoz hasonlóan viselkedett, magas konkurencián pedig rövidebb blokkot választott. A vLLM állítása szerint így a rendszer a 256-os konkurenciáig is megőrizte a spekulatív dekódolás előnyeit, miközben csökkenti a num_speculative_tokens kézi hangolásának szükségességét.

A funkciónak korlátai is vannak. A teljes változó hosszúságú CUDA-grafikonokhoz az AttentionCGSupport.ALWAYS támogatása szükséges, amelyet a közlemény szerint az SM100-as DSV4 sparse-MLA, sparse-SWA és indexelő háttérprogramok biztosítanak. Az adaptív mód jelenleg nem támogatja az enforce-eager beállítást, a LoRA-t és a pipeline parallelismust. Bekapcsolt adaptív ellenőrzés mellett a kimeneti logprobs használatát is elutasítja a rendszer.