Ekonomika trvalej vs. prudkej inferencie: Kedy vyhrá lokálna platforma a kedy vás zachráni cloud

Inferenčný server so štyrmi GPU spotrebuje rovnakú elektrinu, zaberá rovnaký priestor v racku a odpisuje sa podľa rovnakého harmonogramu, či už obslúži dvadsať miliónov tokenov denne alebo dvadsaťtisíc. Karty nevedia, že sú nečinné. Účtovník áno. Táto jediná asymetria – fixné náklady na strane lokálneho riešenia, marginálne náklady na strane cloudu – je jediným dôvodom, prečo správna odpoveď na otázku „mali by sme prejsť na lokálne riešenie?“ závisí rovnako od formovať vašej návštevnosti podľa objemu.

T01 spracoval matematiku na kartu v jednom bode využitia. T02 mapuje cenu za milión tokenov oproti cloudovým API pri plnom zaťažení. Tento článok (T03) je ten, ktorý by si mal váš finančný riaditeľ skutočne prečítať: čo sa stane s týmito číslami, keď je prevádzka prudko napätá, keď je trvalá a ako navrhnúť systém, ktorý neprekročí rozpočet na žiadnej strane.

Publikum je niekto, kto už dospel k záveru, že pracovná záťaž by mohla byť vhodná pre lokálne prostredie a teraz sa musí rozhodnúť. koľko lokálne a čo zachraňuje zvyšok.

Pasca fixných nákladov

Náklady na cloudovú inferenciu sa škálujú v závislosti od používania. Jeden hovor Llama 70B u poskytovateľa OpenRouter vás stojí približne 0.50 € – 2.00 € za milión tokenov (líši sa v závislosti od úrovne a poskytovateľa). Ak neposielate žiadnu prevádzku, neplatíte nič. Ak posielate 10-násobok prevádzky, plaťte 10-násobok. Vzťah je lineárny a začína na nule.

On-premise inferencia je opačná. Box Blackwell so 4× RTX Pro 6000 (T01 Celkové 3-ročné celkové náklady na vlastníctvo (TCO) sa pohybujú okolo 58 000 EUR – amortizované kapitálové výdavky, elektrina, podiel na šasi, údržba) stoja 58 000 EUR, či už ide o obsluhu jedného milióna tokenov alebo jedného bilióna. Marginálne náklady na 200-miliónty token za mesiac sú rovnaké ako marginálne náklady na druhý token: kWh elektriny potrebnej na jeho výpočet a nič viac. Kapitálové náklady sú utopené náklady v deň odoslania zariadenia.

Účtovné dôsledky sú brutálne a kupujúci ich len zriedka internalizujú:

(Rovnaký hardvér, rovnaké celkové náklady na vlastníctvo 14.4 000 EUR na kartu za tri roky; mení sa iba menovateľ.)

Cloudová sadzba pre Llama 70B FP8 sa v roku 2026 pohybuje v pásme 0.50 € – 1.50 €/Mtok v závislosti od úrovne poskytovateľa. Prečítajte si tabuľku znova s ​​týmto vedomím. Pri 5 % trvalom využití je lokálny box drahší ako každá existujúca cloudová možnosť. Pri 30 % sa vyrovnáva najdrahším poskytovateľom. Pri 60 % a viac sa to vyrovná výpočtom.

Pasca spočíva v tom, že zákazníci porovnávajú kapitálové výdavky s aktuálnym zaťažením a potom o šesť mesiacov neskôr zistia, že aktuálne zaťaženie bolo 8 % z hodnoty zariadenia. Hardvér neurobil nič zlé. Zlé bolo dimenzovanie.

Ako vyzerá skutočné využitie produkcie

Máme verejné údaje a tiež vlastnú databázu o všetkých inštaláciách K-AI, ktoré prevádzkujeme alebo navštevujeme, a obraz je v roku 2026 v celom odvetví konzistentný:

Hlavné čísla z produkčných nasadení a prieskumov operátorov: väčšina tímov si vytvára vlastnú inferenčnú správu Priemerné využitie GPU 20 – 40 %, pričom sa postupne blížia zrelé nastavenia 40-65%Čokoľvek nad 65 % trvalej prevádzky je buď čistá dávková práca, alebo klaster sa prehrieva natoľko, že ďalší nárast prevádzky sa zaradí do radu. Pod 20 % znamená, že zariadenie beží hlavne preto, aby sa zaplatilo, nie aby slúžilo používateľom.

Číslo, ktoré vždy prekvapí kupujúcich: interaktívne pracovné zaťaženie – chatbot, asistent kódovania, bot zákazníckej podpory – takmer nikdy nepresiahne 30 %. Dôvodom je denné svetlo. Dokonca aj globálny produkt má mimopracovnú dobu; regionálny produkt má každý deň 14 hodín nízkeho zaťaženia. Matematika to tvrdo trestá.

Trvalé pracovné zaťaženie – chlieb a maslo

Ekonomika lokálnych systémov funguje čisto pre akúkoľvek pracovnú záťaž, kde môžete nechať grafické karty bežať väčšinu dňa. Zhruba v poradí, ako často ich vidíme na inštaláciách K-AI:

• Asistent kódovania / IDE backend pre tím viac ako 30 inžinierov. Stabilné zaťaženie počas pracovných dní 09:00 – 18:00, ľahšie večery, takmer nulové víkendy. Priemerne 20 – 30 % počas celého týždňa, s maximálnym zaťažením 60 – 80 % počas pracovného dňa.
• Zákaznícka podpora / predajný chatbot s nepretržitou prevádzkou. Denný model sleduje obsluhovaný región; globálne produkty dosahujú 25 – 35 % trvalo udržateľného predaja, regionálne 15 – 25 %.
• Backend RAG / sémantické vyhľadávanie indexovanie a obsluha internej znalostnej bázy. Miera dopytov je mierne stabilná; reindexovanie je plánovaná úloha cez noc, ktorá dosahuje 95 %. Kombinované využitie 30 – 50 %.
• Dávkové spracovanie — nočné sumarizovanie včerajších dokumentov, týždenné automatické označovanie, mesačné opätovné klasifikácie v rámci korpusu. Čistá práca s radom, využitie 70 – 90 %, kým rad nie je prázdny, navrhnuté tak, aby bežalo až do dokončenia.
• Inferencia robotickej flotily — viacero jednotiek odpájajúcich sa z toho istého koncového bodu VLM počas prevádzkovej doby, nečinných vonku (I01, I06).

Vzor je taký, že trvalé pracovné zaťaženia buď pokrývajú dostatok časových pásiem na zaplnenie dňa, alebo majú dávkové komponenty, ktoré zámerne vypĺňajú medzery. Technika „vyplnenia medzier“ je najväčšou pákou na zníženie celkových nákladov na vlastníctvo, ktorú môže zákazník použiť, a zároveň najprehliadanejšou. Krabica, ktorá interaktívne chatuje 12 hodín denne s využitím 30 % a cez noc spúšťa automatické označovanie s využitím 90 %, dosahuje v priemere okolo 60 % – čo je dvojnásobok efektívneho využitia a polovica nákladov na token.

Burst pracovné zaťaženie – kde lokálne riešenia škodia

Opačným tvarom je pracovná záťaž, ktorá vyžaduje obrovskú kapacitu na krátke obdobie a takmer nič po zvyšok času. Príklady, ktoré vidíme pravidelne:

• Marketingová kampaň / podpora generovania obsahu. Vygenerujte varianty reklamnej kampane na N trhoch za 48 hodín a potom mesiac nič.
• Momenty virálneho obsahu. Spotrebiteľská aplikácia spustí funkciu, objaví sa v technologickom newsletteri, návštevnosť sa počas šiestich hodín zvýši 50-krát viac ako v bežnom režime a do nasledujúceho rána sa vráti na pôvodnú úroveň.
• Demo / pilotné podujatia. Stánok na veľtrhu, kde tri dni prebiehali živé inferenčné ukážky a potom sa všetko skončilo na nule.
• Periodické dávkové úlohy, ktoré musia byť dokončené v určitom okne. Mesačná kontrola súladu celého dokumentu s predpismi, ktorá musí byť dokončená do stanoveného termínu.
• Analýzy volebnej noci alebo živých udalostí — obdobie 12 – 48 hodín, v ktorom je objem 100-násobok normálu.

Pracovaný príklad. Pracovná záťaž potrebuje vygenerovať 10 miliónov tokenov. Rozložené na 24 hodín, čo je súhrnne zhruba 116 tokenov/s – zvládne to jedna L4. Zhustené do hodinového okna je to 2 778 tokenov/s – vyžaduje si 4-GPU Pro 6000 bežiaci naplno, alebo zhruba šesť L4.

Takže tých istých 10 miliónov tokenov vyžaduje buď jednu kartu 24 hodín denne, 7 dní v týždni, alebo šesť kariet na jednu hodinu. Pri nadmerných pracovných zaťaženiach je lokálna kapacita nečinná 23 hodiny každých 24 hodín. Matematika celkových nákladov na vlastníctvo sa rúca: tá šesťkartová krabica pri 4 % využití stojí 13 – 25 €/Mtok, čo je ekvivalent vyššie uvedenej tabuľky. Prietrž mračien za 1.50 €/Mtok obslúži rovnakú záťaž za celkovo 15 €. Bod zvratu sa ani zďaleka nepribližuje.

Nevyhnutný záver: Najčastejšou chybou pri nadmernom míňaní, s ktorou sa stretávame, je snaha o dimenzovanie lokálnej siete na maximálny výpadok. Zákazníci chcú, aby zariadenie pokrylo najhorší prípad v utorok popoludní, a preto si kúpia 4× viac grafických kariet, ako potrebujú počas bežného týždňa. Faktúra prichádza vo forme kapitálových výdavkov, ktoré si nedokážu pokryť, a 90 % nečinnej flotily.

Hybridný vzor

Úprimná architektúra pre skutočnú produkčnú záťaž s oboma tvarmi je základná línia lokálneho prostredia plus pretečenie cloudového burst.

Hybridné smerovanie: najprv lokálne, pretečenie cloudu iba vtedy, keď hĺbka frontu prekročí nakonfigurovaný prah.

Správna logika smerovania je nie „odoslať X % do cloudu, zvyšok do lokálnej siete.“ Je to tak najprv lokálne, cloud iba pri plnej kapacite lokálneho prostrediaSignálom je hĺbka frontu alebo využitie KV-cache na strane vLLM (K03 (pokrýva metriky), nie statické rozdelenie.

Recept na betón s vLLM:

1. Vytvorte prednú časť lokálneho klastra pomocou smerovača, ktorý sprístupňuje /v1/chat/completionsNGINX, HAProxy, smerovač vLLM alebo malá vlastná brána fungujú.
2. vystaviť vllm:num_requests_waiting ako ukazovateľ hĺbky frontu. Prahová hodnota je napríklad 8 – 16 čakajúcich na repliku predtým, ako sa spustí záložný režim.
3. Pri pretečení smerujte na cloudový koncový bod s rovnakým názvom modelu. OpenRouter / Together / Fireworks všetky obsluhujú modely triedy Llama. Jeden nastavte ako primárny a jeden ako záložný, aby ste nestratili istotu u jedného poskytovateľa.
4. Označte požiadavky na preplnenie vo vašej pozorovateľnosti, aby ste denne videli, aké percento vyplácate. Ak je väčšinu dní nad 15 %, vaša lokálna platforma je poddimenzovaná; ak je niekoľko týždňov pod 1 %, lokálna platforma je predimenzovaná.

Ekonomická logika: zaplatiť kapitálové výdavky raz za záťaž, ktorá je vždy tam, plaťte variabilné cloudové sadzby za špičky. Ak sa to urobí dobre, efektívne využitie lokálneho zariadenia sa dostane na 50 – 70 % (prah smerovania je to, na čo sa ladí), pričom sa počas burstov zachovajú záväzky týkajúce sa latencie chvosta.

Studený štart: realita automatického škálovania

Naivná cloudová odpoveď na nárazové zaťaženie je „automatické škálovanie lokálneho klastra“ – udržiavanie replik na nule, keď sú nečinné, ich roztočenie na požiadanie. Toto má z jedného dôvodu vážne následky pre LLM služby: čas načítania modelu.

Načítanie Llama 70B FP8 (~75 GB hmotnosti) z disku Gen5 NVMe trvá 30–60 sekúnd čistého I/O pri teoretických rýchlostiach čítania 12–14 GB/s. Pridajte kompiláciu jadra CUDA, zahrievanie plánovača vLLM, predalokáciu vyrovnávacej pamäte KV a nová replika je pripravená prijať prvú požiadavku. 60 – 120 sekúnd po spustení poduMenšie modely pomáhajú proporcionálne – 8B sa zmestí za 5 – 10 sekúnd – ale čokoľvek nad 30B spadá do rozsahu „používatelia prestanú používať“.

Pre dávkové úlohy je to v poriadku. Pre interaktívne úlohy je to fatálne. Dvojminútová latencia požiadavky, ktorá spustila udalosť škálovania, je neprijateľná.

Zmierňujúce opatrenia, zoradené podľa úsilia:

• Udržujte N replík vždy v teple. Minimálna hodnota, ktorá unesie vašu priemernú záťaž. Váha up na požiadanie, nikdy až na nuluVzor minimálneho zahrievania je to, okolo čoho vyspelí operátori stavajú celé produkty.
• Režim spánku vLLM. Novšie verzie vLLM podporujú stav „spánku“, v ktorom váhy zostávajú v pamäti GPU, ale engine uvoľňuje výpočtové prostriedky. Prebudenie je 18–20× rýchlejšie ako čerstvá náplňUžitočné, keď máte viacero modelov, ktoré zdieľajú grafické procesory, ale naraz beží iba jeden.
• Predhriata vyrovnávacia pamäť modelu na zdieľanom NVMe / NFS. Závažia sa načítajú raz do rýchlej lokálnej vyrovnávacej pamäte a všetky repliky ich pripoja. Prvé načítanie sa vykoná raz pri spustení klastra; ďalšie repliky sa načítajú v priebehu niekoľkých sekúnd.
• Plánované škálovanie podľa denného času. Predbežné škálovanie o 08:30 s očakávaním prevádzky o 09:00. Najjednoduchší a najefektívnejší vzorec pre predvídateľné denné pracovné zaťaženia. Nastavenie CronJobs. kubectl scale sú nemoderné, ale fungujú.
• Operátor NVIDIA NIM s predpripravenými enginami TRT-LLM. Enginey vytvorené vopred, uložené do vyrovnávacej pamäte na disku, načítané na požiadanie. Rýchlejší studený štart ako čerstvá kompilácia, ale stále v desiatkach sekúnd pre 70B.

Pre zákaznícku základňu K-AI – malé flotily, predvídateľné vzorce používania – je správna odpoveď takmer vždy N teplých replík + plánované škálovanie + pretečenie cloudového burstu. Škálovanie na nulu je určené pre bezserverové platformy, kde niekto iný preberá úlohu studeného štartu.

Automatické škálovanie: Na čom je založené HPA?

Kubernetes HPA predvolene používa metriky CPU a pamäte. Obe sú nesprávne pre inferenciu GPU. Pod vLLM môže byť na 5 % CPU a 100 % preťažený, alebo na 95 % CPU a funguje bez problémov. Metrika, ktorú v skutočnosti potrebujete, je jedna z:

Správny nástroj na prepojenie tohto s Kubernetes je XNUMXsdjsXNUMXjp-XNUMX (Kubernetes Event-Driven Autoscaling), ktorý dokáže priamo prijímať dotazy Prometheus a posielať ich do HPA. Produkčný stack vLLM poskytuje prvotriednu integráciu KEDA a rovnaký vzorec funguje s KServe na OpenShift AI.

Funkčný objekt ScaledObject na škálovanie hĺbky frontu:

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

Dve výrobné lekcie, ktoré sme získali ťažkým spôsobom:

1. cooldownPeriod záleží rovnako ako spúšť. Hlučný rad spôsobuje hromadné zháňanie pri zväčšovaní/zmenšovaní rozsahu a každé zväčšovanie rozsahu platí za studený štart. 5 minút je rozumné minimum.
2. minReplicaCount by mala byť dimenzovaná pre žľab, nie nulová. Dva pody nečinné o 03:00 sú tie dva pody, ktoré zvládajú špičku o 09:00 bez uplynutia časového limitu.

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

Jemná architektonická voľba pri dimenzovaní: kupujete viac krabíc (horizontálne) alebo viac grafických kariet na krabici (vertikálne)?

Pre inferenčné pracovné zaťaženia s pulznou prevádzkou, horizontálne takmer vždy vyhráva. Dva boxy so 4 GPU môžu bežať ako štyri repliky DP=2, zvládnuť zásah na jednom boxe bez straty služby a umožniť vám škálovať kapacitu po polovicach namiesto celých jednotiek. Vertikálna konštrukcia je správna voľba pre trénovanie a pre veľmi rozsiahlu inferenciu jedného modelu, kde TP potrebuje GPU v jednej elektrickej doméne.

Psychologická pasca „GPU je nečinný, ale ja za to platím“

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

Úprimná odpoveď je, že pre akúkoľvek pracovnú záťaž citlivú na latenciu, Určitá nečinnosť je cena, ktorú platíte za odozvu s nízkou latenciou. Krabica s 95 % trvalým využitím má front. Front znamená latenciu požiadavky. Zákazník, ktorý chce čas do prvého tokenu 300 ms, nedosiahne na tej istej krabici aj 95 % využitie. Vyberte si jednu.

Kompromis, ktorý môcť byť optimalizovaný je presunutie opravenej práce do nečinných okien:

• Dávkové úlohy (automatické označovanie, extrakcia dokumentov, generovanie vkladania nového obsahu) naplánované na noc, keď je chatbot tichý.
• Jemné ladenie prebieha cez víkendy, keď nie sú žiadni používatelia.
• Pravidelné opätovné indexovanie vektorových úložísk počas skorých ranných hodín.

Toto je disciplína zaobchádzania s lokálnym zariadením ako s aktívum s dvojitým účelomInteraktívne poskytovanie služieb citlivých na latenciu počas dňa, dávková práca cez noc. Pri dobrej práci ten istý hardvér, ktorý vykazuje 25 % využitie na interaktívnom paneli, vykazuje 65 % využitie na paneli všetkých úloh. Finančný riaditeľ vidí to druhé.

Čo je nie Riešenie: umelé zvyšovanie miery požiadaviek, aby „vyzeralo zaneprázdnene“. Zákazníci to občas skúšajú. Zhoršuje to latenciu chvosta, monitorovanie je zbytočné a nemení to účet.

Rozhodovacia matica

Správnu architektúru určuje skôr tvar pracovnej záťaže než objem. Namapujte svoju situáciu na najbližší riadok:

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

• Čisté burstové pracovné zaťaženia patria do cloudu. Kúpa hardvéru pre pracovnú záťaž, ktorá beží štyri hodiny mesačne, je nedbalá činnosť.
• Hybrid „trvalý + výbuch“ takmer vždy chce oboje. Snaha vybrať si jedno alebo druhé zvyčajne vedie k nesprávnemu výberu.

Úprimný pohľad

Väčšina zákazníkov spoločnosti Kentino by mala počítať s 30 – 50 % trvalé využitie v lokálnej sieti a na všetko nad to využívať cloudové preplnenie. Zákazníci, ktorí dosiahnu 60 – 80 % využitie lokálnej siete, sú tí, ktorí prevádzkujú dávkovú prácu popri interaktívnej – automatické označovanie cez noc, dolaďovanie cez víkendy, vkladanie generovania v skorých ranných hodinách. Zákazníci, ktorí majú využitie 10 – 15 %, sú tí, ktorí počítali s maximálnou záťažou.

Najdrahšou chybou je nákup pre najhorší možný utorok popoludní. Druhou najdrahšou je prechod na čistý cloud, keď by trvalé zaťaženie vrátilo kapitálové výdavky za 14 mesiacov. Správna odpoveď je takmer vždy niekde uprostred: menšia lokálna boxová platforma, než akú zákazník pôvodne špecifikoval, s cestou pretečenia cloudu pre prípad špičiek.

Porovnajte si to s výpočtami: pri cloudových sadzbách 0.50 €/Mtok a cene 4-GPU Pro 6000 boxu 58 000 € za 3 roky sa box zaplatí pri približne 14 miliardách tokenov. Rovnomerne rozložené, čo predstavuje celkovo ~150 tokov/s – čo je v dosahu boxu pri využití 25 – 35 %. Pod týmto objemom si prenajímajte. Nad ním vlastnite. Toto je rovnaký bod zlomu. T01 a T02 dosah z uhlov pohľadu na kartu a žetón.

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.