Ekonomie trvalé vs. expanzivní inference: Kdy vítězí on-premise a kdy vás zachrání cloud

Inferenční server se čtyřmi GPU spotřebovává stejnou elektřinu, zabírá stejný prostor v racku a odepisuje se podle stejného harmonogramu, ať už obsluhuje dvacet milionů tokenů denně nebo dvacet tisíc. Karty nevědí, že jsou nečinné. Účetní ano. Tato jediná asymetrie – fixní náklady na straně on-premise, marginální náklady na straně cloudu – je jediným důvodem, proč správná odpověď na otázku „měli bychom přejít na on-premise?“ závisí stejně tak na formovat vaší návštěvnosti v závislosti na objemu.

T01 propočítal náklady na kartu v jednom bodě využití. T02 mapuje náklady na milion tokenů s cloudovými API při plném zatížení. Tento článek (T03) je ten, který by si váš finanční ředitel skutečně měl přečíst: co se s těmito čísly stane, když je provoz přetížený, když je trvalý a jak navrhnout systém, který na žádné straně nevede k nadměrným výdajům.

Publikum je někdo, kdo již dospěl k závěru, že by pracovní zátěž mohla být vhodná pro lokální prostředí a nyní se musí rozhodnout. jak moc on-premise a co zachraňuje zbytek.

Past fixních nákladů

Cloudová inference se škáluje podle využití. Jediné volání Llama 70B u poskytovatele OpenRouteru vás stojí zhruba 0.50–2.00 € za milion tokenů (liší se podle úrovně a poskytovatele). Neodesíláte žádný provoz, neplatíte nic. Posíláte 10× provoz, plaťte 10×. Vztah je lineární a začíná na nule.

On-premise inference je opačná. Krabice Blackwell se 4× RTX Pro 6000 (T01 Tříleté celkové náklady na vlastnictví (TCO) se pohybují kolem 58 000 EUR (amortizované kapitálové náklady, elektřina, sdílení šasi, údržba) a činí těchto 58 000 EUR, ať už se jedná o obsluhu jednoho milionu tokenů nebo jednoho bilionu. Mezní náklady na 200miliontý token za měsíc jsou stejné jako mezní náklady na druhý token: kWh elektřiny potřebné k jeho výpočtu a nic víc. Kapitálové náklady jsou utopenými náklady v den odeslání zařízení.

Účetní důsledky jsou brutální a kupující si je jen zřídka uvědomují:

(Stejný hardware, stejné celkové náklady na vlastnictví (TCO) 14.4 tis. EUR na kartu za tři roky; mění se pouze jmenovatel.)

Cloudová sazba pro Llama 70B FP8 se v roce 2026 pohybuje v pásmu 0.50–1.50 €/Mtok v závislosti na úrovni poskytovatele. S ohledem na to si znovu přečtěte tabulku. Při 5% trvalém využití je on-premise box dražší než všechny existující cloudové možnosti. Na 30 % se shoduje s nejdražšími poskytovateli. Na 60 % a více už to bez problémů vyjde.

Past spočívá v tom, že zákazníci porovnávají kapitálové výdaje s aktuálním zatížením a o šest měsíců později zjistí, že aktuální zatížení činilo 8 % výkonu zařízení. Hardware neudělal nic špatného. Špatně to bylo s dimenzováním.

Jak vypadá skutečné využití výroby

Máme veřejně dostupná data a také vlastní srovnávací analýzu všech instalací K-AI, které provozujeme nebo navštěvujeme, a situace je v celém odvětví v roce 2026 konzistentní:

Hlavní čísla z produkčních nasazení a průzkumů mezi operátory: většina týmů si vytváří vlastní inferenční zprávu Průměrné využití GPU 20–40 %, s postupně se rozvíjejícími systémy 40-65%Cokoli nad 65 % trvalé kapacity je buď čistě dávkový provoz, nebo cluster běží natolik, že další špička provozu se zařadí do fronty. Pod 20 % znamená, že zařízení běží převážně proto, aby se zaplatilo, ne aby sloužilo uživatelům.

Číslo, které kupující vždy překvapí: interaktivní pracovní zátěž – chatbot, asistent kódování, bot zákaznické podpory – téměř nikdy nepřekročí 30 %. Důvodem je denní světlo. I globální produkt má mimopracovní dobu; regionální produkt má každý den 14 hodin nízkého zatížení. Matematika to tvrdě trestá.

Trvalé pracovní zatížení – chleba a máslo

Ekonomika on-premise funguje čistě pro jakoukoli pracovní zátěž, kde můžete nechat GPU běžet po většinu dne. Zhruba v pořadí, jak často je vidíme na instalacích K-AI:

• Asistent kódování / IDE backend pro tým 30+ inženýrů. Stabilní vytížení ve všední dny 09:00–18:00, slabší večery, téměř nulové víkendy. Průměrně 20–30 % během týdne, vrcholí 60–80 % během pracovního dne.
• Zákaznická podpora / prodejní chatbot s nepřetržitým provozem. Denní spotřeba kopíruje obsluhovaný region; globální produkty dosahují 25–35 % trvalého příjmu, regionální 15–25 %.
• Backend RAG / sémantického vyhledávání indexování a obsluha interní znalostní báze. Míra dotazů je poměrně stabilní; reindexování je plánovaná úloha přes noc, která se pohybuje na 95 %. Kombinované využití 30–50 %.
• Dávkové zpracování — noční sumarizace včerejších dokumentů, týdenní automatické označování, měsíční opakovaná klasifikace korpusu. Čistá práce s frontou, využití 70–90 %, dokud fronta není prázdná, navrženo tak, aby běželo až do dokončení.
• Odvození robotické flotily — více jednotek odpojujících se od stejného koncového bodu VLM během provozní doby, nečinných venku (I01, I06).

Vzor je takový, že trvalé pracovní zátěže buď pokrývají dostatek časových pásem, aby zaplnily celý den, nebo mají dávkové komponenty, které záměrně vyplňují mezery. Technika „vyplnění mezer“ je největší pákou pro snížení celkových nákladů na vlastnictví, kterou může zákazník použít, a zároveň nejpřehlíženější. Zařízení, které provádí interaktivní chat 12 hodin denně s využitím 30 % a automatické označování běží přes noc s využitím 90 %, dosahuje průměrného využití kolem 60 % – dvojnásobek efektivního využití a poloviční náklady na token.

Burst workloads – kde on-premise škodí

Opačným tvarem je pracovní zátěž, která vyžaduje obrovskou kapacitu pro krátké období a téměř nic po zbytek času. Příklady, které vídáme pravidelně:

• Marketingová kampaň / podpora generování obsahu. Vygenerujte varianty reklamní kampaně napříč N trhy během 48 hodin a pak měsíc nic.
• Momenty virálního obsahu. Spotřebitelská aplikace spustí funkci, objeví se v technologickém newsletteru, návštěvnost se po dobu šesti hodin zvýší 50krát více než obvykle a do následujícího rána se vrátí k výchozímu stavu.
• Demo / pilotní akce. Veletržní stánek, kde tři dny probíhaly živé inferenční ukázky a pak zase nula.
• Periodické dávkové úlohy, které musí být dokončeny v určitém okně. Měsíční kontrola souladu celého dokumentu s předpisy, která musí být dokončena do stanoveného termínu.
• Analýzy volební noci nebo živých událostí — období 12–48 hodin, kdy je objem 100× větší než normální objem.

Zpracovaný příklad. Pracovní zátěž potřebuje vygenerovat 10 milionů tokenů. Rozloženo na 24 hodin to je zhruba 116 tokenů/s celkem – zvládne to jedna L4. V rámci jednoho hodinového okna je to 2 778 tokenů/s – potřebuje 4GPU Pro 6000 běžící na plný výkon, neboli zhruba šest L4.

Takže stejných 10 milionů tokenů vyžaduje buď jednu kartu 24 hodin denně, 7 dní v týdnu, nebo šest karet po dobu jedné hodiny. U burst úloh je místní kapacita nečinná 23 hodiny každých 24 hodin. Matematika celkových nákladů na vlastnictví se hroutí: ta šestikartová krabice s využitím 4 % stojí 13–25 EUR/Mtok, což je ekvivalent výše uvedené tabulky. Průtrž mračen za 1.50 EUR/Mtok obslouží stejnou zátěž celkem za 15 EUR. Bod zvratu se ani zdaleka neblíží.

Nevyhnutelný závěr: Snaha o dimenzování on-premise pro maximální výpadek je nejčastější chybou při nadměrném utrácení, kterou vidíme. Zákazníci chtějí, aby zařízení pokrylo nejhorší možný případ v úterý odpoledne, a proto si koupí 4× více grafických karet, než kolik potřebují v běžném týdnu. Účet přichází ve formě kapitálových výdajů, které nedokážou získat zpět, a 90% nečinné flotily.

Hybridní vzor

Poctivá architektura pro skutečnou produkční zátěž s oběma tvary je on-premise baseline plus cloud burst overflow.

Hybridní směrování: nejdříve on-premise, přetečení cloudu pouze tehdy, když hloubka fronty překročí nakonfigurovanou prahovou hodnotu.

Správná logika směrování je ne „odeslat X % do cloudu, zbytek do lokální infrastruktury.“ Je to tak. Nejprve on-premise, cloud pouze při plné kapacitě on-premiseSignálem je hloubka fronty nebo využití KV-cache na straně vLLM (K03 zahrnuje metriky), nikoli statické rozdělení.

Receptura betonu s vLLM:

1. Předpojte místní cluster s routerem, který zpřístupňuje /v1/chat/completionsFunguje NGINX, HAProxy, router vLLM nebo malá vlastní brána.
2. Odhalit vllm:num_requests_waiting jako měřič hloubky fronty. Prahová hodnota je řekněme 8–16 čekání na repliku, než se aktivuje záložní režim.
3. V případě přetečení směrujte na cloudový koncový bod se stejným názvem modelu. OpenRouter / Together / Fireworks všechny obsluhují modely třídy Llama. Jeden z nich si připněte jako primární a jeden jako záložní, abyste se vyhnuli chybě u jednoho poskytovatele.
4. V observabilitě můžete denně sledovat, z jakého procenta vyplácíte. Pokud je toto procento většinu dní nad 15 %, je vaše on-premise řešení poddimenzované; pokud je po dobu několika týdnů pod 1 %, je on-premise řešení předimenzované.

Ekonomická logika: zaplatit kapitálové výdaje jednou za zátěž, která je vždycky tam, plaťte variabilní cloudové sazby za špičky. Pokud se to provede dobře, efektivní využití místního serveru se zvýší na 50–70 % (ladíte na prahovou hodnotu směrování) a zároveň se zachovají závazky latence ocasu během burstů.

Studený start: realita automatického škálování

Naivní cloudovou odpovědí na burst load je „autoškálování lokálního clusteru“ – udržování replik na nule při nečinnosti a jejich spouštění na vyžádání. To má z jednoho důvodu velký dopad na obsluhu LLM: dobu načítání modelu.

Načítání Llama 70B FP8 (~75 GB hmotnosti) z disku Gen5 NVMe trvá 30–60 sekund čistého I/O při teoretických rychlostech čtení 12–14 GB/s. Přidejte kompilaci jádra CUDA, zahřátí plánovače vLLM, předběžnou alokaci mezipaměti KV a nová replika je připravena přijmout první požadavek. 60–120 sekund po spuštění poduMenší modely pomáhají proporcionálně – 8B se vejde za 5–10 sekund – ale cokoli nad 30B spadá do rozsahu „uživatelé vyprší“.

Pro dávkové úlohy je to v pořádku. Pro interaktivní úlohy je to fatální. Dvouminutová latence u požadavku, který spustil událost škálování, je nepřijatelná.

Zmírnění, seřazené podle úsilí:

• Udržujte N replik vždy v teple. Minimum, které unese vaši průměrnou zátěž. Váha up na požádání, nikdy až na nuluVzor minimálního zahřívání je to, na čem zralí operátoři staví celé své produkty.
• Režim spánku vLLM. Novější verze vLLM podporují stav „spánku“, kdy váhy zůstávají v paměti GPU, ale engine uvolňuje výpočetní prostředky. Probuzení je 18–20× rychlejší než čerstvá várkaUžitečné, když máte více modelů, které sdílejí GPU, ale v danou chvíli běží pouze jeden.
• Předehřátá mezipaměť modelu na sdíleném NVMe / NFS. Váhy se jednou načtou do rychlé lokální mezipaměti, všechny repliky je připojí. První načtení proběhne jednou při spuštění clusteru; další repliky se načtou během několika sekund.
• Plánované škálování podle denní doby. Předběžné škálování v 08:30 s očekáváním provozu v 09:00. Nejjednodušší a nejefektivnější vzorec pro předvídatelné denní úlohy. Nastavení CronJobs. kubectl scale jsou nemoderní, ale fungují.
• Operátor NVIDIA NIM s předpřipravenými enginy TRT-LLM. Enginey sestavené předem, uložené v mezipaměti na disku, načítání na vyžádání. Rychlejší studený start než čerstvá kompilace, ale stále v desítkách sekund pro 70B.

Pro zákaznickou základnu K-AI – malé vozové parky, předvídatelné vzorce používání – je správná odpověď téměř vždy N teplých replik + plánované škálování + přetečení cloud burst. Škálování na nulu je určeno pro bezserverové platformy, kde někdo jiný provádí studený start.

Automatické škálování: Na čem je založeno HPA?

Kubernetes HPA standardně používá metriky CPU a paměti. Oba jsou pro inferenci GPU špatné. Pod vLLM může být na 5 % CPU a 100 % přetížený, nebo na 95 % CPU a fungovat bez problémů. Metrika, kterou skutečně potřebujete, je jedna z:

Správný nástroj pro propojení s Kubernetes je Keda (Kubernetes Event-Driven Autoscaling), který může přímo přijímat dotazy Prometheus a předávat je HPA. Produkční stack vLLM nabízí prvotřídní integraci KEDA a stejný vzorec funguje s KServe na OpenShift AI.

Funkční objekt ScaledObject pro škálování 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ě lekce z produkce, které jsme získali těžkou cestou:

1. cooldownPeriod záleží stejně jako na spouštěči. Hlučná fronta způsobuje hromadné narůstání/zmenšování rozsahu a každé narůstání rozsahu platí za studený start. 5 minut je rozumné minimum.
2. minReplicaCount by měl být dimenzován pro žlab, ne nulový. Dva pody, které jsou v 03:00 nečinné, jsou ty dva pody, které zvládají špičku v 09:00 bez vypršení časového limitu.

Horizontální škálování vs. vertikální škálování

Jemná architektonická volba při dimenzování: kupujete více krabic (horizontální) nebo více grafických karet na krabici (vertikální)?

Pro inferenční úlohy s burstujícím provozem, horizontální téměř vždy vítězí. Dva 4GPU servery mohou běžet jako čtyři repliky s DP=2, snášet zásahy na jednom serveru bez ztráty služby a umožňují škálovat kapacitu po polovinách, nikoli po celých jednotkách. Vertikální řešení je tou správnou volbou pro trénování a pro velmi rozsáhlou inferenci jednoho modelu, kde TP potřebuje GPU v jedné elektrické doméně.

Psychologická past „GPU je nečinná, ale já za ni platím“

Zákazníci, kteří instalaci navštíví poprvé, si často otevřou ovládací panel Grafany, v úterý ve 14:30 uvidí využití GPU na 18 % a ptají se, proč zaplatili za hardware, který 80 % času nic nedělá.

Upřímná odpověď zní, že pro jakoukoli pracovní zátěž citlivou na latenci, Nějaká nečinnost je cena, kterou platíte za odezvu s nízkou latencí. Krabice s trvalým využitím 95 % má frontu. Fronta znamená latenci požadavku. Zákazník, který chce dobu do prvního tokenu 300 ms, nedosáhne na stejné krabičce využití 95 %. Vyberte jednu.

Kompromis, který umět optimalizováno je přesouvání opravených úloh do nečinných oken:

• Dávkové úlohy (automatické označování, extrakce dokumentů, generování vkládání nového obsahu) naplánované přes noc, kdy je chatbot tichý.
• Jemné ladění probíhá o víkendech, kdy nejsou aktivní žádní uživatelé.
• Pravidelné přeindexování vektorových úložišť v časných ranních hodinách.

Toto je disciplína zacházení s lokální krabicí jako s aktivum s dvojím účelemInteraktivní obsluha citlivá na latenci během dne, dávková práce přes noc. Pokud je to dobře provedeno, stejný hardware, který na interaktivním dashboardu vykazuje 25% využití, vykazuje na dashboardu všech úloh 65% využití. Finanční ředitel vidí to druhé.

Co je to ne Řešení: umělé zvyšování frekvence požadavků, aby „vypadalo zaneprázdněně“. Zákazníci to občas zkoušejí. Zhoršuje to latenci chvostu, monitorování je zbytečné a nemění to účet.

Rozhodovací matice

Správnou architekturu určuje spíše tvar pracovní zátěže než objem. Namapujte svou situaci na nejbližší řádek:

Dvě věci, které tato matice zvládá správně, ale ad-hoc plánování se mýlí:

• Čistě burstové úlohy patří do cloudu. Nákup hardwaru pro pracovní zátěž, která běží čtyři hodiny měsíčně, je nedbalost.
• Hybrid „trvalý + výbuch“ téměř vždycky chce obojí. Snažit se vybrat si jedno nebo druhé obvykle vede k chybě.

Upřímný pohled

Většina zákazníků Kentina by měla počítat s 30–50% trvalé využití v on-premise a pro vše nad tím využívat cloudové přetečení. Zákazníci, kteří dosáhnou 60–80% využití on-premise, jsou ti, kteří provozují dávkovou práci vedle interaktivní – automatické označování přes noc, jemné ladění o víkendech, vkládání generování v časných ranních hodinách. Zákazníci, kteří mají využití 10–15 %, jsou ti, kteří počítali s maximálním zatížením.

Nejdražší chybou je nákup řešení pro nejhorší možný případ v úterý odpoledne. Druhou nejdražší je přechod na čistý cloud, když by trvalé zatížení vrátilo kapitálové výdaje za 14 měsíců. Správná odpověď je téměř vždy někde uprostřed: menší on-premise server, než si zákazník původně představil, s možností přetečení cloudu pro případ špičkových výpadků.

Zkontrolujte si to: při cloudových sazbách 0.50 €/Mtok a 4GPU Pro 6000 boxu v ceně 58 000 € za 3 roky se box zaplatí při zhruba 14 miliardách obsloužených tokenů. Rovnoměrně rozložené, což je celkem ~150 tok/s – což je v dosahu boxu při využití 25–35 %. Pod tímto objemem pronajímáte. Nad ním vlastníte. Toto je stejný bod zlomu. T01 a T02 dosah z úhlů na kartu a na žeton.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.