Koupit si počítač s velkou pamětí a provozovat na něm vlastní jazykový model může působit jako jednoduchý způsob, jak utéct od cloudových účtů. Žádné předplatné, žádné platby za tokeny, data zůstávají doma. Jenže mezi „neplatím API“ a „ušetřil jsem“ je ještě cena počítače, elektřina, rychlost, velikost modelu a hlavně množství práce, které na něm skutečně uděláte.
Právě na tuto nepříjemnou část otázky míří rychlá zpráva o nástroji Sunk Cost a jeho kalkulátor. Neptá se jen, kolik stojí jeden token v cloudu. Snaží se spočítat, za jak dlouho se konkrétní hardware zaplatí proti konkrétnímu modelu a konkrétnímu způsobu používání. A jeho nejpoctivější výsledek může znít: nikdy.
Vlastní model není zdarma, jen účet vypadá jinak
Základní logika je prostá. Cloudový účet vzniká z počtu vstupních a výstupních tokenů a z ceny za milion tokenů. U lokálního provozu se místo toho počítá čas generování, příkon zařízení a cena elektřiny. Do výsledku se pak přidá pořizovací cena počítače. Pokud je denní úspora malá nebo záporná, bod zvratu se neobjeví.
To je důležitý rozdíl proti běžným srovnáním, která vedle sebe postaví cenu grafické karty a cenu API. Takové srovnání často ignoruje, že hardware musí běžet dlouho, aby vyrobil stejné množství práce jako cloudová služba. A ignoruje také to, že nejlevnější lokální model nemusí být náhradou za model, který jste původně používali v cloudu.
Sunk Cost proto pracuje s konkrétní sestavou, kapacitou paměti, odhadovanou nebo změřenou rychlostí, cenou elektřiny a poměrem vstupních a výstupních tokenů. Uživatel může zadat i vlastní pořizovací cenu. To dává smysl u bazarového Macu, počítače koupeného ve slevě nebo sestavy, kterou už doma máte a nechcete do ní započítat původní cenu stejně jako při novém nákupu.
Nejdražší chyba je zaměnit tokeny za zprávy
Lidé obvykle nepřemýšlejí v tokenech. Přemýšlejí v e-mailech, odpovědích, souborech a úkolech. Jenže jedna krátká otázka a práce coding agenta nad celou sadou souborů jsou z hlediska účtu dvě úplně jiné věci. Agent při každém kroku znovu posílá kontext, nástroje a výsledky předchozích operací. Výstup může být krátký, ale vstupu se nasčítá hodně.
Kalkulátor má pro tento účel přednastavené scénáře od běžného chatu přes psaní a shrnování až po coding a agentické programování. Výchozí scénář počítá s poměrem patnácti vstupních tokenů na jeden výstupní token. Není to univerzální pravda, ale rozumná připomínka, že „půl milionu tokenů denně“ nemusí znamenat půl milionu dlouhých odpovědí.
Stejně důležitý je denní objem. Při několika desítkách tisíc tokenů denně se i relativně levný počítač může zaplatit až za absurdně dlouhou dobu. Při milionech tokenů denně už výsledek vypadá lépe, ale takové využití odpovídá spíš automatizovanému zpracování dokumentů, intenzivnímu codingu nebo agentům běžícím většinu dne než běžnému chatování.
Paměť rozhoduje dřív než cena
U lokálních modelů nestačí podívat se na počet parametrů. Do paměti se musí vejít také kvantizované váhy a KV cache, tedy pracovní paměť pro kontext. Čím delší kontext požadujete, tím větší část paměti cache zabere. Model, který se pohodlně vejde při osmi tisících tokenech, může být při 128 tisících prakticky nepoužitelný.
Sunk Cost proto u každého modelu kontroluje nejen to, zda se vejde do použitelné paměti, ale také maximální kontext, který model podporuje. U Apple Silicon navíc nepočítá automaticky s celou deklarovanou kapacitou. Vychází z konzervativního limitu, kolik jednotné paměti může GPU běžně použít. U jiných strojů se zase může lišit situace podle ovladačů a operačního systému.
V praxi to znamená, že větší paměť často nekupujete kvůli vyšší rychlosti. Kupujete si možnost spustit větší model nebo držet delší kontext. To je jiná hodnota než počet tokenů za sekundu a obě věci se při nákupu snadno smíchají.
Rychlost z krabice je jen začátek
Kalkulátor dává přednost měřeným hodnotám. Pokud pro určitou kombinaci modelu a hardwaru žádné měření nemá, odhaduje rychlost z propustnosti paměti, velikosti vah a účinnostního koeficientu. Výsledek je v rozhraní označený jako odhad, nikoli jako benchmark.
Tohle rozlišení je podstatné. Výpočet založený na propustnosti paměti může být užitečný pro hrubé srovnání, ale neříká všechno o konkrétním runtime, ovladačích, kvantizaci ani o tom, jak si poradí s danou architekturou. U MoE modelů se navíc pracuje jen s aktivními parametry, přestože celková velikost modelu rozhoduje o nárocích na paměť.
Ještě větší problém představuje dlouhý kontext. S každým vygenerovaným tokenem se znovu čtou váhy i celá KV cache, takže generování zpomaluje. Sunk Cost rychlost upravuje podle jednoduchého modelu, který porovnává velikost vah a cache při měřeném a požadovaném kontextu. Autoři sami uvádějí, že jde o první přiblížení, ne o náhradu měření. Ve veřejných případech se trefuje přibližně v řádu desítek procent.
Dobrá ilustrace je měření gpt-oss-20b na DGX Spark v llama.cpp. Při prázdném kontextu uvádí datový soubor kalkulátoru 83,43 tokenu za sekundu, při 32 tisících tokenech 61,65. Hardware tedy nezměníte, ale pracovní podmínky ano – a s nimi i ekonomiku provozu.
Co vyjde, když necháme čísla mluvit
Pro představu lze vzít DGX Spark s cenou 4 699 dolarů, příkonem 150 wattů a elektřinou za 0,17 dolaru za kilowatthodinu. To jsou hodnoty použité v datové sadě projektu, nikoli univerzální český ceník. U gpt-oss-20b kalkulátor pracuje s cenou cloudového ekvivalentu 0,02 dolaru za milion vstupních a 0,10 dolaru za milion výstupních tokenů podle údajů OpenRouteru.
Při půl milionu tokenů denně a poměru 15:1 vychází cloudový provoz v tomto modelovém příkladu zhruba na 1,25 centu denně. Lokální generování při 32tisícovém kontextu stojí na elektřině přibližně 0,37 centu denně. Rozdíl existuje, ale proti pořizovací ceně tisíců dolarů je příliš malý: jednoduché dělení by dalo návratnost zhruba 1 460 let.
To číslo není předpověď pro každého majitele DGX Spark. Je to kontrola intuice. I kdyby hardware běžel při stejných předpokladech na dvacet milionů tokenů denně, vyjde prostý bod zvratu přibližně na 36 let. Takový objem už je ale sám o sobě extrémní a navíc předpokládá, že cloudové ceny zůstanou stejné.
U jiného modelu se poměr může změnit. Qwen3 30B-A3B má v datasetu projektu nízkou cenu cloudového endpointu a na některých zařízeních vysokou rychlost, protože při každém tokenu aktivuje jen část parametrů. Současně však stále zabírá paměť jako mnohem větší model. Výsledek tedy může být dobrý pro rychlý lokální provoz, ale nemusí znamenat rychlou finanční návratnost.
Bod zvratu není konečný verdikt
Nejzajímavější část kalkulátoru začíná tam, kde běžné tabulky končí. Uživatel může zapnout předpoklad, že API ceny budou dál klesat. Výchozí nastavení používá konzervativní pokles 40 procent ročně, který projekt odvozuje z analýzy Epoch AI o vývoji cen inference. Autoři zároveň upozorňují, že tento zdroj je potřeba znovu kontrolovat, protože data předcházejí roku 2026.
Když cloud zlevňuje, dnešní rozdíl mezi lokálním a cloudovým provozem se postupně zmenšuje. Hardware se pak nemusí nikdy dostat nad nulu. Kalkulátor proto umí ukázat nejen případný den návratnosti, ale také nejlepší dosaženou finanční pozici. Po určité době může být lokální stroj stále dražší než cloud, i když elektřina na jeden token vychází levněji.
To je důvod, proč je fér mluvit o bodu zvratu pouze jako o scénáři. Závisí na využití, ceně elektřiny, ceně API, životnosti zařízení i na tom, zda za dva roky nezačnete používat jiný model. Výpočet s dnešní cenou drženou navždy je jednoduchý, ale optimistický. Výpočet s poklesem API je realističtější, ale stále jen odhad budoucnosti.
Soukromí se do tabulky nevejde, ale do rozhodnutí ano
Přesto by bylo chybou z kalkulátoru vyvodit, že lokální AI dává smysl pouze při obřím objemu tokenů. Finanční návratnost je jen jedna z možných metrik. Pro firmu, která zpracovává citlivé dokumenty, může mít cenu už samotná možnost nepředávat data externímu poskytovateli. Pro vývojáře může být důležitá autonomie, práce bez internetu nebo možnost provoz upravit podle vlastních potřeb.
Stejný rozdíl je vidět u běžných aplikací. Lokální diktování v projektu SayItErmano není zajímavé jen cenou přepisu. Uživatel řeší také to, zda jeho řeč odchází do cloudu, jakou má kontrolu nad nástrojem a zda mu nevadí omezení konkrétní platformy.
Podobnou logiku jsme viděli i u LibreOffice a odmítnutí povinné AI. Hodnota lokálního nebo necloudového přístupu nespočívá automaticky v tom, že porazí komerční službu v ceně a schopnostech. Může spočívat v předvídatelnosti: uživatel ví, kde se zpracování odehrává, kdo ho ovládá a co se stane, když se změní ceník.
Kdy tedy vlastní hardware dává smysl
Sunk Cost bych nepoužíval jako automatický nákupní automat. Použil bych ho jako brzdu před nákupem. Nejprve bych zadal skutečnou cenu zařízení, realistický denní objem, poměr vstupu a výstupu, kontext, příkon a místní cenu elektřiny. Potom bych se podíval, jestli vybraný model opravdu odpovídá práci, kterou chci dělat, a jestli výsledek stojí na měření, nebo na odhadu.
Vlastní stroj dává větší smysl tam, kde běží často, kde je důležitá kontrola nad daty nebo kde cloudová služba není vhodnou náhradou. Může být rozumnou součástí interního workflow, nástrojem pro experimenty nebo pojistkou proti závislosti na jednom poskytovateli. Nemusí se ale vyplatit jako domácí náhrada za občasné dotazy do levného API.
Nejpoctivější závěr kalkulátoru proto není „lokální AI je levnější“ ani „cloud vždy vyhrává“. Je mnohem méně pohodlný: záleží na tom, kolik práce máte, jaký model potřebujete a co pro vás znamená kontrola. Pokud chcete jen levné odpovědi několikrát denně, vlastní hardware bude často drahý koníček. Pokud potřebujete dlouhodobě provozovat velké množství práce mimo cloud, může se z něj stát infrastruktura. Rozhodnutí by ale mělo začít čísly, ne představou, že elektřina je jediný účet.
