Lokální modely vs frontier modely: kde opravdu leží hranice praktického použití

Tahle otázka přijde skoro v každém rozhovoru o návrhu AI řešení: „Máme provozovat vlastní model, nebo používat frontier API?“ A skoro vždycky je položená jako tábor proti táboru — soukromí a kontrola versus prostě ber to nejlepší. Obě strany ale argumentují ideologií. Skutečná odpověď je rozhodnutí o vhodnosti.

01Špatná otázka

„Lokální, nebo frontier — co je lepší?“ je špatně položená otázka. Lepší v čem? Pro koho? Za jakou cenu? Je to jako ptát se, jestli je dodávka lepší než sporťák. Odpověď zní „na co?“.

Otázka, ze které vypadnou rozhodnutí, je jiná: pro tenhle úkol, s těmihle daty, v tomhle objemu — co se hodí? Přerámujte to z „který model“ na „který workload“. Pak zjistíte, že různé části jednoho produktu chtějí různou odpověď.

02Sedm os, na kterých se to láme

Volba se neláme na jedné ose, ale na sedmi — a každá táhne jinam:

• Soukromí a kontrola dat — kde data fyzicky i právně jsou.
• Cena — a hlavně její tvar: fixní vs. variabilní.
• Latence — kolik a jak předvídatelně.
• Kvalita — schopnosti na vaší úloze, ne na žebříčku.
• Customizace — jak hluboko si model ohnete k sobě.
• Údržba — kolik provozu si tím pořizujete.
• Vendor lock-in — jak draho se z toho dostává.

Žádný model nevyhrává všech sedm. Frontier API vede v kvalitě a v minimální provozní zátěži. Lokální model vede v kontrole dat, latenci, customizaci a v předvídatelnosti ceny při objemu — zaplatíte to ale provozní zátěží a často i kusem kvality.

03Kvalita: mezera je reálná, ale nerovnoměrná

Ke konci roku 2025 platí: na nejtěžších úlohách — náročné uvažování, agentní běhy, dlouhý kontext — frontier modely pořád vedou. Ta mezera je reálná, ale má dvě vlastnosti, na které se zapomíná. Zaprvé se zužuje. Zadruhé je velmi nerovnoměrná.

Pro spoustu ohraničených úloh — klasifikace, extrakce, strukturovaný výstup, doménově laděné úkoly — je dobrý otevřený model dávno „dost dobrý“. Klasická chyba je změřit lokální model na frontier-style těžké úloze, vidět, že propadne, a uzavřít „lokální na to není“. Měřte na své úloze. Model může být obecně slabší a přitom na to, co po něm chcete, naprosto stačit. Část toho zužování mezery ostatně jde z open-weight modelů od frontier labů samotných, které leží uprostřed obou táborů: kvalita blízko špičky, váhy si stáhnete.

Druhá strana mince je ale stejně důležitá: kde se mezera nezužuje — a místy se i prohlubuje. Jsou to dlouhé agentní běhy, tool use o mnoha krocích a uvažování přes velký kontext. Takové úlohy trestají i malou nespolehlivost, protože chyby se přes kroky násobí. Má-li váš workload tyhle vlastnosti, „dost dobrý“ otevřený model snadno znamená řádově vyšší míru selhání než frontier — a to není kus kvality navíc, to je rozdíl mezi funkčním a nefunkčním.

04Customizace: vlastní model ohnete, API jen do dané míry

Kvalita říká, jak je model dobrý sám o sobě. Customizace říká něco jiného: jak hluboko ho umíte ohnout k sobě. A tady má vlastní model páku, kterou frontier API nedává. S vlastními váhami si s modelem můžete dělat prakticky cokoli — fine-tuning na doménových datech, kvantizaci, vlastní dekódovací logiku. U frontier API jste omezeni na to, co poskytovatel nabídne; ta nabídka se zlepšuje, ale strop si určuje někdo jiný a může ho posunout.

Pro většinu úloh customizaci nepotřebujete — dobrý prompt a pár příkladů ji trumfnou rychlostí i cenou. Ale u úzké doménové úlohy, kde záleží na žargonu, formátu nebo chování, které se promptem dotáhnout nedá, může být hluboký fine-tuning rozdíl mezi „použitelné“ a „ne“. Tam tahle osa rozhoduje sama o sobě.

Jen pozor na druhou hranu. Fine-tune je navázaný na konkrétní základní model — když ten doslouží, doslouží fine-tune s ním. Customizace je výhoda i opakovaný náklad zároveň; počítejte s obojím.

05Cena: API není levné a self-hosting není zadarmo

Cena je osa, kterou týmy počítají nejhůř — protože u obou možností má jiný tvar. API se rozjede levně a škáluje lineárně s používáním: při velkém objemu umí ovládnout účet za infrastrukturu a tu cenu navíc neřídíte vy. Self-hosting má vysoký fixní náklad — GPU nebo jejich pronájem, lidi na MLOps — a nízký náklad na každý další dotaz.

Poctivé rámování: API je provozní náklad, který roste s úspěchem; lokální řešení je investice plus fixní provoz. Pod určitým objemem je levnější API, nad ním lokální. Většina týmů svůj objem přecení a self-hostuje moc brzy; část ho podcení a přijde jim překvapivý účet za API. Spočítejte ten práh dřív, než se rozhodnete.

A jeden háček, který ten práh posouvá: nízký náklad lokálního modelu na dotaz platí jen při slušné vytíženosti GPU. Třicetiprocentně využitá H100 má cenu na token, při které vám žádný výpočet návratnosti nevyjde — fixní náklad běží dál, ať kartou teče cokoli. Otázka „v jakém objemu se self-hosting vyplatí“ je proto ve skutečnosti „v jakém objemu udržím GPU vytíženou“. To není totéž a tým, který si ty dvě otázky neoddělí, počítá špatný práh.

06Latence a soukromí: kde lokální vyhrává jasně

Dvě osy, kde má lokální model strukturální výhodu. Latence: odpadá síťový round-trip a rozptyl cizí fronty — u interaktivního nebo vysokofrekvenčního použití to znát je. Soukromí: pokud data z právních nebo smluvních důvodů nesmí opustit vaši hranici, není to preference — rozhoduje to za vás.

Buďme ale přesní. „Frontier API = nebezpečné“ je nesmysl: enterprise tarify s netrénováním na vašich datech, definovanou rezidencí dat i nasazením v konkrétním regionu existují. Skutečná výhoda lokálního modelu není magické bezpečí — je to kontrola a auditovatelnost: víte přesně, kde data jsou a kdo na ně vidí.

07Údržba a lock-in: skryté položky účtu

Dvě osy, na které se zapomíná. Údržba: self-hostovaný model je systém, který teď vlastníte — aktualizace, škálování, monitoring, model, který stárne. To je stálý náklad v lidech, ne jen ve výpočtu.

Lock-in: frontier API je závislost na cizím roadmapu, ceníku, rušení starých verzí a rate limitech. Obrana je jednoduchá — držte integraci za abstrakcí, ať je model vyměnitelný kus, ne základ stavby. Tým, který umí přejít k jinému poskytovateli za týden, má reálnou vyjednávací sílu. Tým přivařený k jednomu API ji nemá.

08Skoro nikdy to není „buď, anebo“

Praktická odpověď: většina vyzrálých nasazení je hybridní. Routujte podle workloadu — citlivé, vysokoobjemové nebo latenčně kritické úlohy lokálně; těžké, vzácné nebo na schopnosti náročné úlohy přes frontier API. Mezi tím leží střední cesta, na kterou se zapomíná: malý fine-tuned nebo destilovaný model routovaný jen na úzký subtask často poráží jak naivní self-hosting velkého modelu, tak frontier volání.

Hybrid ale není zadarmo a bylo by nepoctivé to zamlčet. Platíte za něj dvěma pipelinami, dvěma eval suitami, dvěma bezpečnostními hladinami, dvěma módy selhání — a routovací logikou, která se sama stává systémem k údržbě. U většího týmu se ta daň rozpustí v rozsahu. U malého často převýší kteroukoli čistou variantu; tam je poctivější zvolit jednu stranu a držet ji.

A pořadí kroků: začněte na API — rychle ověříte hypotézu bez infrastruktury —, měřte reálné použití a reálnou obtížnost úloh, a konkrétní workloady přesouvejte lokálně teprve, až to čísla obhájí. Jedna výjimka, kterou je férové přiznat: máte-li tvrdý regulatorní požadavek na rezidenci dat, cesta „začněte na API“ neexistuje — pak je jediná volba lokálně od začátku. Pro všechny ostatní ale platí: nerozhodujte architekturu ideologií dřív, než máte data.

09Závěr: routovací rozhodnutí, ne vyznání

„Lokální vs frontier“ není přesvědčení, které zastáváte. Je to routovací rozhodnutí, které děláte pro každý workload zvlášť — a pravidelně ho revidujete, protože mezera ve schopnostech, ceny i nástroje se hýbou. Tenhle text popisuje krajinu na konci roku 2025; za pár měsíců může práh vyjít jinde.

Rozhodněte se na sedmi osách s vlastními čísly, držte model vyměnitelný a nastavte si rytmus revize — třeba každé dva kvartály přeměřit svůj eval set proti aktuální nabídce. Správná odpověď tohoto kvartálu nemusí platit příští a tým, který nemá určeno kdy a jak ji reviduje, na ní zůstane sedět tři roky.