vLLM 0.28.0 přesunul podporu bitsandbytes z hlavního stromu do zásuvného modulu
Obsluha jazykových modelů vLLM vydala 26. srpna 2026 verzi 0.28.0 s 584 commity od 270 přispěvatelů. Podpora kvantizace bitsandbytes odešla z hlavního stromu do samostatného zásuvného modulu, dvě ladicí volby byly odstraněny a knihovna Transformers musí být nově ve verzi 5.15.0. Výchozí velikost dávky tokenů se zdvojnásobila na 16 384.
Projekt vLLM vydal 26. srpna 2026 verzi 0.28.0. Poznámky k vydání počítají 584 commitů od 270 přispěvatelů, z toho 76 nových. Kdo aktualizuje z předchozí řady, narazí nejdřív na čtyři změny, které zpětně slučitelné nejsou, a na tři přenastavené výchozí hodnoty.
Bitsandbytes se od této verze instaluje zvlášť
Nejcitelnější je odchod knihovny bitsandbytes. Kvantizace vah do čtyř a osmi bitů přes tuhle knihovnu byla dosud přímo ve vLLM. Návrh #43529 ji z hlavního stromu vyjmul a přenesl do samostatného zásuvného modulu vllm-bnb-plugin; v kódu je to 187 přidaných řádků proti 1 895 odebraným ve 31 souborech. Modely v tomhle formátu poběží dál, ale až po doinstalování modulu příkazem uv pip install vllm-bnb-plugin. Tak to v popisu návrhu píše jeho autor.
Je to první polovina většího záměru. Rozprava #39583 navrhuje vystěhovat z hlavního stromu vedle bitsandbytes i podporu formátu GGUF. U GGUF poznámky k vydání 0.28.0 žádnou takovou změnu neuvádějí, takže ta část zatím zůstává na svém místě.
Dvě volby z konfigurace zmizely
Druhá dvojice zpětně neslučitelných změn míří na lidi, kteří si vLLM ladí ručně. Návrh #49389 odstranil dopočet měřítek KV cache za běhu (calculate_kv_scales), který byl už dřív označený za odepsaný. Návrh #48684 zrušil přepínač override_attention_dtype, kterým se dal vnutit datový typ mechanismu pozornosti. Kdo má některý z nich ve spouštěcím skriptu, dostane po aktualizaci chybu, ne varování.
Čtvrtou změnou je povinný skok knihovny Transformers na verzi 5.15.0 (#51668). Ta řada sama nese svůj vlastní seznam nekompatibilních změn, takže se s aktualizací vLLM mění i chování knihovny pod ním. Předchozí vydání 0.27.0 stálo na podobném skoku, jen u PyTorche.
Dávka je nově dvojnásobná
Výchozí hodnota max_num_batched_tokens stoupla z 8 192 na 16 384 (#51726). Je to strop na počet tokenů, které plánovač nacpe do jednoho průchodu; čím vyšší, tím líp se karta vytíží, ale tím víc paměti si obsluha vezme. Autor návrhu podmínku napsal do popisu rovnou: zvýšit se to má tam, kde je paměti dost.
Druhá přenastavená hodnota zapíná ukládání společných předpon (prefix caching) u modelů rodiny Mamba (#50991), třetí zvedá počet zachytávaných grafů CUDA na kartách Blackwell na 1 024 (#49390). Ani jedna nic neruší, obě mění chování bez zásahu do konfigurace.
Zbytek vydání táhnou velké modely
Mimo tyhle položky je 0.28.0 hlavně kolo optimalizací pro dva modely. U Kimi K3 přibylo souběžné zpracování kontextu při dekódování, spojené kernely FlashKDA a volitelné rozdělení sdíleného experta, které podle poznámek ušetří kolem 17 GiB paměti na kartu. U DeepSeeku V4 začala řídká varianta MLA fungovat od začátku do konce, tedy i pro spekulativní dekódování.
K tomu se rozšířilo odkládání KV cache: nově se dá odsypat i na disk a správce druhé úrovně smí sedět mimo repozitář vLLM. Rozhraní v Rustu dostalo samostatný renderer a posílání obrázků přes gRPC.
Jediné, co se z poznámek k vydání vyčíst nedá, je dopad těch tří výchozích hodnot na konkrétní sestavu. Čísla u nich pocházejí od přispěvatelů projektu a nikdo je zatím nezopakoval nezávisle, takže po aktualizaci má smysl změřit si obsazenou paměť dřív, než se stroj pustí do ostrého provozu.