Trzy tryby działania agentów AI i ich wpływ na koszty: analiza kursu Decoding AI

Decyzja o wyborze odpowiedniego modelu sztucznej inteligencji często jest postrzegana jako najważniejszy czynnik wpływający na jakość działania agenta. Jednakże, jak wskazują najnowsze badania i literatura inżynierska, kluczowe znaczenie ma architektura otaczająca model, czyli tzw. „harness”. Eksperyment LangChain Terminal-Bench wykazał, że sama zmiana harnessu, przy zachowaniu tego samego modelu, pozwoliła agentowi kodującemu awansować z około 30. miejsca do pierwszej piątki pod względem wydajności.

Ten wynik zmienia perspektywę – jeśli to harness decyduje o jakości, sposób uruchamiania pętli agenta staje się decyzją architektoniczną, a nie jedynie szczegółem wdrożeniowym. Paul Iusztin w swoim otwartym kursie „Building a Coding Agent From Scratch”, opublikowanym przez Decoding AI, przedstawia agenta Pythona o nazwie Decode. Kurs ten wyróżnia trzy tryby działania, z których każdy charakteryzuje się innym profilem opóźnień i wymaga odmiennego dostawcy usług inferencji.

Architektura agenta i rola harnessu

Centralnym elementem systemu jest bezgłowy harness, pozbawiony własnego interfejsu. W jego wnętrzu działa pętla agenta, wspólna dla wszystkich harnessów: LLM (Large Language Model) wybiera akcję, narzędzie ją wykonuje, a obserwacja jest przekazywana z powrotem. Wszystkie operacje odczytu i zapisu odbywają się w oknie kontekstowym.

Sam agent jest stosunkowo niewielki. W przypadku Decode, jest to około 20-liniowa definicja Pydantic AI, która łączy model, narzędzia i typ wyjścia. W ujawnionym kodzie Claude Code, podstawowa pętla to około 150 linii. Cała reszta – pamięć, umiejętności, środowisko piaskownicy (sandbox), uprawnienia, informacje zwrotne z LSP (Language Server Protocol) i kompresja – to elementy harnessu.

Interfejsy podłączają się do tego rdzenia, co prowadzi do wyróżnienia trzech trybów działania:

Trzy tryby działania agentów

1. Interaktywny tryb terminalowy (Terminal UI): Ten tryb jest połączony z jedną aktywną sesją, działającą w pamięci, w tym samym procesie. Zdarzenia są przesyłane strumieniowo za pomocą generatorów asynchronicznych w miarę pojawiania się tokenów. Kluczowym wyzwaniem jest tutaj sterowanie. Jeśli użytkownik wprowadzi tekst w trakcie wykonywania narzędzia, natychmiastowe wstrzyknięcie wiadomości może zakłócić przebieg. Rozwiązaniem w Decode jest kolejka sterująca oraz bramka priorytetowa. Dane wejściowe są buforowane po przybyciu i wstrzykiwane tylko w bezpiecznym momencie. Pętla udostępnia dwa takie punkty: MODEL_REQUEST (przed kolejnym wywołaniem modelu) i WOULD_STOP (gdy tura miałaby się zakończyć). Trzy tryby wprowadzania danych odpowiadają temu: Enter steruje w ramach tury, Alt+Enter dodaje kontynuację do kolejki, a Esc wywołuje kooperatywne przerwanie w najbliższym punkcie granicznym, czyszcząc obie kolejki, aby historia pozostała nienaruszona. W tym trybie, gdzie człowiek odczytuje każdy token, kluczowe są niskie opóźnienia, co sprawia, że idealnie nadaje się do hostowanych API o niskiej latencji.

2. Tryb zdalny (Remote Mode): W tym trybie harness pozostaje bezgłowy i działa na serwerze za pośrednictwem środowiska uruchomieniowego agenta. Decode wykorzystuje Kitaru, środowisko uruchomieniowe agenta firmy ZenML, wdrożone na GCP, z agentami wykonującymi zadania na Modal. Nikt nie monitoruje agenta na bieżąco; zaległe zadania są rozsyłane do wielu harnessów równolegle, a każdy z nich generuje własne żądanie pull (PR). Dzięki temu, że środowisko uruchomieniowe rejestruje postępy krok po kroku, piaskownica, która ulegnie awarii w trakcie zadania, wznawia pracę od ostatniego zarejestrowanego kroku, zamiast rozpoczynać od nowa. Uruchomienie, które wymaga interwencji człowieka, zostaje wstrzymane i nie zużywa zasobów obliczeniowych podczas oczekiwania. Narzędzia są wykonywane zdalnie w Modal Sandboxes lub lokalnie w Dockerze. Kluczową metryką jest tutaj przepustowość na dolara, a nie czas do pierwszego tokena.

3. Tryb hybrydowy (Hybrid Mode): Ten tryb plasuje się pomiędzy dwoma poprzednimi. Aktywna sesja przekazuje pracę do kolejki zadań i natychmiast zwraca wynik. Procesy w tle rozsyłają wywołania LLM i później publikują wyniki. Użytkownik jest online, ale nie obserwuje każdego kroku. Kolejka zarządza pracą, więc uruchomienie trwa dłużej niż klient, który je zainicjował. Jest to wzorzec stojący za agentami aktywowanymi przez Slacka i przeglądami PR w tle, a jego rozliczanie przypomina przetwarzanie wsadowe, a nie czat.

Ekonomika dostawców i koszty

Model kosztowy ściśle podąża za wymaganiami dotyczącymi opóźnień, a różnice są znaczące. Przykładem może być przetwarzanie 1000 dokumentów, każdy po 30 000 tokenów wejściowych i około 500 tokenów wyjściowych. Przy stawkach API na poziomie 3 USD za milion tokenów wejściowych i 15 USD za milion tokenów wyjściowych, koszt wynosiłby około 97 USD. Buforowanie promptów nie rozwiązuje problemu, ponieważ każdy dokument ma inny prefiks. To samo zadanie, przetwarzane wsadowo na bezserwerowym GPU z prędkością około 3000 tokenów na sekundę, zajmuje mniej niż trzy godziny czasu GPU, co kosztuje około 13 USD.

Odwrotny przypadek jest równie wymowny. Domyślny model testowy Decode, Qwen3.6 35B, działa na pojedynczym H200. Cennik Modal podaje cenę H200 SXM na 0,001261 USD za sekundę, czyli około 4,54 USD za godzinę. Jeśli interaktywny agent pozostanie bezczynny przez noc, czekając na potwierdzenie, dziesięć godzin bezczynności może dodać około 45 USD do rachunku.

Cały argument sprowadza się do tego: praca interaktywna jest rozliczana za token, ponieważ człowiek czeka na odpowiedź. Praca offline i asynchroniczna jest rozliczana za godzinę GPU, ponieważ celem jest przepustowość, a czas bezczynności jest wrogiem.

Serwerless kontra rezerwacja pojemności

Istnieje również druga oś: serwerless kontra zarezerwowana pojemność. Analiza cenowa Modal sprowadza to do jednego porównania. Rezerwacje obciążają stawką szczytową za cały okres umowy, podczas gdy serwerless podąża za krzywą popytu. Gdy stosunek szczytu do średniej przekracza zniżkę za rezerwację, serwerless jest tańszy. Modal podaje typowe zniżki od 2 do 5 razy w stosunku do stosunków szczytu do średniej wynoszących od 5 do 10 razy dla inferencji, szkolenia i rozwoju agentów. Badania branżowe, na które się powołuje, wskazują, że wykorzystanie rezerwacji jest poniżej 30%, często nawet poniżej 10%.

Zrozumienie tych trzech trybów działania agentów AI oraz ich implikacji kosztowych jest kluczowe dla firm i deweloperów, którzy chcą efektywnie wdrażać i skalować rozwiązania oparte na sztucznej inteligencji. Wybór odpowiedniej architektury i modelu rozliczeniowego może znacząco wpłynąć na rentowność i wydajność projektów AI, zwłaszcza w kontekście rosnących wymagań dotyczących zarówno interaktywności, jak i przetwarzania wsadowego.

Źródło: marktechpost.com