
Cena AI agenta není počet tokenů: smyčky znovu účtují celý kontext

Náklady AI agenta měřte jako součet placených událostí přiřazených k jednomu úkolu, nikoli jako počet tokenů v poslední odpovědi. Každý další modelový požadavek může znovu obsahovat instrukce, popisy nástrojů a dosavadní historii. V příkladu příručky ElephantClock se stabilní prefix o 6 000 tokenech odesílá v deseti krocích, takže se započítá do vstupu desetkrát; případná cache může cenu opakovaného vstupu snížit.
Každému úkolu proto dejte trvalý identifikátor a pod něj zapisujte skutečnou spotřebu jednotlivých volání modelu i poplatky dalších služeb. Dokumentace OpenAI Agents SDK popisuje souhrnnou spotřebu za běh, která zahrnuje modelová volání vedoucí k použití nástroje či předání úkolu, a také rozpad po jednotlivých požadavcích. Poplatek externího API nebo placeného nástroje však musí evidence zachytit zvlášť.
Určete hranici úkolu dřív než hranici běhu
Úkolem je požadavek s předem určeným kritériem dokončení, například vyřízený dotaz nebo schválený výstup. Jeden úkol může zahrnovat více běhů agenta, obnovení po chybě i předání specializovanému agentovi. Pokud náklady přiřadíte jen jednomu běhu, opakované pokusy se z ceny výsledku ztratí.
V evidenci rozlišujte task_id pro celý úkol, run_id pro spuštění a attempt_id pro pokus. Předání dalšímu agentovi ponechte pod stejným task_id; novému kroku dejte vlastní identifikátor a odkaz na rodičovský krok. Výsledek označte jako úspěšný, neúspěšný, zrušený nebo předaný člověku podle pravidel produktu. Stejná pravidla musí platit i při porovnávání nákladů různých verzí agenta.
Zapisujte každou placenou událost
Jednotkou evidence je událost, kterou lze přiřadit k účtované položce. Společné schéma pro volání modelu, placený nástroj a externí API může obsahovat tato pole:
- Jedinečné event_id, task_id, run_id, attempt_id, identifikátor rodičovského kroku, čas a stav události.
- Typ události, poskytovatele, model nebo službu, účtovanou jednotku, měnu a verzi sazby použité při výpočtu.
- Spotřebu vykázanou poskytovatelem, vypočtenou cenu a identifikátor požadavku pro kontrolu vyúčtování.
- U modelového volání vstupní a výstupní tokeny, samostatně vykázané čtení či zápis cache a další účtované kategorie, pokud je poskytovatel uvádí.
- U externí služby počet účtovaných požadavků, výsledků nebo jiných jednotek podle jejího ceníku.
Záznam uložte i při chybě nebo opakování, pokud placené volání již proběhlo. Jedinečné event_id umožní při obnovení procesu poznat tutéž událost a nezapočítat ji dvakrát. Souhrn spotřeby z frameworku používejte jako kontrolu: do ceny nesčítejte zároveň souhrn a požadavky, z nichž vznikl. Když poskytovatel spotřebu nevrátí, označte ji jako neznámou a vyřešte podle vyúčtování; nulová spotřeba by znamenala něco jiného.
Rozložte vstup podle skutečného účtování
Pro každé modelové volání vypočtěte cenu vstupu, výstupu a případných dalších kategorií podle sazeb konkrétního modelu. Čtení z cache může mít jinou sazbu než běžný vstup a zápis cache může být účtován zvlášť. Při výpočtu proto použijte kategorie z vyúčtování poskytovatele a tokeny označené jako cache znovu nepřičítejte k celkovému vstupu.
Opakovaný kontext stojí za samostatné sledování i tehdy, když cache část ceny sníží. Studie Total Cost of Agency popisuje, jak se kontext vložený z paměti účtuje jako vstupní tokeny v uzlech víceagentního workflow, a navrhuje tuto složku odděleně přiřazovat. Její měření se týká běhů bez prompt cachingu, takže z něj nelze odvozovat cenu vstupu uloženého v cache.
Vedle účtované ceny lze zaznamenat také původ vstupního kontextu: stálé instrukce, popisy nástrojů, historii, výsledky vyhledávání a paměť. Takový rozklad ukáže, která složka roste s dalšími kroky. Získání dat z placeného vyhledávání přitom tvoří náklad služby; pozdější vložení získaných dat do modelového vstupu vytváří další, odlišnou položku.
Počítejte cenu úspěchu včetně nezdarů
Cena konkrétního úkolu je součet všech jeho účtovaných událostí, včetně opakovaných pokusů a volání, po nichž agent výsledek nedokončil. Pro porovnání verzí počítejte také cenu za úspěšně dokončený úkol: celkové náklady na vybranou skupinu úkolů vydělte počtem těch, které splnily kritérium úspěchu. V čitateli ponechte i náklady na neúspěšné úkoly ze stejné skupiny. Pokud v ní žádný úkol neuspěl, metrika nemá číselnou hodnotu; ukažte celkové náklady a nulový počet úspěchů.
Vedle této metriky zobrazujte podíl úspěšných úkolů a rozložení ceny jednotlivých úkolů. Průměr sám o sobě může skrýt několik drahých smyček. Skupiny porovnávejte při stejné definici úspěchu a podobné skladbě požadavků, aby se změna obtížnosti úkolů netvářila jako úspora. Pokud používáte více měn, převodní pravidlo stanovte před výpočtem společného součtu.
Před dalším krokem rezervujte rozpočet
Rozpočtovou pojistku vyhodnoťte před každým dalším placeným voláním. K dosavadním potvrzeným nákladům úkolu přidejte rezervu na zamýšlený krok: odhad vstupu, nastavený strop výstupu a případnou cenu externí služby. Pokud zásah cache nelze předem zaručit, počítejte při rozhodování s cenou běžného vstupu. Odhad musí pokrýt i poplatek nástroje, který chce agent v tomto kroku spustit.
Přesáhne-li potvrzená útrata spolu s rezervou limit úkolu, další placený krok nespouštějte a běh ukončete nebo předejte podle pravidel produktu. Při souběžných krocích musí být rezervace sdílená, aby více větví neutrácelo tentýž zůstatek. Po dokončení kroku nahraďte rezervu skutečnou cenou. Vedle peněžního limitu nastavte i strop kroků a opakování, protože smyčka může pokračovat, přestože každé její volání stojí málo.
Teprve podle nákladů přiřazených jednotlivým úkolům lze rozhodnout, zda nejvíce pomůže cache stabilního prefixu, kratší historie, omezení výsledků nástroje nebo jiný model pro vybrané kroky. Úsporu posuzujte spolu s úspěšností a kvalitou dokončených úkolů: levnější jednotlivé volání nemusí zlevnit výsledek, pokud vyvolá další pokusy.
Přečtěte si také:
Související články


Prompt injection nezastaví filtr: agent potřebuje omezené nástroje i schválení

Cloudflare, nebo Fastly: nulový tarif prohrává, když potřebujete kontrolu

Chatbot, nebo AI agent: autonomie znamená i nové riziko

AI agent, nebo RPA: flexibilita prohrává tam, kde rozhoduje rychlost

GitHub Actions, nebo GitLab CI: účet mění minuty, cache i runner
Přihlaste se k odběru newsletteru
Nejnovější zprávy ze světa Web3, AI a kryptoměn přímo do vaší schránky.