CFO’en er vågen nu. VentureBeat rapporterer, at Gartner estimerer 401 mia. USD i ny AI‑infrastrukturspending i år, og samtidig viser audits og en Cast AI‑rapport, at den gennemsnitlige GPU‑udnyttelse ligger omkring 5 procent. Det regnestykke er svært at forsvare på direktionsgangen, selv om scramble‑fasen gav mening dengang. Vi har set de dashboards. Nogle blinker rødt uden, at noget egentlig kører.
En stor del af kapaciteten blev købt eller reserveret under et narrativ om knaphed, og mange organisationer bandt sig til tre‑fem års afskrivninger. Ifølge VentureBeat er de GPU’er nu faste omkostninger uanset brug. Spørgsmålet er ikke længere, om investeringen var smart, men hvordan den skaber output i kroner og kunder.
Hvad viser tallene
VentureBeat skriver, med henvisning til Gartner, at AI‑infrastruktur lægger 401 mia. USD oven på årets udgifter. Samme artikel peger på, at faktiske audits i virksomheder lander GPU‑udnyttelsen omkring 5 procent. Cast AI, refereret hos Dataconomy, går skridtet videre og siger, at virksomheder i praksis køber cirka tyve gange mere GPU‑kapacitet end nødvendigt. De nævner også, at CPU‑udnyttelse er faldet fra 10 til 8 procent og memory fra 23 til 20, mens overprovisionering stiger.
Vi har dobbeltjekket, hvor tallene kommer fra. VentureBeat citerer Gartner for beløbet, men uden at vi her kan se Gartners fulde note. Cast AI’s fund er præsenteret via en mediedækning, og metoden er ikke fuldt gennemlyst i den offentlige opsummering. Alligevel er pejlemærket konsistent: lav udnyttelse, høj CapEx og stigende pres for at få inferensøkonomien til at hænge sammen.
Hvor kommer 5 procent fra — metodologi og plausibilitet
Her bliver vi lidt nørdede. Cast AI analyserer typisk kunders cloud‑infrastruktur og kan derfor måle reelle udnyttelsesgrader på tværs af klynger. Men vi mangler stadig fuld gennemsigtighed i definitionerne: er 5 procent gennemsnitlig SM‑load, aktiv inferenstid, VRAM‑tryk eller noget fjerde? Det betyder noget, især for workloads med burst og købetjening.
VentureBeat refererer “real‑world audits” og forbinder det med den samme lave udnyttelse. Det er plausibelt. Vi ser lignende mønstre hos større kunder: test‑ og dev‑trafik ligger og pumper på produktionsklynger, mens produktionslasten er ujævn. Konklusionen er ikke en dom over alle, men et signal: der er systemisk spild, og det kan angribes.
Hvorfor det skete: GPU‑scramble og regnskabskonsekvenser
Frygten for ikke at få fat i H100‑klasserne var reel. Aftaler blev indgået hurtigt, ofte bundet op på tre‑fem års afskrivning og reserveret kapacitet hos hyperscalere. VentureBeat beskriver, hvordan de valg i praksis gjorde GPU’er til faste omkostninger uanset udnyttelse. Set fra CFO‑stolen er det en mursten i budgettet.
I samme periode løb arkitekturen bagefter. Data gravity, governance, sikkerhedsgodkendelser. Alt det, der ikke trender på X, men fylder i hverdagen. Resultatet blev activity‑rich, output‑poor: man købte kapacitet, fordi alle andre også købte — ikke fordi enhedsøkonomien var bevist.
Hvad det betyder i praksis for drift og arkitektur
Første konsekvens er styring af omkostninger. CFO og CTO sidder tættere, og “cost per inference” bliver en KPI, ikke en fodnote. Vi har set møder, hvor en simpel graf over tokens per dollar fik hele roadmap’et til at skifte retning på 40 minutter. Brutalt, men befriende: tal i stedet for slogans.
Anden konsekvens rammer MLOps og orkestrering. Når priserne flytter sig til ren forbrug, bliver autoscaling, køstyring og model‑registries med cost‑metrics kritisk infrastruktur. Hvis køer ikke styres, forsvinder gevinsten ved batching. Uden observabilitet flytter workloads sig ikke fra GPU til CPU, selv når det kan lade sig gøre.
Tredje konsekvens er arkitekturvalg. Hybride set‑ups (on‑prem, cloud og specialiserede inferens‑tjenester) betyder mere kompleks routing, dataresidency og latency‑styring. Compliance spiller ind. I finans kan man ikke altid flytte til en eksperimentel engine, selv om den er 20 procent hurtigere. Ændringen skal dokumenteres, og det tager tid.
Fire praktiske tiltag der virker
Rightsizing og workload‑kortlægning. Start kedeligt: hvem bruger hvad, hvornår. Vi laver ofte et to ugers audit, hvor vi adskiller dev, CI og produktion og kortlægger per‑model cost pr. 1.000 tokens. Det alene kan fjerne en stor del af spildet, fordi testtrafik flyttes væk fra dyre klynger, og natlige peaks får egen kø.
Opgrader MLOps. Konkret: bedre monitoring (per‑model TPM\/TPS og GPU‑udnyttelse), autoscaling på inferens og køer, der kan batche uden at sprænge SLO’er. Det er ikke gratis. Men selv moderate forbedringer i udnyttelse kan ændre TCO markant, fordi GPU‑timer er dyre dollars, mens CPU‑spild er småpenge.
Modeloptimering. Kvantisering, distillation og mere aggressiv batching. Ja, kvalitet og driftssikkerhed skal testes. Men i flere tilfælde kan man køre mellemtunge modeller på CPU eller alternative accelerators til visse ikke‑kritiske paths, uden at brugeren mærker det. Det kræver disciplin i CI\/CD, ellers glider man tilbage.
Kontrakter og afskrivning. Her bliver økonomi praktisk. Leasing, kortere bindinger og burstable aftaler kan gøre underværker. Ikke alt kan ændres overnight, men mange får frigjort handlemuligheder ved at genforhandle én kritisk reservation eller flytte en del trafik til pay‑per‑use inferens, så man undgår at købe mere on‑prem for at dække sjældne peaks.
Teknisk spotlight: Token
Speed og inferenseffektivitet
Der rører sig også noget på software‑siden. LightSeek Foundation har frigivet TokenSpeed som open source under MIT‑licens, målrettet agentiske workloads og med et mål om TensorRT‑LLM‑lignende effektivitet, ifølge MarkTechPost. Det er i preview og uden uafhængige benchmarks, så tag det roligt. Men ideen er interessant: at balancere per‑GPU TPM og per‑bruger TPS via bedre scheduler, parallelisme og hukommelsesstyring.
Hvis sådanne motorer virker i praksis, kan de flytte regnestykket. Højere TPM på samme kort betyder lavere cost per inference, alt andet lige. Forbeholdet står ved magt: uden tredjepartsmålinger og driftstestede integrationsmønstre er det for tidligt at love noget. Vi følger med og har en testplan liggende i backloggen, bogstaveligt talt med kaffepletter på.
Snillds erfaringer fra feltet
I foråret sad vi i et koldt mødelokale i Ballerup. En finanskunde havde 24 GPU’er i produktion, men grafen viste tynd trafik. Vi kørte en to dages workshop, isolerede dev\/CI fra prod og indførte simpel kølogik med batching på de langsomme aftenforespørgsler. På 10 dage rykkede de fra næsten konstant idle til noget, der lignede fornuftig udnyttelse.
I en anden case flyttede vi en dokumentklassifikationsmodel til kvantiseret CPU‑inferens. Halverede GPU‑timerne uden, at supporten meldte flere sager. Implementeringen tog seks uger, og vi skulle ændre CI\/CD‑pipelines, fordi testcontainers ellers trak GPU’er ind igen. Det overraskede os, hvor meget organisatorisk friktion der var — ikke teknisk. Hvem “ejede” retten til at sænke latency med 40 millisekunder mod at spare penge. Små ting. Store diskussioner.
Modargumenter og risici
Nogle vil sige, at 5 procent overdriver problemet. At udvalget i rapporterne skævvrider billedet mod bestemte brancher eller en cloud‑tung profil. Det kan være rigtigt. Vi har også set H200‑klynger køre solidt over 30 procent i visse teams, som Dataconomy‑dækningen også nævner som modeksempel. Pointen her er ikke talmagi, men retning.
Andre vil pege på fremtidige workloads. At man har brug for “luft” i kapaciteten, fordi nye produkter kan lande hårdt. Fair. Men “luft” måles bedst som veldefinerede burst‑aftaler og køparametre, ikke som konstant tomgang. Og så er der sikkerhed og compliance: en hurtig flytning til en ny inferens‑engine kan koste dyrt, hvis dokumentationen ikke følger med.
Anbefalinger og næste skridt for beslutningstagere
Start med et audit. Ikke et 200 siders slide‑dæk, men en fire ugers gennemgang med tre outputs: per‑model cost per 1.000 tokens, udnyttelsesgrad per klynge og en liste over flytbare workloads. Sørg for, at dev\/CI måles separat. Den forveksling skaber halv panik og halvt selvbedrag i mange dashboards.
Kør en pilot. Vælg én model, én pipeline og gennemfør tre ting: kvantisering eller distillation, enable batching\/køstyring og test CPU eller alternativ accelerator som fallback. Mål latency og brugerklager, ikke kun tokens per krone. Hvis piloten virker, har I et mønster, der kan skaleres.
Indfør governance. Fælles sprog mellem finans og it om afskrivning, leasing og burst. Sæt tærskler: hvornår må et team få nye GPU’er, og hvornår skal de optimere eksisterende. Og vigtigst: gør “cost per inference” synlig i model‑registry og i weekly reviews. Det ændrer adfærd — mere end en plakat om “effektivitet”.
Hvad konkurrenterne vil sige og hvad der mangler
Markedet vil nu blive fyldt med værktøjer, der lover 50 procent besparelse på tre uger. Nogle holder, mange gør ikke. Den store forskel ligger i integrationen med jeres eksisterende data‑ og deploy‑stak. Det er dér, tiden går tabt — ikke i et enkelt flag til en ny runtime.
Vi efterlyser stadig bedre data. Cast AI’s metode bør belyses mere: hvordan defineres “utilization”, hvordan er sektorer fordelt, og hvor meget er on‑prem versus cloud. Og vi vil gerne se Gartners fulde opdeling bag 401 mia. USD: er det CapEx plus OpEx globalt, og hvilke kategorier tæller med. Indtil da arbejder vi med de bedste pejlemærker og holder kæden stram på usikkerhederne.
Hvad det betyder for jeres hverdag
Projektprioritering skifter. Uden en klar inferensøkonomi vil flere AI‑projekter blive sat på pause eller skaleret ned. Drift får mere telemetry at passe: per‑model TPM\/TPS, kø‑latency og alarmer for fald i udnyttelse. Support‑SLA’er bliver mere konkrete, for man kan ikke batche aggressivt uden at forklare brugeroplevelsen — helst med data.
Implementering er håndværk. Rightsizing tager tid, og det er OK. Seks uger for at kvantisere, teste og ændre CI\/CD er ikke spild, hvis det bagefter frigør GPU‑timer løbende. Governance er kultur, ikke kun et Excel‑ark. Når CFO og CTO taler samme sprog, falder tempoet i nye GPU‑indkøb naturligt. Ikke som forbud, men som fornuft.
Afslutning
Hvis udnyttelsen er 5 procent, forsvinder 95 ud af 100 kroner i praksis som stilstand. Det er firkantet, men nyttigt. Tre skridt gør forskellen: audit, pilot, governance. Sælge kortene er sjældent løsningen; at få dem til at arbejde er.
