DeepSeek-V4.1-Flash ve vLLM: kde se vzala 5,3× vyšší propustnost

DeepSeek-V4.1-Flash není model vytvořený týmem vLLM. DeepSeek zveřejnil model i související kernely, zatímco Inferact a komunita vLLM během prvních tří týdnů optimalizovaly jeho serving. Podle jejich měření na benchmarku SemiAnalysis AgentX se výsledek v režimu nízké latence zrychlil 1,9× a propustnost při omezení 150 TPS vzrostla 5,3× proti implementaci dostupné v den vydání.

Jde o měření autorů implementace, ne o nezávislý test modelu. Zajímavá proto nejsou jen dvě výsledná čísla, ale hlavně popsané mechanismy a situace, ve kterých pomáhají.

Proč je obnova sliding-window cache drahá

Architektura DeepSeek-V4.1 při generování aktivuje 16 miliard parametrů na token, při zpracování vstupu jen 8 miliard. Současně používá dva druhy KV cache. Globální cache je komprimovaná do FP4, sdílená mezi vrstvami a podle vLLM zabírá přibližně 890 bajtů na token. Sliding-window cache je naopak uložená v FP8 a v každé ze 40 vrstev pokrývá posledních 128 pozic.

Právě druhá cache komplikuje opakované využití prefixu. Její přesné přepočítání se postupně přelévá mezi vrstvami, takže nestačí jednoduše obnovit posledních 128 tokenů jednou. DeepSeek proto navrhl SWA bounded replay: vLLM po zásahu prefixové cache znovu projede jen poslední okno a na jeho začátku ořízne závislosti na starších pozicích. Výsledek není bitově shodný s úplným přepočtem.

DeepSeek u této aproximace uvádí zanedbatelný pokles kvality. Tým vLLM ji navíc porovnal na GSM8K a GPQA a píše, že nezaznamenal významný rozdíl; odchylky zůstaly přibližně v rozsahu 1,5 standardní chyby. Ani to ale není důkaz stejného chování na všech úlohách.

Polovina vrstev nemusí číst celý prompt

Největší úspora vzniká na dekodérové straně. Vrstva 20 vytváří globální KV, kterou znovu používají vrstvy 21 až 39. vLLM proto spouští vrstvu 20 nad celým vstupem, ale horní část modelu už jen nad posledními 128 tokeny každého požadavku. U dlouhého promptu tak téměř polovina modelu nemusí zpracovat celý vstup.

Samotné ořezání vrstev však nestačilo. Při menším objemu práce začala dominovat režie spouštění GPU kernelů. vLLM proto zachytává vrstvy 0 až 20 a zkrácené vrstvy 21 až 39 do oddělených CUDA grafů. V měření na NVIDIA GB200 tato kombinace zkrátila prefill TTFT zhruba o 30 až 40 procent.

Zdroj uvádí i důležitý negativní výsledek: bez CUDA grafů může režie u krátkých promptů převážit úsporu práce na GPU. V konfiguraci DEP2 byl replay při vstupu o délce 1 000 tokenů až o 12 procent pomalejší než výchozí stav. U dlouhých vstupů se režie lépe schová za samotný výpočet.

SWA bounded replay je pro DeepSeek-V4.1 ve vLLM zapnutý standardně. Přepínač --[no-]swa-bounded-replay slouží k jeho zapnutí nebo vypnutí; nejde tedy o chybějící povinný krok instalace.

Výkon nepřinesl jeden kernel

Druhá část zrychlení pochází z integrace a slučování kernelů. Přínosy se liší podle délky kontextu, velikosti dávky a hardwaru:

• Mega-mHC je podle měření na NVIDIA GB200 1,14× až 1,51× rychlejší než předchozí cesta založená na TileLang.
• Mega-Gate spojuje směrování expertů a výběr top-k do jediného kernelu; při středních dávkách přinesl 1,18× až 1,31× zrychlení této operace.
• Sparse MQA logits počítá skóre jen pro kandidátní pozice. Na GB300 bylo jedno provedení vrstvy 1,2× rychlejší při kontextu 8 000 tokenů a 14× až 23× rychlejší při 512 000 tokenech. End-to-end dekódování se však zlepšilo jen o 3 až 6 procent, což dobře ukazuje rozdíl mezi mikrobenchmarkem a celým systémem.
• MegaAttention pracuje s komprimovanou NVFP4 KV cache, která je podle vLLM o 45 procent menší než předchozí FP8 varianta. Samotný kernel díky slučování operací zrychlil 1,45×.

Článek vLLM popisuje i další dílčí optimalizace, například paralelní výpočet mHC koeficientů, sloučenou cestu WO-A nebo rychlejší práci s tabulkami Engram. Celkových 5,3× proto nelze připsat jediné technice ani jednoduše přenést na jiný hardware.

Dvě konfigurace pro dva cíle

Pro nízkou latenci použil vLLM konfiguraci TP4 s FlashInfer attention. MegaAttention v tomto režimu nepřinesl očekávanou výhodu a FlashInfer byl v jejich testech rychlejší. Pro vysokou propustnost tým přešel na DEP2, kde je attention rozdělena datovým paralelismem a experti napříč GPU. Tím se KV cache neduplikuje na každé kartě a session affinity zachovává lokalitu prefixové cache mezi tahy agenta.

To je pro interpretaci benchmarku podstatné: čísla 1,9× a 5,3× nevznikla ve stejné konfiguraci a neříkají, že model bude automaticky stejně rychlejší v libovolném nasazení. Ukazují spíš to, kolik výkonu může zůstat nevyužitého v první implementaci nové architektury — a že při ladění inference je potřeba měřit celý systém, ne pouze rychlost jednotlivého kernelu.