Proč open source modely nejsou stokrát levnější? Prozkoumejme Paretovu hranici.

V ceně API bych si pro začátek oddělil dvě ekonomické vrstvy.

První je provozování modelu. GPU, paměť, propojení, energie, datacentrum, software a lidé, kteří to drží v chodu. A také odměna poskytovateli, který to celé zajišťuje a nese riziko nevyužité kapacity. V tomhle je serving modelů docela klasický cloudový byznys.

Druhá je vývoj modelu a hodnota jeho vah. Někdo zaplatil výzkum, data, trénink a post-training. U uzavřeného modelu si přístup k výsledku kupuju od jeho vlastníka nebo partnera. U otevřeného modelu můžu mít právo váhy používat bez průběžné licenční platby, pokud mi to jeho licence dovoluje.

Neznamená to, že vývoj otevřeného modelu nic nestál. Znamená to, že ho nemusím platit stejným způsobem. Otevřenost může odstranit licenční platbu za váhy. Neodstraní práci, kterou musí udělat hardware při používání modelu.

Navíc tyhle dvě vrstvy na faktuře obvykle neuvidím odděleně. API cena není povinně „náklad na generování tokenů plus marže za váhy“. Ovlivňuje ji konkurence, kapacita, obchodní strategie nebo snaha získat zákazníky. Může být dočasně i pod náklady.

Právě v provozní vrstvě podle mě budou výnosy z rozsahu hrát zásadní roli. Velký provider má poptávku z více aplikací a časových pásem. Dokáže skládat požadavky do větších dávek, lépe využívat cache a rozpočítat specialisty na serving přes obrovský objem.

V minulém měření jsme se při přechodu z jednoho na padesát souběžných požadavků dostali s cache asi na 5,5násobek souhrnné kapacity. Jeden požadavek ale trval déle. A vedle batch size potřebuju také využití v čase: ideálně práci, která se blíží nepřetržitému provozu, ne GPU čekající každý večer na ráno.

To neznamená, že vlastní inference musí běžet přesně 24×7, jinak se nikdy nevyplatí. Znamená to, že její ekonomiku určuje množství užitečné práce při přijatelné latenci.

Tyhle výhody přitom může využít poskytovatel otevřených i uzavřených modelů. Když odstraním jeho marži, automaticky tím nezískám jeho provozní náklady.

Tady podle mě vzniká velká část těch stonásobných úspor. Vezmu relativně malý otevřený model a porovnám ho s drahým frontier modelem. Rozdíl v ceníku může být obrovský. Jenže jsem nezměnil pouze licenci. Změnil jsem i to, co kupuju.

Pro pořádek jednotky: B je miliarda, T je bilion. Model 2T tedy má dva biliony parametrů.

Tohle nejsou vymyšlené velikostní kategorie mimo realitu. Kimi K3 má podle zveřejněné modelové karty 2,8T parametrů celkem a 104B aktivních na token. U Mixture of Experts mají aktivní parametry velký vliv na compute nároky, všechny váhy se ale musejí někam vejít. A nejde jen o kapacitu paměti: zásadním limitem je i její propustnost při načítání potřebných vah a práci s cache. Neznamená to, že při každém tokenu načítám všechny experty.

To je také jeden z důvodů, proč na rozdíl od domácího použití dává ve velkém servingu smysl disagregace prefill a decode. Zpracování vstupu bývá více omezené výpočtem, postupné generování zase pamětí a její propustností. Provider může každou fázi poslat na jinak nastavený hardware a škálovat je odděleně. Musí se mu ovšem vyplatit i přenos KV cache mezi nimi.

Ani míru sparsity, tedy jak malou část expertů aktivuju, nemůžu zvyšovat libovolně bez dopadu na schopnosti. Experimenty s MoE a reasoningem ukazují, že více parametrů při vysoké sparsity pomáhá ukládání znalostí, ale uvažování potřebuje také dost aktivního výpočtu a trénovacích dat na parametr. Co je efektivní pro znalosti, tedy nemusí být efektivní pro reasoning. Není to univerzální optimální poměr pro každý model, ale dobrý důvod, proč nestačí donekonečna přidávat neaktivní experty.

Od jednotek miliard k jednotkám bilionů jsme přibližně na třech řádech. Velikost ovšem není přesný ceník ani automatická známka kvality. Záleží na architektuře, tréninku, kvantizaci i konkrétní úloze. Menší specializovaný model může být na mém zadání lepší než větší obecný.

Nemůžu tedy vzít stonásobek parametrů a prohlásit ho za stonásobek ceny inference. Ale pořád porovnávám výrazně odlišné hardwarové a schopnostní třídy, ne stejný výrobek s odlepenou cenovkou za licenci.

Levný malý model může být skvělá volba. Jen k tomu nepotřebuje otevřené váhy. Existují i levné modely s uzavřenými vahami — přesně ty si do cenového srovnání nesmím zapomenout přidat.

V úplné špičce grafu jsou na tomto snímku uzavřené modely Astra a Fable. O kus níž už se pohybují velmi schopné otevřené modely jako GLM-5.3 a Kimi K3.

Moje pracovní hypotéza je, že tým na technologické špičce může část náskoku proměnit také v efektivitu: dosáhnout určité kvality s menším výpočtem, kratším reasoningem nebo lépe optimalizovaným servingem. Pak může uzavřený model potřebovat na srovnatelnou práci méně hardwaru, ale současně mi účtovat víc za přístup k vahám.

O jakých maržích se vůbec bavíme? V mediálních odhadech pro rok 2025 se u předního poskytovatele modelů objevovalo kolem 50 % hrubé marže. Zářijové zprávy z roku 2026 už mluví o více než 80 %, ovšem před podíly distribučních partnerů a náklady na trénink. Beru je jako řádové odhady, ne auditovanou časovou řadu jednoho API; zářijovou zprávu navíc Reuters nezávisle neověřil.

U cloudu zase pro orientaci vidíme třeba za rok 2025 tržby AWS 128,7 miliardy USD a provozní zisk 45,6 miliardy, tedy provozní marži asi 35 %. To ale není hrubá marže na pronájmu jedné GPU. Tato různě definovaná procenta nemůžu jednoduše odečíst a rozdíl prohlásit za cenu vah.

Pro řádovou kalkulačku proto vezmu 50 nebo 80 % jako celkovou modelovou marži uzavřené služby, zahrnující odměnu za serving i modelovou prémii. U otevřené varianty nechám 30 % za serving. Není to rekonstrukce účetnictví konkrétní firmy: pokud nakupuje compute od cloudu, část infrastrukturní marže už může být zahrnutá v jejích nákladech. Tady obě varianty počítám od stejné nákladové základny a nic nepřičítám dvakrát.

Přímý náklad na inferenci stejné práce bude u uzavřeného modelu 100 jednotek. Otevřená alternativa bude v našem příkladu o 15 % nákladnější, tedy 115. Třicetiprocentní marže poskytovatele znamená, že náklad tvoří 70 % prodejní ceny: otevřené API proto stojí 164,29 jednotky, ne 149,50 jako při pouhé 30% přirážce.

Jak v tom modelově oddělím ty dvě složky? Při přímém nákladu 100 by samotný serving s 30% marží stál 142,86: sto za inferenci, 42,86 jako odměna provozovateli. Do konečných 200 pak zbývá 57,14 jako modelová prémie; do 500 zbývá 357,14. To není čistý zisk za váhy, financuje se z toho i vývoj, trénink a další náklady.

Patnáctiprocentní rozdíl v efektivitě i třicetiprocentní serving marže zůstávají předpoklady příkladu, ne měřením konkrétního endpointu. Kdyby byly obě varianty provozně stejně efektivní, vyjde poměr cen 1,4× až 3,5×. S naším rozdílem efektivity přibližně 1,2× až 3×. Pro firmu to může být zajímavá úspora, ale řádově jsme pořád úplně jinde než u 100×.

Když modely porovnávám přes API, nestačí mi cena za milion tokenů. Potřebuju vědět, kolik jich spotřebují na stejnou práci. Včetně reasoningu, vstupu, opakovaného kontextu a případných dalších pokusů.

Úplně jednoduchý příklad: jeden model má výstupní tokeny za polovinu, ale potřebuje jich třikrát tolik. Jen jeho výstup mě pak stojí o polovinu víc. Vstup a cache zatím nechávám stranou.

U Kimi K3 to není jen akademická otázka. V údajích Artificial Analysis dostupných při přípravě článku má Kimi K3 v nastavení max přibližně 160 milionů výstupních tokenů za běh Intelligence Indexu, zatímco GPT-5.6 Sol v nastavení max asi 90 milionů. Kimi má přitom v uvedeném ceníku output za 15 USD za milion, Sol za 20 USD. Levnější token, ale větší spotřeba; vážená cena benchmarkové úlohy vychází u obou přibližně na dva dolary.

Proti Opusu 5 v nastavení max, který má uvedeno asi 140 milionů výstupních tokenů, je ale rozdíl ve spotřebě mnohem menší. Neřekl bych tedy obecně, že Kimi potřebuje násobně víc tokenů než všechny uzavřené modely. Záleží, proti čemu a v jakém nastavení ho měřím.

Ani z těchto souhrnných tokenových počtů nelze prostým dělením dopočítat vodorovnou osu grafu. Cost per Intelligence Index Task je vážený průměr nákladů jednotlivých evaluací na úlohu. Zohledňuje jejich váhy v indexu a příslušné účtované tokeny — vstup, cache, reasoning a odpověď.

Proto se mi ten graf líbí víc než samotný ceník. Pořád ale ukazuje cenu benchmarkové úlohy, ne cenu úspěšně vyřešeného firemního případu. Kvalita je na druhé ose. Když mi levný agent úlohu pokazí, jeho tokeny se sice hezky účtují, ale já práci pořád nemám hotovou.

A při vlastním hostování musím API cenu nahradit svým úplným provozním nákladem. Tenhle obrázek sám o sobě neříká, kolik by mě Kimi stálo na mém clusteru.

Když se vrátím k obrázku, vidím tři důležité věci.

Úplný vrchol schopností není automaticky dostupný v otevřené variantě. Astra a Fable jsou nahoře kolem skóre 53. GLM-5.3 a Kimi K3 kolem 44–45, Sol kolem 47 a Opus 5 kolem 51. To neznamená, že otevřený model nemůže některou konkrétní úlohu zvládnout stejně dobře nebo lépe, ale pro tento benchmark to vychází takhle. Váš use case samozřejmě může být jiný - nicméně nečekám propastně jiné výsledky.

O kus níž otevřené modely skutečně konkurují, ale nevidím automatickou stonásobnou slevu. Kimi K3, GLM-5.3 a Sol se tu všechny pohybují přibližně kolem dvou dolarů za úlohu. Opus stojí kolem šesti, ale má také vyšší skóre. Když zvolím Kimi místo Opusu, může to být správné rozhodnutí. Jen je to v tomhle grafu obchod mezi cenou a kvalitou, ne důkaz stejného výsledku třikrát levněji.

Levný konec trhu není vyhrazený otevřeným modelům. GPT-5.6 Luna v nastavení medium leží úplně vlevo, přibližně na 0,016 USD za úlohu. To je proti Solu více než stonásobný cenový rozdíl — uvnitř nabídky jednoho výrobce uzavřených modelů. Jenže Luna tu má skóre kolem 25,5, nikoli Solových 47. A otevřený GLM-5.3-Flash je naopak zajímavý bod hranice kolem 0,25 USD a skóre 42. Pozor, Flash není stejná varianta jako GLM-5.3 max z předchozího odstavce.

Zajímavé je, jak si vedou někteří výrobci (ke dni, kdy jsem tento článek napsal). OpenAI má velmi vyrovnané portfolio od malých (Luna, Terra) až po velké velmi schopné modely (Sol, Astra). Anthropic umí excelovat v high-end spektru, ale jeho cenově dostupnější varianty dnes na Paretovu hranici nemají (Haiku je úplně mimo, Sonnet nic moc, Opus rovněž ztrácí cenově optimální dech). Google je dnes ve stavu, kdy je high-end v podobě Gemini Pro mimo hru, ale střední třída s Gemini 3.8 Flash je na Paretově hranici, zatímco nižší třída s 3.5 Flash-Lite je aktuálně mimo hru.

Za mě přesně tohle rozbíjí zkratku „otevřené rovná se levné, uzavřené rovná se drahé“. Na zajímavých místech jsou obě skupiny. Některé jiné modely mají ve sledované dvojici kritérií alternativu, která je levnější i schopnější, bez ohledu na licenci.

Tenhle graf bych používal jako výborný začátek výběru, ne jako jeho konec. Intelligence Index skládá různé typy úloh a jejich váhy. Moje aplikace ale může celý den dělat jednu věc, na kterou je menší model výborný.

Začal bych vlastními příklady a jasnou laťkou: co musí model zvládnout a co už je chyba. Pak bych porovnal několik levných i silnějších modelů, otevřených i uzavřených, včetně rozumných nastavení reasoningu. Vedle výsledků bych měřil celý účet za hotovou práci: všechny pokusy, nástroje, případný fallback a opravy člověkem.

Tohle znovu ukazuje, proč jsou do budoucna tak důležité vlastní evaluations sady a vlastní trénovací prostředí (RLE), tak jak jsem o tom už psal v článku o evals jako nejcennějším aktivu.