vLLM omezil výpadek při škálování z 16 na 20 GPU na 0,82 sekundy
Elastic EP s NIXL zkrátil přerušení obsluhy z desítek sekund pod jednu sekundu. Rozhodující bylo připojení GPU za běhu a zachování CUDA Graphs.
Tým vLLM popsal, jak u modelu DeepSeek V4 Pro rozšířil běžící službu z 16 na 20 GPU s výpadkem pouhých 0,82 sekundy. Při návratu na 16 GPU trvalo přerušení 1,96 sekundy. Nešlo přitom jen o přesunutí pomalé práce před samotné přepnutí. Podstatnou část výsledku přineslo NIXL EP, které dovolilo zachovat komunikační prostředky i již vytvořené CUDA Graphs.
Čísla pocházejí z měření autorů implementace, nikoli z nezávislého benchmarku. Přesto je experiment zajímavý tím, že odděluje celkovou dobu škálování od času, po který služba skutečně nepřijímá nové požadavky a rozpracované požadavky se neposouvají.
Restart, blokující změna a asynchronní příprava nejsou totéž
Úplný restart vLLM při rozšíření DeepSeek V4 Pro z 16 na 20 GPU zastavil obsluhu na 197 sekund. Tento údaj ale není totožný s hodnotou 99,62 sekundy z hlavní srovnávací tabulky. Ta patří blokující reconfiguration v rámci Elastic EP: všechny přípravné kroky se provedou za pozastavené služby, ale nejde o kompletní restart serveru.
Autoři porovnali tři způsoby změny topologie:
| Varianta | Výpadek 16→20 GPU | Výpadek 20→16 GPU | Celkový čas 16→20 GPU | Celkový čas 20→16 GPU |
|---|---|---|---|---|
| Blokující reconfiguration | 99,62 s | 56,25 s | 99,72 s | 56,21 s |
| Asynchronní příprava | 58,04 s | 44,07 s | 97,27 s | 51,46 s |
| Asynchronní příprava + zachování grafů přes NIXL EP | 0,82 s | 1,96 s | 92,34 s | 9,32 s |
Samotné přesunutí části přípravy na pozadí tedy výpadek při rozšíření snížilo ze 99,62 na 58,04 sekundy. Teprve třetí varianta jej dostala pod jednu sekundu. Celá operace přitom stále trvala 92,34 sekundy: většina práce pouze proběhla souběžně s obsluhou požadavků.
Příprava na pozadí a krátké přepnutí
vLLM rozdělil změnu topologie do dvou fází. Během přípravy na pozadí stávající workery dál obsluhují provoz, zatímco systém:
- spustí nové workery a vyhradí jim paměť,
- připraví cílové komunikační skupiny,
- přenese potřebné váhy přes NVLink nebo RDMA,
- provede kompilaci, warm-up, tuning a vytvoření CUDA Graphs na nových workerech.
Následuje krátký commit: plánovače se pozastaví, aktivuje se připravená topologie a obsluha pokračuje. Asynchronní Expert Parallel Load Balancing potom na pozadí přerozdělí experty mezi rozšířenou skupinu.
Toto rozdělení samo o sobě nestačilo. Dřívější komunikační backendy měly pevně dané členství, takže změna počtu ranků vyžadovala nový komunikátor, nové buffery a nová spojení. Změnily se také adresy a komunikační stav zachycený v CUDA Graphs. Stávající workery proto musely znovu projít warm-upem a capture grafů, což se odehrávalo během výpadku.
Co mění NIXL EP
NIXL EP přidává a odebírá ranky přímo ve stávajícím komunikátoru. Znovu používá NIXL agent, buffery i existující spojení a nové peers nejprve připojí jako neaktivní. Při krátkém commitu je pouze aktivuje, místo aby celý komunikátor nahradil.
Současně udržuje stabilní parametry kernelů a adresy tensorů viditelné z CUDA Graphs. Zachované workery tak mohou po změně topologie použít své existující grafy. Nově připojovaný worker si během přípravy dočasně skryje všechny vzdálené peers, spustí lokální dummy dávky a vytvoří vlastní grafy bez účasti workerů, které právě obsluhují skutečný provoz.
Právě kombinace přípravy na pozadí, změny členství komunikátoru za běhu a zachování CUDA Graphs vysvětluje rozdíl mezi 58,04 a 0,82 sekundy. Označit výsledek pouze za přínos „asynchronní přípravy“ by minulo hlavní technickou pointu.
Na čem tým výsledek měřil
Všechny varianty používaly DeepSeek V4 Pro na GPU NVIDIA GB200 s tensor parallelismem TP=1 a data/expert parallel velikostmi 16 a 20. Váhy byly předem stažené ve formátu safetensors na sdíleném úložišti Lustre a načítaly se přes výchozí --load-format auto. Kompilační cache pro Triton, TileLang a FlashInfer už byly zahřáté. Všechny konfigurace podle autorů prošly numerickou kontrolou správnosti, včetně kontroly každého nově připojeného workeru.
Tyto podmínky jsou důležité. Výsledek neříká, že libovolný model na libovolných GPU půjde rozšířit s výpadkem pod jednu sekundu. Nezahrnuje ani studený start kompilačních cache nebo načítání vah, které nebyly předem dostupné na sdíleném úložišti.
SLO test sledoval p95 time to first token
Vedle časování samotné změny topologie tým přehrál scénář s 11 391 požadavky. Vstupní zátěž postupně rostla přibližně z 8 na 16 požadavků za sekundu a porovnávaly se tři služby: statická sestava se 16 GPU, restart na 20 GPU a Elastic EP s NIXL EP při přechodu na 20 GPU.
SLO nebylo obecně definované jako „výkon pod určitou úrovní“. Konkrétně šlo o průběžný p95 time to first token kratší než pět sekund. Neúspěšným požadavkům autoři při vyhodnocení přiřadili penalizaci 30 sekund. Elastic EP dokončil všech 11 391 požadavků a během scénáře zůstal pod stanoveným limitem. Během přípravy odpovídal výkonu statické sestavy se 16 GPU a po rozšíření obnovené sestavě s 20 GPU.
Co si z výsledku odnést
Největší přínos NIXL EP není v tom, že by celou operaci změny topologie dokončil za 0,82 sekundy. Příprava stále trvá desítky sekund. Důležité je, že téměř vše probíhá mimo kritickou část, během níž služba nemůže obsluhovat provoz.
Funkce jsou podle autorů dostupné v aktuálních vydáních vLLM a NIXL. Odkazovaný test obsahuje menší příklad škálování ze dvou na čtyři GPU a zpět, včetně požadavků posílaných během přípravy a kontroly přesnosti okolo změny velikosti. Pro rozhodnutí o produkčním nasazení ale bude potřeba stejné metriky ověřit na vlastním modelu, síti, úložišti a profilu provozu.