Cena a latence · LLM po lopatě

LLM je první API, u kterého tě nezajímá jen počet volání, ale délka každého z nich. Platíš za tokeny a čekáš úměrně délce odpovědi. Aplikace, která funguje skvěle v testu s deseti dotazy, umí v produkci vygenerovat účet, ze kterého ti zatrne a přitom většina úspor je snadná.

Z čeho se skládá účet

cena = (vstupní tokeny × cena za vstup) + (výstupní tokeny × cena za výstup)

Dvě věci, které lidi překvapí:

Výstup je několikanásobně dražší než vstup. Ukecaný model stojí víc než dlouhý prompt.
Historie se posílá znovu při každé zprávě. Konverzace o dvaceti výměnách stojí mnohem víc než dvacetinásobek první zprávy, protože náklady rostou zhruba kvadraticky.

Kde se peníze ztrácejí nejčastěji

Zdroj plýtvání	Náprava
Velký model na triviální úlohu	Routing: klasifikaci dělej malým modelem
Celý dokument v promptu	RAG: pošli 3–5 relevantních chunků
Celá historie konverzace	Shrnování, klouzavé okno (paměť)
Opakované stejné dotazy	Cache
Ukecané odpovědi	Vyžádej stručnost + `max_tokens`
Dlouhý systémový prompt	Zkrať; posílá se pokaždé
Agent bez limitu	Strop na kroky a rozpočet (agenti)

💡 Největší jednorázová úspora bývá routing: 80 % dotazů zvládne malý model za desetinu ceny. Velký model si nech na to, co ho opravdu potřebuje.

Cachování

Tři úrovně, každá jinak účinná:

Přesná shoda, stejný prompt = uložená odpověď. Triviální, funguje u opakovaných dotazů (FAQ, generované popisky).
Sémantická cache, podobný dotaz (přes embedding) vrátí uloženou odpověď. Pozor na falešné shody; hodí se na FAQ, ne na osobní data.
Prompt caching u poskytovatele, dlouhý neměnný začátek promptu (systémové instrukce, podklady) se dá označit a poskytovatel ho účtuje levněji. Když máš velký stálý kontext, tohle se vyplatí okamžitě.

Latence: co ji doopravdy ovlivňuje

celkový čas ≈ čas na první token + (počet výstupních tokenů × čas na token)

Délka výstupu je hlavní faktor. Kratší odpověď = rychlejší.
Délka vstupu ovlivňuje hlavně čas na první token.
Velikost modelu: menší model odpovídá znatelně rychleji.
Streaming celkový čas nezkrátí, ale uživatel vidí text hned, takže vnímaná rychlost je několikanásobně lepší.

Co s tím prakticky:

Streamuj všechno, co čte člověk.
Dlouhé úlohy dej do fronty a informuj o průběhu, místo aby uživatel čekal na request.
Paralelizuj, když zpracováváš víc nezávislých položek.
Měř p95, ne průměr. Průměr vypadá krásně a uživatel s pomalou odpovědí ti stejně odejde.

Odhad nákladů dopředu

Než něco nasadíš, spočítej si to na ubrousek:

1 000 dotazů denně
× (1 500 vstupních + 400 výstupních tokenů)
= 1,5 M vstupních + 0,4 M výstupních tokenů denně
→ vynásob cenou modelu → měsíční odhad

A pak nastav u poskytovatele tvrdý limit útraty. Chyba ve smyčce nebo nečekaný nápor umí za noc utratit rozpočet na celý kvartál.

Cvičení

Aplikace dělá 200 000 volání měsíčně, každé 3 000 vstupních a 400 výstupních tokenů. Kolik tokenů to je? Kolik ušetří prompt caching, když je 2 200 tokenů vstupu vždy stejných?
Uživatelé si stěžují, že je aplikace pomalá, přestože průměrná latence je 1,2 s. Co změříš?

Náčrt řešení: rozbal, až si cvičení zkusíš sám

680 milionů tokenů měsíčně, z toho 440 milionů cachovatelných. Vstup 200 000 × 3 000 = 600 mil., výstup 200 000 × 400 = 80 mil. Stálá část 200 000 × 2 200 = 440 mil., tedy 73 % vstupu a 65 % celkového objemu. Prompt caching je proto u aplikací se stabilním systémovým promptem první věc, kterou zapneš, a často srazí účet víc než výměna modelu za menší.
p95 a p99, a zvlášť čas do prvního tokenu. Průměr schová právě ty případy, kvůli kterým si lidé stěžují. U streamovaných odpovědí navíc rozhoduje, jak dlouho uživatel kouká na prázdno, ne celková doba: odpověď, která začne psát za 300 ms a dopíše za 8 s, působí rychleji než ta, co mlčí 3 s a doručí se naráz.

Shrnutí

Platí se za vstupní i výstupní tokeny, výstup je dražší; historie zdražuje kvadraticky.
Největší úspory: menší model na jednoduché úlohy, méně kontextu, cache.
Latenci určuje hlavně délka výstupu; streaming zlepší vnímanou rychlost.
Spočítej si náklady dopředu a nastav limit útraty.

Konverzační aplikace má u dlouhých chatů neúměrně vysoké náklady. Proč?

Protože se při každé zprávě posílá celá dosavadní historie znovu, náklady rostou zhruba kvadraticky s délkou konverzace. Řeší se to zkracováním historie, shrnováním starší části a držením faktů mimo konverzaci.

Aplikace klasifikuje tikety, generuje odpovědi a překládá. Jak nejrychleji srazit náklady?

Routingem: klasifikaci a překlad dá malý levný model, velký si nech na generování odpovědí. Typicky to ušetří většinu nákladů, protože jednoduchých volání bývá řádově víc.

Uživatelé si stěžují na pomalost, přestože průměrná latence je 1,2 s. Co zkontrolovat?

Percentil p95 a p99, průměr pomalé případy schová. A hlavně délku výstupu, protože ta určuje celkový čas; pomůže vyžádat stručnější odpovědi, nastavit max_tokens a streamovat.