Waarom je AI-workloads in de wachtrij staan terwijl je GPU's niets lijken te doen

Sophie Jansen · 2026-09-25

Je kent het gevoel vast wel: je AI-workloads staan in de wachtrij, maar als je naar je GPU-dashboard kijkt, zie je dat de kaarten amper actief zijn. Gemiddeld 5% compute-utilisatie, om precies te zijn. Dat cijfer komt uit het Cast AI 2026 Kubernetes Optimalisatie Rapport, dat tienduizenden productieclusters analyseerde tussen januari 2025 en april 2026. Het is een verbluffend laag getal. Maar betekent dat ook dat er 95% van je GPU-capaciteit direct beschikbaar is? Nee. En dat misverstand kost bedrijven handenvol geld. ### GPU-utilisatie: wat het wel en niet vertelt GPU-utilisatie is een containerbegrip. De meeste dashboards tonen compute-utilisatie: het percentage streaming multiprocessors (SM's) dat actief is in een bepaald tijdsvenster. Dat zegt iets over hoe hard de chip werkt op het moment dat er iets draait. Het zegt niets over of die GPU beschikbaar is voor een nieuwe workload. Stel je voor: een model is in het VRAM geladen. Dat geheugen is permanent bezet. De inference-service beantwoordt misschien één verzoek per minuut, waardoor de compute-activiteit op 5% blijft steken. Maar de GPU is toegewezen, het geheugen is vol, en Kubernetes zal er niets anders op plannen. Voor de scheduler is die GPU onbeschikbaar. Voor jouw monitor ziet hij er bijna werkloos uit. ### De vier gezichten van GPU-utilisatie Er zijn minstens vier verschillende metingen die mensen op één hoop gooien. Dat is de snelste weg naar een verkeerde diagnose. Hier is het onderscheid: - **Compute-activiteit (%SM):** het deel van de streaming multiprocessors dat actief is tijdens de meting. Zegt níet of de GPU is toegewezen of dat er VRAM vrij is. - **Geheugengebruik (VRAM):** hoeveel GPU-geheugen is ingenomen door geladen modellen en tensors. Zegt níet of wachtende workloads in het resterende geheugen passen. - **Wachttijd in de wachtrij (pod-scheduling):** hoe lang pending pods wachten voordat een GPU vrijkomt. Zegt níet of de vertraging komt door allocatie, geheugen, plaatsing of een applicatieknelpunt. - **Doorvoer / latentie:** verzoeken per seconde, tijd tot eerste token of end-to-end responstijd. Zegt níet of de GPU effectief wordt benut. ### Waarom workloads blijven wachten Kubernetes wijst standaard hele GPU's toe aan pods. Eén workload die een device vasthoudt, blokkeert alle anderen, ongeacht hoeveel van die GPU hij daadwerkelijk gebruikt. Dat is de kern van het probleem. Er zijn minstens vier oorzaken waarom een workload in de wachtrij staat naast een ogenschijnlijk idle GPU: - **Allocatieregels:** de GPU is toegewezen aan een andere pod, ook al draait die pod bijna niets. - **Geheugenvereisten:** het VRAM is vol, zelfs als de compute-activiteit laag is. - **Plaatsingsbeperkingen:** hardwarecompatibiliteit, isolatie-eisen of node-affinity houden de pod tegen. - **Applicatieknelpunten:** de bottleneck zit in de applicatie zelf, niet in de GPU. Alleen de eerste oorzaak los je op met GPU-sharing. De rest vraagt om een andere aanpak. ### GPU-sharing: geen wondermiddel Er zijn drie gangbare methoden om GPU's te delen, en ze hebben allemaal hun eigen afwegingen: - **Time-slicing:** meerdere workloads wisselen elkaar af op dezelfde GPU. Geen hardwarevereisten, maar zwakke isolatie en beperkte observeerbaarheid. - **MIG (Multi-Instance GPU):** hardwarematige partitionering met sterke isolatie. Alleen op bepaalde GPU-modellen en niet altijd ondersteund door cloudproviders. - **MPS (Multi-Process Service):** deelt de GPU tussen processen met betere benutting, maar met beperkte geheugenisolatie. Geen enkele methode past bij elke workload. De kunst is om te kiezen op basis van je eisen rond isolatie, voorspelbaarheid en kosten. ### De juiste diagnose in de juiste volgorde De volgorde van je diagnose maakt het verschil. Begin bij de allocatiestatus, kijk dan naar geheugengebruik, daarna naar plaatsingsbeperkingen en pas als laatste naar applicatieknelpunten. In die volgorde. Zo voorkom je dat je een dure hardware-upgrade koopt terwijl het echte probleem in je configuratie zit. “De grootste fout die teams maken, is een hardwaretekort veronderstellen terwijl het in werkelijkheid om een allocatie- of plaatsingsprobleem gaat,” zegt Sophie Jansen, Senior Media Monitoring Analist & Strategisch Adviseur. “Een GPU die 5% compute laat zien, kan volledig toegewezen zijn. Dat besef alleen al kan je cloudrekening halveren.” ### Praktische stappen - Controleer of je GPU's daadwerkelijk zijn toegewezen aan pods, niet alleen of ze actief lijken. - Analyseer VRAM-gebruik apart van compute-utilisatie. - Onderzoek of plaatsingsregels (affinity, taints, tolerations) workloads tegenhouden. - Meet applicatielatentie en doorvoer om te zien of de GPU überhaupt de bottleneck is. - Overweeg GPU-sharing alleen als allocatie de echte oorzaak is. Met automatische bin-packing en ondersteuning voor alle drie de sharing-methoden kun je bestaande workload-manifests ongewijzigd laten. Zo haal je meer uit de hardware die je al hebt, zonder te investeren in extra GPU's die je misschien helemaal niet nodig hebt.