Stručné shrnutí

  • Jedna NVIDIA B300 dosáhla při krátké zátěži 285 výstupních tokenů/s pro jeden požadavek a 972 tokenů/s při souběhu osmi požadavků. Vyšší souběh už téměř nezvýšil propustnost, pouze prodloužil čekání.
  • První odpověď nad přesně 800 000 vstupními tokeny začala za 71,4 s. Přirozený navazující dotaz se znovu použitým prefixem začal za 1,59 s, ale kontrolované běhy ukázaly rozptyl od 1,62 do 11,15 s.
  • V hlavní zátěžové sadě proběhlo 1 788 požadavků bez chyby, preempce nebo nedostatku paměti. Pro produkci jsme ponechali dávku 8 192 tokenů a kontextový limit 1 048 576 tokenů.

Čísla hodnotí výkon infrastruktury, nikoli kvalitu odpovědí modelu.

Co jsme měřili

Nasadili jsme DeepSeek V4 Flash ve vLLM 0.25.0 na jednu NVIDIA B300 SXM6 s 275 040 MiB paměti. Model používá smíšené FP4/FP8 váhy, FP8 KV cache a spekulativní dekódování DSpark se sedmi návrhovými tokeny. Klient posílal streamované OpenAI kompatibilní požadavky přímo na serveru, takže výsledky neobsahují latenci veřejné sítě ani webového rozhraní.

Kde končí užitečná propustnost

U krátké úlohy s 1 024 vstupními a 256 výstupními tokeny se nejlepší poměr propustnosti a odezvy objevil při souběhu osmi požadavků.

SouběhVýstupní tokeny/sTTFT p50 / p95E2E p50
128589 / 90 ms863 ms
4698109 / 286 ms1 398 ms
8972119 / 494 ms1 941 ms
161 0302 051 / 2 436 ms3 769 ms

Přechod z osmi na šestnáct souběžných požadavků přidal jen 6 % propustnosti, ale medián času do prvního tokenu narostl z 119 ms na 2,05 s. Při otevřeném příchodu požadavků byly 2 požadavky/s stabilní, od 3 požadavků/s už rostla fronta. U úlohy se 4 096 vstupními a 2 048 výstupními tokeny dosáhlo dekódování při souběhu osmi požadavků 1 695 tokenů/s.

Právní dokument a navazující dotazy

Typický pracovní postup jsme změřili nad dlouhým rozhodnutím a českým dotazem na argumentaci Ústavního soudu. Pro zátěžový test jsme dokument opakovali tak, aby formátovaný vstup obsahoval přesně 800 000 tokenů. Následoval dotaz se stejným dokumentem a předchozí odpovědí.

ScénářVstupní tokenyZásah prefixové cacheTTFTCelková odezva
První dotaz800 0000 %71,40 s78,42 s
Navazující dotaz s cache801 62299,80 %1,59 s6,15 s
Stejný dotaz bez cache801 6220 %71,56 s79,31 s

Cache v tomto přirozeném běhu zkrátila čas do prvního tokenu o 97,8 %. Výsledek ale není vhodné chápat jako pevné SLA. Ve třech izolovaných opakováních měla cache téměř shodný zásah 99,78 %, zatímco TTFT se pohybovalo mezi 1,62 a 11,15 s. Čekací fronta zůstala prázdná a rozdíl vznikal přímo ve fázi prefillu ve vLLM.

Co jsme ponechali

Zvýšení plánovací dávky z 8 192 na 16 384 tokenů urychlilo studený prefill o 2,7 %, ale celý dvoudotazový postup byl o 0,8 % pomalejší. Současně klesla kapacita KV cache o 31,6 %. Proto jsme ponechali dávku 8 192 tokenů a pouze zvýšili limit kontextu na nativních 1 048 576 tokenů.

Model zabral 156,32 GiB a vLLM vyhradilo 81,17 GiB pro KV cache. Při 800K testu zůstalo nejméně 20,72 GiB volné paměti. GPU dosáhlo 100% vytížení, příkonu 1 006 W z limitu 1 100 W a teploty 67 °C. Paměťová rezerva tedy existuje, ale studený prefill už na jedné kartě nemá praktickou výpočetní rezervu.

Doporučení pro produkci

Navazující dotazy musí směřovat na stejnou živou cache podle konverzace nebo dokumentu. Při více replikách je proto důležitá afinitní směrovací vrstva, případně perzistentní či sdílená KV cache. Rozptyl latence cache je potřeba ověřit na novějších verzích vLLM před stanovením SLA.

Pokud aplikace nemusí znovu posílat celý dokument, dává větší smysl stavová relace nebo vyhledávání nad uloženým obsahem. Pro skutečné 800K požadavky musí brána přijmout alespoň 4 MiB tělo, streamovat odpověď a mít timeout delší než 100 sekund.

U druhé B300 propojené přes NVLink bychom nejprve porovnali tensorové a expertové dělení modelu se dvěma samostatnými replikami se striktní afinitou relace. Oddělené prefill a decode uzly dávají větší smysl až u smíšené souběžné zátěže. Jedna dlouhá konverzace obě fáze používá postupně a mezi GPU by bylo nutné přenášet rozsáhlý KV stav.