AWS balí viacuzlovú inferenciu s Ray: prefill a decode môžu bežať na oddelených GPU

AWS predstavil postup, ako nasadiť jeden veľký jazykový model na dva GPU uzly v Amazon EKS pomocou viacuzlového Ray LLM Deep Learning Containera. Referenčná architektúra oddeľuje fázu prefill, ktorá spracuje vstupný prompt a vytvorí KV cache, od fázy decode, ktorá z tejto cache postupne generuje výstupné tokeny. Obe časti pritom zostávajú dostupné cez jeden endpoint kompatibilný s API OpenAI. Novinkou nie je samotná myšlienka distribuovanej inferencie, ale hotovejšie spojenie Ray Serve LLM, kontajnera s otestovaným GPU softvérovým zásobníkom, Kubernetes orchestrácie a sieťovej vrstvy potrebnej na prenos cache medzi uzlami.

AWS ukazuje konfiguráciu s dvoma GPU uzlami, nie univerzálnu službu, ktorá automaticky zrýchli každý model. Jeden uzol vykonáva prefill a druhý decode. Ray koordinuje distribuované komponenty a KubeRay spravuje ich životný cyklus v klastri. Kontajner zahŕňa Ray Serve LLM, NVIDIA Inference Transfer Library a podporu Elastic Fabric Adaptera. Úlohou NIXL a EFA je preniesť KV cache dostatočne rýchlo, aby samostatný decode uzol nemusel prompt spracovať znova. Aplikácia sa navonok správa ako jeden inferenčný server, hoci výpočet prebieha na viacerých strojoch.

Prečo sa prefill a decode správajú odlišne

Pri prefill fáze model naraz prechádza všetky tokeny vstupu a vytvára ich vnútorné reprezentácie uložené v KV cache. Táto časť býva výpočtovo náročná, najmä pri dlhých dokumentoch, rozsiahlej histórii rozhovoru alebo RAG kontexte. Decode potom produkuje token po tokene a pri každom kroku číta a rozširuje cache. Jeho správanie je citlivejšie na priepustnosť pamäte a stabilnú latenciu. Ak obe fázy zdieľajú ten istý akcelerátor, nárazový príchod dlhého promptu môže spomaliť generovanie odpovedí, ktoré už prebieha pre iných používateľov.

Oddelenie umožňuje prideľovať obom fázam kapacitu samostatne. Prevádzkovateľ môže napríklad pridať decode repliky, ak služba obsluhuje veľa súbežných odpovedí, alebo posilniť prefill časť pri práci s dlhými vstupmi. Ray vo svojej dokumentácii uvádza prefill/decode disaggregation spolu s tensorovým, pipeline, expertovým a dátovým paralelizmom medzi podporovanými stratégiami. Nejde teda o náhradu všetkých ostatných spôsobov škálovania. Ak sa model nezmestí do pamäte jedného uzla, stále môže byť potrebné rozdeliť jeho váhy. Oddelenie prefill a decode rieši predovšetkým rozdielne prevádzkové vlastnosti dvoch fáz jednej požiadavky.

Táto architektúra dáva najväčší zmysel pri nevyrovnanej záťaži: podnikové vyhľadávanie s dlhými dokumentmi, sumarizácia, agentické systémy s rozsiahlym stavom alebo asistenti, ktorí dostávajú veľký kontext, ale majú odpovedať plynulo. Menšiu hodnotu môže mať pri krátkych promptoch, nízkej súbežnosti alebo modeloch, ktoré bez problémov obslúži jediná GPU. Rozdelenie totiž pridáva sieťový prenos, ďalší uzol a viac prevádzkových komponentov. Prínos preto musí byť väčší než cena presunu KV cache a koordinácie medzi službami.

Kontajner odstraňuje časť integračnej práce

Praktickým prínosom Ray LLM DLC je zbalenie verzií rámca, CUDA knižníc, obslužnej vrstvy a sieťových závislostí do kombinácie testovanej AWS. Pri ručne poskladanom zásobníku môže aktualizácia jednej vrstvy narušiť kompatibilitu s ovládačom, komunikačnou knižnicou alebo inferenčným enginom. AWS tvrdí, že komponenty kontajnera overuje spoločne a bezpečnostné opravy pridáva pri jeho zostavení. Tým sa nezruší potreba testovania konkrétneho modelu, ale zmenší sa priestor, v ktorom musí tím sám hľadať kompatibilné verzie.

Referenčné nasadenie sa opisuje najmä konfiguráciou v YAML. KubeRay vytvorí Ray klaster a rozmiestni jeho procesy na GPU uzly v EKS. Ray Serve zabezpečí smerovanie požiadaviek a poskytne rozhranie kompatibilné s klientmi OpenAI. Kubernetes naďalej rieši uzly, pody, plánovanie a stav workloadu, takže riešenie zapadá do prostredia, ktoré už môže podnik používať pre ostatné kontajnerové služby. Nie je to však bezobslužná platforma: tím musí spravovať kapacitu GPU, sieť, obrazy, aktualizácie klastra, pozorovanie latencie aj správanie pri výpadku jedného z uzlov.

Pre slovenské firmy je podstatné, že ide o stavebný prvok pre vlastnú infraštruktúru, nie o nový model ani hotovú používateľskú aplikáciu. Môže byť relevantný pre organizácie, ktoré musia prevádzkovať open-weight model vo vlastnom cloudovom účte, potrebujú kontrolovať sieťové hranice alebo chcú zjednotiť AI workloady s existujúcim Kubernetes prostredím. Menšie tímy by však mali porovnať túto flexibilitu so spravovanou inferenčnou službou. Dva GPU uzly, vysokorýchlostné prepojenie a odborná správa klastra môžu stáť viac než úspora získaná lepším rozdelením práce.

Výkon závisí od siete aj charakteru požiadaviek

Kritickým miestom je KV cache. Prefill uzol ju musí odovzdať decode uzlu skôr, než začne plynulé generovanie. AWS na tento prenos používa NIXL nad EFA a v návode uvádza aj kontrolu použitého komunikačného backendu a test priepustnosti pomocou NCCL benchmarku. To je dôležitý detail: funkčné nasadenie ešte nedokazuje, že komunikácia využíva očakávanú rýchlu cestu. Nesprávna konfigurácia sieťového rozhrania, umiestnenia podov alebo ovládačov môže vytvoriť systém, ktorý odpovedá správne, ale pomalšie než jednoduchšie riešenie na jednom uzle.

AWS v oznámení nepredkladá univerzálne výsledky, podľa ktorých by rozdelenie vždy znížilo latenciu alebo náklady. Článok je technický návod a demonštrácia architektúry, nie porovnávací benchmark viacerých modelov a typov inštancií. Zatiaľ preto nevieme, pri akej dĺžke promptu, súbežnosti a veľkosti modelu sa dodatočný uzol ekonomicky oplatí. Chýbajú aj čísla pre čas do prvého tokenu, medzitokenovú latenciu, priepustnosť, objem prenesenej cache a správanie počas špičky. Tieto parametre si musí každý prevádzkovateľ zmerať na vlastnej distribúcii požiadaviek.

Pred produkčným použitím by mal tím porovnať aspoň tri varianty: spoločný prefill a decode na jednom uzle, oddelenie na dvoch uzloch a viac replík bez oddelenia fáz. Meranie má zahŕňať krátke aj dlhé vstupy, percentily latencie, využitie GPU, náklady na požiadavku a obnovu po strate uzla. Dôležité je tiež sledovať, či jeden prefill uzol nezostane úzkym miestom po pridaní decode replík. Otvorené zostávajú produkčné otázky okolo aktualizácie bez prerušenia, obnovy rozpracovaných požiadaviek a riadenia kapacity pri náhlom náraste dlhých promptov.

Ray LLM DLC tak posúva viacuzlovú inferenciu bližšie k opakovateľnému nasadeniu: namiesto ručného skladania celej GPU a komunikačnej vrstvy ponúka AWS otestovaný základ a konkrétny vzor pre EKS. Hodnota riešenia sa však ukáže až v meraniach. Ak pracovná záťaž naozaj trpí tým, že dlhý prefill blokuje decode, samostatné škálovanie oboch fáz môže zlepšiť využitie hardvéru aj predvídateľnosť odpovedí. Ak je problémom skôr malý objem prevádzky alebo vysoká cena GPU, ďalší uzol by iba presunul zložitosť a zvýšil účet.