Ekonomika trvalej a nárazovej inferencie: kedy vyhráva on-prem a kedy Vás zachráni cloud

Štvorkartový inferenčný server spáli rovnaké množstvo elektriny, zaberie rovnaké miesto v racku a odpisuje sa podľa rovnakého plánu, či už obslúži dvadsať miliónov tokenov denne alebo dvadsaťtisíc. Karty nevedia, že sú nečinné. Účtovník to vie. Práve táto jediná asymetria — fixný náklad na strane on-prem, marginálny náklad na strane cloudu — je celý dôvod, prečo správna odpoveď na otázku „máme ísť do on-prem?“ závisí rovnako od toho, aký je tvar vašej prevádzky, ako od jej objemu.

T01 rozobral ekonomiku na jednu kartu v jedinom bode vyťaženia. T02 porovnáva náklady na milión tokenov s cloudovými API pri plnom zaťažení. Tento článok (T03) je ten, ktorý si váš finančný riaditeľ naozaj potrebuje prečítať: čo sa s týmito číslami stane, keď je prevádzka nárazová, keď je trvalá, a ako navrhnúť systém, ktorý neprepláca ani na jednej strane.

Je určený niekomu, kto už dospel k záveru, že jeho workload by sa na on-prem mohol zmestiť, a teraz potrebuje rozhodnúť, koľko on-prem a čo pokryje zvyšok.

Pasca fixných nákladov

Cloudová inferencia škáluje náklady spolu s využitím. Jedno volanie modelu Llama 70B u poskytovateľa cez OpenRouter vás vyjde zhruba na €0.50–€2.00 za milión tokenov (líši sa podľa tarify a poskytovateľa). Neposielate žiadnu prevádzku, neplatíte nič. Pošlete 10× viac prevádzky, zaplatíte 10×. Vzťah je lineárny a začína na nule.

Pri on-prem inferencii je to presne naopak. Zostava so 4× RTX Pro 6000 Blackwell (T01 uvádza 3-ročné TCO na približne €58k vrátane všetkého — amortizovaný capex, elektrina, podiel na šasi, údržba) stojí týchto €58k bez ohľadu na to, či obslúži jeden milión tokenov alebo bilión. Marginálny náklad 200-miliónteho tokenu v mesiaci je rovnaký ako marginálny náklad druhého: kWh elektriny, ktorú si jeho výpočet vyžiadal, a nič viac. Capex je utopený náklad odo dňa, keď zostava dorazí.

Účtovný dôsledok je nemilosrdný a kupujúci si ho málokedy pripustia:

(Rovnaký hardvér, rovnaké TCO €14.4k na kartu počas troch rokov; mení sa len menovateľ.)

Cloudová sadzba za Llama 70B FP8 sa v roku 2026 pohybuje v pásme €0.50–€1.50/Mtok podľa tarify poskytovateľa. Prečítajte si tabuľku ešte raz s týmto na pamäti. Pri 5 % trvalého vyťaženia je on-prem zostava drahšia než ktorákoľvek existujúca cloudová možnosť. Pri 30 % sa vyrovná tým najdrahším poskytovateľom. Pri 60 % a viac si matematiku odnáša suverénne.

Pasca je v tom, že zákazníci porovnávajú capex s aktuálnym zaťažením a o pol roka zistia, že aktuálne zaťaženie bolo 8 % kapacity zostavy. Hardvér neurobil nič zle. Chybné bolo dimenzovanie.

Ako vyzerá reálne produkčné vyťaženie

Máme k dispozícii verejné dáta aj vlastné merania naprieč inštaláciami Kentino AI, ktoré prevádzkujeme alebo navštevujeme, a obraz je v roku 2026 naprieč odvetvím konzistentný:

Hlavné čísla z produkčných nasadení a z prieskumov medzi prevádzkovateľmi: väčšina tímov, ktorá si inferenciu prevádzkuje sama, uvádza 20–40 % priemerné vyťaženie GPU, pričom vyzreté nasadenia sa blížia k 40–65 %. Čokoľvek nad 65 % trvalo je buď čistá dávková práca, alebo klaster bežiaci tak horúco, že nasledujúca špička sa zaradí do fronty. Pod 20 % znamená, že zostava beží hlavne preto, aby sa zaplatila, nie aby obsluhovala používateľov.

Číslo, ktoré kupujúcich vždy prekvapí: interaktívny workload — chatbot, asistent pre programovanie, bot zákazníckej podpory — takmer nikdy neudrží viac než 30 %. Dôvodom je denné svetlo. Aj globálny produkt má hodiny mimo špičky; regionálny produkt má každý deň 14 hodín nízkeho zaťaženia. Matematika to tvrdo trestá.

Trvalé workloady — chlieb a soľ

Ekonomika on-prem vychádza čisto pri každom workloade, kde dokážete udržať GPU v práci väčšinu dňa. Zhruba v poradí, ako často ich na inštaláciách Kentino AI vidíme:

• Asistent pre programovanie / backend pre IDE pre tím 30+ inžinierov. Stabilné zaťaženie v pracovné dni 09:00–18:00, slabšie večery, cez víkend takmer nula. V priemere 20–30 % za týždeň, so špičkami 60–80 % počas pracovného dňa.
• Chatbot zákazníckej podpory / predaja s prevádzkou 24/7. Denný cyklus kopíruje obsluhovaný región; globálne produkty sa pohybujú na 25–35 % trvalo, regionálne na 15–25 %.
• RAG / backend sémantického vyhľadávania indexujúci a obsluhujúci internú znalostnú bázu. Miera dopytov je pomerne vyrovnaná; preindexovanie je plánovaná nočná úloha, ktorá zostavu vyťaží na 95 %. Kombinované vyťaženie 30–50 %.
• Dávkové spracovanie — nočná sumarizácia včerajších dokumentov, týždenné behy autolabelingu, mesačné opakované klasifikácie nad korpusom. Čistá práca z fronty, 70–90 % vyťaženie, kým fronta nie je prázdna, navrhnutá tak, aby dobehla do konca.
• Inferencia pre flotilu robotov — viacero jednotiek ťahá z toho istého VLM endpointu počas prevádzkových hodín, mimo nich nečinné (I01, I06).

Spoločným menovateľom je, že trvalé workloady buď pokrývajú dosť časových pásiem na to, aby zaplnili deň, alebo majú dávkové zložky, ktoré medzery zaplnia zámerne. Technika „zaplň medzery“ je zďaleka najväčšia páka na TCO, akú môže zákazník použiť — a tá najprehliadanejšia. Zostava, ktorá robí 12 hodín denne interaktívny chat na 30 % a cez noc beží autolabeling na 90 %, sa v priemere dostane na zhruba 60 % — dvojnásobné efektívne vyťaženie, polovičný náklad na token.

Nárazové workloady — kde on-prem bolí

Opačným tvarom je workload, ktorý potrebuje obrovskú kapacitu na krátke okno a po zvyšok času takmer nič. Príklady, ktoré vidíme pravidelne:

• Marketingová kampaň / nápor na generovanie obsahu. Vygenerovať varianty pre reklamnú kampaň naprieč N trhmi za 48 hodín, potom mesiac nič.
• Virálne momenty obsahu. Spotrebiteľská aplikácia vypustí novú funkciu, dostane sa do technologického newslettra, prevádzka 50× vyššia než bežne po dobu šiestich hodín a do druhého rána späť na východiskovej úrovni.
• Demá / pilotné podujatia. Stánok na veľtrhu s živými ukážkami inferencie tri dni, potom späť na nulu.
• Periodické dávkové úlohy, ktoré musia dobehnúť v danom okne. Mesačná compliance kontrola nad celým korpusom dokumentov, ktorá musí byť hotová do regulačného termínu.
• Analytika volebnej noci alebo živého podujatia — okno 12–48 hodín, kde je objem 100× vyšší než bežne.

Príklad z praxe. Workload potrebuje vygenerovať 10 miliónov tokenov. Rozložené do 24 hodín je to zhruba 116 tok/s v súhrne — zvládne to jediná L4. Stlačené do jednohodinového okna je to 2,778 tok/s — treba 4-GPU zostavu Pro 6000 bežiacu naplno, alebo zhruba šesť kariet L4.

Tých istých 10 miliónov tokenov si teda vyžiada buď jednu kartu 24/7, alebo šesť kariet na jednu hodinu. Pri nárazových workloadoch sedí on-prem kapacita nečinne 23 z každých 24 hodín. Výpočet TCO sa rozsype: tá šesťkartová zostava pri 4 % vyťaženia stojí €13–25/Mtok v ekvivalente tabuľky vyššie. Cloudová špička za €1.50/Mtok obslúži to isté zaťaženie celkovo za €15. Bod zvratu nie je ani zďaleka blízko.

Nevyhnutný záver: snaha dimenzovať on-prem na špičku je najčastejšia chyba vedúca k preplateniu, akú vidíme. Zákazníci chcú, aby zostava pokryla najhorší utorok popoludní, a tak kúpia 4× viac GPU, než potrebujú v bežnom týždni. Účet príde v podobe capexu, ktorý už nezískajú späť, a 90 % nečinnej flotily.

Hybridný vzor

Poctivou architektúrou pre reálny produkčný workload s oboma tvarmi je on-prem základňa plus prepad špičiek do cloudu.

Hybridné smerovanie: najprv on-prem, prepad do cloudu až keď hĺbka fronty prekročí nastavený prah.

Správna logika smerovania nie je „pošli X % do cloudu, zvyšok na on-prem“. Je to najprv on-prem, cloud až keď je on-prem na hranici kapacity. Signálom je hĺbka fronty alebo vyťaženie KV cache na strane vLLM (K03 sa venuje metrikám), nie statické rozdelenie.

Konkrétny postup s vLLM:

1. Pred on-prem klaster postavte router, ktorý vystavuje /v1/chat/completions. NGINX, HAProxy, vLLM Router aj malá vlastná brána fungujú rovnako dobre.
2. Vystavte vllm:num_requests_waiting ako ukazovateľ hĺbky fronty. Prah nastavte napríklad na 8–16 čakajúcich na repliku, než sa zapne prepad.
3. Pri prepade smerujte na cloudový endpoint s rovnakým názvom modelu. OpenRouter, Together aj Fireworks obsluhujú modely triedy Llama. Jedného si určte ako primárneho a jedného ako záložného, aby vás nepoložil výpadok jediného poskytovateľa.
4. Prepadnuté požiadavky si v observabilite označte, aby ste denne videli, aké percento doplácate. Ak je to väčšinu dní nad 15 %, váš on-prem je poddimenzovaný; ak je to týždne pod 1 %, je predimenzovaný.

Ekonomická logika: capex zaplaťte raz za zaťaženie, ktoré je tu stále, a variabilné cloudové sadzby plaťte za špičky. Ak to urobíte dobre, dostanete efektívne vyťaženie on-prem zostavy na 50–70 % (ladíte práve prah smerovania) a zároveň udržíte záväzky na latenciu chvosta aj počas špičiek.

Studený štart: realita autoškálovania

Naivná odpoveď v cloudovom štýle na nárazové zaťaženie znie „autoškáluj on-prem klaster“ — repliky drž na nule, keď je nečinno, a nabehni na požiadanie. Pri obsluhe LLM to zlyháva, a to z jediného dôvodu: čas načítania modelu.

Načítanie Llama 70B FP8 (~75 GB váh) z disku Gen5 NVMe trvá 30–60 sekúnd čistého I/O pri teoretickej rýchlosti čítania 12–14 GB/s. Pripočítajte kompiláciu CUDA kernelov, zahrievanie plánovača vLLM a predalokáciu KV cache a čerstvá replika je pripravená prijať prvú požiadavku 60–120 sekúnd po štarte podu. Menšie modely pomáhajú úmerne — 8B sa zmestí do 5–10 sekúnd — ale čokoľvek nad 30B je už v pásme „používateľom vyprší časový limit“.

Pri dávkových workloadoch je to v poriadku. Pri interaktívnych je to fatálne. Dve minúty latencie na požiadavke, ktorá škálovanie spustila, sú neprijateľné.

Zmierňujúce opatrenia, zoradené podľa náročnosti:

• Držte N replík stále zahriatych. Toľko, koľko pokryje vaše priemerné zaťaženie. Škálujte hore na požiadanie, nikdy nie dole na nulu. Vzor „minimálne zahriate“ je presne to, okolo čoho vyzretí prevádzkovatelia stavajú celé produkty.
• Režim spánku vLLM. Novšie verzie vLLM podporujú stav „sleep“, v ktorom váhy zostávajú v pamäti GPU, ale engine uvoľní výpočtové prostriedky. Prebudenie je 18–20× rýchlejšie než čerstvé načítanie. Užitočné, keď máte viac modelov, ktoré zdieľajú GPU, ale naraz beží vždy len jeden.
• Predhriata vyrovnávacia pamäť modelov na zdieľanom NVMe / NFS. Váhy stiahnete raz do rýchlej lokálnej cache a všetky repliky ju pripoja. Prvé načítanie prebehne raz pri štarte klastra; ďalšie repliky nabehnú v sekundách.
• Plánované škálovanie podľa dennej doby. Naškálujte vopred o 08:30 v očakávaní prevádzky o 09:00. Najjednoduchší a najúčinnejší vzor pre predvídateľné denné cykly. CronJoby, ktoré volajú kubectl scale , nie sú v móde, ale fungujú.
• NVIDIA NIM Operator s predpripravenými TRT-LLM enginmi. Enginy zostavené vopred, uložené na disku, načítané na požiadanie. Rýchlejší studený štart než čerstvá kompilácia, pri 70B však stále v desiatkach sekúnd.

Pre zákaznícku základňu Kentino AI — malé flotily, predvídateľné vzorce využitia — je správnou odpoveďou takmer vždy N zahriatych replík + plánované škálovanie + prepad špičiek do cloudu. Škálovanie na nulu patrí na serverless platformy, kde studený štart znáša niekto iný.

Autoškálovanie: HPA na základe čoho?

Kubernetes HPA štandardne vychádza z metrík CPU a pamäte. Obe sú pre GPU inferenciu nesprávne. Pod s vLLM môže byť na 5 % CPU a pritom 100 % preťažený, alebo na 95 % CPU a obsluhovať úplne v pohode. Metrika, ktorú naozaj potrebujete, je jedna z týchto:

Správnym nástrojom na zapojenie do Kubernetes je KEDA (Kubernetes Event-Driven Autoscaling), ktorý dokáže priamo konzumovať dopyty z Prometheus a podávať ich do HPA. Produkčný stack vLLM prináša prvotriednu integráciu s KEDA a rovnaký vzor funguje aj s KServe na OpenShift AI.

Funkčný ScaledObject pre škálovanie podľa hĺbky fronty:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama70b
spec:
  scaleTargetRef:
    name: vllm-llama70b
  minReplicaCount: 2     # vždy zahriate minimum
  maxReplicaCount: 6     # strop pred prepadom do cloudu
  pollingInterval: 15
  cooldownPeriod: 300    # aby to nekmitalo pri rozkolísanej fronte
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      query: avg(vllm:num_requests_waiting)
      threshold: '5'     # priem. 5 čakajúcich na repliku → škálovanie hore

Dve produkčné ponaučenia, ktoré sme si vydreli:

1. cooldownPeriod je rovnako dôležitý ako samotný spúšťač. Rozkolísaná fronta spôsobuje kmitanie medzi škálovaním hore a dole a každé škálovanie hore zaplatí studený štart. Rozumné minimum je 5 minút.
2. minReplicaCount treba dimenzovať na sedlo, nie na nulu. Tie dva pody, čo nečinne sedia o 03:00, sú presne tie dva pody, ktoré o 09:00 zvládnu špičku bez vypršania časového limitu.

Horizontálne vs. vertikálne škálovanie

Jemnejšia architektonická voľba pri dimenzovaní: kúpite viac zostáv (horizontálne) alebo viac GPU na zostavu (vertikálne)?

Pri inferenčných workloadoch s nárazovou prevádzkou takmer vždy vyhráva horizontálne škálovanie. Dve zostavy so 4 GPU môžu bežať ako štyri repliky DP=2, znesú výpadok jednej zostavy bez straty služby a umožnia vám škálovať kapacitu po polovičkách namiesto po celých jednotkách. Vertikálne je správna voľba pri trénovaní a pri inferencii veľmi veľkých modelov, kde TP potrebuje mať GPU v jednej elektrickej doméne.

Psychologická pasca „GPU je nečinná, a ja ju platím“

Zákazníci, ktorí inštaláciu navštívia prvýkrát, si často otvoria dashboard v Grafane, uvidia vyťaženie GPU na 18 % o 14:30 v utorok a pýtajú sa, prečo zaplatili za hardvér, ktorý 80 % času nič nerobí.

Poctivá odpoveď znie, že pri akomkoľvek workloade citlivom na latenciu je istá miera nečinnosti cena, ktorú platíte za nízku latenciu chvosta. Zostava na 95 % trvalého vyťaženia má frontu. Fronta znamená latenciu požiadaviek. Zákazník, ktorý chce čas do prvého tokenu 300 ms, nedostane na tej istej zostave zároveň 95 % vyťaženie. Vyberte si jedno.

Kompromis, ktorý sa optimalizovať dá, je presunúť fixnú prácu do nečinných okien:

• Dávkové úlohy (autolabeling, extrakcia dokumentov, generovanie embeddingov pre nový obsah) naplánované na noc, keď je chatbot ticho.
• Behy dolaďovania cez víkendy, keď na systéme nie sú používatelia.
• Periodické preindexovanie vektorových úložísk v skorých ranných hodinách.

To je disciplína, v ktorej sa na on-prem zostavu pozeráte ako na aktívum s dvojakým využitím: cez deň interaktívna obsluha citlivá na latenciu, cez noc dávková práca. Ak to urobíte dobre, ten istý hardvér, ktorý na interaktívnom dashboarde ukazuje 25 % vyťaženie, ukazuje na dashboarde všetkých workloadov 65 %. Finančný riaditeľ vidí to druhé.

Čo nie je riešenie: umelo naháňať mieru požiadaviek, aby to „vyzeralo zaneprázdnene“. Zákazníci to občas skúšajú. Zhorší to latenciu chvosta, znefunkční monitoring a na účte nezmení nič.

Rozhodovacia matica

Tvar workloadu diktuje správnu architektúru viac než jeho objem. Priraďte svoju situáciu k najbližšiemu riadku:

Dve veci, ktoré táto matica robí správne a ad hoc plánovanie zle:

• Čisto nárazové workloady patria do cloudu. Kupovať hardvér pre workload, ktorý beží štyri hodiny mesačne, je hazard.
• Hybrid „trvalé + nárazové“ takmer vždy chce oboje. Snaha vybrať si len jedno zvyčajne vyberie zle.

Poctivý záver

Väčšina zákazníkov Kentino by mala počítať s 30–50 % trvalého vyťaženia na on-prem a všetko nad to riešiť prepadom do cloudu. Zákazníci, ktorí sa dostanú na 60–80 % vyťaženia on-prem, sú tí, ktorí popri interaktívnej prevádzke púšťajú dávkovú prácu — autolabeling cez noc, dolaďovanie cez víkendy, generovanie embeddingov v skorých ranných hodinách. Zákazníci, ktorí sedia na 10–15 % vyťaženia, sú tí, ktorí dimenzovali na špičku.

Najdrahšou chybou je nákup na najhorší utorok popoludní. Druhou najdrahšou je ísť čisto do cloudu tam, kde by trvalé zaťaženie splatilo capex za 14 mesiacov. Správna odpoveď je takmer vždy niekde v strede: menšia on-prem zostava, než si zákazník pôvodne našpecifikoval, s cestou pre prepad špičiek do cloudu.

Overte si to protipočtom: pri cloudových sadzbách €0.50/Mtok a 4-GPU zostave Pro 6000 za €58k na 3 roky sa zostava zaplatí zhruba pri 14 miliardách obslúžených tokenov. Rovnomerne rozložené je to ~150 tok/s trvalo v súhrne — pohodlne v dosahu zostavy pri 25–35 % vyťaženia. Pod týmto objemom si prenajímajte. Nad ním vlastnite. Je to ten istý bod zvratu, ku ktorému sa T01 a T02 dopracúvajú z pohľadu na kartu a na token.

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy privítame na info@kentino.com.