Otevřený AI model má mnoho výhod. Většina z nich nevyžaduje vlastní hardware.

Tady otevřenému modelu fandím. Můžu si podržet konkrétní verzi, měnit runtime, kvantizaci, cache nebo přidat vlastní adaptér. Nemusím čekat, jestli mi poskytovatel takovou možnost vystaví v API.

A když dodavatel API vypne? Buď je tu mnoho dalších, nebo se staženými vahami můžu nastartovat GPU kdekoli jinde.

Když skončí tým, který model vyvíjí, uchovám si dnešní schopnosti. Nezískám tím automaticky jeho budoucí inovace. A ani přechod na jiný model není jen výměna URL: jinak může fungovat tool calling, formát odpovědí nebo kvalita na mojí úloze.

Kvůli tomu všemu ovšem nemusím kupovat server. Stejný model nabízí jak velcí provideři, tak ti menší i lokální, nebo můžu rozjet inferenci na vlastní VM — máme tedy možnost relativně snadno přejít jinam a udržuju si flexibilitu kdykoli cokoli změnit (poskytovatele, typ železa, region).

1. června 2026 Anthropic po americké exportní direktivě vypnul Fable 5 všem uživatelům; globální přístup obnovil 1. července. Sám popisuje, že nedokázal v reálném čase ověřovat státní příslušnost uživatelů, aby mohl omezení uplatnit selektivně. Nebyl to běžný výpadek serveru. Stažené otevřené váhy snižují závislost na podobném vypínači konkrétní služby, neplatí ale jako výjimka ze zákonů nebo exportních pravidel.

Přestože váhy, co už jsou na internetu, těžko někdo zamaskuje, neznamená to, že přístup k nim vám dá možnost je plně použít. Firmy i stát mohou smluvně zakázat používání čínských modelů ve svých zakázkách, stát může omezit použití třeba ve zdravotnictví nebo při práci s dětmi. Může se tak stát, že vám model zbyde jen pro „osobní potřebu“.

Představme si, že dělám autorizovaný penetrační test nebo rozebírám logy napadeného systému. Potřebuju pracovat i s útočnými technikami, jinak tomu incidentu těžko porozumím. Případně pracuji na výzkumu v oblasti AI nebo biologie. Filtr může vidět nebezpečné téma a práci zastavit nebo mě přepnout na méně schopný model a to může být omezující.

Otevřený model ale neznamená automaticky model bez guardrails. Odmítání může mít naučené ve vahách. Další omezení přidává aplikace, licence nebo provozovatel infrastruktury.

Vlastní inference mi umožní rozhodnout, kam data tečou, kdo je uvidí a co se ukládá. To je skutečná výhoda, ale neznamená to, že při používání per-token API automaticky někdo získá přístup k mým datům nebo že provozovatel cloudu musí vidět dovnitř mého VM. API může mít zero retention policy, která pro podporované funkce a za sjednaných podmínek omezuje uchovávání dat. Confidential computing zase umožňuje chránit data v paměti i před privilegovaným provozovatelem infrastruktury. Jsou to různé ochrany — samotné zero retention neznamená, že služba data při inference vůbec nezpracovává.

Liší se míra toho, co nastavuji a za co odpovídám sám. To ale neříká, která varianta je bezpečná více nebo méně, záleží na detailech.

A vrátím se i k trénovacím datům: otevřené váhy samy neodhalují jejich původ a nejsou důkazem, že model nemá nežádoucí nebo skrytě podmíněné chování (například tzv. spící agent). Umístění serveru tuhle důvěru v model samo nevyřeší.

Pokud mi vyhoví vhodný region, privátní přístup a smluvní podmínky služby, nemusím kvůli citlivým datům automaticky do on-prem.

Vlastní provozování modelu mi dovolí rezervovat kapacitu pro moji aplikaci a ladit ho na rychlou odpověď, ne na maximální počet tokenů za den. Jinak řečeno můžu ovlivnit inferencing parametry a prioritizovat vyšší počet tokenů za vteřinu pro jeden požadavek na úkor celkové kapacity. Typicky snížím batch size: jednotlivý požadavek běží rychleji, ale náklady na token mohou výrazně narůst.

Podobnou volbu nabízejí i komerční poskytovatelé. Například Claude fast mode používá stejné váhy a rychlejší nastavení inference za vyšší cenu. Není to jiný, chytřejší model. Konkrétní implementaci ale Anthropic nepopisuje jako pouhé snížení batch size a zrychlení se týká hlavně generování tokenů, ne času do prvního tokenu.

Vedle sítě totiž čekám také ve frontě, na zpracování vstupu a na generování odpovědi. Dobře provozované vzdálené API může malý lokální server předběhnout. U hlasu nebo mnoha krátkých agentních kroků naopak síťové round tripy poznám víc než u jedné dlouhé odpovědi.

Když chci kontrolovat latenci, může stačit vlastní cloudová VM. Když musím fungovat bez internetu, tak nestačí. Tam už dává smysl model na zařízení nebo místní server.

Jenže tam, kde běží systém, který nesmí mít přístup k internetu, často nepotřebuju žádné LLM. Útočný dron může používat „AI“ ve formě computer vision; pro tuhle úlohu nepotřebuje diskutovat rozdíly mezi přístupy Platóna a Sókrata. Offline AI tedy není automaticky argument pro lokální velký jazykový model.

U notebooku bych si nejdřív ověřil, že menší model vůbec zvládne moji úlohu. Na extrakci nebo klasifikaci může být výborný; složitý coding agent je jiné zadání. Za mě je pro kódování, které od agenta očekávám, cokoli, co dokáže běžet na notebooku, naprosto nepoužitelné. To je moje laťka pro tenhle způsob práce, ne tvrzení, že malý model nenapíše užitečnou funkci.

Otevřené modely jako GLM 5.3 nebo Kimi K3 jsou podle mě úžasné, ale notebooková liga to není. Ani oba nejsou stejně velké: zveřejněné váhy GLM 5.3 mají přibližně 753 miliard parametrů, Kimi K3 má 2,8 bilionu. Na efektivní provoz potřebuju velké vícenásobné GPU sestavy, u největších modelů cluster, jehož cena se bude pohybovat v desítkách milionů korun. Hardware doporučený firmou Moonshot AI pro provoz Kimi K3 vychází na téměř 100 milionů korun.

Tady bych nejdřív oddělil dvě úspory. Vybrat levnější model není totéž jako levněji provozovat stejný model.

Pro řadu úloh můžu místo drahého frontier modelu vzít menší otevřený model s levným API a ušetřit. Pokud úlohu zvládá, proč ne? Úsporu mám hned, bez nákupu GPU. Jen ji nezaručuje samotná licence: záleží na ceníku, kvalitě, počtu pokusů a tom, kolik práce nakonec musí dodělat člověk. Typicky mluvíme o tzv. pareto-optimální hranici, tedy modelech, které leží na nejlepším poměru ceny a výkonu. Například velmi levná GPT 5.6 Luna je na této hranici — closed source model neznamená nutně, že má špatný poměr ceny a výkonu. Stejně tak aktuální modely Mistral mají od této hranice dost daleko — jsou sice otevřené, ale na náročnost hardwaru nedávají tak dobré výsledky jako ostatní.

Druhá otázka už je jiná: když jsem si model vybral, bude levnější kupovat jeho tokeny jako službu, provozovat ho na IaaS, nebo koupit vlastní železo?

A přesně to chci ve druhé části propočítat. Kontrolu, bezpečnost a omezení už máme rozebrané. Teď nebudu obhajovat server jinými výhodami — zajímá mě cena stejné práce.

Testoval jsem Mistral i Nemotron, ale dál budu komentovat jen NVIDIA Nemotron 3.5 Lightning 30B-A3B v BF16. Princip srovnání platí i pro další modely; konkrétní rychlost a hranice návratnosti se samozřejmě přenášet nedají.

Použil jsem Azure VM Standard_NC24ads_A100_v4 s jednou A100 80 GB PCIe a vLLM 0.28.0. Každý požadavek měl 16 384 vstupních a 512 výstupních tokenů. Zkoušel jsem 1, 5, 10, 20, 50 a 100 souběžných požadavků, vždy s opakovaným prefixem a bez něj. Každou kombinaci třikrát — celkem 36 měření a 4 017 úspěšných požadavků.

Varianta se společným prefixem simuluje opakovanou práci coding agenta v jednom projektu: instrukce, nástroje a část kontextu posílám znovu (takže jde o test s velkou částí cached tokenů). Bez sdíleného začátku model víc pracuje na novém vstupu (un-cached scénář).

A100 je karta poměrně stará, jinou jsem neměl k dispozici — myslím ale, že pro řádové srovnání na malém modelu to není problém a trend, který navnímáme zde, bude podobný i u větších modelů a novějších karet.

Pojďme si představit, že GPU obsluhuje jen mě. Načítá váhy a postupně generuje tokeny. Když obsluhuje víc požadavků společně, může práci nad stejnými vahami lépe využít. Batch size je velikost takové společně zpracovávané dávky.

Moderní serving používá continuous batching: hotové požadavky odcházejí a nové průběžně přibývají. Já zvenku nastavuju souběh klientů, tedy concurrency, ne pevnou velikost každé interní dávky. Souběh 50 také neznamená 50 registrovaných uživatelů, ale 50 současně rozpracovaných požadavků.

Co to udělalo s cenově použitelnou kapacitou? V tabulkách je souhrnný output tok/s celé karty, ne rychlost jednoho člověka. TTFT je čas do prvního tokenu; všechna čísla jsou průměry tří opakování.

S cache jsem se z jednoho na padesát streamů dostal na přibližně 5,5násobek celkové kapacity. Ale odpověď jednotlivci trvá déle. Při stovce už throughput dokonce klesá. „Přidám větší batch a budu levnější“ tedy neplatí donekonečna.

Za mě z toho plyne jednoduché pravidlo pro kalkulačku: počítat můžu jen s kapacitou, jejíž latence mi ještě vyhovuje. Noční dávka a interaktivní asistent jsou jiné scénáře a je pro ně vhodná jiná batch size.

Teď ta druhá osa. Souběh říká, kolik práce dělám najednou. Časové využití říká, jak dlouho tu práci vůbec mám.

Sto procent času při jednom streamu není stejný objem jako sto procent při padesáti. A údaj z nvidia-smi není odpověď na žádnou z těchto ekonomických otázek. Zajímá mě dokončená užitečná práce, na kterou rozpočítám náklady.

Osm hodin pět dní v týdnu je jen 23,8 % kalendáře. A to bych uvnitř pracovní doby musel držet zvolený souběh nepřetržitě. Lidé ale chodí na schůzky, agenti čekají na nástroje a poptávka kolísá. Šedesátiprocentní využití znamená přes sto hodin práce týdně. K tomu už potřebuju třeba více časových pásem, více aplikací nebo frontu úloh na noc.

Tady má velký provider praktickou výhodu: skládá poptávku mnoha zákazníků. Když já končím, někdo jiný začíná. Můj vlastní server takovou frontu práce sám od sebe nedostane.

Poskytovatel díky výnosům z rozsahu může mít podstatně nižší náklady: levnější hardware, efektivnější datacentrum, custom kernely či inferencing čipy nebo lépe vyladěná řešení (například disagregace prefill a decode či spekulativní decoding). Více níže.

Srovnávám pět let a tři způsoby provozu stejného modelu. U VM ještě rozliším, jestli ji zapínám jen na dávku, nebo si kapacitu držím dlouhodobě.

API sazba je veřejná reference Fireworks on Foundry ze snapshotu z 3. 9. 2026.

Cloudová rezervace a vlastnictví tady nejsou řádově od sebe. Rozdíl vychází na 12 776,87 USD za pět let, tedy asi 2 555 USD ročně. Tolik prostoru zbývá na další náklady on-prem navíc proti VM, než se modelový náskok vytratí.

Pojďme měnit vždycky jednu věc: jak dobře využiju zaplacený čas a kolik požadavků zpracovávám najednou. V obou scénářích používám lokální společný prefix a předpokládám, že API vyúčtuje 64 % vstupních tokenů jako levnější cached tokeny. Zbytek vstupu platím běžnou sazbou, výstup se generuje a platí zvlášť.

Stručně: vlastní inference potřebuje dost práce v čase i najednou. Výsledek ovlivňuje i sleva za cached tokeny v API: čím levnější API díky ní je, tím víc práce potřebuju pro výhodný vlastní provoz.

Bez společného prefixu na obou stranách vychází při naměřeném souběhu 50 potřebné využití rezervace 56,18 % a on-prem 44,73 %. Podobná procenta, ale jiná kapacita a výrazně horší latence: první token až za 17,72 s.

H = 43 800 hodin za pět let
u = produktivní podíl kalendáře
R = naměřené output tok/s × 3600 / 512
h = předpokládaný podíl vstupních tokenů účtovaných API jako cached
p = [16384 × ((1 − h) × 0,06 + h × 0,01) + 512 × 0,22] / 1 000 000
API = H × u × R × p
PAYG po celé srovnávané období alokované = H × 4,775 USD
rezervace = 77 611,67 USD
on-prem = 59 316 USD + H × u × 0,126 USD

Otevřené modely chci mít ve výběru. Kvůli kontrole, možnosti podržet verzi, vlastnímu chování i tomu, abych měl kam jít, když mi služba přestane vyhovovat. Kvůli většině těchto výhod ale nepotřebuju kupovat server.

A peníze? U tohoto modelu a workloadu mi při malém souběhu nebo nepravidelné práci vychází lépe levné API. Když mám dost souběžné práce po velkou část týdne, může vyjít vlastní inference. Pak bych porovnával především rezervovanou cloudovou VM s opravdu úplným on-prem rozpočtem, ne nákupní cenu karty s nekonečně běžícím PAYG.

Naše pracovní varianta s 64 % vstupu účtovaných API jako cached potřebuje při souběhu 50 zhruba 54 % času pro rezervaci a 43 % pro on-prem. On-prem má přitom před rezervací modelový náskok jen asi 2,6 tisíce dolarů ročně na další rozdílové náklady. To už se provozním odhadem otočí docela snadno.

Za mě tedy nejdřív vybrat model, který práci zvládne. Potom říct, jakou kontrolu a odezvu potřebuju. A teprve nakonec se ptát, kdo bude provozovat GPU. Neplatit marži poskytovateli je příjemná představa. Platit vlastní nevyužitý server už méně.