Jak funguje vLLM V1: engine, scheduler, KV cache a škálování

Aleksa Gordić ve svém technickém rozboru prochází architekturu vLLM V1 od základního enginu až po distribuované servírování. Text je založený na konkrétním stavu projektu z 9. srpna 2025, takže názvy tříd a některé implementační detaily se mohou v novějších verzích vLLM změnit.

Základním prvkem je LLM engine. Ten přijímá požadavky, připravuje jejich stav a předává je scheduleru, který rozhoduje, které požadavky se dostanou do dalšího výpočetního kroku. Vedle něj funguje KV-cache manager, který spravuje bloky paměti používané pro attention cache.

Scheduler a continuous batching

Důležitou částí návrhu je průběžné plánování požadavků. Místo pevně sestavených batchů může scheduler mezi jednotlivými kroky doplňovat nové požadavky a dokončené naopak odstraňovat.

To je podstatné hlavně pro online provoz, kde požadavky přicházejí v různých časech a mají různě dlouhé prompty i odpovědi. Cílem není jen maximalizovat počet tokenů za sekundu, ale zároveň využívat dostupnou GPU bez zbytečného čekání.

Chunked prefill

Dlouhý prompt může při prefill fázi zabrat velkou část jednoho výpočetního kroku. Chunked prefill proto umožňuje rozdělit zpracování dlouhého vstupu do menších částí.

Smyslem není jednoduše „urychlit generování textu“. Praktický přínos spočívá hlavně v tom, že jeden dlouhý prefill nemusí monopolizovat scheduler a zhoršovat latenci ostatních požadavků.

Prefix caching

Prefix caching využívá situace, kdy více požadavků začíná stejnou sekvencí tokenů. Pokud už vLLM výpočet společného prefixu provedlo, může odpovídající KV cache znovu použít místo opakovaného prefillu.

Tato optimalizace proto pomáhá především tam, kde se opakují stejné systémové prompty, dlouhé instrukce nebo společný kontext. Nejde primárně o urychlení decode fáze každého dalšího tokenu.

Od jedné GPU k více procesům a uzlům

Zdroj postupně ukazuje několik úrovní škálování.

Nejjednodušší konfigurace běží na jedné GPU. Pro více GPU v jednom stroji vLLM používá více procesů a podporuje například tensor parallelism a pipeline parallelism. Další vrstva přidává asynchronní engine a architekturu vhodnou pro online požadavky.

Při větším nasazení lze systém rozšířit i přes více uzlů. To už není jen otázka samotného modelového výpočtu, ale také komunikace mezi procesy, řízení požadavků a distribuce práce.

Jak měřit výkon

Zdroj rozlišuje několik metrik, které není vhodné shrnovat jedním slovem „latence“.

• TTFT (Time To First Token) měří čas od odeslání požadavku do prvního výstupního tokenu.
• ITL (Inter-Token Latency) sleduje prodlevu mezi jednotlivými tokeny.
• TPOT (Time Per Output Token) vyjadřuje průměrný čas na výstupní token.
• End-to-end latency měří celý čas od požadavku až po poslední token.
• Throughput sleduje množství zpracovaných tokenů nebo požadavků za jednotku času.
• Goodput navíc zohledňuje, kolik požadavků splnilo zadané výkonnostní cíle.

Pro interaktivní aplikaci může být důležitý nízký TTFT a stabilní ITL. U dávkového zpracování může mít větší váhu celková propustnost.

Benchmarking a ladění konfigurace

vLLM nabízí benchmarkovací nástroje pro různé scénáře. Gordić také popisuje auto-tuning a hledání konfigurace, která odpovídá konkrétnímu hardwaru, modelu a typu provozu.

Zajímavé na celém rozboru je, že vysoká propustnost není výsledkem jedné optimalizace. Vzniká kombinací scheduleru, správy KV cache, continuous batchingu, chunked prefillu, prefix cachingu a způsobu, jakým se systém škáluje přes více GPU a procesů.

Článek zdroje je proto užitečný hlavně jako mapa vnitřní architektury vLLM V1, ne jako neměnná dokumentace aktuální verze projektu.