Optimalizácia nákladov na AI agentov: kde miznú

Optimalizácia nákladov na AI agentov nezačína pri výbere lacnejšieho modelu, ale pri tom, ako narábate s kontextom a cache. Najväčšie plytvanie vzniká, keď server znovu a znovu prepočítava celú históriu konverzácie za plnú cenu namiesto toho, aby čítal z cache. Keď k tomu pripočítate zle využitý hardvér pri agentoch, účet rastie bez toho, aby ste dostali viac práce.

Poviem to rovno: pri agentických nasadeniach nás nikdy nezabil model. Zabíjala nás réžia okolo neho. Prepísaná cache, zbytočne dlhá história v každom ťahu a jedna agentová inštancia, ktorá nechá polovicu výkonu ležať ladom.

Ako funguje cache a prečo ju platíte znova?

Každý ťah v konverzácii prehráva modelu celú doterajšiu históriu. Prompt caching^?Uloženie doterajšej histórie konverzácie na strane servera, aby sa pri ďalšom ťahu čítala lacnejšie namiesto plného prepočtu. to robí zvládnuteľným: história sa uloží na strane servera a pri ďalšom ťahu sa číta za desatinu bežnej ceny vstupu. Cache má však časové okno. Keď vyprší alebo sa naruší zhoda, systém ju prepíše za plnú cenu.

Používateľ na fóre r/ClaudeAI opísal, ako mu prepisovanie cache pohltilo 30 % spotreby v Claude Code. Príčinou boli dlhé sedenia s prestávkami: keď medzi ťahmi ubehlo viac než hodina, cache vypršala a celá história sa prepočítala nanovo, tentoraz bez zľavy.

• Časové okno cache je krátke. Pri Claude ide o hodinu. Prestávka na obed teda nemusí byť zadarmo.
• Cache sa naruší aj vtedy, keď sa zmení čo i len byte na začiatku promptu. Jedinečné ID v systémovom prompte dokáže rozbiť zhodu úplne.
• Prehráva sa celá história, nie iba nová správa. Čím dlhšia session, tým drahší každý ďalší ťah.

Čo sú cold fills a ako spomaľujú aj zdražujú?

Cold fill^?Situácia, keď model musí prepočítať kontext od nuly napriek zdanlivo teplému stavu, čo spôsobí dlhú pauzu pred prvým výstupom. je situácia, keď má agent teoreticky teplý kontext, no server ho aj tak musí prepočítať od začiatku. Prejaví sa dlhou pauzou pred prvým vygenerovaným tokenom. Nejde len o rýchlosť; ten prepočet niekto zaplatí, či už tokenmi u poskytovateľa, alebo časom vlastného GPU.

Vývojár, ktorý prevádzkoval Qwen3.5-122B na Mac Studio s 96 GB, opísal, že následné správy sa začínali generovať až po 3 až 5 minútach napriek údajne teplému kontextu. Príčina nebola v modeli. Jedinečné ID v systémovom prompte rozbilo byte-exact zhodu KV cache^?Vnútorná pamäť modelu s medzivýsledkami pre už spracovaný kontext; ak sa naruší jej zhoda, kontext sa musí prepočítať od začiatku. a vynútilo si úplný prepočet celého kontextu.

Poučenie je nepríjemne banálne. Stabilný, nemenný začiatok promptu je podmienka, aby cache vôbec fungovala. Ak do systémového promptu vkladáte časové značky, náhodné identifikátory alebo poradové čísla, každý ťah je pre model nový a platíte plnú cenu.

Ako paralelní agenti menia využitie hardvéru?

Pri agentických nástrojoch typu Open Code sa oplatí spúšťať viac agentov naraz. Jedna inštancia často nevyužije dostupný priechod (throughput^?Priepustnosť, teda koľko práce dokáže model alebo GPU spracovať za jednotku času; pri agentoch ju zvyšuje paralelizácia.) hardvéru. Behanie štyroch a viac agentov paralelne dokáže tú istú prácu dostať cez model výrazne efektívnejšie.

Používateľ r/LocalLLaMA testoval Qwen3.6 35B cez LM Studio na RTX 5090 s nastavením na 8 paralelných úloh. Podľa jeho meraní pri behu s jednou úlohou necháva človek ležať zhruba polovicu možného výkonu; reálny zisk sa začína pri aspoň štyroch bežiacich agentoch.

Berte to ako meranie jednotlivca, nie ako laboratórny benchmark. No smer sedí s tým, čo vidno v praxi: pri lokálnom nasadení sa oplatí naplniť priepustnosť GPU súbežnými požiadavkami, nie posielať jednu úlohu za druhou a čakať.

Kým však do agenta pridáte paralelizáciu alebo mu dáte ďalší nástroj, počítajte, čo sa stane, keď ho použije zle. O tom, ako agentom obmedziť dosah a čo robiť s právom zápisu, som písal v texte o tom, čo sa deje, keď agent dostane priveľa právomocí. Rýchlosť bez brzdy je len rýchlejšia cesta k problému.

Prečo je kontext dôležitejší než výber modelu?

Pri optimalizácii nákladov na AI agentov sa väčšina firiem sústredí na cenník modelov. Podľa publikácie naucime.ai má pritom správa kontextu väčší praktický dosah, pretože dobre pripravené inštrukcie a dokumentácia prežijú viac generácií modelov. Zlá práca s kontextom zdražuje každý jeden ťah bez ohľadu na to, ktorý model použijete.

Odporúčania, ktoré sa opakujú naprieč zdrojmi, sú nudné a fungujú:

• Pri novej úlohe začni novú konverzáciu, nesnaž sa recyklovať starú históriu.
• Pri dlhších projektoch si nechaj model priebežne zhrnúť najdôležitejšie body a pokračuj s týmto zhrnutím ako kontextom.
• Kontext organizuj cez súbory, projekty a štruktúrované dokumenty, nie cez neporiadnu históriu chatu.

Portál flowhunt.io k tomu dodáva sledovanie efektivity tokenov a odstraňovanie problematického kontextu pri takzvanom context poisoning^?Znečistenie kontextu obsahom, ktorý agenta systematicky tlačí k horším odpovediam, kým sa problematická časť neodstráni., keď sa do konverzácie dostane obsah, ktorý agenta trvalo tlačí k horším odpovediam. Konkrétne čísla o úsporách zdroj neuvádza, takže to berte ako princíp, nie ako záruku percent.

Kde sa oplatí do optimalizácie investovať čas?

Poradie je jasné z toho, koľko peňazí každá vrstva ovplyvní. Najprv stabilizujte začiatok promptu, aby cache držala. Potom skráťte a zhrňte kontext, aby ste v každom ťahu neprehrávali celú históriu. Nakoniec, ak beží lokálny alebo vlastný inference, doplňte priepustnosť paralelnými agentmi.

1. Stabilný systémový prompt. Žiadne náhodné ID ani časové značky na začiatku. Toto je najlacnejšia oprava s najväčším dosahom.
2. Aktívna správa kontextu: zhrnutia medzi etapami, nové konverzácie pri nových úlohách.
3. Paralelizácia agentov pri vlastnom hardvéri, keď jedna inštancia nevyužíva GPU.

Ak tieto veci riešite v produkcii a nie v prototype, oplatí sa pozrieť na dvojdňový workshop o produkčnej AI, RAG a architektúre kontextu pre CTO a architektov. Postavený je práve okolo správy kontextu, pamäťových komponentov a agentových architektúr na reálnych nasadeniach. Nie je to pre tím, ktorý potrebuje prvý prototyp; má zmysel vtedy, keď už niečo beží a účet za tokeny začína bolieť.

Rozdiel medzi prototypom a produkciou je presne tá disciplína, o ktorej píšem aj v texte o tom, prečo prototyp nie je produkcia. Cache a cold fills v prototype nikoho netrápia. V produkcii tvoria väčšinu účtu.

Kedy sa optimalizácia ešte neoplatí?

Ak posielate pár desiatok dopytov denne a účet je zanedbateľný, nechajte to tak. Optimalizácia cache a paralelizácie má zmysel pri objeme, kde sa desiatky percent premietnu do reálnych peňazí alebo do minút čakania, ktoré blokujú vývojárov.

Moje triezve odporúčanie: začnite meraním. Pozrite sa, koľko z účtu tvoria prepočítané cache a cold fills, a až potom siahnite po zložitejších riešeniach. Väčšinu úspor u nás priniesli dve nudné veci: nemenný začiatok promptu a kratší kontext. Nie výmena modelu.