Agentní AI narazí na limity infrastruktury dřív než na limity inteligence

Modely se zlepšují rychleji, než dokážeme obsloužit to, co po nich chceme.

Většina debat o tom, kam směřují AI agenti, se točí kolem jejich schopností. Dokáže model spolehlivě plánovat? Umí napravit vlastní chyby? Lze mu svěřit úkol, jehož provedení má důsledky?

To jsou skutečně důležité otázky. O tom, zda budou agenti v příštích několika letech nasazováni ve velkém, ale nerozhodnou, protože existuje bližší omezení, které se blíží rychleji. Provoz agentů je z ekonomického hlediska problematický a s každou schopností, kterou jim všichni chtějí přidat, se tento problém prohlubuje.

Chatbot a agent představují odlišnou zátěž

Konverzační požadavek znamená jedno komunikační kolečko. Odešle se prompt, přijdou tokeny a spojení se ukončí. Požadavky lze dávkovat, předponu ukládat do mezipaměti a propustnost posuzovat podle jediného čísla.

Požadavek agenta představuje celou relaci. Agent zavolá nástroj, počká, přečte si výsledek, rozhodne se, co dál, zavolá další nástroj a nakonec odpoví. I poměrně jednoduchý úkol může zahrnovat šest nebo osm volání modelu, mezi nimiž se čeká.

Na tomto rozdílu záleží z důvodu, který s inteligencí nijak nesouvisí. Mezi jednotlivými kroky agent uchovává stav — konverzaci, výstupy nástrojů i dosavadní uvažování. Při obsluze se tento stav nachází v paměti GPU jako mezipaměť KV a zabírá ji po celou dobu relace, včetně sekund, kdy agent čeká na API, které neprovozujete vy.

Jednotkou kapacity tak přestávají být „požadavky za sekundu“ a stává se jí „počet souběžných relací uložených v paměti“. Systém, který bez problémů obsloužil tisíc konverzačních požadavků za sekundu, může na stejném hardwaru zvládnout jen několik desítek souběžných relací agentů.

Nejvíc stojí čekání

Tady je ta nepříjemná skutečnost: během volání nástroje agent nedělá nic. Negenerují se žádné tokeny a nespotřebovává se žádný výpočetní výkon. Paměť GPU je však stále obsazená, protože uvolnit tento kontext a znovu ho vypočítat by stálo víc než ho v paměti ponechat.

Váš nejdražší hardware je vyhrazen požadavku, který právě čeká na výsledek databázového dotazu.

V tradičních distribuovaných systémech jsme tento problém vyřešili už dávno — prostředek uvolníte a po příchodu odpovědi v práci pokračujete. Při obsluze modelů by stejný postup znamenal přesunout mezipaměť KV do hostitelské paměti nebo na disk a pak ji obnovit. Náklady na přenos jsou ale tak vysoké, že se tím většina systémů nezabývá. Výzkum právě této problematiky aktivně probíhá, protože jde o nákladný problém.

Sekvenční provádění situaci zbytečně zhoršuje

Téměř každý framework pro agenty provádí volání nástrojů jedno po druhém. Model požádá o zjištění počasí, dostane výsledek, požádá o kontrolu kalendáře, dostane výsledek, požádá o vyhledání letu a dostane výsledek.

Tyto tři požadavky na sobě přitom často nijak nezávisí. Mohly by se zpracovat současně. Při sekvenčním provádění se latence rovná součtu jejich dob, při souběžném provádění době trvání toho nejdelšího.

Nejde o nový postřeh týkající se agentů — je to tentýž strukturální princip, který platí pro každý systém provozující několik modelů nebo služeb v rámci jednoho rozpočtu latence. Celkovou latenci by měla určovat nejdelší cesta grafem závislostí, nikoli součet všech fází. U agentů je to důležitější proto, že relace zůstává po celou dobu v paměti GPU. Zkrácení celkové doby běhu proto nejen zlepší uživatelský zážitek, ale také přímo zvýší počet relací, které se na daný hardware vejdou.

Zkrácením délky relace na polovinu přibližně zdvojnásobíte kapacitu souběžných relací na stejných GPU, aniž byste museli měnit model.

Opakované pokusy se násobí způsobem, který nikdo nenavrhl

Frameworky pro agenty přebírají výchozí nastavení opakování požadavků z knihoven HTTP, na kterých jsou postavené. Obvykle jde o tři pokusy.

Model také opakuje pokusy, jen po svém. Když nástroj vrátí neužitečný výsledek, model schopný uvažování často zkusí jiný postup — jde tedy o opakování, které ale nikdo nenastavil.

Když se tyto mechanismy zkombinují, pravidlo tří pokusů obalené kolem modelu, který samostatně vymyslí další tři postupy, znamená devět pokusů — ačkoli to nikdo nikde nenapsal. Každý z nich představuje úplné volání modelu s vlastními tokeny i dobou využití GPU.

Když se některá závislost zpomalí, právě toto zesílení problému promění zhoršený výkon ve výpadek. Náklady na jeden pokus jsou přitom o řády vyšší než u opakovaného volání REST.

Jak tato překážka ve skutečnosti vypadá

Nejde o strop schopností. Je to něco mnohem všednějšího: problém nákladové efektivity, který zastavuje projekty na hranici mezi pilotním provozem a produkčním nasazením.

Pilotní provoz funguje. Má deset uživatelů, latence je přijatelná a účet za provoz představuje zaokrouhlovací chybu. Pak někdo přepočítá náklady pro deset tisíc uživatelů a potřebný počet GPU vyjde jako nereálný — ne proto, že by byl model pomalý, ale protože každá souběžná relace zabírá paměť po celou dobu svého trvání, včetně čekání.

Právě v této fázi řada slibných interních ukázek nenápadně končí.

Co posouvá hranici

Nic exotického — jde výhradně o infrastrukturu, nikoli o modelování:

Spouštějte nezávislá volání nástrojů souběžně. Největší jednotlivé zlepšení, které je k dispozici už dnes a nevyžaduje žádný nový hardware.

Kapacitu měřte délkou trvání relací. Ne počtem tokenů za sekundu. Ne využitím GPU. Rozhoduje, jak dlouho zůstává stav v paměti a kolik relací se do ní vejde.

Rozpočítejte opakování požadavků v rámci celého systému, nikoli pro každé volání zvlášť. Globální limit — opakování jako malé procento celkového provozu — brání výše popsanému řetězovému nárůstu. Praxe SRE společnosti Google při zvládání přetížení i rozpočty na opakování požadavků v Envoy tento přístup uplatňují mimo AI stack.

Oddělte uvažování od provádění. Velký model použijte k plánování, mnohem menší k mechanickým krokům. Většina činností agenta nevyžaduje špičkový model.

Zajistěte, aby uvolňování kontextu bylo nenákladné. Kvantovaná mezipaměť KV, stránkovaná pozornost a možnosti odložení neaktivních relací. Právě zde se nyní odehrává nejzajímavější vývoj v oblasti obsluhy modelů.

Modely se budou dál zlepšovat. Tato část vypadá jistě. O tom, zda se agenti stanou součástí infrastruktury, nebo zůstanou jen ukázkami, rozhodne něco méně okázalého — zda dokážeme obsluhovat úlohu, která během čekání drží drahou paměť, a zda přestaneme platit za součet délek jednotlivých kroků, když bychom mohli platit jen za nejdelší cestu.

Model provádění, který stojí za touto poslední myšlenkou — souběžné provádění závislých volání modelu v rámci jediného rozpočtu na latenci — jsem publikoval v článku „Asynchronní provádění inferenčních grafů pro směrování modelů v systémech strojového učení“, International Journal of Computer Trends and Technology 72(10), říjen 2024. O integraci generativních modelů konkrétně do rozhodovacích systémů s omezenou latencí pojednává článek „Obchodní a rozhodovací platformy rozšířené o LLM: propojení generativní inteligence s finančními rozhodovacími systémy“, Journal of Information Systems Engineering and Management 11(1s), 2026.