Dlaczego koszty sztucznej inteligencji agentowej gwałtownie rosną: model kosztów oparty na architekturze

Gdy ludzie mówią o kontrolowaniu wydatków na modele językowe, dyskusja zwykle zaczyna się i kończy na cenie tokenów.

„Jaka jest stawka za milion tokenów dla tego modelu?”

To słuszne pytanie, ale w przypadku systemów AI typu agentic o poziomie produkcyjnym pomija ono prawdziwy problem.

Jedna prośba od użytkownika nie przekłada się na jeden wywołanie modelu językowego.

Pipeline agentic zazwyczaj funkcjonuje w następujący sposób:

User Request
     ↓
Router
     ↓
Planner
     ↓
Retrieval
     ↓
Tool Call
     ↓
Tool Result Interpretation
     ↓
Validator
     ↓
Final Response

Jedna przychodząca prośba może wywołać pięć, sześć, dziesięć lub nawet więcej wywołań modeli i narzędzi, zanim zostanie rozwiązana.

Z tego powodu warto śledzić nie tyle:

Koszt za jedno wywołanie modelu

ile:

Koszt za ukończoną zadanie.

Co naprawdę wpływa na koszt agenta

Całkowity koszt uruchamiania workflow agentic znacznie przewyższa samą ilość zużytych tokenów:

Agent Cost
=
LLM inference
+ Embeddings
+ Reranking
+ Vector/Search infrastructure
+ Tool/API calls
+ Compute
+ Storage
+ Observability
+ Evaluations

Nawet w obszarze „LLM inference” mamy do czynienia z tokenami wejściowymi, tokenami wyjściowymi, tokenami w pamięci cache oraz ewentualnie kilkoma różnymi modelami, które działają na różnych etapach procesu.

Ta rzeczywistość zmienia sposób podejmowania decyzji dotyczących architektury.

1. Wysyłaj każdą prośbę do modelu o odpowiedniej mocy

Nie każde zadanie wymaga użycia najpotężniejszego modelu, do którego mamy dostęp.

Request
   ↓
Router
   ├── Simple extraction → Small model
   ├── Moderate reasoning → Mid-tier model
   └── Complex reasoning → Strong model

Kolejnym przydatnym wzorcem jest eskalacja.

Zacznij od lekkiego, niedrogiego modelu i przenieś zadanie do silniejszego tylko wtedy, gdy poziom pewności jest niski, walidacja się nie powiedzie lub zadanie okazuje się bardziej złożone, niż się spodziewano.

Celem nie jest zawsze wybór najtańszej opcji.

Celem jest znalezienie najmniej kosztownej architektury, która nadal spełnia wymagane standardy jakości i niezawodności.

2. Przestań wydawać zasoby na wywołania modeli w logice deterministycznej

To wydaje się oczywiste, ale ma ogromne znaczenie, gdy pracujesz na dużą skalę.

Zawsze, gdy zwykły kod może niezawodnie odpowiedzieć na pytanie, pozwól mu to zrobić.

Rzeczy takie jak sprawdzanie uprawnień, operacje arytmetyczne, walidacja schematu, filtrowanie, deterministyczne decyzje routingu oraz większość reguł biznesowych zazwyczaj nie wymagają wykorzystania LLM.

Poluzowana zasada praktyczna:

Nigdy nie deleguj do LLM czegoś, co deterministyczny oprogramowanie radzi sobie lepiej.

Zachowaj rozumowanie probabilistyczne na te etapy w procesie pracy, gdzie naprawdę uzasadnia swoją cenę.

3. Traktuj kontekst jak budżet wydatków

Agenty działające przez długi czas stale gromadzą kontekst w trakcie swojej pracy.

Jeśli tego nie kontrolować, każdy dodatkowy krok może ponownie wysłać całą historię rozmów, poprzednie wyniki narzędzi, pobraane dokumenty oraz wcześniejsze ślady rozumowania z powrotem do modelu.

Zamiast pozwalać kontekstowi rosnąć bez ograniczeń, należy utrzymać go na poziomie bliższym:

Recent Context
      +
Compact Summary
      +
Relevant Memory
      +
Task-Specific Retrieved Context

Praktyki takie jak streszczanie, wygaszanie czasu trwania, przesuwane okna kontekstu oraz pobieranie danych z pamięci na podstawie istotności służą nie tylko do zarządzania rozmiarem kontekstu.

Funkcjonują one również jako narzędzia kontroli kosztów.

4. Ustawienie RAG Top-K to element sterujący kosztami

Załóżmy, że pobierasz 20 fragmentów, z których każdy liczy około 700 tokenów.

Daje to łącznie mniej więcej 14 000 tokenów pobranego materiału.

Jednak być może tylko cztery z tych fragmentów są rzeczywiście istotne dla odpowiedzi.

Lepiej zaprojektowany proces pobierania danych wygląda bardziej tak:

Query
  ↓
Retrieve broader candidate set
  ↓
Rerank
  ↓
Select best 4–6 chunks
  ↓
LLM

Zastosowanie szerokiego zbioru kandydatów nie oznacza, że każdy z nich musi trafić do okna kontekstowego modelu.

Jakość pozyskiwania danych oraz koszty przetwarzania są więc powiązanymi ze sobą decyzjami architektonicznymi, a nie odrębnymi kwestiami.

5. Cache na więcej niż jednej warstwie

Caching to nie pojedyncza technika — istnieje kilka rodzajów, które warto łączyć ze sobą.

Naprzимер:

Exact Cache
Semantic Cache
Prompt/Context Cache
Tool Result Cache
Retrieval Cache

Gdy duża liczba użytkowników zadaje pytania semantycznie identyczne, ponowne uruchamianie całego procesu agenta od zera za każdym razem jest często marnotrawstwem zasobów.

Podobnie, obszerne statyczne instrukcje systemu, definicje narzędzi oraz teksty polityk nie muszą być przetwarzane od nowa przy każdym wezwaniu, o ile twoja platforma lub dostawca modeli obsługuje odpowiedni mechanizm cache’owania.

6. Ustalenie ścisłych ograniczeń dla agentów autonomicznych

Agenty niosą ze sobą własne zagrożenie: niekontrolowane pętle.

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
...

Jeden błąd w orkiestracji może jednocześnie doprowadzić do awarii niezawodności oraz gwałtownego wzrostu kosztów.

Z tego powodu agenty produkcyjne wymagają wyraźnych zasad bezpieczeństwa obejmujących m.in.:

Maximum agent steps
Maximum tool calls
Maximum tokens
Maximum wall-clock time
Maximum cost per run

Gdy jeden z tych budżetów zostanie wyczerpany, proces powinien się zatrzymać, przejść na alternatywną ścieżkę, spokojnie zmienić swoje zachowanie lub przekazać zadanie człowiekowi, w zależności od wymagań sytuacji.

7. Włącz koszty do swojego zestawu narzędzi do obserwacji

Każda ślad generowana w produkcji powinna umożliwić odpowiadanie na pytania takie jak:

Which application?
Which workflow?
Which agent?
Which model/provider?
How many input tokens?
How many output tokens?
How many tool calls?
How long did it take?
How much did it cost?
Did the task actually succeed?

Następnie panele kontrolne mogą pokazywać takie metryki jak:

Cost / request
Cost / successful task
Cost / workflow
Cost / model
Cost / application
Cost / team
Cost / customer

W tym momencie optymalizacja wydatków na AI coraz bardziej przypomina inżynierię platform i FinOps, niż modyfikację promptów.

Koszt i jakość muszą być dostrojone razem

Najtańszy proces nie jest automatycznie najlepszy.

Jeśli tani model często zawodzi i wymusza ponowne próby, alternatywne ścieżki lub interwencję ręczną, jego rzeczywisty koszt może ostatecznie przewyższyć koszt lepszego modelu, który rozwiązuje problem od razu.

Dlatego wskaźnik, który warto optymalizować, wygląda mniej więcej tak:

Successful Tasks
Value = --------------------
        Cost + Latency + Risk

To nie jest dosłowne, uniwersalne równanie — to sposób myślenia inżynierskiego.

Dla produkcji opartej na sztucznej inteligencji konieczna jest następująca zmiana podejścia:

Przestań optymalizować tokeny oddzielnie. Zacznij optymalizować aspekty ekonomiczne skutecznego ukończenia zadania.

Ponieważ w momencie, gdy agenci potrafią rozumować, wyszukiwać informacje, korzystać z narzędzi, próbować ponownie, weryfikować i powtarzać proces:

Jedna prośba użytkownika nie odpowiada już jednej wywołaniu modelu.

I właśnie w tym momencie koszt przestaje być jedynie detalą cenowym i staje się wyzwaniem w projektowaniu systemu.

Literatura pokrewna

• Agentic AI wyjaśnione: od modeli językowych do autonomicznych agentów — Strukturalny przegląd tego, jak modele językowe ewoluują w systemy agencyjne za pomocą narzędzi, pamięci, planowania, architektur wieloagentowych oraz integracji MCP.
• Agency vs. Autonomy: Rozróżnienie dwóch podstawowych koncepcji w agentic AI — Dowiedz się, jak odróżnić zdolność agenta AI do działania (agency) od jego niezależności w podejmowaniu decyzji (autonomia), korzystając z prostego modelu mentalnego i przykładów.