Når GPU'er ser ledige ud, men jobene står i kø
Et tal går igen i driftsnoter: cirka 5 procent gennemsnitlig GPU compute-utilisation på tværs af produktionsklynger. Cast AI, via ArtificialIntelligence-News, peger på den observation i 2026-målinger. Brug det som research-hook. Ikke som bevis for, at køer og lavt forbrug skete samtidig i de samme miljøer, eller at 95 procent kan hentes i morgen. Pointen er smallere og mere nyttig: compute-procenten måler aktivitet, ikke tilgængelighed.
De fleste dashboards viser compute-aktivitet på streaming multiprocessors (SM). Ifølge gennemgangen hos ArtificialIntelligence-News er det ikke det samme som, om en GPU er fri til nye workloads. Du kan se 5 procent SM-aktivitet, mens hele enheden er tildelt én pod og VRAM er optaget af en stor model. For scheduler er den optaget. For dit dashboard ser den tom ud. Det er dér, køerne bliver ulogiske.
Hvad er problemet her — og hvorfor virker det forkert
“Ledig” bliver ofte læst som “brugbar”. Det holder ikke. En VRAM-resident model kan holde enheden optaget, mens compute knap rykker sig. Kubernetes lægger ikke andre pods på samme device, fordi den er taget. Det er ikke et sjældent hjørnetilfælde; det er standardopførsel i mange opsætninger.
Hvorfor et job kan stå i kø ved 'ledig' hardware
Fire rodårsager går igen. 1) Allokering/ejerskab: Kubernetes tildeler som udgangspunkt hele GPUer til pods. Én pod kan derfor blokere resten – også ved lavt compute-forbrug. 2) VRAM-residency/occupancy: en model bliver liggende i hukommelsen og efterlader for lidt plads til andre. 3) Placement-constraints: node-affinity, taints og tolerations kan betyde, at den eneste node der matcher, allerede er optaget. 4) Applikationsflaskehalse: I/O, enkelttrådet pre/post-processing eller for små batches holder SM-aktiviteten nede, mens enheden stadig er låst.
Hvordan ser det ud i data? Allokering ses i scheduler-events og device-ownership, ikke i %SM. VRAM-residency viser sig som høj memory-occupancy over tid uden tilsvarende compute. Placement-fejl ses som pending pods med specifikke affinity-krav. App-flaskehalse ligner lave kernel-launch rates, stigende latency og ubalance mellem host- og device-aktivitet. ArtificialIntelligence-News forklarer skellene; Snilld-manualen supplerer med konkrete checks og instrumentering.
Kubernetes og hele-GPU tildeling: den praktiske konsekvens
Standardadfærden er simpel: hele GPUer tildeles pods. Konsekvensen er tydelig. En online inference-service med stor model i VRAM og lav QPS kan binde en hel enhed, selv om compute sjældent stiger. Andre job kan stå i kø i timevis, mens grafen viser 5–10 procent. Ikke fordi der er ledigt, men fordi reglerne siger nej.
Et andet typisk forløb: Et træningsjob får en GPU, loader data… og venter på en langsom kilde. Compute-målingen falder. Enheden er stadig allokeret, og scheduler kører intet andet på den. For drift ligner det spild. For Kubernetes er det korrekt opførsel. Derfor kan dashboards virke vildledende, hvis compute-procenter læses som kapacitet.
Hvad GPU 'utilisation' faktisk måler — og hvilke målinger du mangler
Cast AI-opsummeringen (via ArtificialIntelligence-News) anbefaler at skille metrikkerne ad: %SM er compute-aktivitet. VRAM-occupancy/residency viser, om hukommelsen er bundet af modeller/tensorer. SM-occupancy over tid siger noget om, hvor fyldte kernerne er, ikke bare om de er i brug. Kernel-launch-wait afslører huller i køen af arbejde til GPUen. PCIe/NVLink-throughput viser, om interconnect er flaskehalsen.
Brug dem sådan her: Lav %SM + høj VRAM-residency tyder på en resident model, der låser enheden. Lave kernel-launch rates og lav PCIe-trafik peger mod CPU- eller I/O-flaskehalse. Høj PCIe men lav SM-occupancy kan tyde på dyre transfers eller for små batches. Snilld-manualen anbefaler at indsamle dem systematisk, så diagnoser tager timer – ikke uger.
Diagnostisk flow: hvad du skal tjekke først — og hvorfor
Rækkefølgen sparer tid: 1) allokering, 2) hukommelse, 3) placement, 4) applikation. Start med det banale: er enheden allerede tildelt? Tjek pod- og node-tilstand (fx kubectl describe pod for device-claims og events) og schedulerens pending-oversigt. Hvis alt er allokeret, ved du, hvorfor.
Dernæst hukommelse: brug nvidia-smi -q eller GPU-telemetri til at se VRAM-residency over tid. Ligger en stor model permanent i hukommelsen uden tilsvarende compute? Så videre til placement: gennemgå node-affinity, taints og tolerations. Små linjer i manifests kan udelukke det meste af klyngen. Til sidst applikationen: mål kernel-launch-wait, SM-occupancy, PCIe/NVLink, batch-størrelse og serielle trin. Snilld-manualen lister instrumenteringspunkter og anbefaler at logge dem sammen med pod-livscyklus.
Delingsteknikker: time-slicing, NVIDIA MIG og MPS — hvad de løser og hvad de ikke gør
GPU-sharing adresserer primært allokeringskonflikter. ArtificialIntelligence-News gennemgår tre muligheder. Time-slicing deler compute-tid mellem processer, men uden stærk hukommelsesisolation. NVIDIA MIG skaber hardware-partitioner med skarp isolation af compute og memory, men kræver kompatibel Ampere/Hopper-hardware og lidt mere planlægning. MPS deler kontekst for bedre concurrency i CUDA – med nogle observability-udfordringer.
Trade-offs: MIG giver isolation og forudsigelighed, men workloads skal passe i faste “skiver”. Time-slicing er fleksibel, men performance kan variere, og forbrugeransvar kan være sværere at se. MPS kan løfte udnyttelsen for mange små kerner, men ændrer ikke ved VRAM-residency. Cloud-support varierer, og managed Kubernetes kræver ofte ekstra opsætning. Der er ikke én vinder til alt.
Hvad GPU-sharing IKKE løser
Deling fjerner ikke memory-residency, placement-begrænsninger eller app-flaskehalse. En stor model, der fylder VRAM, spærrer stadig – også med time-slicing. Stram node-affinity kan stadig sende pods i kø, selv med MIG. Et enkelttrådet preprocessing-led holder compute nede og latency ustabil uanset MPS. ArtificialIntelligence-News’ pointe er klar: deling adresserer allokering, ikke alt det andet.
Eksempel: To små inference-tjenester får hver en MIG-partition. De undgår slagsmål om en hel enhed. Fint. Men med batch-størrelse 1 og tung CPU-bunden tokenisering bliver throughput stadig lav. Gevinsten ligger i batching og asynkron I/O – ikke flere skillerum.
Praktiske optimeringer og instrumentering — konkrete anbefalinger
Snilld-manualens rækkefølge er jordnær. A) Instrumentér: tilføj metrikker for memory-residency, SM-occupancy, kernel-launch-wait og PCIe/NVLink. Lav dashboards, der adskiller compute-aktivitet fra allokering og hukommelse. Uden det gætter man. B) Redesign workloads: mixed precision, model-sharding til store checkpoints, batch-kontrol og asynkron I/O – hold køen til GPUen fyldt.
Platform-tiltag: overvej fractional GPU-support, preemption og mere aggressiv bin-packing dér, hvor det er stabilt. Vær opmærksom på, at “ingen manifest-ændringer” kan være sandt i nogle stacks, men ikke alle. Små justeringer af device-krav, node-affinity og tolerations kan give stor effekt. Og når I kapacitetsplanlægger: regn langlivede VRAM-allokationer som reelt blokerende, ikke bare kig på peak compute.
Produktpåstande og usikkerheder
ArtificialIntelligence-News refererer, at Cast AI understøtter time-slicing, MIG og MPS med automatisk bin-packing og hævder, at workloads ikke kræver manifest-ændringer. Tag det som producent-udmelding. Uafhængig validering på tværs af cloud-udbydere og orkestreringsopsætninger er begrænset, og edge-cases kan gemme sig i driver-versioner, CNI-plugins og security-policies.
En anden mangel: Der er få offentlige, uafhængige før/efter-målinger, der kvantificerer effekten af ny instrumentering eller workload-redesign på throughput eller cost-per-inference/training. Snilld-manualen skitserer praksis, men brede tal er ikke lagt frem. Og igen: 5-procents-tallet er en indgang, ikke et løfte om 95 procent “gratis” kapacitet.
Operational konsekvens: hvad kan man faktisk spare
Potentialet er til at få øje på: færre panikkøb af nye GPUer, højere throughput på de eksisterende og lavere enhedsomkostning per job. Når allokering og hukommelse er ryddet op, falder køtider. Når app-flaskehalse fjernes, stiger SM-occupancy. Men gevinsten afhænger af workload-mix, hardware og cloud-støtte til delingsmetoder. Ingen universel tommelfingerregel her.
Risikoen ved at gøre ingenting er også reel: “kolde” GPUer, der holder modeller varme uden at levere throughput, og utilfredse teams, hvis job aldrig får en enhed. Det koster tid, moral og i sidste ende budget. Derfor giver et stramt diagnoseforløb mening, før nogen bestiller en kasse nye kort.
Checkliste for en første uge
Dag 1: kortlæg allokering. Hvilke pods holder hvilke enheder? Sammenlign med pending pods. Notér hvor mange, der venter på GPU. Dag 2: mål VRAM-residency og SM-occupancy over tid. Find modeller, der er resident uden tilsvarende compute. Dag 3: test en delingsmetode i staging. Start med time-slicing eller MPS, hvis hardware/cloud ikke understøtter MIG. Mål varians.
Dag 4: tweake workloads. Slå mixed precision til, øg batch-størrelse forsigtigt, flyt langsom tokenisering til asynkrone tråde. Dag 5: opsæt dashboards og alerting for memory-residency, kernel-launch-wait og PCIe/NVLink. Bind metrikker til SLO’er, så regressions fanges. En uge er kort, men nok til at afgøre, om køen skyldes allokering, hukommelse, placement eller applikation.
Bag dashboardet: hvorfor lav GPU-utilisation ikke altid betyder ledig kapacitet
Compute-procenter alene fortæller ikke, om noget kan køre nu. Cast AI-opsummeringens pointer om SM-aktivitet vs. allokering og VRAM-residency gør forskellen. Mange har “grønne” grafer, mens brugere ser røde køer. Det er ikke ond vilje, bare for simple målinger.
Det, der mangler, er adskilte visninger: én for aktivitet, én for tilgængelighed. Og en scheduler-rapport, der tydeligt viser, hvorfor pods ikke blev placeret. Når de tre billeder peger samme vej, stopper misforståelserne. Når de ikke gør, fejlsøg i sekvens – ikke med mavefornemmelse.
Hvad ledere bør beslutte denne måned
Af sager, der kan besluttes hurtigt: afsæt budget til observability ud over %SM – især memory-residency, kernel-launch-wait og interconnect-trafik. Godkend en pilot for GPU-sharing, valgt efter workload-krav, ikke én metrik. Planlæg et kort kapacitetsreview, der indregner langlivede VRAM-allokationer som blokerende elementer. Og hold fast i en regel: ingen større hardware-indkøb før diagnoseflowet er kørt til ende.
En sidste detalje: “ingen manifest-ændringer” kan spare tid, men gennemgå alligevel manifests for device-krav, affinity og tolerations. Små rettelser her kan frigøre mere end nye kort. Det opdager man først, når man prøver det af.
