AI API podle tokenů vs. lokální model v Dockeru: kdy se co vyplatí

Proč se ptát na cenu za token právě teď

Otázka, zda platit za AI přes API, nebo model provozovat u sebe, se v praxi vrací pokaždé, když pilot přeroste v produkční službu. Na začátku vítězí API: žádná infrastruktura, žádné čekání na hardware, účet za pár dolarů. Jenže s rostoucím objemem se začne číst faktura a objeví se pokušení spustit model lokálně, třeba v Dockeru. Tento článek nenabízí univerzální vítěze. Ukazuje, jak oba přístupy poctivě porovnat, jaké proměnné do výpočtu patří a kdy je který přístup rozumný. Konkrétní ceny a technické údaje vycházejí pouze z oficiální dokumentace uvedené v textu; u rychle se měnících věcí (ceny, modely) vždy ověřte aktuální stav u poskytovatele.

Jak funguje cenotvorba za token

Placené API účtuje podle spotřeby: zvlášť vstupní a zvlášť výstupní tokeny, obvykle v jednotkách za milion tokenů (MTok). Dokumentace Anthropic uvádí ceny v USD a zdůrazňuje, že aktuální hodnoty je třeba ověřit na jejich webu (https://platform.claude.com/docs/en/about-claude/pricing). Z tabulky je vidět několik zásadních vzorců:

• Výstup je výrazně dražší než vstup. U modelů v uvedené dokumentaci je cena výstupních tokenů několikanásobkem ceny vstupních (například u řady Sonnet 5.5 je to 2 USD vstup a 10 USD výstup za MTok). Aplikace, které generují dlouhé odpovědi, tedy platí jinak než aplikace, které hlavně klasifikují nebo extrahují.
• Cena se liší podle třídy modelu. Dokumentace řadí modely od nejlevnějších, určených pro vysoký objem a nízkou latenci (klasifikace, extrakce, směrování), po nejdražší pro náročné uvažování a dlouhé agentní úlohy. Rozdíl mezi nejlevnější a nejdražší třídou je v tabulce o řády.
• Prompt caching mění rovnici. Přečtení z cache stojí zlomek základní vstupní ceny, zatímco zápis do cache stojí víc než běžný vstup. Pokud opakovaně posíláte stejný dlouhý systémový prompt nebo kontext, může být efektivní cena vstupu mnohem nižší než ceníková.
• Cena může záviset na délce promptu. U nejlevnějšího modelu v tabulce je jiná sazba pro prompty do 100 000 tokenů a jiná nad touto hranicí.
• Regionální a multiregionální endpointy mohou mít příplatek. Dokumentace uvádí desetiprocentní přirážku oproti globálním endpointům u některých cloudových platforem, a pokud potřebujete data residency, počítejte s tím.

Důležitá pasta pro plánování: dokumentace upozorňuje, že novější modely používají jiný tokenizér, který produkuje zhruba o 30 % více tokenů pro stejný text, přičemž přesný nárůst závisí na obsahu a charakteru zátěže (https://platform.claude.com/docs/en/about-claude/pricing). Přechod na novější model tedy neznamená jen změnu ceníkové sazby, ale i změnu počtu tokenů za stejnou úlohu. Odhad nákladů proto nestavějte na počtu znaků ani na zkušenostech z jiného modelu.

Jak si spotřebu změřit dřív, než ji zaplatíte

Poctivé srovnání začíná měřením, ne odhadem. API poskytuje endpoint pro počítání tokenů, který přijímá stejnou strukturu vstupu jako vytvoření zprávy, včetně systémových promptů, nástrojů, obrázků a PDF, a vrací celkový počet vstupních tokenů (https://platform.claude.com/docs/en/build-with-claude/token-counting). Dokumentace jej doporučuje pro řízení limitů a nákladů, pro rozhodování o směrování mezi modely a pro úpravu promptů na cílovou délku.

Praktický postup:

1. Vezměte reprezentativní vzorek reálných požadavků (ne syntetické ukázky). 2. Spočítejte vstupní tokeny pro každý model, který zvažujete, protože kvůli různým tokenizérům nejsou čísla přenositelná. 3. Změřte skutečnou délku výstupů, protože ta u API tvoří často největší část účtu a vstupní počítadlo ji nezachytí. 4. Vynásobte měsíčním objemem a rozdělte podle toho, kolik vstupu lze cachovat.

Tím získáte základ pro variantu API. Pro lokální variantu je potřeba jiná sada čísel, viz dále.

Lokální model v Dockeru: co to vlastně obnáší

Docker nabízí Docker Model Runner, nástroj pro provoz modelů v rámci Docker ekosystému (https://docs.docker.com/ai/model-runner/). Pro služby, které potřebují akceleraci, popisuje Docker dokumentace, jak v Compose spouštět služby s přístupem k GPU (https://docs.docker.com/compose/gpu-support/). Stránky v dostupných výňatcích neobsahují podrobnosti o výkonu ani o konkrétních podporovaných modelech, proto o propustnosti, latenci ani kvalitě konkrétních lokálních modelů zde netvrdím nic. Tyto parametry si musíte změřit na vlastním hardwaru.

Důležité je pochopit, že lokální provoz mění povahu nákladů. Z proměnných nákladů (platím za každý token) se stávají převážně fixní náklady (platím za hardware a provoz bez ohledu na to, zda ho využívám). Do výpočtu proto patří:

• Hardware: pořízení nebo pronájem GPU, případně servery, chlazení a napájení.
• Využití: stroj, který je z 10 % vytížený, má efektivní cenu za token zhruba desetkrát vyšší než stroj vytížený na 100 %. Rovnoměrnost provozu je zde klíčová.
• Lidská práce: instalace, aktualizace, monitoring, bezpečnostní záplaty, řešení výpadků. Tato položka se v kalkulacích často podceňuje.
• Kvalita modelu: lokální model nemusí dosahovat kvality špičkového placeného modelu. Pokud kvůli tomu potřebujete víc pokusů, ruční kontrolu nebo složitější prompty, roste cena správného výsledku, byť cena za token klesá.
• Škálování a špičky: API absorbuje nárazové zatížení za vás, lokální stack ne.

Jak sestavit férové srovnání

Aby srovnání dávalo smysl, nepoměřujte cenu za token s cenou za token. Poměřujte cenu za úspěšně dokončenou úlohu při požadované kvalitě. Jednoduchý rámec:

API: (vstupní tokeny × vstupní sazba + výstupní tokeny × výstupní sazba, upraveno o podíl cache) × počet úloh × průměrný počet pokusů.

Lokálně: (měsíční náklady na hardware + provoz + práce) ÷ počet úspěšně zvládnutých úloh při reálném využití.

Výsledek porovnávejte při různých objemech. Typický tvar křivky je tento: při nízkém objemu je API prakticky vždy levnější, protože fixní náklady lokálního provozu nejsou rozloženy. S rostoucím a stabilním objemem se křivky mohou protnout. Kde přesně, závisí na vašem hardwaru, modelu a režii, a proto žádné obecné číslo neuvádím. Zdrženlivost je tu na místě: bod zlomu, který si nikdo nezměřil na vlastních datech, je jen domněnka.

Dvě úpravy, které srovnání často změní ještě před jakoukoli migrací:

• Směrování podle náročnosti. Dokumentace řadí nejlevnější model pro klasifikaci, extrakci a směrování; pokud většinu provozu tvoří právě takové úlohy, lze je poslat na levnější model a drahý ponechat jen pro složité případy (https://platform.claude.com/docs/en/about-claude/pricing).
• Cache a zkrácení promptů. Dlouhé opakující se kontexty mohou být díky cache výrazně levnější, a to často bez jakékoli změny architektury.

Pokud po těchto úpravách API stále vychází neúnosně draze, teprve pak má lokální varianta smysl detailně počítat.

Kdy se vyplatí API

Placené API je rozumná volba, pokud:

• objem je malý, nepravidelný nebo se teprve zjišťuje, takže fixní náklady by zůstaly nevyužité;
• potřebujete nejvyšší dostupnou kvalitu nebo funkce, které lokální model nenabízí (dlouhý kontext, nástroje, zpracování obrázků a PDF);
• nemáte kapacitu provozovat a zabezpečit vlastní inferenční stack;
• zátěž má velké špičky, které byste lokálně museli pokrýt předimenzovaným hardwarem;
• rychlost uvedení do provozu je důležitější než jednotková cena.

Do poznámek o rizicích patří i závislost na dodavateli: ceny, modely a podmínky se mění a starší modely se vyřazují. Dokumentace má samostatné sekce o vyřazování modelů a o přechodu mezi verzemi, což je signál, že s migracemi je třeba počítat. Navrhněte proto aplikaci tak, aby výměna modelu byla konfigurační změnou, ne přepisem.

Kdy se vyplatí lokální model v Dockeru

Lokální provoz dává smysl, pokud:

• máte stabilní, předvídatelný a dostatečně vysoký objem, který udrží hardware vytížený;
• úlohy jsou dostatečně jednoduché na to, aby je zvládl menší model s přijatelnou kvalitou (typicky klasifikace, extrakce, interní nástroje);
• data nesmí opustit vaši infrastrukturu a to je pro vás tvrdý požadavek (posuzujte však sami, případně s odborníkem na compliance; tento text není právní poradenství);
• máte lidi, kteří dokážou stack provozovat a dlouhodobě udržovat;
• potřebujete nízkou a předvídatelnou latenci bez závislosti na externí službě.

Docker přináší hlavně opakovatelnost: stejná konfigurace běží na vývojářském stroji i na serveru a Compose umožňuje deklarovat požadavky na GPU přímo v definici služby (https://docs.docker.com/compose/gpu-support/). To zjednodušuje nasazení, ale neřeší otázku, zda je hardware dostatečně výkonný a vytížený.

Hybridní přístup jako realistický střed

Volba nemusí být binární. Častým kompromisem je kombinace: levné, objemné a standardizované úlohy zpracovává lokální model, náročné nebo řídké případy jdou na placené API. Směrovací vrstva rozhoduje podle typu úlohy, délky vstupu nebo skóre jistoty. Výhody jsou jasné: fixní náklady lokálního stroje se rozloží na stabilní základ provozu a špičky a obtížné případy absorbuje API. Nevýhodou je složitější architektura, dvojí monitoring a nutnost udržovat kvalitu u obou větví. Hybrid se vyplatí zavádět až ve chvíli, kdy z měření vidíte, které úlohy jsou skutečně jednoduché a objemné.

Typické způsoby selhání

Podcenění výstupu. Tým spočítá vstupní tokeny, ale zapomene, že výstup je u API násobně dražší. Řešení: měřit reálné délky odpovědí a omezit je promptem nebo limity.

Přenesení tokenových odhadů mezi modely. Kvůli jinému tokenizéru (podle dokumentace zhruba o 30 % více tokenů u novějších modelů) může stejný text stát víc. Řešení: počítat tokeny pro každý cílový model zvlášť.

Nevyužitý lokální hardware. GPU, které většinu času stojí, je nejdražší způsob, jak získat tokeny. Řešení: před nákupem odhadnout reálné vytížení a zvážit pronájem.

Podceněná kvalita. Levný lokální model vyžaduje opakování nebo ruční kontrolu a celková cena za správný výsledek vyjde vyšší. Řešení: srovnávat cenu za úspěšnou úlohu, ne za token.

Skrytá provozní zátěž. Aktualizace, bezpečnost a monitoring se do kalkulace nezapočítají. Řešení: vyčíslit hodiny práce a započítat je.

Zamčení na dodavatele nebo na konfiguraci. Pevně zadrátované názvy modelů znesnadní přechod při vyřazení modelu. Řešení: abstrahovat volbu modelu v konfiguraci.

Praktický kontrolní seznam

1. Definujte úlohu a kritérium úspěchu (kvalita, latence, povolená chybovost). 2. Nasbírejte reprezentativní vzorek reálných požadavků. 3. Spočítejte vstupní tokeny pro každý kandidátní model přes počítadlo tokenů. 4. Změřte skutečnou délku výstupů a podíl opakujícího se kontextu vhodného do cache. 5. Vyzkoušejte levnější třídu modelu a směrování podle náročnosti, než začnete uvažovat o migraci. 6. Vypočtěte cenu za úspěšnou úlohu u API včetně opakovaných pokusů. 7. Pro lokální variantu na vlastním hardwaru změřte propustnost, latenci a kvalitu; nespoléhejte na cizí čísla. 8. Odhadněte reálné vytížení hardwaru a přičtěte provozní práci. 9. Spočítejte bod zlomu při několika scénářích objemu, ne při jednom. 10. Ověřte požadavky na data a soulad s předpisy u odpovědné osoby. 11. Navrhněte výměnu modelu jako konfigurační změnu. 12. Naplánujte pravidelnou revizi, protože ceny i modely se mění.

Omezení tohoto srovnání

Tento text vychází pouze z veřejné dokumentace Anthropic a Dockeru, a to ještě z jejích výňatků. Neobsahuje měření výkonu lokálních modelů, ceny hardwaru ani energie, a proto neuvádí žádné univerzální číslo, od kterého se lokální provoz vyplatí. Ceny API se mění a jejich aktuální podobu je nutné ověřit u poskytovatele (https://platform.claude.com/docs/en/about-claude/pricing). Podrobnosti o schopnostech a omezeních Docker Model Runneru najdete v jeho dokumentaci (https://docs.docker.com/ai/model-runner/). Výsledek vždy závisí na vaší zátěži, kvalitativních nárocích a provozních schopnostech, takže jediné spolehlivé rozhodnutí je to, které opřete o vlastní měření.

Závěr

API s cenou za token je výchozí volbou pro nízké a nejisté objemy, náročné úlohy a rychlý start. Lokální model v Dockeru dává smysl tam, kde je objem stabilní a vysoký, úlohy jednodušší a kde máte schopnost provoz udržet. Mezi těmito póly leží hybridní řešení a řada levnějších úprav (cache, směrování, kratší výstupy), které často ušetří víc než samotná změna platformy. Rozhodujte se podle ceny za úspěšnou úlohu, měřte na vlastních datech a počítejte s tím, že optimální volba se časem změní.