Lokálne LLM vs. cloud: kedy sa firme oplatí prevádzkovať AI vo vlastnej serverovni

Otázka „lokálne alebo v cloude“ sa vo firmách často rieši ako svetonázor. V skutočnosti je to prevádzkové rozhodnutie s tromi vstupmi: koľko tokenov systém reálne spotrebuje, aké dáta cez neho tečú a koľko hodín denne budú GPU naozaj vyťažené. Kto si tieto tri čísla odhadne poctivo, má odpoveď takmer vždy.

Tento text je zhrnutím toho, čo o probléme hovoria dostupné dáta — nie argumentom za nákup servera. V množstve prípadov je správna odpoveď cloud a je dobré vedieť, ktoré to sú.

Otvorené modely už nie sú kompromis

Najdôležitejšia zmena posledných dvoch rokov nie je technologická, ale konkurenčná: rozdiel medzi otvorenými a uzavretými modelmi sa scvrkol. Podľa merania Epoch AI zaostávali od januára 2026 najlepšie open-weight modely za špičkovými uzavretými modelmi v priemere o štyri mesiace, čo v ich agregovanom indexe schopností (ECI) zodpovedá zhruba 8 bodom — podobnému rozdielu, aký býva medzi dvoma po sebe idúcimi verziami toho istého komerčného modelu.

Praktický dôsledok je jednoduchý. Pri úzko vymedzených úlohách — klasifikácia dokumentov, extrakcia štruktúrovaných dát, rešerš nad internou dokumentáciou, generovanie hlásení — je rozdiel medzi frontier modelom a dobrým otvoreným modelom často pod hranicou toho, čo daný proces vôbec dokáže odmerať. Pri otvorenom uvažovaní, dlhých agentových reťazcoch a náročnom kóde je rozdiel stále cítiť. Voľba modelu preto nie je otázka prestíže, ale toho, kde na tejto škále leží konkrétna úloha.

Kvantizácia: čo robí lokálne nasadenie fyzicky možným

Bežná námietka znie, že veľký model sa do firemnej serverovne jednoducho nezmestí. Odpoveďou je kvantizácia — uloženie váh modelu v nižšej presnosti než pôvodných 16 bitov. Otázka nie je, či to funguje, ale koľko to stojí na kvalite.

Najrozsiahlejšie verejné meranie tohto typu pochádza z práce „Give Me BF16 or Give Me Death?“ (ACL 2025), ktorá na celej rodine Llama 3.1 (8B, 70B, 405B) urobila vyše 500 000 vyhodnotení naprieč akademickými aj reálnymi benchmarkmi. Výsledky sú pre praktické nasadenie veľmi konkrétne:

• 8-bitový formát s pohyblivou desatinnou čiarkou (W8A8-FP) dosahuje približne 99 % skóre nekomprimovaného modelu — autori ho označujú za prakticky bezstratový.
• 8-bitová celočíselná varianta (W8A8-INT) stráca v priemere 1 až 3 % na úlohu, teda výrazne menej, než uvádzali staršie práce.
• 4-bitové váhy so 16-bitovými aktiváciami (W4A16-INT) dosahujú na akademických benchmarkoch okolo 99,4 % pôvodného skóre a sú podľa autorov najefektívnejšou voľbou pre latenčne citlivé, synchrónne nasadenia.

Metodicky za tým stojí poznatok z práce AWQ, ocenenej ako najlepší článok na MLSys 2024: kvalitu modelu drží veľmi malý podiel váh. Ochrana približne 1 % najdôležitejších kanálov výrazne znižuje chybu kvantizácie, pričom metóda nevyžaduje spätné šírenie ani rekonštrukciu, takže sa neprispôsobuje jednému doménovému datasetu. Autori na jej základe demonštrovali beh 70-miliardového modelu aj na mobilných GPU.

Zhrnuté prakticky: 4-bitová kvantizácia zmenší pamäťové nároky niekoľkonásobne pri strate, ktorá je vo väčšine firemných úloh nemerateľná. Práve to posunulo on-premise AI z rozpočtu dátového centra do rozpočtu bežného IT oddelenia.

Ekonomika: rozhoduje vyťaženie, nie cena hardvéru

Najčastejšia chyba pri porovnávaní je počítať cenu za milión tokenov proti cene GPU. Reálne porovnanie je päťročné TCO vrátane elektriny, chladenia, údržby a ľudí.

Whitepaper Lenovo Press „On-Premise vs Cloud: Generative AI Total Cost of Ownership“ (edícia 2026) modeluje presne toto pri päťročnej amortizácii, 12 % ročnej údržbe a cene elektriny 0,12 USD/kWh. Vybrané čísla:

• Uzol s 8× H200 sa oproti cloudovej on-demand cene zaplatí približne za 5,2 mesiaca; oproti trojročnej rezervovanej cene až za 13,4 mesiaca.
• Uzol s 8× B200 sa oproti prenájmu vypláca už pri 5,3 hodinách denného využitia počas piatich rokov.
• Cena za milión tokenov pri modeli veľkosti 70B vychádza on-premise na 0,159 USD oproti 0,97 USD v cloude na porovnateľnom hardvéri — zhruba šesťnásobný rozdiel.
• Pri najväčšej modelovanej konfigurácii je päťročný náklad 1,51 mil. USD oproti 6,25 mil. USD za ekvivalentnú cloudovú inštanciu.

Tieto čísla treba čítať s jednou dôležitou výhradou, ktorú TCO modely radi zamlčia: platia pri vysokom a stabilnom vyťažení. GPU server stojí rovnako, keď počíta, ako keď stojí prázdny. Ak firma spotrebuje pár miliónov tokenov mesačne v nepravidelných špičkách, on-premise nasadenie prehrá s cloudom o rád — a žiadna kvantizácia to nezachráni.

Do TCO na strane on-premise treba zarátať aj položky, na ktoré sa v prvom rozpočte zabúda:

• čas človeka, ktorý stack aktualizuje, monitoruje a rieši výpadky,
• náhradný hardvér a záložnú prevádzku pre prípad poruchy GPU,
• migráciu na nové modely, ktoré vychádzajú rýchlejšie, než sa amortizuje server,
• evaluačnú sadu, bez ktorej sa výmena modelu nedá bezpečne urobiť.

Dáta a regulácia: čo self-hosting rieši a čo nie

Lokálne nasadenie eliminuje celé kategórie rizika naraz: odpadá prenos osobných údajov do tretích krajín, sprostredkovateľské zmluvy s poskytovateľom modelu aj otázka, čo sa s promptmi deje po odoslaní. To je vecná výhoda, nie marketingová.

Neplatí však, že self-hosting znamená súlad s GDPR. Právny základ spracúvania, lehoty uchovávania, bezpečnostné opatrenia, postup pri incidente aj posúdenie vplyvu (DPIA) pri rizikovom spracúvaní ostávajú v plnej miere na prevádzkovateľovi. Lokálny model odstraňuje najľahšie zlyhania, nie prácu.

Stanovisko Európskeho výboru pre ochranu údajov (EDPB) č. 28/2024 z decembra 2024 pridáva dôležitý detail: model natrénovaný na osobných údajoch nie je automaticky anonymný. Anonymitu treba posudzovať prípad od prípadu a preukázať, že pravdepodobnosť získania osobných údajov priamo z modelu — napríklad útokmi typu model inversion či membership inference — je zanedbateľná a že ani výstupy modelu neodhalia konkrétne osoby. Stanovisko zároveň rieši situáciu, keď bol model vyvinutý nezákonne: subjekt, ktorý ho preberá, si musí vykonať vlastnú previerku.

Pri AI Acte je dnes dôležitejšia časová os než samotný text. Zákaz vybraných praktík a povinnosť AI gramotnosti platia od februára 2025, povinnosti pre poskytovateľov modelov na všeobecné účely od augusta 2025. Po dohode z mája 2026 sa však povinnosti pre vysokorizikové systémy podľa prílohy III odkladajú z 2. augusta 2026 na 2. decembra 2027 a systémy podľa prílohy I z augusta 2027 na august 2028. Firmám to dáva čas, nie amnestiu — a je rozumné využiť ho na to, čo bude treba tak či tak: logovanie, evidenciu verzií modelov a dokumentáciu dát.

Práve tu má lokálne nasadenie tichú prevahu. Keď model beží vo vlastnej infraštruktúre, kompletný audit trail je technicky triviálny — všetko prechádza cez vlastnú bránu. V cloudovom scenári treba tú istú vrstvu postaviť tak či tak, len s menšou kontrolou nad tým, čo sa deje za ňou.

Ako to vyzerá technicky

Prevádzkový stack je dnes dobre zmapovaný a nevyžaduje výskumný tím. Pre serverové nasadenie sa štandardne používa vLLM, ktorého mechanizmus PagedAttention spravuje KV cache podobne, ako operačný systém spravuje virtuálnu pamäť — podľa pôvodnej práce prináša 2 až 4-násobný nárast priepustnosti pri rovnakej latencii a takmer nulové plytvanie pamäťou. Pre menšie nasadenia a testovanie sa používa llama.cpp a nadstavby nad ním.

Podľa našich skúseností z výskumu lokálnych agentových systémov, ktorý robíme v spolupráci so Strojníckou fakultou STU, býva najnáročnejšou časťou projektu práve to, čo s modelom nesúvisí: prístup k dátam, ich kvalita a definícia toho, čo znamená správna odpoveď. Model je vymeniteľný komponent — evaluačná sada a dátová vrstva nie.

Kedy je cloud lepšia voľba

Poctivá odpoveď musí obsahovať aj opačný smer. Cloud dáva zmysel, keď:

• objem je nízky alebo veľmi nepravidelný a server by väčšinu času stál prázdny,
• projekt je vo fáze prototypu a hlavná otázka znie, či to vôbec bude fungovať,
• úloha vyžaduje najsilnejší dostupný model a spomínaný náskok uzavretých modelov sa reálne prejaví na výsledku,
• firma nemá ani čiastočnú kapacitu na prevádzku infraštruktúry a ani ju nechce budovať,
• dáta nie sú citlivé a regulačná záťaž je nízka.

Rozumný postup je preto zväčša hybridný: rutinné, vysokoobjemové a dátovo citlivé úlohy bežia lokálne, zatiaľ čo pre okrajové prípady vyžadujúce maximálnu schopnosť ostáva otvorená cesta do cloudu — cez rovnaké rozhranie, aby sa dala kedykoľvek prepnúť.

Zhrnutie v troch otázkach

Rozhodnutie sa dá zredukovať na tri veci. Po prvé: bude hardvér vyťažený aspoň niekoľko hodín denne po celý rok? Ak nie, ekonomika on-premise nevychádza. Po druhé: sú dáta také, že by ich odoslanie tretej strane bolo problém aj pri podpísanej zmluve? Ak áno, lokálne nasadenie rieši viac než len súlad. Po tretie: viem definovať a odmerať, čo je pri mojej úlohe dostatočne dobrá odpoveď? Ak nie, na výbere modelu zatiaľ nezáleží — a to platí rovnako pre cloud aj pre vlastnú serverovňu.