Načítání vah z disku spolklo ve SGLangu čtyři pětiny startu Qwen3-235B
Vývojáři obslužné vrstvy SGLang si rozebrali po krocích, co server dělá, než přijme první požadavek. Ze 390 sekund startu modelu Qwen3-235B na čtyřech kartách připadlo 306 až 327 sekund na samotné čtení vah z disku. Verze 0.5.17 z 8. srpna proto přidala proces, který váhy drží v paměti karty a novému serveru je předá bez kopírování.
Server, který obsluhuje velký jazykový model, se po restartu neozve hned. Nejdřív musí přečíst váhy z disku do paměti karet, navázat komunikaci mezi nimi a zaznamenat výpočetní grafy. Vývojáři projektu SGLang si tenhle úsek změřili po jednotlivých krocích a čísla zveřejnili v návrhu, který se 25. července dostal do hlavní větve. Hotová funkce vyšla 8. srpna ve verzi 0.5.17.
SGLang je jedna z vrstev, přes které se model v provozu obsluhuje; nejbližší obdobou je vLLM. Restart takového serveru není okamžik. Přehled novinek mluví u velkých modelů o třech až šesti minutách a víc, návrh k tomu dodává, že rozpracované požadavky po tu dobu buď selžou, nebo zůstanou viset ve frontě.
Ze šesti a půl minuty startu jde pět na disk
Měřil to sám projekt na modelu Qwen3-235B v osmibitovém formátu FP8, rozděleném mezi čtyři karty; na které verzi SGLangu, návrh neuvádí. Celý start od spuštění po připravený server trval zhruba 390 sekund, tedy šest a půl minuty. Jednotlivé kroky vyšly takto:
- příprava serveru a tokenizéru – 17,3 s (4,4 %),
- navázání komunikace mezi kartami – 4,7 s (1,2 %),
- čtení vah z disku – 306 až 327 s (79 %),
- přidělení paměti pro mezipaměť klíčů a hodnot – 0,5 s,
- záznam grafů CUDA včetně zahřátí jaderných funkcí – 34,9 s (8,9 %),
- dokončení a zahřívací požadavky – 3,4 s.
Dvě čísla, která tabulka uvádí zvlášť – 12,7 a 10,4 sekundy na překlad jaderných funkcí DeepGEMM –, se k seznamu nepřičítají. Časové značky v tabulce ukazují, že oba překlady probíhají uvnitř těch 34,9 sekund, ne vedle nich. Ostatní kroky na sebe navazují a sečteny s pomalejší z obou hodnot za čtení vah dají právě uváděných zhruba 390 sekund.
Rozpětí 306 až 327 sekund je rozdíl mezi kartami. Nejpomalejší z nich četla svůj díl vah 327 sekund a server je připravený teprve tehdy, když dočte poslední.
Necelý gigabajt za sekundu je i na obyčejný disk málo
Model s 235 miliardami parametrů zabírá v osmibitovém formátu zhruba 235 GB, protože na jeden parametr připadá jeden bajt. Vydělíme-li tuhle velikost naměřenými 306 až 327 sekundami, vyjde dohromady za všechny čtyři karty přibližně 0,72 až 0,77 GB za sekundu. Je to vlastní výpočet ze dvou vstupů, velikosti modelu a času z tabulky: návrh přenosovou rychlost neuvádí a nepíše ani, na jakém úložišti se měřilo.
Že se právě na tomhle kroku dá získat nejvíc, doložil dřív i někdo jiný. Knihovna Run:ai Model Streamer, kterou vLLM umí zapnout přepínačem --load-format runai_streamer, má v repozitáři vlastní měření zveřejněné v říjnu 2024. Model Llama 3 8B o velikosti 15 GB se na stroji AWS g5.12xlarge s jednou kartou A10G a diskem GP3 načítal běžnou čtečkou formátu safetensors 47,99 sekundy. Streamer potřeboval při jednom vlákně 47,56 sekundy a při šestnácti 14,34 sekundy, kde už narazil na strop disku 1 GiB/s.
Ta čísla měřil autor knihovny, ne nezávislá strana, a jde o starší software (vLLM 0.5.5, streamer 0.6.0). Pořadí velikostí ale sedí s tím, co teď naměřil SGLang: dokud se váhy čtou z úložiště, rozhoduje o době náběhu rychlost disku, ne výpočet.
Démon drží váhy a novému procesu je namapuje
Nová funkce je proces, který na každé kartě drží už načtené a kvantizované váhy a dalšímu serveru je zpřístupní přes CUDA IPC, tedy sdílení paměti mezi procesy na téže kartě. Kopírovat se nemusí nic, takže čtení vah má podle návrhu klesnout z 306 sekund pod jednu sekundu.
Druhé použití je záložní server. Ten běží vedle hlavního, váhy má namapované z téhož démona a při výpadku podle autorů převezme provoz pod jednu sekundu, aniž by pro něj musely stát nečinné karty navíc. Třetí je sdílení jedněch vah mezi víc procesů na jedné kartě, takže se z disku čtou a kvantizují jen jednou. Současná podoba umí jeden stroj a jen tenzorový paralelismus.
Zapíná se ručně a jedna ze dvou podob restart nezrychlí
Ve výchozím nastavení je mezipaměť vypnutá. Přepínač --weight-cache-mode má tři hodnoty: off, daemon a client. Nápověda ve zdrojovém kódu vydané verze u toho říká něco, co v přehledu novinek není: démon spuštěný samotným serverem končí zároveň s ním, takže restart tímhle způsobem nezrychlí a první start je s ním naopak pomalejší. Zrychlení dá jedině démon spuštěný zvlášť, ke kterému se server připojí v režimu client.
Kód uvádí i dvě hranice použití. Mezipaměť vah nejde zapnout současně se spekulativním dekódováním a na připravenost démona server ve výchozím nastavení čeká 1 800 sekund. Spojení vede přes unixový soket, jehož výchozí jméno se odvozuje od pořadí karty.
Zbytek startu zůstává, kde byl
I kdyby čtení vah zmizelo úplně, zbývá podle téže tabulky ještě zhruba minuta: šedesát sekund rozdělených mezi přípravu serveru, záznam grafů a zahřívací požadavky. Návrh proto počítá s dalšími pěti fázemi – uložením zaznamenaných grafů CUDA k pozdějšímu přehrání, trvalou mezipamětí přeložených jaderných funkcí, líným načítáním tokenizéru, opakovaným použitím spojení NCCL a rozšířením démona na víc strojů a na datový i expertní paralelismus. Cílem je start pod deset sekund.
Vydaná je z toho zatím jen první fáze, zbylých pět je popsaný plán. Návrh to říká sám: v tabulce cílových časů stojí u všech ostatních kroků slovo „Planned“.
Z celého měření zůstane použitelné i mimo SGLang to první číslo. Doba, než se model ozve, se dnes u velkých vah neurčuje výkonem karet, ale tím, jak rychle jde obsah přečíst z úložiště. U modelu K-EXAONE 2.0 s 1,5 TB vah by při naměřených 0,75 GB za sekundu vyšel samotný náběh na víc než půl hodiny – a to je zase jen podíl dvou čísel, ne něčí měření.