AWS navrhuje spoločný GPU klaster s oddelením tímov, kvótami a rozpočítaním nákladov

AWS zverejnilo referenčnú architektúru pre firmy, v ktorých viac tímov zdieľa jeden GPU klaster Amazon SageMaker HyperPod nad Amazon EKS. Návrh kombinuje centrálnu autentifikáciu cez AWS IAM Identity Center, samostatné roly a SageMaker domény pre jednotlivé tímy, menné priestory Kubernetes, HyperPod Task Governance a účtovanie nákladov podľa namespace. Nejde o nový typ GPU ani o automatickú službu, ktorá vyrieši viacnájomnosť jedným prepínačom. AWS skladá existujúce stavebné prvky do konkrétneho prevádzkového vzoru pre tréning, inferenciu a experimenty. Cieľom je, aby spoločný klaster priniesol vyššie využitie drahých akcelerátorov bez toho, aby jeden tím nekontrolovane spotreboval kapacitu alebo videl pracovné zaťaženie iného tímu.

Jeden klaster, nie jedna úroveň dôvery

Zdieľanie GPU je ekonomicky lákavé, pretože tréningové a experimentálne úlohy majú nerovnomerný priebeh. Samostatný klaster pre každý tím môže veľkú časť času stáť nevyužitý, zatiaľ čo iný tím čaká na voľné akcelerátory. Spoločná infraštruktúra však vytvára tri odlišné problémy. Prvým je identita a oprávnenie: systém musí vedieť, kto úlohu zadáva a ku ktorým objektom má prístup. Druhým je plánovanie kapacity, aby dlhý tréning alebo séria experimentov nevytlačili ostatných. Tretím je finančná zodpovednosť, pretože bez presného označenia spotreby sa náklady na GPU menia na spoločný účet, ktorý nepodporuje rozumné rozhodovanie tímov.

Architektúra AWS začína vo firemnom poskytovateľovi identity, napríklad Microsoft Entra ID, ktorý je federovaný s IAM Identity Center. Používateľ dostane tímovú rolu a prostredníctvom nej vstupuje do príslušnej SageMaker AI domény alebo pracuje s klastrom programovo. Každému tímu zodpovedá vlastný namespace v EKS. Na tejto vrstve sa uplatní Kubernetes RBAC a ďalšie pravidlá, ktoré obmedzujú, aké objekty môže tím čítať alebo meniť. Oddelenie používateľského prostredia od samotného výpočtového klastra je dôležité: pohodlný prístup cez SageMaker Studio nemusí znamenať široké administrátorské práva v Kubernetes.

Férovosť sa nekončí pevnou kvótou

Bežný Kubernetes ResourceQuota vie obmedziť súhrnné požiadavky a limity zdrojov v namespace. Je to užitočná ochrana pred neobmedzenou spotrebou, no samotná tvrdá kvóta nemusí byť ideálna pre vzácne GPU. Ak má tím rezervovanú kapacitu, ktorú práve nepoužíva, pevné rozdelenie ju môže nechať nečinnú aj vtedy, keď na ňu čaká iná úloha. AWS preto do návrhu pridáva HyperPod Task Governance. Správcovia definujú compute allocation pre tímy a systém používa fronty a priority na prideľovanie kapacity. Zmyslom je zachovať garantovaný podiel, ale zároveň umožniť efektívnejšie využitie dočasne voľných zdrojov podľa nastavenej politiky.

Takéto plánovanie je pre AI úlohy dôležitejšie než pri mnohých bežných webových službách. Distribuovaný tréning môže potrebovať viac GPU naraz a čiastočné pridelenie mu nemusí priniesť žiadny úžitok. Interaktívny notebook zasa potrebuje rýchlu odozvu, hoci spotrebuje menej zdrojov, a inferenčná služba môže mať prevádzkové ciele, ktoré ju stavajú nad experimenty. Referenčný návrh dáva administrátorom mechanizmy na vyjadrenie priorít, ale neurčuje univerzálne správne poradie. Firma musí sama rozhodnúť, či má prednosť produkčná inferencia, časovo obmedzený tréning, výskumná úloha alebo pohotovostná kapacita pre incidenty.

Ďalšou vrstvou je priradenie nákladov k menným priestorom a tímom. Ak sú úlohy konzistentne označené a identita sa premieta do namespace, prevádzkovateľ môže merať, kto spotreboval pridelené GPU a ako dlho. To podporuje interný chargeback, pri ktorom sa náklad účtuje konkrétnemu útvaru, alebo showback, pri ktorom tím spotrebu iba vidí. Samotná viditeľnosť často mení správanie: zabudnuté notebooky, zbytočne veľké rezervácie a opakované experimenty bez ukončovacích podmienok už nie sú skryté v spoločnej faktúre. AWS však nepredkladá univerzálny ekonomický model a výsledná presnosť závisí od zberu metrík, označovania a pravidiel organizácie.

Namespace nie je nepriestrelná bezpečnostná hranica

Najdôležitejšie obmedzenie návrhu vyplýva zo samotného Kubernetes. Oficiálne odporúčania projektu rozlišujú viacnájomnosť s dôveryhodnými a nedôveryhodnými používateľmi a upozorňujú, že menné priestory poskytujú najmä logické oddelenie. Dokumentácia EKS to formuluje ešte priamočiarejšie: klaster je silnejšia bezpečnostná hranica než namespace. Útočník s prístupom k hostiteľskému uzlu môže potenciálne zasiahnuť tajomstvá, zväzky alebo pracovné zaťaženia ďalších nájomníkov na tom istom uzle. RBAC, kvóty a sieťové politiky preto nemožno zamieňať s fyzickou alebo kryptografickou izoláciou samostatných klastrov.

Pre interné tímy s porovnateľnou úrovňou dôvery môže byť takzvaná mäkká viacnájomnosť primeraným kompromisom. Treba ju však doplniť sieťovými politikami, bezpečnostnými štandardmi pre pody, obmedzením privilegovaných kontajnerov, kontrolou obrazov, auditnými záznamami a starostlivou správou tajomstiev. Ak pracovné zaťaženia spracúvajú výrazne odlišné regulačné triedy dát alebo ich prevádzkujú vzájomne nedôveryhodné subjekty, vhodnejšie môžu byť oddelené uzly, účty alebo celé klastre. Tie znižujú efekt zdieľania a zvyšujú administratívne náklady, no poskytujú menší dosah chybnej konfigurácie alebo kompromitovaného uzla.

Čo to znamená pre menšie AI tímy

Pre slovenské firmy a výskumné pracoviská je tento vzor zaujímavý najmä tam, kde je GPU kapacita dostatočne drahá na centralizáciu, ale organizácia už má viac samostatných projektov. Jeden tím môže dolaďovať jazykový model, druhý prevádzkovať počítačové videnie a tretí spúšťať dávkovú inferenciu. Spoločný klaster môže zlepšiť využitie hardvéru, no až vtedy, keď sú vopred určení vlastníci namespace, limity, priority a spôsob merania nákladov. Bez týchto pravidiel centralizácia iba presunie spor o rozpočet do frontu plánovača. Návrh AWS je preto skôr organizačno-technická šablóna než skratka k lacnejšiemu cloudu.

Migrácia na tento model si vyžaduje aj prevádzkovú disciplínu. Tímy musia správne deklarovať požiadavky na zdroje, používať reprodukovateľné kontajnery a vedieť úlohy bezpečne obnoviť po prerušení. Administrátori musia testovať, ako sa fronty správajú pri súbehu veľkých tréningov a krátkych interaktívnych úloh. Potrebné je tiež sledovať nevyužitú rezervovanú kapacitu, čas čakania, úspešnosť úloh a reálne náklady na jeden experiment. Bez týchto metrík môže klaster vyzerať vyťažený, ale poskytovať horší čas dokončenia alebo drahšiu prácu než niekoľko jednoduchších prostredí.

AWS neuvádza, že referencia automaticky prinesie konkrétne percento úspor alebo garantovanú úroveň izolácie. Výsledok bude závisieť od profilu úloh, cien zvolených inštancií, pravidiel priority a kvality bezpečnostnej konfigurácie. Hodnota nového materiálu spočíva v tom, že prepája identitu, pracovné prostredie, plánovanie GPU a finančnú evidenciu do jedného kontrolovateľného návrhu. Organizácie tak dostávajú praktický základ, ale pred produkčným nasadením musia vykonať vlastné záťažové, bezpečnostné a obnovovacie testy a rozhodnúť, ktoré tímy si môžu spoločnú hranicu dôvery dovoliť.