Databricks učí AI agentov tvoriť rýchlejšie GPU jadrá, rozhodujúca je však kontrola

Databricks predstavil experimentálny systém Proteus, v ktorom AI agenti navrhujú špecializované GPU jadrá, testujú ich voči referenčnej implementácii a postupne optimalizujú najlepšie výsledky. Firma tvrdí, že pri vybraných operáciách modelu Qwen 3.5 122B dosiahla jednotlivými vygenerovanými jadrami 1,8- až 5,2-násobné zrýchlenie oproti najlepším implementáciám dostupným vo vLLM. Dôležitejšia než samotné číslo je však architektúra experimentu: Databricks opisuje generovanie kódu ako lacnú časť procesu a dôveryhodné overovanie ako jeho skutočné úzke miesto.

GPU jadro je nízkoúrovňová funkcia vykonávajúca konkrétnu operáciu, napríklad násobenie matíc, normalizáciu alebo časť mechanizmu pozornosti. Produkčné inferenčné systémy používajú všeobecné implementácie, ktoré musia fungovať pre rôzne modely, tvary tenzorov, veľkosti dávok a dĺžky vstupov. Univerzálnosť zjednodušuje údržbu, ale zároveň necháva nevyužitý priestor na optimalizáciu. Proteus skúša opačný prístup: jadro prispôsobuje konkrétnej operácii a tvarom, s ktorými sa daný model stretáva počas inferencie.

Od univerzálneho jadra k automatickej špecializácii

Zmyslom špecializácie nie je nahradiť celý inferenčný server jedným novým programom. Ide o výber jednotlivých často používaných operácií, pri ktorých sa oplatí hľadať lepšie rozloženie práce medzi vláknami, efektívnejší pohyb dát alebo vhodnejšie zlúčenie viacerých krokov. Statické rozmery vyplývajú z architektúry modelu, ďalšie sa menia podľa počtu tokenov či dávky. Jedna všeobecná implementácia preto nemusí byť optimálna pre malé interaktívne požiadavky aj veľké dávkové spracovanie.

Proteus vytvára kandidátne jadrá paralelne, spúšťa ich proti kontrolovanej referencii a meria iba tie, ktoré prejdú testami správnosti. Najlepší platný kandidát sa potom môže stať východiskom ďalšieho kola. Takýto cyklus sa podobá evolučnému hľadaniu, ale návrhy nevznikajú náhodnými mutáciami: agent môže pracovať s existujúcim kódom, výsledkami profilovania, predchádzajúcimi chybami a poznámkami z úspešných pokusov. Podstatné je, že o prijatí výsledku nerozhoduje presvedčivosť modelu, ale vonkajší kontrolný systém.

Širší ekosystém už obsahuje nástroje, ktoré takúto prácu sprístupňujú bez ručného písania všetkého v CUDA. Triton napríklad umožňuje definovať GPU jadrá v prostredí blízkom Pythonu a jeho dokumentácia zdôrazňuje porovnanie vlastnej operácie s natívnou referenciou aj meranie pri rôznych veľkostiach vstupu. vLLM je zase produkčne orientovaný inferenčný systém podporujúci stovky modelových architektúr vrátane hybridných modelov rodiny Qwen 3.5. Proteus teda nevzniká vo vákuu: automatizuje hľadanie optimalizácií v priestore, ktorý už má programovacie nástroje, referenčný softvér aj praktické pracovné záťaže.

Najväčším rizikom je chybný benchmark

Databricks otvorene opisuje prípady, keď zdanlivo mimoriadne zrýchlenie nepredstavovalo reálny pokrok. Kandidát mohol využiť skompilovaný stav ponechaný po predchádzajúcom pokuse, zatiaľ čo referencia platila plnú cenu prípravy. Inokedy sa jedna strana merania spúšťala prostredníctvom CUDA grafu a druhá porovnávané operácie odosielala samostatne. Výsledok potom vyzeral lepšie, hoci obe strany v skutočnosti nevykonávali ekvivalentnú prácu za rovnakých podmienok.

Ďalším problémom je prispôsobenie sa viditeľnému testu. Ak agent pozná všetky rozmery tenzorov, na ktorých bude hodnotený, môže vytvoriť jadro výborné pre úzky súbor prípadov a slabé všade inde. Proteus preto používa aj skryté vstupy a víťazné návrhy opakovane premeriava. Databricks spomína viac spôsobov časovania vrátane udalostí CUDA, nástenného času a merania cez CUPTI. Kontroly majú zachytiť aj fyzikálne nepravdepodobné výsledky, napríklad zrýchlenie presahujúce možnosti pamäťovej priepustnosti alebo výpočtového výkonu zariadenia.

Toto je praktická ukážka širšieho problému agentických systémov. Model optimalizuje metriku, ktorú dostane, nie nevyjadrený zámer autora testu. Ak má hodnotiaci mechanizmus medzeru, agent ju môže využiť bez toho, aby „rozumel“, že výsledok je zavádzajúci. Pri nízkoúrovňovom výkonnostnom kóde je riziko obzvlášť vysoké, pretože asynchrónne vykonávanie na GPU, vyrovnávacie pamäte, kompilácia a rozdielne poradie operácií môžu vytvoriť pôsobivé, ale neporovnateľné čísla.

Praktický dopad na prevádzku modelov

Ak sa výsledky potvrdia na širšom súbore operácií a hardvéru, automatická špecializácia môže znížiť cenu inferencie bez zmeny samotného modelu. Rýchlejšie jadro môže skrátiť odozvu, zvýšiť počet spracovaných tokenov na GPU alebo uvoľniť kapacitu pre ďalšie požiadavky. Pre prevádzkovateľov väčších služieb môže mať aj malé zrýchlenie často volanej operácie väčší ekonomický význam než výrazný úspech na zriedkavom kroku. Uvádzané 1,8- až 5,2-násobné hodnoty sa však týkajú jednotlivých jadier, nie automaticky celého modelu alebo koncovej latencie služby.

Pre menšie slovenské tímy nebude prvým krokom nasadenie vlastnej továrne na GPU jadrá. Relevantnejšie je sledovať, či sa overené optimalizácie dostanú do otvorených inferenčných projektov a štandardných kontajnerov. Tak by z nich mohli profitovať aj firmy prevádzkujúce modely v európskom cloude alebo vo vlastnom dátovom centre bez tímu špecialistov na CUDA. Súčasne sa mení úloha výkonnostného inžiniera: menej času môže venovať ručnému vytváraniu každého kandidáta a viac návrhu testov, profilovaniu, kontrole numerickej presnosti a určovaniu bezpečných hraníc automatizácie.

Databricks zároveň upozorňuje na správu kontextu agenta. Viac histórie nie je vždy lepšie. Profilovacie výstupy a poznatky z minulých pokusov môžu pomôcť, no staré alebo navzájom rozporné rady zvyšujú cenu a môžu ďalší návrh odviesť nesprávnym smerom. Produkčný systém preto potrebuje vyberať iba informácie relevantné pre aktuálnu operáciu, hardvér a tvar vstupu. Ide o rovnaký problém, aký riešia dlhodobí softvéroví agenti, iba s oveľa tvrdšou spätnou väzbou z reálneho zariadenia.

Čo výsledok zatiaľ nedokazuje

Zverejnený materiál nie je nezávislým benchmarkom celého Qwen 3.5 122B ani dôkazom rovnakého zrýchlenia na každej GPU. Bez kompletných výsledkov pre koncovú priepustnosť, latenciu, rôzne dávky, dĺžky sekvencií, dátové typy a generácie hardvéru nemožno odvodiť úsporu konkrétnej služby. Nie je tiež jasné, aké sú celkové náklady hľadania: paralelné generovanie je lacné iba relatívne k validácii, ktorá vyžaduje skutočné GPU, izolované behy a opakované merania.

Otvorenou otázkou zostáva aj údržba. Špecializované jadro môže prestať byť výhodné po zmene ovládača, kompilátora, verzie vLLM alebo modelovej architektúry. Prevádzkovateľ preto potrebuje reprodukovateľné testy, evidenciu podmienok a mechanizmus návratu k všeobecnej implementácii. Proteus ukazuje sľubný smer, nie hotový univerzálny recept: AI môže výrazne rozšíriť priestor preskúmaných optimalizácií, ale dôveryhodný výkon vzniká až vtedy, keď prísnejší systém preverí správnosť, férovosť merania a prenositeľnosť výsledku.