Betaal je voor verveelde GPU’s? Hoe AI-starvation je budget opeet

Rook en tijd maken matig vlees niet beter

Ik kook graag buiten. Vuur, rook, tijd. Wat ik daarbij heb geleerd: je kunt de beste kamado of smoker aanschaffen, als de slager niet kan leveren sta je met je armen over elkaar. En levert hij wel, dan wil je nog weten wat hij levert. Begin je met middelmatig vlees, dan eindig je met middelmatig vlees dat veertien uur heeft liggen garen. Rook, temperatuur en tijd maken een goed stuk vlees beter. Ze maken een matig stuk vlees niet goed.

Over die tweede kant, de kwaliteit van wat je aanlevert, schreef ik eerder al. Daar stranden de meeste AI-projecten op in de testfase. Deze keer gaat het over de aanvoer.

Want die dure GPU staat te wachten, en dat kost je geld zonder dat er iets gebeurt. Wij noemen dat AI-starvation. Je schaalt dan op naar een duurdere tier terwijl het knelpunt niet in de rekenkracht zit. De vraag die mij bezighoudt is een andere. Hoe is het zover gekomen dat niemand het doorhad?

De database die uit beeld raakte

Stel jezelf één vraag: wie beheert op dit moment jullie database? Niet welk product, niet welke cloud. Wie.

Bij de meeste organisaties die wij spreken komt daar geen naam uit. Er komt een dienst uit. “Die draait op RDS.” “Dat is Cloud SQL.” “Dat zit in een container in ons Kubernetes-cluster.” En daar blijft het bij, want er zit managed in de naam en dan is het geregeld. Dat denken we tenminste.

AWS, Google en Azure doen wat ze beloven. Ze houden je database in de lucht en ze patchen de engine. Dat is beheer, en niet meer dan dat. Optimalisatie is het niet.

Bij back-ups zie je hetzelfde. Er draait een automatische snapshotfunctie, maar dat is een retentievenster van maximaal 35 dagen in hetzelfde account en dezelfde regio. Onder het shared-responsibility-model bepaal jij de back-up-strategie en test jij of een restore ook echt werkt. Harry schreef daarover: back-ups maken doet iedereen, restoren bijna niemand.

Datzelfde patroon zie je overal. Niemand bij je cloudprovider kijkt of je indexen nog passen bij de manier waarop je platform vandaag wordt bevraagd. Niemand controleert of je datamodel is meegegroeid met de vier applicaties die er sinds de bouw bij zijn gekomen. En niemand vraagt zich af of je opslaglaag de doorvoer haalt die een trainingsjob of een RAG-pipeline nodig heeft.

Dat werk is nooit verdwenen. Het is van de takenlijst gevallen toen de database achter een console-scherm verdween.

Verveelde GPU’s zijn een symptoom

Wat wij tegenkomen als we bij zo’n omgeving worden gehaald, is bijna nooit spannend. Het is de saaie kant van het vak.

Een dataloader die per record een losse query afvuurt in plaats van in batches op te halen. Een vectorindex met parameters die nog op de standaardwaarden staan van de dag dat iemand hem aanzette. Retrieval die over een netwerkverbinding gaat naar opslag in een andere regio, omdat dat bij het opzetten toevallig zo uitkwam. Statistieken die nooit meer zijn ververst, waardoor de query planner al maanden verkeerde keuzes maakt.

Elk van die dingen kost milliseconden. Vermenigvuldig ze met een paar miljoen retrieval-acties en je GPU staat een aanzienlijk deel van de dag te niksen. Op je dashboard zie je vooral dat de GPU actief is. Dat hij ondertussen op je datalaag wacht, vertelt zo’n grafiek er zelden bij.

Zo herken je het in je eigen omgeving

Vijf signalen die je zonder diepgaand onderzoek al kunt nalopen:

• Je GPU-monitoring meldt hoog verbruik, terwijl de doorvoer achterblijft bij wat je verwacht.
• Het ophalen van data kost meer tijd dan de inferentie of de trainingsstap zelf.
• In je logging zie je veel kleine, losse queries op plekken waar batches zouden moeten staan.
• Je latency piekt zodra retrieval over regio’s of zones heen gaat.
• Query plans, statistieken en indexen zijn niet herzien sinds de oplevering.

Herken je er twee of meer, dan koop je op dit moment rekenkracht die staat te wachten.

Eén nuance daarbij. AI-starvation ontstaat niet altijd in de database zelf. Het kan net zo goed in je object storage zitten, in je netwerk, in de configuratie van je vector store of in de manier waarop je dataloader is gebouwd. Wat wij zien is dat het vaak in de database landt, omdat daar de meeste lagen samenkomen. Je hebt dus iemand nodig die het hele pad bekijkt en niet één onderdeel ervan.

Het echte probleem is eigenaarschap

De verleiding is nu om te zeggen: dan tunen we die database even. Dat kan, en dat doen we ook. Maar dan sta je over een jaar op hetzelfde punt.

Daaronder zit namelijk dat de database geen eigenaar meer heeft. Het datateam kijkt naar modellen en pipelines. Het platformteam kijkt naar Kubernetes en deployments. De cloudprovider kijkt naar uptime. En de database zit daar ergens tussenin, van iedereen en dus van niemand, terwijl elk AI-initiatief in je organisatie erop leunt.

Een fundament heeft iemand nodig die er verstand van heeft en er verantwoordelijk voor is. Onze Database Platform Engineers doen precies dat. Ze kijken naar je datamodel, je indexering, je opslaglaag en je retrievalpatronen, of dat nu draait op een eigen server, in een container of op een volledig managed dienst van een hyperscaler.

Want managed betekent niet geoptimaliseerd. En je AI is pas slim als je database dat is.

Waar begin je?

Verbrand je op dit moment budget aan GPU-uren terwijl de resultaten tegenvallen? Loop dan eerst de vijf signalen hierboven na, voordat je een ander model gaat uitzoeken.

Kom je er zelf niet uit, dan hebben we daar de AI-Data Readiness QuickScan voor. In een paar dagen weet je waar de knelpunten zitten en wat je als eerste moet aanpakken. Geen dik rapport, wel een helder beeld.

En wil je gewoon eens sparren over die vraag van hierboven, wie jullie database nu beheert, bel of mail gerust. Ook als je nog geen klant bent.