Je GPU staat te wachten

Wat is AI-starvation?

Een GPU is een parallelle rekenmachine. Hij kan duizenden berekeningen tegelijk uitvoeren, maar alleen als hij continu gevoed wordt met data. Zodra de aanvoer van trainingsdata, modelgewichten of inputbatches achterblijft bij de verwerkingscapaciteit, ontstaat starvation: de GPU wacht in plaats van te rekenen.

In Azure-termen betekent dit: je betaalt voor NC- of ND-series VM’s met NVIDIA A100 of H100 GPU’s, maar je GPU-benutting ligt op 40 tot 60 procent. Niet omdat de GPU te klein is, maar omdat de storage, de netwerkkoppelingen of de datavoorbereiding de bottleneck vormen.

Bij een recente klant zagen we precies dit patroon. Een ND96asr v4, een van de duurste GPU-VM’s in Azure, met een GPU-benutting die bleef steken op 55%. De aanbeveling vanuit het team was opschalen naar een grotere SKU met nog meer geheugen. Na analyse bleek het probleem te zitten in de I/O-doorvoer vanuit Azure Blob Storage.

Waar zit de I/O-bottleneck?

Blob Storage zonder premium tier. Standaard Azure Blob Storage heeft een latency van enkele milliseconden per request. Bij het laden van grote datasets voor modeltraining, waarbij duizenden kleine bestanden snel achter elkaar worden gelezen, loopt dit op. Azure Premium Blob Storage of Azure NetApp Files biedt significant hogere doorvoer, maar weinig teams maken die afweging bewust.

Geen lokale NVMe-caching. De ND-series VM’s beschikken over lokale NVMe-schijven die bedoeld zijn als snelle tijdelijke opslag. Als trainingsdata niet vooraf naar lokale NVMe wordt geladen maar rechtstreeks van remote storage wordt gelezen tijdens de trainingsstap, verlies je een enorme hoeveelheid doorvoercapaciteit. Veel voorgeconfigureerde instap-AI-VM’s staan standaard op trage HDD in plaats van SSD.

Suboptimale batch-grootte en prefetching. Als de dataloader niet asynchroon prefetcht (de volgende batch alvast laadt terwijl de GPU de huidige verwerkt), staat de GPU periodiek stil te wachten. Dit is een configuratiekeuze, geen hardwarekwestie.

Netwerk als bottleneck bij multi-GPU setups. In gedistribueerde trainingsomgevingen (meerdere GPU-nodes) zijn de onderlinge netwerkkoppelingen bepalend. Azure ND-series ondersteunt InfiniBand voor hoge-bandbreedte communicatie, maar alleen als dit expliciet is geconfigureerd. Zonder InfiniBand valt de communicatie terug op standaard Ethernet, een factor vijf tot tien langzamer.

De kostenvalkuil: opschalen als schijnoplossing

Het probleem met AI-starvation is dat de symptomen lijken op ondercapaciteit. Trage training. Lange doorlooptijden. Hoge wachttijden. De logische conclusie: meer GPU-kracht nodig.

Als de GPU al niet volledig wordt benut door I/O-starvation, lost een grotere GPU niets op. Je betaalt dan twee keer: voor de onderbenutte bestaande instantie én voor de extra capaciteit die het probleem niet verhelpt.

In Azure-tarieven: een Standard_ND96asr_v4 (8x A100) kost circa €28 per uur. Een opschaling naar een grotere of redundantere configuratie kan dat verdubbelen. Als de bottleneck in de I/O zit, is dat geld weggegooid.

Bij diezelfde klant bedroeg de aanbeveling om op te schalen €15.000 per maand extra. Na I/O-tuning (NVMe-caching, prefetching, InfiniBand activeren) steeg de GPU-benutting van 55% naar 89%. De upgrade was niet nodig.

Wat lost het wel op?

AI-starvation is bijna altijd op te lossen zonder duurder te gaan. De interventies zijn technisch, niet financieel: laad trainingsdata vooraf naar lokale NVMe in plaats van live van Blob Storage te lezen. Configureer asynchrone prefetching in je dataloader (PyTorch DataLoader num_workers, prefetch_factor). Check en activeer de InfiniBand NICs bij multi-node training op ND-series VM’s. Overweeg Azure Premium Blob Storage, Azure NetApp Files of Silk storage wanneer je met datasets van honderden gigabytes tot terabytes werkt. Monitor GPU-benutting via Azure Monitor of NVIDIA DCGM, niet alleen GPU-load maar ook memory bandwidth, compute utilization in combinatie met netwerk- en disk-I/O.

Geen van deze ingrepen vereist een duurdere VM-tier. Wel kennis van wat er speelt.

Grip begint met meten

Het fundamentele probleem is dat de meeste Azure-dashboards GPU-load tonen, maar de I/O-bottleneck niet zichtbaar maken. Je ziet dat de GPU “bezig” is, maar niet dat hij voor 40% van de tijd staat te wachten op data.

Dat is het verschil tussen inzicht en begrip. Een dashboard toont getallen. Een FinOps-analyse vertelt je wat die getallen betekenen voor je factuur en wat je eraan kunt doen.

Betaal je voor GPU-capaciteit in Azure maar loopt de performance tegen? OptimaSure analyseert je AI-infrastructuur en identificeert binnen 30 dagen waar de werkelijke bottleneck zit en hoe je die oplost. Neem contact op.