vLLM u Kimi K3 naměřilo 2,2 až 2,8× vyšší propustnost
Srovnání vLLM 0.27.1 s vývojovou verzí ukazuje, které zásahy do plánování, KDA a datových přesunů zkrátily latenci.
Autoři technického blogu vLLM porovnali vydání 0.27.1 s vývojovou verzí na commitu 82a85dc1. U Kimi K3 naměřili podle počtu souběžných požadavků 2,2 až 2,8× vyšší propustnost a přibližně o 56 až 60 % nižší průměrnou latenci. Nejde ale o výsledek jedné optimalizace: změny zasáhly plánování tokenů, práci s KDA stavem, kopírování tensorů i MXFP4 kernely.
Co přesně se testovalo
Benchmark běžel na uzlu NVIDIA B300 s CUDA 13.3. vLLM obsluhovalo syntetický workload s 8 000 vstupními a 1 000 výstupními tokeny, tensor parallelismem TP8 a osmi spekulativními tokeny DSpark. Test použil souběžnost 1, 4 a 16 a pro každou variantu dvacet vzorků. Prefix caching byl v obou bězích vypnutý, protože vLLM 0.27.1 obsahovalo známou chybu pro Kimi K3.
| Souběžnost | Latence 0.27.1 | Latence nová verze | Propustnost 0.27.1 | Propustnost nová verze |
|---|---|---|---|---|
| 1 | 12,37 s | 5,30 s | 83,3 tok./s | 183,3 tok./s |
| 4 | 23,67 s | 10,50 s | 166,7 tok./s | 416,7 tok./s |
| 16 | 55,90 s | 22,17 s | 258,3 tok./s | 725,0 tok./s |
Hodnota 2,8× tedy patří až k souběžnosti 16. Při jediném požadavku vzrostla propustnost z 83,3 na 183,3 tokenu za sekundu, což odpovídá přibližně 2,2×. Současně se time to first token podle konfigurace snížil o 72 až 85 %.
Méně dělení jednoho požadavku
První popsaná změna upravuje rozpočet plánovaných tokenů. Při malém počtu požadavků dřívější logika nevyužívala velkou část max_num_batched_tokens a jeden požadavek rozdělovala do více průchodů modelem. V příkladu s limitem 8 192 tokenů dostal jeden požadavek dříve rozpočet 1 024 tokenů, nově 8 185.
Samotné adaptivní plánování podle autorů snížilo TTFT na testovaném workloadu o 55 až 65 % a zvýšilo propustnost až o 41,5 %. Výsledek ukazuje, proč nemusí být hlavní brzdou velká maticová operace: při nízké souběžnosti může výkon omezit způsob, jakým scheduler rozděluje práci.
KDA checkpoint bez druhého průchodu
Mamba-style prefix cache dříve rozdělovala prefill na poslední hranici, kterou bylo možné uložit do cache. I krátký suffix pak mohl vyvolat další kompletní průchod přes attention, MoE, routing a TP collectives. Interní KDA checkpoint se nyní exportuje během jednoho prefill průchodu. U osm tisíc tokenů tak jedna FlashKDA operace zpracuje celý vstup a uloží stav na požadované hranici. Autoři této změně připisují pokles TTFT o 9 až 25 %.
Méně kopírování v KDA dávkách
Smíšené dávky se spekulativními a běžnými požadavky používaly v každé vrstvě šest operací index_select a dvě index_copy_. Nová cesta pracuje s kontinuálními pohledy do tensorů a zapisuje přímo do výstupních řezů. Při souběžnosti 4 a 16 tím propustnost vzrostla o 5,2 až 7,7 %, zatímco pro batch size 1 zůstala prakticky stejná.
Další přibližně pětiprocentní pokles end-to-end latence přineslo přesunutí finalizace MXFP4 top-k do latent-tail kernelu. Odpadl jeden kernel launch a jeden zápis a opětovné načtení mezivýsledku. Širší sada změn zahrnovala také ReplaySSM, offload stavů a decode context parallelism; celkové číslo proto nelze připsat pouze třem nejviditelnějším úpravám.
Jak výsledky číst
Benchmark dobře ukazuje, že při inference mohou rozhodovat i plánovací limity, malé kopie tensorů a ukládání rekurentního stavu. Neříká však, že stejný násobek dostane jiný model nebo hardware. Výsledek je svázaný s B300, TP8, DSpark, workloadem 8K/1K a konkrétní dvojicí verzí vLLM. Pro vlastní nasazení má proto větší hodnotu rozdělení přínosů jednotlivých změn než samotné maximum 2,8×.