Stejná GPU, víc hodnoty: kapacitu AI často brzdí pořadí práce

TL;DR:

• Nedostatek grafických procesorů pro umělou inteligenci nemusí vždy znamenat, že máš hned kupovat další hardware.
• U vytíženého výpočetního celku rozhoduje i pořadí úloh, jejich priorita, délka a nároky na souvislý blok GPU.
• Srovnávací test popisuje alokátor GPU zohledňující omezení, který proti plánování podle pořadí příchodu zvýšil využití až o 33 procentních bodů.
• Výstup vážený prioritou ve stejném testu vzrostl ve všech sedmi scénářích, nejvíce o 105 %.
• Praktický závěr není „vyždímej GPU na maximum“, ale „měř, která práce má hodnotu a kdy opravdu potřebuje kapacitu“.

Když malý AI tým řekne, že mu nestačí GPU, může tím myslet několik různých věcí. Trénink čeká ve frontě. Odpovědi modelu v reálném čase kolísají. Dávkové zpracování se odsouvá na noc. Kvantizace, tedy úprava modelu pro menší výpočetní nároky, se pouští jen tehdy, když zrovna nikdo nekřičí.

Na první pohled to vypadá jako jednoduchý kapacitní problém. Přidej další grafické procesory a fronta se zkrátí. Jenže u umělé inteligence (AI) často nestačí ptát se, kolik výpočetního výkonu máš. Stejně důležité je, kdo ho dostane, na jak dlouho, v jakém pořadí a s jakou prioritou.

Teze je praktická: dřív než schválíš další nákup GPU, ověř, jestli ti hodnota neutíká ve špatném plánování práce.

Fronta není strategie

Nejjednodušší způsob řízení výpočtů je plánovač podle pořadí příchodu. Kdo přijde první, ten se zpracuje první. Pro inference v reálném čase, tedy spouštění modelu nad aktuálními požadavky uživatelů, se drží pevná rezervace. Ostatní úlohy čekají podle toho, kdy dorazily.

To může být úplně přijatelné, pokud má výpočetní celek dost rezervy. Při nízkém vytížení není důvod stavět složitý plánovací systém. Problém začíná ve chvíli, kdy se na stejnou kapacitu tlačí trénink, inference v reálném čase, dávková inference a kvantizace.

Tyto práce se nechovají stejně. Trénink, dávková inference a kvantizace typicky potřebují souvislý blok GPU po celou dobu běhu. Jakmile začneš, nechceš úlohu každou chvíli přerušovat. Inference v reálném čase je jiná. Je elastická, protože poptávka roste a klesá podle provozu. V jednom časovém okně potřebuje víc kapacity, v dalším méně.

Když se tyto dva tvary práce potkají, samotná fronta ztrácí kontext. Nevidí, že krátká, vysoce prioritní úloha může mít větší hodnotu než starší dlouhý běh. Nevidí ani to, že špatně načasovaný trénink může zabrat souvislý blok GPU právě ve chvíli, kdy začne růst poptávka inference.

Rozhodnutí je menší a tvrdší, než zní

„Udržuj GPU vytížené“ není dost přesné zadání. Skutečné rozhodnutí zní: který grafický procesor spustí kterou úlohu, v kterém časovém kroku a s jakou prioritou.

To je nepříjemně konkrétní. Nestačí mít jeden ukazatel vytížení. Potřebuješ plánovací horizont, tedy pohled na několik budoucích kroků, a mřížku rozhodnutí přes GPU, úlohy a čas. V každém poli může být konkrétní úloha, nebo prázdné místo.

Článek, ze kterého tento signál vychází, popisuje srovnávací test alokátoru GPU zohledňujícího omezení proti plánovači podle pořadí příchodu v sedmi scénářích. Na identickém hardwaru a identických úlohách vzrostlo využití GPU až o 33 procentních bodů. Výstup vážený prioritou rostl ve všech scénářích, nejvíce o 105 %.

To neříká, že každý tým dostane stejný výsledek. Říká to něco užitečnějšího: pořadí práce může být samostatná páka výkonu. Pokud ji neměříš, můžeš si splést špatné řízení kapacity s nedostatkem kapacity.

Hodnota není totéž co vytížení

Vysoké využití GPU samo o sobě nestačí. Výpočetní celek může být plný práce, která má nízkou prioritu, zatímco důležitější úlohy čekají. Proto je zajímavější metrika výstup vážený prioritou: nepočítá jen, kolik se toho spočítalo, ale jak důležitý byl výsledek podle předem daných priorit.

Pro platform tým je to zásadní rozdíl. Pokud provozuješ trénink, inference v reálném čase, dávkovou inference a kvantizaci na jednom výpočetním celku, potřebuješ umět říct, co má v konkrétním čase přednost. Ne obecně. Konkrétně: tento trénink může počkat, tato dávka má doběhnout do rána, tato inference v reálném čase nesmí ztratit kapacitu při špičce.

Pro finanční nebo provozní vedení je to zase způsob, jak oddělit dva typy žádostí o peníze. Jedna žádost říká: „Nemáme dost GPU.“ Druhá říká: „Neumíme dost dobře rozhodovat, komu je v daný čas dát.“ Teprve když změříš druhý problém, dává smysl řešit první.

Kde to dává smysl i malému týmu

Nemusíš provozovat obří infrastrukturu, aby se tě princip týkal. Představ si malý tým, který má omezený rozpočet na GPU v cloudu. Přes den obsluhuje zákaznické dotazy přes model, večer spouští dávkové zpracování dokumentů a občas trénuje nebo dolaďuje menší model.

Pokud vše řadí podle příchodu, může drahý výpočet běžet ve špatný čas. Dávková úloha zabere kapacitu, když přijde provozní špička. Trénink začne těsně před oknem, kdy má doběhnout důležitá dávka. Nebo tým drží příliš velkou pevnou rezervu pro inference v reálném čase, i když skutečná poptávka část dne klesá.

První zlepšení nemusí být nový alokátor. Může to být prostá tabulka rozhodnutí: jaké typy úloh máme, kolik GPU potřebují, jestli vyžadují souvislý blok, jak dlouho běží, kdy je jejich výsledek potřeba a jakou mají prioritu. Jakmile to sepíšeš, fronta podle příchodu začne vypadat méně neutrálně. Ukáže se jako skryté pravidlo, které často nikdo vědomě nevybral.

Bez dobré poptávky plánovač hádá

Celý přístup stojí na tom, že poptávka není vymyšlená. U inference v reálném čase potřebuješ rozumnou křivku zatížení. U tréninku a dávkových úloh potřebuješ znát délku běhu, počet GPU a toleranci zpoždění. Když jsou vstupy špatné, chytřejší plánovač jen rychleji vyrábí špatná rozhodnutí.

Lidská kontrola proto zůstává důležitá. Někdo musí určit priority a říct, co znamená hodnota. Někdo musí zabránit tomu, aby se nízkoprioritní práce dlouhodobě odsouvala tak dlouho, až začne bolet provoz. A někdo musí rozhodnout, kdy už plánování nestačí a další kapacita je opravdu potřeba.

Užitečný první krok je jednoduchý: vezmi poslední týden provozu a rozděl čekání úloh do tří skupin. Čekaly kvůli skutečně plné kapacitě? Čekaly kvůli pevné rezervaci, která nebyla využitá? Nebo čekaly proto, že starší úloha dostala přednost před hodnotnější prací? Pokud neumíš odpovědět, nemáš ještě kapacitní problém popsaný dost přesně.

Zdroj

Hugging Face Blog: Same Cluster, 33 Points More Utilization: What Changed Was the Order https://huggingface.co/blog/Dharma-AI/gpu-management-pt2