Vedvarende vs. burst-inferensøkonomi: Når on-prem vinder, når cloud redder dig

En inferensserver med fire GPU'er bruger den samme strøm, optager den samme rackplads og afskrives efter samme tidsplan, uanset om den betjener tyve millioner tokens om dagen eller tyve tusind. Kortene ved ikke, at de er inaktive. Det gør revisoren. Denne ene asymmetri - faste omkostninger på on-prem-siden, marginale omkostninger på cloud-siden - er hele årsagen til, at det rigtige svar på "skal vi gå on-prem?" afhænger lige så meget af formen på din trafik som af volumen.

T01 beregnede per kort-beregningen på et enkelt udnyttelsespunkt. T02 kortlægger omkostningerne per million tokens mod cloud-API'er ved fuld belastning. Denne artikel (T03) er den, din CFO rent faktisk har brug for at læse: hvad sker der med disse tal, når trafikken er høj, når den er vedvarende, og hvordan man strukturerer et system, der ikke bruger for meget på nogen af ​​siderne.

Målgruppen er en person, der allerede har konkluderet, at arbejdsbyrden måske passer til on-prem, og som nu skal beslutte, hvor meget on-prem, og hvad der redder resten.

Fastomkostningsfælden

Cloud-inferens skalerer omkostninger med brugen. Et enkelt Llama 70B-kald på en OpenRouter-udbyder koster dig cirka €0.50-€2.00 pr. million tokens (varierer efter niveau og udbyder). Send ingen trafik, betal ingenting. Send 10 gange trafikken, betal 10 gange. Forholdet er lineært og starter ved nul.

On-prem-inferens er det modsatte. En 4× RTX Pro 6000 Blackwell-boks ( T01 sætter den 3-årige samlede ejeromkostninger (TCO) omkring €58 alt-in - amortiseret anlægsudgifter, elektricitet, chassisandel, vedligeholdelse) koster de €58, uanset om den betjener en million tokens eller en billion. Den marginale omkostning for den 200 millioner token på en måned er den samme som den marginale omkostning for den anden: den kWh elektricitet, det tog at beregne den, og intet mere. Anlægsudgifter er en irreversibel omkostning den dag, boksen sendes.

Den regnskabsmæssige konsekvens er brutal og internaliseres sjældent af købere:

(Samme hardware, samme samlede ejeromkostninger på €14.4 pr. kort over tre år; kun nævneren ændres.)

Cloud-prisen for Llama 70B FP8 i 2026 ligger i intervallet €0.50-€1.50/Mtok afhængigt af udbyderniveau. Læs tabellen igen med det i tankerne. Ved 5% vedvarende udnyttelse er on-prem-boksen dyrere end alle eksisterende cloud-muligheder. Ved 30% er den på niveau med de dyreste udbydere. Ved 60%+ går den derfra med regnestykket.

Fælden er, at kunderne sammenligner capex med den nuværende belastning, og derefter seks måneder senere opdager, at den nuværende belastning var 8% af kassen. Hardwaren gjorde ikke noget forkert. Dimensioneringen gjorde.

Hvordan den reelle produktionsudnyttelse ser ud

Vi har offentlige data plus vores egen testplatform på tværs af de Kentino AI-installationer, vi driver eller besøger, og billedet er ensartet på tværs af branchen i 2026:

De vigtigste tal fra produktionsimplementeringer og operatørundersøgelser: De fleste teams, der kører deres egen inferens, rapporterer en gennemsnitlig GPU-udnyttelse på 20-40% , mens modne opsætninger sniger sig mod 40-65% . Alt over 65% vedvarende er enten rent batcharbejde eller en klynge, der kører varmt nok til, at den næste trafikstigning vil sætte sig i kø. Under 20% betyder, at boksen primært kører for at betale for sig selv, ikke for at betjene brugerne.

Det tal, der altid overrasker købere: en interaktiv arbejdsbyrde – en chatbot, en kodeassistent, en kundesupportbot – opretholder næsten aldrig mere end 30%. Årsagen er dagslys. Selv et globalt produkt har off-time; et regionalt produkt har 14 timers lav belastning hver dag. Matematikken straffer det hårdt.

Vedvarende arbejdsbyrder — det grundlæggende

On-prem-økonomien fungerer problemfrit for enhver arbejdsbelastning, hvor du kan holde GPU'erne kørende det meste af dagen. I nogenlunde rækkefølge efter hvor ofte vi ser dem på Kentino AI-installationer:

• Kodningsassistent / IDE-backend For et team på over 30 ingeniører. Stabil belastning på hverdage 09:00-18:00, lettere aftener, næsten ingen weekender. Gennemsnit 20-30% i løbet af ugen, med et højdepunkt på 60-80% i løbet af arbejdsdagen.
• Kundesupport / salgschatbot med trafik døgnet rundt. Det daglige mønster følger den betjente region; globale produkter lander 25-35% vedvarende, regionale 15-25%.
• RAG / semantisk søgebackend indeksering og betjening af en intern vidensbase. Forespørgselsraten er moderat stabil; reindeksering er et planlagt job natten over, der placerer feltet på 95 %. Kombineret udnyttelsesgrad 30-50 %.
• Batchbehandling — natten over opsummering af gårsdagens dokumenter, ugentlige automatiske mærkningskørsel, månedlige genkørsler af klassificering over et korpus. Rent køarbejde, 70-90% udnyttelse, mens køen ikke er tom, designet til at køre til færdiggørelse.
• Inferens i robotflåden — flere enheder, der kører fra det samme VLM-endepunkt i driftstimerne, tomgang udenfor (I01, I06).

Mønsteret er, at vedvarende arbejdsbyrder enten strækker sig over tilstrækkeligt mange tidszoner til at fylde dagen, eller også har batchkomponenter, der bevidst udfylder hullerne. "Udfyld hullerne"-teknikken er den største TCO-greb, en kunde kan trække i, og den mest oversete. En boks, der kører interaktiv chat 12 timer om dagen ved 30 % og kører automatisk mærkning natten over ved 90 %, giver i gennemsnit omkring 60 % - dobbelt så effektiv udnyttelse, halvdelen af ​​omkostningerne pr. token.

Burst-arbejdsbelastninger – hvor on-prem-arbejde gør ondt

Den modsatte form er en arbejdsbyrde, der kræver enorm kapacitet i et kort vindue og næsten ingenting resten af ​​tiden. Eksempler vi ser regelmæssigt:

• Marketingkampagne / indholdsgenerering. Generer varianter til en annoncekampagne på tværs af N-markeder på 48 timer, og derefter ingenting i en måned.
• Øjeblikke med viralt indhold. En forbrugerapp lancerer en funktion, bliver vist i et tech-nyhedsbrev, får 50 gange så mange trafik som normalt i seks timer og er tilbage til udgangspunktet næste morgen.
• Demo-/pilotarrangementer. En messestand, der kører live inferensdemonstrationer i tre dage, derefter tilbage til nul.
• Periodiske batchjob, der skal afsluttes i et vindue. Månedlig compliance-scanning af et helt dokumentkorpus, der skal være færdig inden en lovpligtig deadline.
• Analyse af valgaftenen eller livebegivenheder — et vindue på 12-48 timer, hvor volumenet er 100 gange normalt.

Eksempel på en arbejdsbelastning. En arbejdsbyrde kræver 10 millioner genererede tokens. Fordelt over 24 timer er det cirka 116 tok/s samlet set - et enkelt L4 håndterer det. Komprimeret til et vindue på en time er det 2,778 tok/s - det kræver en 4-GPU Pro 6000-boks, der kører på fuld belastning, eller cirka seks L4'er.

Så de samme 10 millioner tokens kræver enten ét kort døgnet rundt eller seks kort i én time. Ved burst-arbejdsbelastninger står on-prem-kapaciteten inaktiv 23 ud af hver 24 timer. Beregningen af ​​de samlede ejeromkostninger kollapser: den seks-korts boks ved 4% udnyttelse koster €13-25/Mtok, hvilket svarer til tabellen ovenfor. Et cloud burst til €1.50/Mtok tjener den samme belastning for €15 i alt. Nulpunktet er ikke engang tæt på.

Den uundgåelige konklusion: at forsøge at dimensionere on-prem til peak burst er den mest almindelige fejl, vi ser, når vi overforbruger. Kunderne ønsker, at pakken skal dække den værst tænkelige tirsdag eftermiddag, og derfor køber de 4 gange så mange GPU'er, de har brug for, på en normal uge. Regningen kommer i form af capex, de ikke kan dække, og en 90% inaktiv flåde.

Hybridmønsteret

Den ærlige arkitektur til en reel produktionsarbejdsbyrde med begge former er on-prem baseline plus cloud burst overflow.

Hybrid routing: først on-prem, kun cloud-overflow, når kødybden overstiger den konfigurerede tærskel.

Den rigtige routinglogik er ikke "send X% til skyen, resten til on-prem". Det er on-prem først, kun skyen, når on-prem har fuld kapacitet . Signalet er kødybde eller KV-cache-udnyttelse på vLLM-siden ( K03 dækker metrikkene), ikke en statisk opdeling.

Konkret opskrift med vLLM:

1. Frontér den lokale klynge med en router, der eksponerer /v1/chat/completionsNGINX, HAProxy, vLLM-routeren eller en lille, brugerdefineret gateway fungerer alle.
2. Udsætte vllm:num_requests_waiting som en kødybdemåler. Tærsklen er f.eks. 8-16 ventetider pr. replika, før reservefunktionen træder i kraft.
3. Ved overløb, rute til et cloud-slutpunkt med samme modelnavn. OpenRouter / Together / Fireworks betjener alle Llama-klassemodeller. Fastgør én som primær og én som backup, så du ikke ender med kun én udbyder.
4. Tag overflow-anmodninger i din observerbarhed, så du dagligt kan se, hvor stor en procentdel du udbetaler. Hvis den er over 15 % de fleste dage, er din on-prem-konto underdimensioneret; hvis den er under 1 % i ugevis, er on-prem-kontoen overdimensioneret.

Den økonomiske logik: betal capex én gang for den belastning, der altid er der , betal variable cloud-rater for pigge. Hvis det gøres godt, får dette en effektiv udnyttelse af on-prem-boksen op på 50-70% (routing-tærsklen er det, du justerer efter), samtidig med at haleforsinkelsesforpligtelserne holdes intakte under bursts.

Koldstart: den autoskalerende virkelighed

Det naive cloud-lignende svar på bursty load er "autoscale the on-prem cluster" - hold replikaer på nul, når de er inaktive, og start op efter behov. Dette fungerer dårligt for LLM-visning af én grund: modellens indlæsningstid.

Indlæsning af Llama 70B FP8 (~75 GB vægte) fra et Gen5 NVMe-drev tager 30-60 sekunder ren I/O ved teoretiske læsehastigheder på 12-14 GB/s. Tilføj CUDA-kernekompilering, vLLM-scheduleropvarmning og KV-cache-forallokering, og en frisk replika er klar til at tage sin første anmodning 60-120 sekunder efter, at poden starter . Mindre modeller hjælper proportionalt - en 8B passer på 5-10 sekunder - men alt nord for 30B er i "brugerne vil få timeout"-området.

For batch-arbejdsbelastninger er dette fint. For interaktive arbejdsbelastninger er det fatalt. To minutters latenstid på den anmodning, der udløste opskaleringshændelsen, er uacceptabelt.

Afhjælpningsforanstaltningerne, i rækkefølge efter indsats:

• Hold N-replikaer altid varme. Minimumsvægten, der kan holde til din gennemsnitlige belastning. up på forespørgsel, aldrig ned til nulMinimum-varme-mønsteret er det, som modne operatører bygger hele produkter omkring.
• vLLM dvaletilstand. Nyere vLLM-versioner understøtter en "dvaletilstand", hvor vægte forbliver i GPU-hukommelsen, men motoren frigiver beregningsressourcer. Opvågning er 18–20 gange hurtigere end en frisk læsningNyttigt, når du har flere modeller, der deler GPU'er, men kun én kører ad gangen.
• Forvarmet modelcache på delt NVMe/NFS. Træk vægte én gang til en hurtig lokal cache, alle replikaer monterer den. Første indlæsning sker én gang ved klyngestart; efterfølgende replikaer dukker op i løbet af sekunder.
• Planlagt skalering på dagen. Forudskalér op kl. 08:30 i forventning om trafik kl. 09:00. Det enkleste og mest effektive mønster for forudsigelige daglige arbejdsbyrder. CronJobs-indstilling kubectl scale er umoderne, men de virker.
• NVIDIA NIM-operatør med præbyggede TRT-LLM-motorer. Motorer bygget på forhånd, cachelagret på disk, indlæst efter behov. Hurtigere koldstart end frisk kompilering, men stadig på få sekunder for 70B.

For Kentinos AI-kundebase – små flåder, forudsigelige brugsmønstre – er det rigtige svar næsten altid N varme replikaer + planlagt skalering + cloud burst overflow. Skalering til nul er til serverløse platforme, hvor en anden tager sig af koldstarten.

Autoskalering: HPA baseret på hvad?

Kubernetes HPA bruger som standard CPU- og hukommelsesmålinger. Begge dele er forkert til GPU-inferens. En vLLM-pod kan have 5% CPU og 100% overbelastet, eller 95% CPU og fungere fint. Den måling, du rent faktisk har brug for, er en af:

Det rette værktøj til at integrere dette i Kubernetes er KEDA (Kubernetes Event-Driven Autoscaling), som kan forbruge Prometheus-forespørgsler direkte og sende dem til en HPA. vLLM-produktionsstakken leverer førsteklasses KEDA-integration, og det samme mønster fungerer med KServe på OpenShift AI.

Et fungerende ScaledObject til skalering af kødybde:

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

To produktionslektioner, vi har samlet på den hårde måde:

1. cooldownPeriod betyder lige så meget som udløseren. En støjende kø forårsager hektisk opskalering/nedskalering, og hver opskalering betaler en koldstart. 5 minutter er et fornuftigt minimum.
2. minReplicaCount bør dimensioneres til truget, ikke nul. De to pods, der er inaktive klokken 03:00, er de to pods, der håndterer 09:00-stigningen uden timeout.

Skalér vandret vs. skalér lodret

Et diskret arkitektonisk valg ved dimensionering: køber du flere kasser (vandret) eller flere GPU'er pr. kasse (vertikal)?

For inferensbelastninger med bursty-trafik vinder horisontal næsten altid. To 4-GPU-bokse kan køre som fire DP=2-replikaer, tage et hit på én boks uden at miste service og lade dig skalere kapaciteten i halve i stedet for hele enheder. Vertikal er det rette valg til træning og til meget stor enkeltmodel-inferens, hvor TP har brug for GPU'erne i ét elektrisk domæne.

Den psykologiske fælde "GPU'en er inaktiv, men jeg betaler for den"

Kunder, der besøger installationen for første gang, åbner ofte Grafana-dashboardet, ser en GPU-udnyttelse på 18 % klokken 14:30 om tirsdagen og spørger, hvorfor de har betalt for hardware, der ikke gør noget 80 % af tiden.

Det ærlige svar er, at for enhver latenstidsfølsom arbejdsbelastning er en vis inaktivitet prisen, du betaler for en respons med lav hale-latens. En boks med 95% vedvarende udnyttelse har en kø. En kø betyder anmodningslatenstid. Kunden, der ønsker 300 ms tid-til-første-token, får ikke også 95% udnyttelse på den samme boks. Vælg én.

Den afvejning, der kan optimeres, er at flytte fast arbejde til inaktive vinduer :

• Batchjob (automatisk etikettering, dokumentudtrækning, generering af integreret indhold til nyt indhold) planlagt natten over, når chatbotten er stille.
• Finjusteringen kører i weekenderne, når der ikke er nogen brugere på.
• Periodisk reindeksering af vektorlagre i de tidlige morgentimer.

Dette er disciplinen med at behandle den lokale boks som et aktiv med dobbelt formål : latenstidsfølsom interaktiv servering om dagen, batcharbejde natten over. Når det gøres godt, viser den samme hardware, der viser en udnyttelsesgrad på 25 % på det interaktive dashboard, 65 % udnyttelsesgrad på dashboardet for alle arbejdsbelastninger. CFO'en ser sidstnævnte.

Hvad der ikke er en løsning: kunstigt at øge anmodningsraten, så den "ser travl ud". Kunder prøver af og til dette. Det forværrer haleforsinkelsen, gør overvågningen ubrugelig og ændrer ikke regningen.

Beslutningsmatricen

Arbejdsbyrdens form, mere end volumen, dikterer den rigtige arkitektur. Kortlæg din situation til den nærmeste række:

To ting denne matrix gør rigtigt, som ad hoc-planlægning gør forkert:

• Rene burst-arbejdsbelastninger hører hjemme i skyen. Det er uregelmæssigheder at købe hardware til en arbejdsbyrde, der kører fire timer om måneden.
• "Vedvarende + eksplosiv"-hybriden ønsker næsten altid begge dele. At forsøge at vælge det ene eller det andet vælger som regel forkert.

Den ærlige holdning

De fleste Kentino-kunder bør planlægge med en vedvarende udnyttelse på 30-50 % on-prem og bruge cloud overflow til alt derover. De kunder, der når en on-prem udnyttelse på 60-80 %, er dem, der kører batcharbejde sideløbende med interaktive løsninger – automatisk etikettering natten over, finjustering i weekenderne, integration af generering i de små timer. De kunder, der ligger på en udnyttelse på 10-15 %, er dem, der har forudset spidsbelastning.

Den dyreste fejltagelse er at købe til den værst tænkelige situation tirsdag eftermiddag. Den næstdyreste er at gå over til ren cloud, når vedvarende belastning ville tjene capex tilbage på 14 måneder. Det rigtige svar er næsten altid midt imellem: en mindre on-prem boks end kunden oprindeligt specificerede, med en cloud overflow-sti for pigge.

Krydstjek regnestykket: med en cloud-pris på €0.50/Mtok og en 4-GPU Pro 6000-boks, der koster €58 over 3 år, tjener boksen sig selv hjem med cirka 14 milliarder serverede tokens. Jævnt fordelt, hvilket er ~150 tok/s samlet set vedvarende - godt inden for rækkevidde af boksen ved 25-35% udnyttelse. Under denne volumen, leje. Over, eje. Dette er det samme break-even-punkt, som T01 og T02 når fra både per-kort og per-token vinklerne.

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.