AI agentowa napotka barierę infrastrukturalną, zanim natrafi na barierę inteligencji

Modele rozwijają się szybciej niż nasze możliwości obsługi zadań, które się przed nimi stawia.

Większość dyskusji o przyszłości agentów AI dotyczy ich możliwości. Czy model potrafi niezawodnie planować? Czy umie naprawiać własne błędy? Czy można mu powierzyć działanie, które niesie ze sobą konsekwencje?

To realne pytania. Nie one jednak zdecydują, czy w ciągu najbliższych kilku lat agenci będą wdrażani na dużą skalę, ponieważ istnieje bliższe ograniczenie, które daje o sobie znać coraz szybciej. Obsługa agentów jest nieefektywna ekonomicznie, a problem nasila się wraz z każdą z funkcji, które wszyscy chcą dodać.

Chatbot i agent to różne rodzaje obciążenia

Pojedyncze zapytanie w rozmowie to jedna wymiana: wysyłasz prompt, otrzymujesz tokeny, po czym połączenie zostaje zamknięte. Można łączyć zapytania w partie, buforować prefiks i oceniać przepustowość za pomocą jednej liczby.

Zapytanie do agenta to cała sesja. Agent wywołuje narzędzie, czeka, odczytuje wynik, decyduje, co zrobić dalej, wywołuje kolejne narzędzie i dopiero na końcu udziela odpowiedzi. Nawet niezbyt złożone zadanie może wymagać sześciu lub ośmiu wywołań modelu, rozdzielonych oczekiwaniem.

Ta różnica ma znaczenie z przyczyny, która nie ma nic wspólnego z inteligencją. Między kolejnymi krokami agent przechowuje stan — rozmowę, wyniki zwracane przez narzędzia i zgromadzone rozumowanie. Po stronie systemu obsługującego ten stan znajduje się w pamięci GPU jako pamięć podręczna KV i zajmuje ją przez całą sesję, również przez te sekundy, kiedy agent czeka na odpowiedź API, które nie jest twoje.

Jednostką określającą przepustowość przestają więc być „zapytania na sekundę”, a stają się nią „jednoczesne sesje przechowywane w pamięci”. System, który bez trudu obsługiwał tysiąc zapytań konwersacyjnych na sekundę, na tym samym sprzęcie może obsłużyć zaledwie kilkadziesiąt jednoczesnych sesji agentów.

Najwięcej kosztuje czekanie

Oto niewygodna właściwość tego rozwiązania: podczas wywoływania narzędzia agent nic nie robi. Nie generuje tokenów ani nie zużywa mocy obliczeniowej. Pamięć GPU pozostaje jednak zajęta, ponieważ usunięcie tego kontekstu i ponowne jego obliczenie kosztowałoby więcej niż jego przechowywanie.

Najdroższy sprzęt jest zarezerwowany dla zapytania, które w danej chwili czeka na wynik zapytania do bazy danych.

W tradycyjnych systemach rozproszonych rozwiązaliśmy ten problem już dawno temu — zwalniamy zasób i wracamy do pracy, gdy nadejdzie odpowiedź. Zastosowanie tego samego podejścia do obsługi modeli wymaga przeniesienia pamięci podręcznej KV do pamięci hosta lub na dysk, a następnie jej przywrócenia. Koszt przesyłania danych jest na tyle wysoki, że większość systemów tego nie robi. Badania nad dokładnie tym zagadnieniem są prowadzone, ponieważ problem jest kosztowny.

Wykonywanie sekwencyjne pogarsza sytuację bardziej, niż to konieczne

Niemal każdy framework agentowy wykonuje wywołania narzędzi jedno po drugim. Model prosi o sprawdzenie pogody, otrzymuje wynik, prosi o sprawdzenie kalendarza, otrzymuje wynik, a następnie prosi o wyszukanie lotu i otrzymuje wynik.

Często te trzy wywołania nie zależą od siebie i mogłyby odbywać się równocześnie. Wykonywane sekwencyjnie, ich opóźnienia się sumują. Wykonywane równolegle, trwają tyle, co najdłuższe z nich.

To nie jest nowa obserwacja dotycząca agentów — ta sama zasada strukturalna ma zastosowanie do każdego systemu, który uruchamia wiele modeli lub usług w ramach jednego budżetu opóźnień. Całkowite opóźnienie powinno odpowiadać najdłuższej ścieżce w grafie zależności, a nie sumie czasu trwania wszystkich etapów. W przypadku agentów ma to większe znaczenie, ponieważ sesja przez cały czas zajmuje pamięć GPU. Skrócenie czasu rzeczywistego nie tylko poprawia komfort użytkownika, ale też bezpośrednio zwiększa liczbę sesji, które mieszczą się na danym sprzęcie.

Skróć czas trwania sesji o połowę, a w przybliżeniu dwukrotnie zwiększysz liczbę jednoczesnych sesji — na tych samych GPU i bez zmiany modelu.

Ponawianie prób nawarstwia się w nieprzewidziany sposób

Frameworki agentowe dziedziczą domyślne ustawienia ponawiania prób z używanych przez nie bibliotek HTTP. Zazwyczaj są to trzy próby.

Model również ponawia próby, choć robi to na swój sposób. Gdy narzędzie zwraca nieprzydatny wynik, model rozumujący często próbuje innego podejścia — to także ponowienie próby, tyle że nieustawione przez nikogo.

Połączenie tych mechanizmów sprawia, że polityka trzech prób, zastosowana wobec modelu, który samodzielnie rozumuje i wybiera jeszcze trzy inne podejścia, w praktyce oznacza dziewięć prób — choć nikt tego nie zapisał. Każda z nich to pełne wywołanie modelu, zużywające własne tokeny i sekundy pracy GPU.

Gdy działanie zależności zwalnia, to właśnie to zwielokrotnienie prób zmienia pogorszenie wydajności w awarię — a koszt każdej próby jest o rzędy wielkości wyższy niż koszt ponowionego wywołania REST.

Jak naprawdę wygląda bariera

Nie jest nią ograniczenie możliwości. To coś bardziej przyziemnego: problem ekonomiki jednostkowej, który zatrzymuje projekty na etapie przejścia od pilotażu do produkcji.

Pilotaż się sprawdza. Użytkowników jest dziesięciu, opóźnienie jest akceptowalne, a rachunek to błąd zaokrąglenia. Potem ktoś szacuje koszty dla dziesięciu tysięcy użytkowników i okazuje się, że wymagania dotyczące GPU są nierealne — nie dlatego, że model działa wolno, lecz dlatego, że każda jednoczesna sesja zajmuje pamięć przez cały czas swojego trwania, a wlicza się w niego również oczekiwanie.

To właśnie na tym etapie wiele obiecujących wewnętrznych wersji demonstracyjnych po cichu kończy swój żywot.

Co przesuwa tę granicę

Nic niezwykłego — wszystko to dotyczy infrastruktury, a nie modelowania:

Równolegle wykonuj niezależne wywołania narzędzi. To największa pojedyncza korzyść, którą można osiągnąć już dziś, bez zakupu nowego sprzętu.

Za miarę wydajności przyjmij czas trwania sesji. Nie liczbę tokenów na sekundę. Nie wykorzystanie GPU. Liczy się to, jak długo stan pozostaje w pamięci i ile sesji można pomieścić.

Ustalaj budżet ponowień dla całego systemu, a nie dla każdego wywołania z osobna. Globalny limit — ponowienia jako niewielki odsetek całego ruchu — zapobiega opisanemu wyżej narastaniu problemu. Praktyki SRE firmy Google dotyczące obsługi przeciążenia oraz budżety ponowień Envoy wdrażają tę samą ideę poza stosem AI.

Oddziel rozumowanie od wykonywania zadań. Do planowania użyj dużego modelu, a do mechanicznych czynności — znacznie mniejszego. Większość zadań wykonywanych przez agenta nie wymaga modelu z najwyższej półki.

Ogranicz koszt usuwania kontekstu. Skwantyzowana pamięć podręczna KV, uwaga stronicowana oraz mechanizmy przenoszenia danych dla nieaktywnych sesji. To właśnie w tym obszarze prowadzone są obecnie najciekawsze prace nad obsługą modeli.

Modele będą się nadal doskonalić. To wydaje się pewne. To, czy agenci staną się elementem infrastruktury, czy pozostaną wersjami demonstracyjnymi, zależy od czegoś mniej efektownego — od tego, czy potrafimy obsługiwać obciążenie, które zajmuje kosztowną pamięć, czekając na swoją kolej, oraz czy przestaniemy płacić za sumę czasów wykonania kolejnych etapów, skoro moglibyśmy płacić za czas najdłuższej ścieżki.

Model wykonania leżący u podstaw tej ostatniej tezy — równoległe wykonywanie zależnych od siebie wywołań modeli w ramach jednego budżetu opóźnień — opisałem w artykule „Asynchroniczne wykonywanie grafów wnioskowania na potrzeby routingu modeli w systemach uczenia maszynowego”, opublikowanym w czasopiśmie International Journal of Computer Trends and Technology 72(10) w październiku 2024 roku. O integracji modeli generatywnych z systemami decyzyjnymi, w których kluczowe znaczenie ma opóźnienie, piszę w artykule „Platformy transakcyjne i decyzyjne wspomagane przez LLM: łączenie inteligencji generatywnej z finansowymi systemami decyzyjnymi”, opublikowanym w czasopiśmie Journal of Information Systems Engineering and Management 11(1s) w 2026 roku.