Ray 2.58 zohledňuje KV cache při směrování dotazů mezi replikami

Ray vydal 23. srpna verzi 2.58.0 a v ní dokončil směrování požadavků pro jazykové modely podle KV cache a počtu tokenů. Funkce byla v předchozí verzi teprve náhledem. Hotové balíčky se stejným číslem se objevily také v registru PyPI pro Python 3.10 až 3.14.

Router hledá už spočítaný začátek dotazu

KV cache ukládá klíče a hodnoty pozornosti, které model spočítal při čtení vstupu. Když několik požadavků začíná stejným systémovým pokynem, dokumentem nebo historií chatu, může server společný začátek znovu použít. Ušetří tím část fáze prefill, tedy zpracování vstupu před prvním vygenerovaným tokenem.

V clusteru je ale podstatné, která replika příslušné bloky drží. Obyčejné kruhové směrování může poslat pokračování rozhovoru na jiný stroj a výhoda cache zmizí. Ray proto nejdřív převede text na tokeny přímo ve vstupní replice LLMRouter. Změna #64642 odstranila dřívější dotaz na rozhraní /tokenize jedné modelové repliky, který ležel v kritické cestě každého požadavku.

Vybraný server už tentýž text nemusí převádět podruhé. Router mu pošle identifikátory tokenů vedlejším kanálem přes ZMQ a běžný HTTP požadavek nese jen klíč. Návrh #65095 tuhle cestu popisuje jako best effort: pokud tokeny nedorazí včas nebo kanál není dostupný, vLLM provede tokenizaci obvyklým způsobem. Výpadek pomocné optimalizace tedy nemá shodit samotné generování.

Každý vstupní router potřebuje stejný obraz zátěže

Jedna směrovací replika by se s růstem provozu stala úzkým hrdlem. Když jich ale běží víc, každá původně viděla jen požadavky, které sama odeslala. Změna #64949 proto posílá všem vstupním replikám události o přidání požadavku, dokončení prefillingu, průběhu generování a ukončení. Jedna nedostupná replika ostatní nezastaví; chyba jejího doručení se zapíše jako varování.

Samotný výběr serveru a rezervace místa proběhnou v jednom atomickém kroku uvnitř routeru. Teprve potom se rezervace asynchronně rozešle jeho protějškům. Autoři změny #65010 tím řeší shlukování požadavků: dva routery by podle stejného starého snímku zátěže mohly současně vybrat tutéž repliku. Nejde však o globální zámek. Ostatní routery dostanou nový stav s krátkým zpožděním, takže jejich pohled je nakonec shodný, ne okamžitě totožný.

Do zásahu cache se počítá i RAM

Nová verze nevidí jen bloky v paměti GPU. Změna #65063 přidala události pro bloky odložené do paměti procesoru. Směrovač tak může poslat požadavek na repliku, která společný prefix nemá právě na GPU, ale dovede ho z RAM načíst. Zásah v RAM není stejně rychlý jako zásah v GPU; systém pouze ví, kde data leží, a může tuto informaci zahrnout do skóre spolu s rozpracovanou zátěží.

Vydání nedává jedno číslo zrychlení

Poznámky k Ray 2.58 neuvádějí přenositelné měření latence ani propustnosti. Jednotlivé návrhy obsahují grafy z vývojových zkoušek, ale ty nestačí k tvrzení, že každé nasazení zrychlí o určité procento. Výsledek závisí na tom, jak často se začátky požadavků opakují, kolik cache se vejde na GPU a jak drahé je načtení z RAM.

Smysl tohoto směru potvrzuje nezávislá práce Preble. Její autoři na dvou otevřených modelech a skutečných vzorcích provozu společně optimalizovali opakované prefixy a rozdělení výpočetní zátěže. Je to jiný systém než Ray a jeho výsledky nelze na verzi 2.58 přenést. Ukazuje ale přesně tentýž kompromis: replika s největší shodou v cache nemusí být nejlepší volbou, pokud už má plnou frontu.

Pro provozovatele je proto důležitější nový přehled o umístění bloků než slibovaná násobná zrychlení. Ray 2.58 spojuje stav cache na GPU a v RAM se stavem rozdělaných požadavků. Teprve měření na vlastním provozu ukáže, zda opakovaných prefixů přichází dost na to, aby složitější směrování přineslo úsporu.

Zdroje

• Ray 2.58.0 – poznámky k vydání (23. 8. 2026)
• PyPI – balíčky Ray 2.58.0 (23. 8. 2026)
• Preble: Efficient Distributed Prompt Scheduling for LLM Serving, verze 2 z 3. 10. 2024