Kolik stojí AI v provozu: jak dostat náklady na inference pod kontrolu

Paradox: token zlevňuje, faktura roste

Obě strany paradoxu jsou dobře doložené. Guido Appenzeller z a16z v analýze „LLMflation“ z listopadu 2024 spočítal, že cena inference za model srovnatelné kvality klesá zhruba desetkrát ročně: model na úrovni GPT-3 stál v listopadu 2021 60 dolarů za milion tokenů, o tři roky později stejné skóre v benchmarku MMLU zvládl model za 0,06 dolaru. Autor sám upozorňuje, že tempo může zpomalit a že benchmark není dokonalé měřítko.

Druhou stranu popisuje Gartner. V tiskové zprávě ze 17. srpna 2026 předpovídá, že náklady na inference na jeden agentní workflow do roku 2028 vzrostou více než pětinásobně. Jev nazývá „inference paradox“: lepší jednotková ekonomika zvyšuje celkové náklady na AI, aniž by nabízela jasnou cestu k odpovídající a předvídatelné hodnotě. Podle téže zprávy předání úlohy agentnímu reasoning modelu zvyšuje náklady poskytovatele na inference nejméně pětkrát, u složitějších úloh výrazně víc.

Že nejde o okrajové téma, ukazuje State of FinOps 2026: z 1 192 respondentů, kteří dohromady zastupují přes 83 miliard dolarů ročních cloudových výdajů, jich 98 % uvádí, že už řídí i výdaje na AI. O rok dříve to bylo 63 %, o dva roky dříve 31 %. Řízení nákladů na AI je podle reportu dovednost číslo jedna, kterou týmy potřebují doplnit, a nejžádanější funkcí nástrojů je granulární sledování AI výdajů – tokenů, LLM requestů a využití GPU.

Český kontext: podle ČSÚ využívalo v roce 2025 některou z technologií AI 18 % podniků s deseti a více zaměstnanci, mezi velkými firmami nad 250 zaměstnanců poprvé 54 %. Ve velkých firmách tedy AI v provozu běží u většiny – a s ní i účet, který někdo musí vysvětlit.

Odkud se spotřeba bere

Tři mechanismy vysvětlují většinu překvapivých faktur. Všechny tři jsou vidět v usage datech, pokud se na ně někdo dívá.

Agentní smyčka posílá kontext znovu a znovu

Model je bezstavový. Agent, který volá nástroje, proto při každém kroku odesílá celou dosavadní historii: systémový prompt, definice nástrojů, všechny předchozí výstupy. Vstupní tokeny tak nerostou lineárně s délkou úlohy, ale přibližně kvadraticky.

Ilustrační výpočet (model, ne měření): agent se systémovým promptem a nástroji o 5 000 tokenech udělá 20 kroků a každý krok přidá do historie 2 000 tokenů. Poslední request má 43 000 vstupních tokenů, ale za celou úlohu se zaplatí 480 000 vstupních tokenů – jedenáctkrát víc, než kolik má finální kontext. Stejná úloha se 40 kroky už vyjde na 1,76 milionu.

Reasoning tokeny nejsou vidět, ale platí se

Dokumentace OpenAI to říká přímo: reasoning tokeny nejsou přes API viditelné, přesto zabírají místo v kontextovém okně a účtují se jako výstupní tokeny. Výstupní tokeny bývají v cenících dražší než vstupní, takže úloha s vysokou úrovní reasoning effort může stát násobek téže úlohy bez něj, aniž se viditelná odpověď prodlouží o jediné slovo.

Dlouhé kontexty a „pro jistotu“ přibalená data

Velké kontextové okno svádí k tomu poslat modelu celý dokument, celý repozitář nebo deset výsledků z RAG místo tří. Každý takový token se platí při každém volání. U jednorázového dotazu je to zanedbatelné, u služby s tisíci volání denně jde o hlavní nákladovou položku.

Nejdřív měřit: cena na úlohu, ne cena za token

Cena za milion tokenů je údaj z ceníku. Pro řízení potřebujete jinou jednotku: kolik stojí jedna dokončená úloha – vyřízený tiket, zrevidovaný pull request, zpracovaná faktura. Teprve ta se dá porovnat s hodnotou, kterou úloha přináší, a teprve na ní je vidět, jestli optimalizace funguje.

K tomu stačí tři věci:

• Usage data z každé odpovědi. API vrací počty vstupních, výstupních, cachovaných a reasoning tokenů. Ukládejte je spolu s identifikátorem úlohy, týmu, aplikace a modelu.
• Jedno místo, kudy volání procházejí. Gateway nebo proxy před poskytovateli modelů. Bez ní se o spotřebě dozvíte z faktury, tedy s měsíčním zpožděním a bez rozpadu na týmy.
• Atribuce na úrovni cloudu. Oddělené deploymenty, API klíče nebo projekty na aplikaci a prostředí a důsledné tagování, aby se náklad dal v billing exportu přiřadit.

State of FinOps 2026 zároveň upozorňuje na slabé místo celého oboru: na otázku, zda AI přináší hodnotu, podle respondentů zatím nikdo neumí odpovědět. Měření ceny na úlohu tuto otázku nevyřeší, ale je nutnou polovinou rovnice. Stejný princip jako u infrastruktury obecně popisuje článek o pořádku v infrastruktuře před nasazením AI.

Pět technik, které snižují účet

1. Prompt caching

Opakovaný začátek promptu (systémové instrukce, definice nástrojů, referenční dokumenty) si poskytovatel uloží a při dalším volání ho účtuje se slevou. U agentní smyčky, kde se prefix opakuje v každém kroku, jde o nejúčinnější jednotlivé opatření.

Konkrétní pravidla se liší podle dodavatele. Například dokumentace Anthropic (stav k říjnu 2026) uvádí zápis do cache s pětiminutovou platností za 1,25násobek základní ceny vstupu, s hodinovou platností za dvojnásobek a čtení z cache standardně za 0,1násobek (u některých nejnovějších modelů ještě méně). Z toho plyne jednoduchá úvaha: u pětiminutové cache se zápis vrátí už při druhém volání (1,25 + 0,1 oproti 2,0), u hodinové při třetím.

Cache funguje jen na přesně shodný prefix. Pořadí je nástroje → systémový prompt → zprávy a změna na vyšší úrovni zneplatní vše pod ní. V praxi to znamená:

• stabilní obsah na začátek, proměnlivý (čas, jméno uživatele, aktuální dotaz) na konec;
• neměnit definice nástrojů mezi kroky téže úlohy;
• sledovat v usage podíl tokenů čtených z cache – nízký podíl u agentního workloadu je chyba v návrhu promptu, ne vlastnost modelu.

2. Dávkové zpracování

Co nemusí být hotové hned, nepatří na synchronní API. Message Batches API od Anthropic účtuje 50 % standardní ceny vstupu i výstupu; většina dávek je podle dokumentace hotová do hodiny, maximum je 24 hodin a slevu lze kombinovat s prompt cachingem. Obdobný režim nabízejí i cloudové platformy – Azure má zlevněný deployment typu Batch, Amazon Bedrock úroveň Flex se slevou pro workloady, které snesou delší zpracování.

Typičtí kandidáti: noční klasifikace a sumarizace, evaluace modelů, hromadné generování popisů, zpětné zpracování archivu.

3. Směrování na menší modely

Gartner v citované zprávě doporučuje „inference-tiering, routing and orchestration“ – tedy posílat rutinní úlohy na levnější modely a nejdražší reasoning vyhradit pro úlohy, které ho skutečně potřebují. Nejjednodušší podoba je statická: klasifikace, extrakce a krátké sumarizace jdou na malý model, plánování a složité ladění na velký. Dynamický router, který rozhoduje podle obsahu dotazu, má smysl až ve chvíli, kdy máte evaluační sadu a umíte ověřit, že kvalita neklesla.

Totéž platí pro reasoning effort: nastavujte ho po úlohách, ne globálně na maximum.

4. Komprese a údržba kontextu

• Z RAG vracet méně, ale lépe seřazených úryvků; rerank je levnější než čtení zbytečných stránek velkým modelem.
• Výstupy nástrojů ořezávat u zdroje – agent nepotřebuje celý log, potřebuje relevantních padesát řádků.
• U dlouhých relací historii průběžně shrnovat nebo staré výstupy nástrojů odstraňovat.
• Omezit délku výstupu a vyžadovat strukturovanou odpověď tam, kde ji čte stroj.

Pozor na střet s cachingem: každý zásah do historie mění prefix a cache zneplatní. Zkracujte proto po větších blocích a méně často, ne po každém kroku.

5. Aplikační cache

Nejlevnější token je ten, který se neodešle. Shodné dotazy (FAQ, opakované klasifikace téhož vstupu) lze obsloužit z vlastní cache odpovědí. Sémantická cache nad embeddingy zachytí i přeformulované dotazy, ale nese riziko vrácení odpovědi na jinou otázku nebo cizích dat – klíč cache proto musí zahrnovat tenant a oprávnění.

Limity a rozpočty: pojistka proti smyčce o víkendu

Optimalizace snižuje průměr. Před extrémem – agentem zacykleným v retry smyčce, zapomenutým testovacím skriptem, uniklým klíčem – chrání jen tvrdé limity. Patří na tři úrovně:

• na úlohu: maximální počet kroků agenta, maximální počet výstupních tokenů, časový limit;
• na klíč a tým: rozpočet za období a limity tokenů a requestů za minutu;
• na účet: rozpočtové alerty a detekce anomálií v cloudovém billingu.

Rozpočet na tým umí většina LLM gateway. Příklad pro open-source LiteLLM proxy, kde se rozpočet po uplynutí zvoleného období automaticky obnovuje:

curl 'http://litellm.internal:4000/team/new' \
  --header 'Authorization: Bearer <master-key>' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "team_alias": "platform-team",
    "max_budget": 500,
    "budget_duration": "30d",
    "tpm_limit": 200000,
    "rpm_limit": 500
  }'

Pay-as-you-go, nebo rezervovaná kapacita

Hyperscaleři nabízejí vedle platby za token i předplacenou kapacitu. Princip je stejný jako u reserved instances: fixní platba výměnou za garantovaný výkon a nižší jednotkovou cenu při vysokém využití.

Na Azure se provisioned throughput účtuje hodinovou sazbou za jednotku PTU bez ohledu na počet zpracovaných tokenů; měsíční nebo roční rezervace sazbu snižuje. Dokumentace upozorňuje na dvě věci, které se snadno přehlédnou: rezervace negarantuje kapacitu, takže se má nejdřív vytvořit deployment a až potom koupit rezervace, a při vyčerpání PTU vrací deployment chybu 429, pokud není nastaven spillover na standardní deployment.

Amazon Bedrock má obdobu v podobě úrovní služby: Reserved s fixní cenou za tisíc tokenů za minutu účtovanou měsíčně, cílovou dostupností 99,5 % a automatickým přetečením do úrovně Standard, dále Priority, Standard a Flex.

Kdy optimalizace nedává smysl

Ne každý účet za AI je problém. Několik situací, kdy je lepší nechat věci být:

• Malý objem. Pokud inference stojí zlomek platu jednoho inženýra, týden práce na routeru se nevrátí. Zaveďte měření a limity, zbytek odložte.
• Menší model, víc pokusů. Levnější model, který úlohu splní napoprvé méně často, může být na dokončenou úlohu dražší – kvůli opakování i kvůli času lidí, kteří výstup opravují. Proto cena na úlohu, ne cena za token.
• Úspora, která zdražuje vývoj. Limity na vývojářské nástroje s AI nastavené příliš nízko ušetří tokeny a utratí hodiny. Rozpočet má zastavit anomálii, ne běžnou práci.
• Závazek v rychle se měnícím trhu. Roční rezervace na konkrétní model je sázka, že ho za rok budete chtít používat. Při tempu, jakým se modely i ceníky mění, je kratší závazek často rozumnější, i když je jednotkově dražší.
• Prognózy nejsou jistota. Pětinásobek od Gartneru je předpověď analytické firmy, ne měření; odhad a16z o desetinásobném ročním poklesu pochází z roku 2024 a stojí na jediném benchmarku. Plánujte podle vlastních dat.

Co udělat v pondělí

Limity a směrování modelů se nejlépe drží jako konfigurace ve verzovacím systému a nasazují stejnou cestou jako zbytek platformy – viz automatizace deploymentu v éře AI.

Klíčové poznatky

• Problém je spotřeba, ne ceník. Token zlevňuje, ale agentní workflow jich podle Gartneru spotřebuje tolik, že náklad na workflow do roku 2028 vzroste více než pětkrát.
• Agentní smyčka roste kvadraticky. Každý krok znovu posílá celou historii; bez cachingu a údržby kontextu platíte za tytéž tokeny mnohokrát.
• Reasoning se účtuje jako výstup. Není vidět v odpovědi, je vidět na faktuře. Úroveň effort nastavujte po úlohách.
• Měřte cenu na dokončenou úlohu. Jen tak poznáte, jestli levnější model opravdu šetří.
• Caching a batch jsou nejlevnější úspory. Vyžadují úpravu promptu a volání, ne změnu architektury.
• Limity chrání před extrémem. Strop kroků, tokenů a rozpočet na tým patří do každého produkčního nasazení agentů.
• Rezervovaná kapacita až s daty. Fixní platba se vrátí jen při trvale vysokém využití; rezervace na Azure navíc sama kapacitu negarantuje.