Keď sme nasadzovali prvého agenta pre klienta z ťažkého priemyslu — úloha: automatizovať zostavovanie týždenných správ z piatich systémov — celkový token cost za prvý mesiac presiahol pôvodný odhad päťnásobne. Nie preto, že agent robil niečo zlé. Ale preto, že sme nedomysleli, koľko tokenov spotrebuje každý krok slučky, keď história rastie, keď sa volanie nástroja opakovane retruje, a keď sa do kontextu pridáva celá konverzácia pri každom volaní. To, čo v prototypu stálo centavov na dotaz, v produkcii s desiatkami používateľov a tisíckami denných úloh stálo o rad vyššie.
Tento článok nie je o hypotetickej cenotvorbe. Je o tom, kde skutočne tečú peniaze pri nasadení agenta, prečo sú bežné odhady tak ďaleko od reality, a aký súbor optimalizácií v praxi funguje — od kratšieho kontextu cez routing na lacnejšie modely až po prompt caching.
Kde sa rodí token cost agenta
Agenti sú drahší ako jednoduché LLM volania z jedného prostého dôvodu: každý krok slučky je nové volanie API, pričom do kontextu vstupuje narástajúca história. Porovnajte to s klasickým RAG: jeden dotaz, jedno volanie, odpoveď. Agent s desiatimi krokmi urobí desať volaní — a každé z nich nesie celý predchádzajúci kontext.
Konkrétna topológia nákladov vyzerá takto:
- Systémový prompt — opakuje sa pri každom volaní. Ak máš systémový prompt s 2 000 tokenmi a agent urobí 8 krokov, zaplatíš za ten istý text osemkrát.
- Konverzačná história — každý Reason-Act-Observe cyklus pridáva ďalšie tokeny do kontextu. Pri dlhých úlohách rastú input tokeny kvadraticky.
- Tool výstupy — odpovede nástrojov (databázové výsledky, API odpovede, dokumenty) sa vkladajú do kontextu a zvyšujú jeho veľkosť. Rozsiahly RAG retrieval pred každým krokom môže zdvojnásobiť input tokeny.
- Retry slučky — ak volanie nástroja zlyhá, agent sa to pokúsi znova. Retry rate 10–15 % je v produkčných systémoch bežný. Každý retry = ďalšie volanie s celým kontextom.
- Output tokeny — reasoning agentov (chain-of-thought, step-by-step uvažovanie) generuje dlhé odpovede. Output tokeny sú zvyčajne 3–5× drahšie ako input.
Výsledok: reálny agent v produkcii spotrebuje na jednu úlohu rádovo 5–50× viac tokenov, než by ste odhadli z prototypu.
Rádové príklady — čo to znamená v eurách
Ceny modelov sa menia každé 1–3 mesiace, preto uvádzam orientačné rádové príklady platné v čase písania tohto článku. Vždy overte aktuálnu cenu priamo u providera.
Frontier modely sa v súčasnosti pohybujú v rozsahu od ~$0.10 do ~$5 za milión input tokenov a od ~$5 do ~$30 za milión output tokenov — teda rozdiel 50× medzi najlacnejším a najdrahším tierom. To je kľúčové číslo: výber modelu je najsilnejšia nákladová páka, silnejšia ako akákoľvek iná optimalizácia.
Predstavte si agenta, ktorý spracúva 100 úloh denne:
- Lacný tier (Flash/Haiku-ekvivalent, $0.10–0.30/1M input tokenov): aj pri 50 000 tokenoch na úlohu sa pohybujete v rádoch eur za deň. Mesačne niekoľko stoviek eur.
- Stredný tier (Sonnet-ekvivalent, ~$3–5/1M input tokenov): rovnaká záťaž môže vyjsť na 1 000–3 000 eur mesačne.
- Premium tier (Opus-ekvivalent, ~$15+/1M input tokenov): tá istá záťaž môže byť 5–10× drahšia ako stredný tier.
Ak navyše systém beží s retry rate 12 %, efektívne platíte za každú úlohu 1.12× — čo sa pri väčšom objeme rýchlo nasčíta.
Human escalation je ďalší skrytý náklad: ak agent zlyhá na 5 % úloh a každá eskalácia na ľudského operátora stojí 2–10 eur (čas), môže byť tento náklad vyšší ako samotný token cost.
Štyri miesta, kde sa náklady dajú efektívne reznúť
1. Skráť kontext — systematicky, nie náhodou
Najväčší úspor nie je lacnejší model, ale menej tokenov na volanie. Konkrétne kroky:
- Systémový prompt komprimuj. Každý nadbytočný riadok v systémovom prompte sa zaplatí stokrát denne. Pravidelne audituj, čo tam skutočne treba.
- Konverzačnú históriu sumarizuj. Namiesto vkladania celej histórie do kontextu nechaj agenta po N krokoch vytvoriť zhrnutie.
LangGraphmá na toto vstavaný sumarizačný node. Stráca sa nejaká granularita, ale pre väčšinu úloh to nevadí. - Tool výstupy filtruj. Ak RAG retrieval vráti päť dokumentov, ale agent potrebuje iba jeden, zbytočne platíte za štyri. Nastav reranking a limit počtu fragmentov vložených do kontextu.
- Limituj output dĺžku. Reasoning toka nemusí byť vždy neobmedzený. Pre štandardné kroky stačí krátka odpoveď; detailný chain-of-thought nechaj len pre skutočne zložité rozhodovacie body.
2. Routuj na lacnejší model pre jednoduché kroky
Nie každý krok agenta potrebuje frontier model. Typická distribúcia:
- Orchestračné kroky (čo robiť ďalej, aký nástroj zavolať): zvyčajne zvládne lacnejší model
- Retrieval a filtrovanie dát: lacný model alebo dokonca deterministická logika
- Finálna syntéza odpovede pre používateľa: tu sa oplatí silnejší model
- Verifikácia a self-consistency check: lacný model v slučke
LLM routing — dynamický výber modelu podľa zložitosti kroku — je optimalizácia, o ktorej sme písali samostatne v článku o LLM routingu a cascadingu. V agentnom kontexte funguje rovnaký princíp: máš dispatcher, ktorý klasifikuje každý krok a posiela ho na najlacnejší model schopný ho zvládnuť.
3. Prompt caching — systémový prompt zaplať raz
Prompt caching je technológia, ktorú Anthropic, OpenAI aj Google ponúkajú vo svojich API. Princíp: ak sa začiatok kontextu (typicky systémový prompt alebo dlhý statický dokument) opakuje naprieč volaniami, provider si ho cachuje na strane servera a za opakovanie ho účtuje zlomkom štandardnej ceny — rádovo –90 % na cachovanú časť.
Pre agenta, ktorý má dlhý systémový prompt a beží v desiatkach súbežných sessions, je caching jedna z najrýchlejšie implementovateľných úspor. Bližšie to rozoberáme v článku o prompt cachingu a nákladoch.
Podmienka: caching funguje dobre pre stabilné časti promptu. Ak každé volanie obsahuje iný dynamický obsah na začiatku, cache hit rate bude nízky a úspora minimálna.
4. Nastav limity — pred nasadením, nie po incidente
Toto je bod, ktorý sa v technickej literatúre spomína ako poznámka pod čiarou, ale v praxi je to zákon: agent bez hard limitov je finančné riziko.
max_steps(alebo ekvivalent): maximálny počet krokov slučky pred zastavenímmax_tokens_per_run: celkový token budget na jednu úlohutimeout: čas, po ktorom sa agent zastaví a vráti čiastočný výsledokcost_budget_per_day: na úrovni celého systému, monitorované alertom
Agent bez max_steps limitu môže pri neočakávanom vstupe alebo závislosti nástroja uviaznuť v slučke a cez noc vygenerovať tisíce volaní — s účtom rádovo v tisícoch eur. Nie je to hypotetické. Vídame to v produkčných systémoch a je to vždy preventabilné.
Agentic RAG: kde náklady eskalujú nenápadne
Agentic RAG — teda RAG, kde agent sám rozhoduje, koľkokrát a čo načítať — je 5–10× drahší ako klasický RAG. Nie preto, že by bol zlý, ale preto, že robí viac práce.
Typická sekvencia agentic RAG na jednu otázku:
- 1.Rozhodnutie, aký retrieval strategy použiť (1 LLM volanie)
- 2.Prvé vyhľadávanie (retrieval + reranking)
- 3.Vyhodnotenie, či sú výsledky dostatočné (1 LLM volanie)
- 4.Prípadné ďalšie vyhľadávanie s upraveným dotazom (retrieval + reranking)
- 5.Syntéza odpovede (1 LLM volanie s celým zozbieraným kontextom)
Každý krok má cenu. Ak navyše používate silný model pri každom z týchto volaní, náklady rastú rýchlo.
Optimalizácia: použite lacný model na rozhodovacie kroky (1, 3) a silný model len na finálnu syntézu (5). A nastavte limit počtu retrieval iterácií — väčšina otázok sa vyrieši v 1–2 kolách, nie v piatich.
Viac o architektúre agentic RAG nájdete v článku Agentic RAG — ako to funguje v praxi.
Batch API: keď nemusíte čakať na výsledok ihneď
Ak máte úlohy, ktoré nepotrebujú odpoveď v reálnom čase — offline spracovanie dokumentov, nočné analytické behy, tréningové dáta — Batch API je výrazná úspora. Anthropic (a ďalší provideri) ponúkajú –50 % na batch volania oproti synchronnej cene, za cenu spracovania s oneskorením niekoľko hodín.
Architektúra: front-end systém zbiera úlohy do fronty, batch job beží v noci alebo keď je záťaž nízka, výsledky sa zapíšu do databázy a sú k dispozícii na ráno. Pre mnohé priemyselné aplikácie — sumarizácia reportov, kategorizácia dokumentácie, extrakcia dát z PDF — je tento prístup finančne o rad výhodnejší.
Meranie nákladov: čo sledovať v produkcii
Token cost bez observability je čierna skrinka. Odporúčame sledovať minimálne tieto metriky:
- Cost per task type — rôzne typy úloh majú rôzny nákladový profil. Bez tohto rozlíšenia nevieš, kde optimalizovať.
- Retry rate per tool — ktorý nástroj najčastejšie spôsobuje retry? Je to nástrojová chyba alebo slabá tool description?
- Average steps per run — ak ide v priemere na 8 krokov tam, kde ste predpokladali 4, treba sa pozrieť na architektúru.
- Cache hit rate — ak máte prompt caching, koľko percent volaní skutočne cache-uje? Pod 60 % je caching zle nastavený.
- Human escalation rate — koľko percent úloh skončí eskaláciou? Ak rastie, pravdepodobne agent zlyhá na scenároch, pre ktoré nebol dizajnovaný.
Nástroje ako Langfuse (self-hostable, framework-agnostic) alebo LangSmith (deep LangGraph integrácia) tieto metriky zachytávajú na úrovni každého node-u a volania. Bez observability ste slepí — o tom viac v článku o observability AI agentov.
Open-weight modely ako nákladová alternatíva
Pre tímy, ktoré riešia predovšetkým nákladovú stránku, sú aktuálne open-weight modely reálnou alternatívou. Rodiny ako Qwen 3.x, DeepSeek alebo Llama 4 dosahujú na mnohých agentic benchmarkoch výsledky porovnateľné s frontier closed-source modelmi — pri nulových alebo minimálnych API nákladoch, ak bežia on-premises.
Platíte GPU server namiesto API. Pre veľké objemy úloh (desaťtisíce denných volaní) je break-even bod zvyčajne v horizonte mesiacov. Pre regulované prostredia, kde dáta nesmú opustiť firmu, je on-prem navyše compliance požiadavka.
Tradeoff: on-prem vyžaduje engineering kapacitu na správu infraštruktúry, serving stack (vLLM, SGLang), monitoring a upgrady modelov. Nie každý tím to má.
Časté otázky
Prečo je môj agent oveľa drahší, ako som pôvodne odhadol?
Bežný dôvod je kombinácia troch vecí: rastúca história v kontexte pri každom kroku slučky, retry volania pri zlyhaní nástrojov a dlhé systémové prompty opakované pri každom volaní. Prototype testuje zvyčajne 1–2 kroky so statickými vstupmi. Produkcia znamená reálne vstupy, reálne chyby nástrojov a používateľov, ktorí agent dostavia do neočakávaných stavov. Odporúčame profilovať cost per run rozdelený na zložky (systémový prompt, história, tool výstupy, output) skôr, ako začnete optimalizovať.
Oplatí sa implementovať prompt caching?
Ak máš systémový prompt dlhší ako 1 000 tokenov a agent beží v desiatkach alebo stovkách sessions denne, áno — oplatí sa takmer vždy. Implementácia je väčšinou jednoduchá (parameter pri API volaní), úspora na cachovanej časti je rádovo –90 % u Anthropicu. Podmienka je stabilita začiatku kontextu — ak sa systémový prompt pri každom volaní mení, cache hit rate bude nízky.
Kedy sa oplatí prepnúť z API na on-prem model?
Záleží na objeme a compliance požiadavkách. Ako orientačné pravidlo: ak mesačný API bill presiahne náklady na dedikovaný GPU server (vrátane správy a amortizácie HW) — typicky niekde okolo niekoľkých tisíc eur mesačne — má zmysel robiť analýzu. Pre regulated odvetvia (zdravotníctvo, právo, financie) je on-prem navyše podmienka GDPR compliance, nie len nákladová otázka.
Ako nastaviť rozumný max_steps limit?
Začnite profilovaním — koľko krokov skutočne potrebuje vaša typická úloha? Ak median je 4 kroky a 95. percentil je 8, nastavte limit na 12–15 s bezpečnostnou rezervou. Limit by mal byť dosť vysoký, aby neprerušoval legitímne dlhé úlohy, ale dosť nízky, aby zachytil nekonečné slučky. Kombinácia max_steps + timeout + monitoring alertu na runs s > 80 % limitu je v praxi robustná.
Čo je väčší náklad — tokeny alebo human escalation?
Záleží od miery eskalácie. Ak agent eskaluje 1–2 % úloh a ľudský čas stojí 5 eur na incident, pri 1 000 úlohách denne je to 50–100 eur/deň na eskalácie — čo môže prevýšiť token cost lacnejšieho modelu. Pre systémy s vysokým objemom úloh a nezanedbateľnou mierou eskalácie je znižovanie eskalácie (lepší tréning agenta, jasnejšie guardrails) lepšia investícia ako šetriť na tokenoch.
*Náklady agenta v produkcii sú merateľné a kontrolovateľné — ale len ak ich reálne meriame. V MP Industrial Solutions pomáhame firmám navrhnúť agentic systémy s jasným cost profilem od začiatku, nie retrospektívne optimalizovať po tom, čo prvý mesačný účet prekvapí. Ak uvažujete o nasadení agenta a chcete si urobiť realistický cost model ešte pred implementáciou, radi sa porozprávame.*