Ekonomika trvalé vs. nárazové inference: kdy vyhrává on-prem a kdy Vás zachrání cloud

Inferenční server se čtyřmi GPU spotřebuje stejně elektřiny, zabere stejné místo v racku a odepisuje se podle stejného plánu, ať obslouží dvacet milionů tokenů denně, nebo dvacet tisíc. Karty netuší, že zahálejí. Účetní to ví. Právě tahle jediná asymetrie — fixní náklad na straně on-prem, mezní náklad na straně cloudu — je celý důvod, proč správná odpověď na otázku „máme jít on-prem?" závisí stejně tak na tvaru Vašeho provozu jako na jeho objemu.

T01 spočítal matematiku na kartu v jediném bodě vytížení. T02 porovnává náklad na milion tokenů proti cloudovým API při plné zátěži. Tenhle článek (T03) je ten, který si Váš finanční ředitel opravdu potřebuje přečíst: co se s těmi čísly stane, když je provoz nárazový, když je rovnoměrný, a jak navrhnout systém, který nepřeplácí ani na jedné straně.

Čtenářem je ten, kdo už došel k závěru, že by se workload na on-prem hodil, a teď se potřebuje rozhodnout, kolik on-prem a co pokryje zbytek.

Past fixních nákladů

Cloudová inference škáluje náklad s použitím. Jedno volání Llamy 70B u poskytovatele na OpenRouteru Vás vyjde zhruba na 0,50–2,00 € za milion tokenů (podle tarifu a poskytovatele). Neposíláte provoz, neplatíte nic. Pošlete 10× víc provozu, platíte 10×. Vztah je lineární a začíná na nule.

U on-prem inference je to naopak. Stroj se 4× RTX Pro 6000 Blackwell (T01 uvádí tříleté TCO kolem 58 tis. € se vším všudy — rozpuštěný capex, elektřina, podíl na skříni, údržba) stojí těch 58 tis. € bez ohledu na to, jestli obslouží milion tokenů, nebo bilion. Mezní náklad dvoustamiliontého tokenu v měsíci je stejný jako mezní náklad toho druhého: kilowatthodiny elektřiny, která ho spočítala, a nic víc. Capex je utopený náklad ode dne, kdy se stroj expeduje.

Účetní důsledek je brutální a kupující si ho málokdy připustí:

(Stejný hardware, stejné TCO 14,4 tis. € na kartu za tři roky; mění se jen jmenovatel.)

Cloudová sazba za Llamu 70B FP8 se v roce 2026 pohybuje v pásmu 0,50–1,50 €/Mtok podle tarifu poskytovatele. Přečtěte si tabulku znovu s tímhle na paměti. Při 5% dlouhodobém vytížení je on-prem stroj dražší než každá existující cloudová varianta. Při 30 % se vyrovná nejdražším poskytovatelům. Při 60 % a výš matematiku jasně vyhrává.

Past spočívá v tom, že zákazníci poměřují capex proti současné zátěži a po půl roce zjistí, že současná zátěž byla 8 % stroje. Hardware neudělal nic špatně. Dimenzování ano.

Jak vypadá vytížení v reálném provozu

Máme veřejná data i vlastní měření napříč instalacemi Kentino AI, které provozujeme nebo navštěvujeme, a obrázek je v roce 2026 napříč oborem konzistentní:

Hlavní čísla z produkčních nasazení a průzkumů mezi provozovateli: většina týmů, které si inferenci provozují samy, hlásí průměrné vytížení GPU 20–40 %, přičemž vyzrálé provozy se blíží 40–65%. Cokoli nad 65 % dlouhodobě je buď čistě dávková práce, nebo cluster běžící tak nahorko, že se další špička provozu zařadí do fronty. Pod 20 % znamená, že stroj běží hlavně proto, aby se zaplatil, ne aby obsluhoval uživatele.

Číslo, které kupující vždycky překvapí: interaktivní workload — chatbot, programátorský asistent, bot zákaznické podpory — téměř nikdy neudrží víc než 30 %. Může za to denní světlo. I globální produkt má hluchá místa; regionální produkt má každý den 14 hodin nízké zátěže. Matematika to tvrdě trestá.

Rovnoměrné workloady — chléb náš vezdejší

On-prem ekonomika funguje čistě u každého workloadu, kde dokážete udržet GPU v práci po většinu dne. Zhruba v pořadí, jak často je na instalacích Kentino AI vídáme:

• Programátorský asistent / backend pro IDE pro tým 30+ inženýrů. Vyrovnaná zátěž v pracovní dny 09:00–18:00, slabší večery, o víkendu téměř nula. Průměr 20–30 % za týden, ve špičce během pracovní doby 60–80 %.
• Chatbot pro zákaznickou podporu / prodej s provozem 24/7. Denní rytmus kopíruje obsluhovaný region; globální produkty se dostanou na 25–35 % dlouhodobě, regionální na 15–25 %.
• Backend pro RAG / sémantické vyhledávání , který indexuje a obsluhuje interní znalostní bázi. Míra dotazů je středně vyrovnaná; reindexace je plánovaná noční úloha, která stroj vytíží na 95 %. Kombinované vytížení 30–50 %.
• Dávkové zpracování — noční sumarizace včerejších dokumentů, týdenní běhy autolabelingu, měsíční reklasifikace celého korpusu. Čistá práce z fronty, 70–90 % vytížení, dokud fronta není prázdná, navržená tak, aby doběhla do konce.
• Inference pro flotilu robotů — několik jednotek odebírá ze stejného VLM endpointu během provozní doby, mimo ni nečinnost (I01, I06).

Vzorec je takový, že rovnoměrné workloady buď pokrývají dost časových pásem, aby zaplnily den, nebo mají dávkové části, které mezery zaplní záměrně. Technika „zaplň mezery" je jediná největší páka na TCO, kterou zákazník může zatáhnout, a zároveň ta nejpřehlíženější. Stroj, který 12 hodin denně dělá interaktivní chat na 30 % a přes noc jede autolabeling na 90 %, vyjde v průměru na zhruba 60 % — dvojnásobné efektivní vytížení, poloviční náklad na token.

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

Opačný tvar je workload, který potřebuje obrovskou kapacitu na krátké okno a po zbytek času skoro nic. Příklady, které vídáme pravidelně:

• Marketingová kampaň / nápor na generování obsahu. Vygenerovat varianty reklamní kampaně pro N trhů za 48 hodin, pak měsíc nic.
• Virální momenty. Spotřebitelská aplikace vydá novou funkci, dostane se do technologického newsletteru, provoz na šest hodin 50× nad normálem a do rána zpět na výchozí hodnotě.
• Dema a pilotní akce. Stánek na veletrhu s živými ukázkami inference po tři dny, pak zpátky na nulu.
• Pravidelné dávkové úlohy, které musí doběhnout v daném okně. Měsíční compliance kontrola celého korpusu dokumentů, která musí být hotová do regulatorního termínu.
• Analytika volební noci nebo živé události — okno 12–48 hodin, kdy je objem 100× nad normálem.

Příklad z praxe. Workload potřebuje vygenerovat 10 milionů tokenů. Rozložené do 24 hodin je to zhruba 116 tok/s v souhrnu — zvládne to jediná L4. Stlačené do jednohodinového okna je to 2,778 tok/s — potřebujete 4GPU stroj Pro 6000 na plný výkon, nebo zhruba šest L4.

Takže stejných 10 milionů tokenů si vyžádá buď jednu kartu 24/7, nebo šest karet na jednu hodinu. U nárazových workloadů stojí on-prem kapacita nečinně 23 hodin z každých 24. Matematika TCO se hroutí: ten šestikartový stroj při 4% vytížení stojí v přepočtu podle tabulky výše 13–25 €/Mtok. Cloudová špička za 1,50 €/Mtok obslouží stejnou zátěž celkem za 15 €. Bod zvratu není ani zdaleka blízko.

Nevyhnutelný závěr: snaha dimenzovat on-prem na špičku nárazu je nejčastější přeplacení, jaké vídáme. Zákazníci chtějí, aby stroj pokryl nejhorší možné úterní odpoledne, a tak koupí 4× víc GPU, než v běžném týdnu potřebují. Účet přijde v podobě capexu, který už nedostanou zpět, a z 90 % nečinné flotily.

Hybridní vzorec

Poctivá architektura pro reálný produkční workload s oběma tvary je on-prem základna plus přetékání špiček do cloudu.

Hybridní směrování: nejprve on-prem, přetečení do cloudu až když hloubka fronty překročí nastavený práh.

Správná logika směrování není „pošli X % do cloudu, zbytek on-prem". Je to nejprve on-prem, cloud jen když je on-prem na hraně kapacity. Signálem je hloubka fronty nebo vytížení KV cache na straně vLLM (K03 rozebírá metriky), ne statické rozdělení.

Konkrétní postup s vLLM:

1. Před on-prem cluster postavte router, který vystavuje /v1/chat/completions. NGINX, HAProxy, vLLM Router i malá vlastní brána fungují stejně dobře.
2. Vystavte vllm:num_requests_waiting jako ukazatel hloubky fronty. Práh nastavte třeba na 8–16 čekajících na repliku, než se spustí záloha.
3. Při přetečení směrujte na cloudový endpoint se stejným názvem modelu. OpenRouter / Together / Fireworks obsluhují modely třídy Llama. Jeden nastavte jako primární a jeden jako záložní, abyste nespadli s jedním poskytovatelem.
4. Označte si přetečené požadavky v monitoringu, abyste denně viděli, jakou část doplácíte. Pokud je to většinu dní nad 15 %, je Váš on-prem poddimenzovaný; pokud je to týdny pod 1 %, je předimenzovaný.

Ekonomická logika: capex zaplaťte jednou za zátěž, která je tam pořád, a za špičky plaťte proměnlivé cloudové sazby. Když se to udělá dobře, dostane to efektivní vytížení on-prem stroje na 50–70 % (práh směrování je to, co ladíte) a přitom se i během náporů dodrží závazky na latenci v chvostu.

Studený start: realita autoškálování

Naivní cloudová odpověď na nárazovou zátěž zní „nechte on-prem cluster autoškálovat" — držet repliky na nule a nahodit je na vyžádání. U provozu LLM to ošklivě selhává z jednoho důvodu: doby načtení modelu.

Načtení Llamy 70B FP8 (~75 GB vah) z disku Gen5 NVMe zabere 30–60 sekund čistého I/O při teoretické rychlosti čtení 12–14 GB/s. Přičtěte kompilaci CUDA kernelů, zahřátí plánovače vLLM a předalokaci KV cache a čerstvá replika je připravená přijmout první požadavek 60–120 sekund po startu podu. U menších modelů to klesá úměrně — 8B se vejde do 5–10 sekund — ale cokoli nad 30B je v pásmu „uživatelům to vyprší".

U dávkových workloadů to nevadí. U interaktivních je to fatální. Dvě minuty latence u požadavku, který škálování spustil, jsou nepřijatelné.

Možná opatření, v pořadí podle náročnosti:

• Držte N replik trvale zahřátých. Minimum, které pokryje Vaši průměrnou zátěž. Škálujte nahoru na vyžádání, nikdy dolů na nulu. Na vzorci „minimum zahřátých" staví vyzrálí provozovatelé celé produkty.
• Režim spánku ve vLLM. Novější verze vLLM podporují stav „sleep", kdy váhy zůstanou v paměti GPU, ale engine uvolní výpočetní prostředky. Probuzení je 18–20× rychlejší než čerstvé načtení. Užitečné, když máte víc modelů sdílejících GPU, ale vždy běží jen jeden.
• Předehřátá cache modelů na sdíleném NVMe / NFS. Váhy stáhnete jednou do rychlé lokální cache a všechny repliky ji připojí. První načtení proběhne jednou při startu clusteru, další repliky naběhnou během sekund.
• Plánované škálování podle denní doby. Naškálujte dopředu v 08:30 v očekávání provozu v 09:00. Nejjednodušší a nejúčinnější vzorec pro předvídatelné denní rytmy. CronJoby volající kubectl scale sice nejsou v módě, ale fungují.
• NVIDIA NIM Operator s předpřipravenými TRT-LLM enginy. Enginy postavené předem, uložené na disku, načítané na vyžádání. Rychlejší studený start než čerstvá kompilace, ale u 70B pořád v řádu desítek sekund.

Pro zákaznickou základnu Kentino AI — malé flotily, předvídatelné vzorce použití — je správnou odpovědí téměř vždy N zahřátých replik + plánované škálování + přetékání špiček do cloudu. Škálování na nulu patří na serverless platformy, kde studený start zaplatí někdo jiný.

Autoškálování: HPA podle čeho?

Kubernetes HPA se ve výchozím stavu řídí metrikami CPU a paměti. Obě jsou pro GPU inferenci špatně. Pod s vLLM může být na 5 % CPU a přitom zcela přetížený, nebo na 95 % CPU a obsluhovat bez problémů. Metrika, kterou skutečně potřebujete, je jedna z těchto:

Správným nástrojem, jak to zapojit do Kubernetes, je KEDA (Kubernetes Event-Driven Autoscaling), která umí přímo konzumovat dotazy do Promethea a předávat je HPA. Produkční stack vLLM má integraci s KEDA přímo zabudovanou a stejný vzorec funguje i s KServe na OpenShift AI.

Funkční ScaledObject pro škálování podle hloubky fronty:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama70b
spec:
  scaleTargetRef:
    name: vllm-llama70b
  minReplicaCount: 2     # always-warm floor
  maxReplicaCount: 6     # cap before cloud overflow
  pollingInterval: 15
  cooldownPeriod: 300    # don't thrash on noisy queue
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      query: avg(vllm:num_requests_waiting)
      threshold: '5'     # avg 5 waiting per replica → scale up

Dvě produkční ponaučení, která jsme vykoupili tvrdě:

1. cooldownPeriod je stejně důležitý jako samotný spouštěč. Rozkolísaná fronta způsobí zmítání mezi škálováním nahoru a dolů a každé naškálování zaplatí studený start. 5 minut je rozumné minimum.
2. minReplicaCount se má dimenzovat na sedlo, ne na nulu. Ty dva pody, které v 03:00 zahálejí, jsou přesně ty dva pody, které v 09:00 zvládnou špičku, aniž by požadavkům vypršel čas.

Škálovat horizontálně, nebo vertikálně

Nenápadné architektonické rozhodnutí při dimenzování: koupíte víc strojů (horizontálně), nebo víc GPU na stroj (vertikálně)?

U inferenčních workloadů s nárazovým provozem horizontální cesta téměř vždy vyhrává. Dva stroje se 4 GPU mohou běžet jako čtyři repliky DP=2, unesou výpadek jednoho stroje bez ztráty služby a dovolí Vám přidávat kapacitu po polovinách místo po celých jednotkách. Vertikální cesta je správná volba pro trénink a pro inferenci velmi velkých jednotlivých modelů, kde TP potřebuje mít GPU v jedné elektrické doméně.

Psychologická past „GPU zahálí, a já ho platím"

Zákazníci, kteří přijedou na instalaci poprvé, si často otevřou dashboard v Grafaně, uvidí vytížení GPU 18 % v úterý ve 14:30 a ptají se, proč zaplatili hardware, který 80 % času nic nedělá.

Poctivá odpověď zní, že u každého workloadu citlivého na latenci je jistá nečinnost cenou, kterou platíte za nízkou latenci v chvostu. Stroj na 95% dlouhodobém vytížení má frontu. Fronta znamená latenci požadavků. Zákazník, který chce čas do prvního tokenu 300 ms, nedostane na témže stroji zároveň 95% vytížení. Vyberte si jedno.

Kompromis, který lze optimalizovat, je přesunout fixní práci do nečinných oken:

• Dávkové úlohy (autolabeling, extrakce dokumentů, generování embeddingů pro nový obsah) naplánované na noc, kdy je chatbot v klidu.
• Běhy fine-tuningu o víkendech, kdy nejsou na systému žádní uživatelé.
• Pravidelná reindexace vektorových databází v časných ranních hodinách.

To je ta disciplína, kdy k on-prem stroji přistupujete jako k aktivu s dvojím využitím: přes den interaktivní provoz citlivý na latenci, v noci dávková práce. Když se to udělá dobře, tentýž hardware, který na interaktivním dashboardu ukazuje 25% vytížení, ukáže na dashboardu všech workloadů 65 %. Finanční ředitel vidí to druhé.

Co není řešení: uměle nahánět míru požadavků, aby to „vypadalo vytíženě". Zákazníci to občas zkoušejí. Zhorší to latenci v chvostu, znehodnotí monitoring a na účtu to nic nezmění.

Rozhodovací matice

Správnou architekturu určuje spíš tvar workloadu než jeho objem. Najděte si řádek nejbližší Vaší situaci:

Dvě věci, které tahle matice dělá správně a živelné plánování špatně:

• Čistě nárazové workloady patří do cloudu. Kupovat hardware pro workload, který běží čtyři hodiny měsíčně, je hazard.
• Hybrid „rovnoměrné + nárazové" téměř vždy chce obojí. Snaha vybrat jen jedno obvykle vybere špatně.

Poctivé shrnutí

Většina zákazníků Kentina by měla počítat s dlouhodobým vytížením on-prem 30–50 % a všechno nad to řešit přetečením do cloudu. Zákazníci, kteří se dostanou na 60–80% vytížení on-prem, jsou ti, kdo vedle interaktivního provozu pouštějí dávkovou práci — autolabeling přes noc, fine-tuning o víkendech, generování embeddingů v časných ranních hodinách. Zákazníci, kteří sedí na 10–15 %, jsou ti, kdo dimenzovali na špičku.

Nejdražší chyba je nakupovat na nejhorší možné úterní odpoledne. Druhá nejdražší je jít čistě do cloudu ve chvíli, kdy by se rovnoměrná zátěž zaplatila za 14 měsíců. Správná odpověď je téměř vždy někde uprostřed: menší on-prem stroj, než jaký si zákazník původně vyspecifikoval, s cestou přetečení do cloudu pro špičky.

Kontrola výpočtem: při cloudových sazbách 0,50 €/Mtok a 4GPU stroji Pro 6000 za 58 tis. € na tři roky se stroj zaplatí zhruba při 14 miliardách obsloužených tokenů. Rovnoměrně rozloženo je to ~150 tok/s v souhrnu trvale — což je pro tento stroj v dosahu při 25–35% vytížení. Pod tímto objemem si pronajímejte. Nad ním vlastněte. Je to tentýž bod zvratu, k němuž T01 a T02 docházejí z pohledu na kartu a na token.

Tento text je součástí Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Připomínky a opravy uvítáme na info@kentino.com.