Waarom ‘meer GPU’s’ geen AI-strategie is

Begin met de verkeerde vraag

Veel AI-teams starten hun infrastructuurgesprek met een ogenschijnlijk logische vraag: hoeveel GPU’s hebben we nodig? Die vraag is begrijpelijk. Modelontwikkeling, fine-tuning, retrieval, inference, evaluatie en agentic workflows vragen allemaal om rekenkracht. Zodra wachtrijen ontstaan of experimenten vertragen, voelt extra hardware als de snelste route naar vooruitgang.

Maar als Funnel Adviseur zou ik die vraag bewust een stap terugduwen. Niet omdat capaciteit onbelangrijk is, maar omdat capaciteit zonder operating model vooral een duurdere vorm van chaos kan worden. De betere vraag is: welke AI-workloads moeten voorspelbaar, betaalbaar en verantwoord draaien, en onder welke randvoorwaarden?

Dat verschil lijkt semantisch, maar is strategisch. Een team dat alleen capaciteit koopt, optimaliseert voor bezit of toegang. Een team dat workloads ontwerpt, optimaliseert voor waarde. In AI-infrastructuur zit het verschil tussen die twee vaak in planning, prioritering, benutting, governance en kostenallocatie. Meer GPU’s kunnen dan nog steeds nodig zijn, maar ze zijn niet langer het beginpunt van de strategie.

Compute is een systeem, geen voorraadkast

Een GPU die beschikbaar is, is nog geen productieve GPU. Capaciteit krijgt pas zakelijke waarde wanneer duidelijk is welk werk erop draait, wanneer dat werk moet draaien, wie voorrang krijgt, welke kwaliteitseisen gelden en wat er gebeurt als capaciteit schaars wordt. Dat maakt compute geen voorraadkast, maar een operationeel systeem.

Voor AI-teams betekent dit dat de infrastructuurlaag niet los gezien kan worden van productmanagement. Een experiment van een researchteam heeft een ander profiel dan een klantgerichte inferenceflow. Een batch-evaluatie kan soms wachten; een realtime assistent in een klantproces meestal niet. Fine-tuning heeft andere risico’s dan gewone inference. Training, evaluatie en productiegebruik horen daarom niet automatisch in dezelfde wachtrij met dezelfde spelregels.

Daar gaat het vaak mis. Teams verzamelen compute-vragen in één abstracte bak: modelkosten, GPU-kosten of cloudkosten. Daardoor blijft verborgen welke workloads echt bedrijfskritisch zijn, welke experimenten structureel capaciteit opslokken en welke processen eigenlijk beter gepland kunnen worden. Als niemand het onderscheid maakt, wordt schaarste opgelost met budget in plaats van met ontwerp.

Benutting is geen doel op zichzelf

Bij AI-infrastructuur klinkt hoge benutting aantrekkelijk. Niemand wil dure hardware ongebruikt laten staan. Toch is benutting op zichzelf geen voldoende stuurgetal. Een omgeving kan hoog belast zijn en tegelijk slecht functioneren, bijvoorbeeld omdat belangrijke taken moeten wachten achter minder urgente jobs, omdat teams geen voorspelbare toegang hebben of omdat pieken telkens ad hoc worden opgelost.

Daarom is het nuttiger om benutting te koppelen aan workloadkwaliteit. Welke capaciteit moet direct beschikbaar zijn? Welke capaciteit mag worden gevuld met minder urgente taken? Waar ontstaan wachtrijen? Waar is idle capacity acceptabel omdat betrouwbaarheid belangrijker is dan maximale bezetting? En waar betalen teams voor flexibiliteit die ze in de praktijk nauwelijks gebruiken?

De volwassen stap is om compute te behandelen als een portfolio. Sommige workloads vragen om lage latency en duidelijke service-afspraken. Andere workloads kunnen batchgewijs worden ingepland. Experimentele jobs kunnen mogelijk naar goedkopere of minder gegarandeerde capaciteit. Evaluaties kunnen periodiek worden gebundeld. Zo ontstaat niet alleen kostencontrole, maar ook rust in de organisatie: teams weten waar ze aan toe zijn.

Waarom horizontale pooling aantrekkelijk klinkt, maar geen wondermiddel is

Een terugkerend idee in AI-infrastructuur is dat compute flexibeler verdeeld zou moeten worden. In plaats van elk team, lab of bedrijf dat zijn eigen capaciteit probeert veilig te stellen, ontstaat dan een denkrichting waarin rekenwerk via gedeelde pools of grids beter wordt afgestemd op vraag en aanbod. Dat klinkt aantrekkelijk, vooral wanneer capaciteit schaars, duur of ongelijk verdeeld is.

Voor AI-leads is het belangrijk om dit nuchter te bekijken. Gedeelde capaciteit kan voordelen hebben: betere spreiding, minder stilstand, toegang tot meer variatie in infrastructuur en mogelijk een flexibeler kostenniveau. Maar het introduceert ook vragen. Wie bepaalt prioriteit? Hoe worden data-afspraken geborgd? Welke garanties gelden voor beschikbaarheid? Hoe transparant zijn kosten, performance en risico’s?

In de praktijk komt de keuze vaak neer op een mix: publieke cloud voor flexibiliteit, dedicated capaciteit voor voorspelbare workloads, gespecialiseerde aanbieders voor specifieke taken en soms eigen infrastructuur waar controle belangrijk is. De juiste vraag is dus niet of één model wint. De juiste vraag is welk deel van je AI-operatie welk infrastructuurmodel verdient.

De vergeten factor: omgeving en draagvlak

AI-infrastructuur is niet alleen een interne technische puzzel. Datacenters, energiegebruik, locatiekeuzes, contractvoorwaarden en data-afspraken raken ook de omgeving waarin organisaties opereren. Voor Nederlandse en Europese teams kan dat praktisch worden: klanten, partners of interne governancefuncties kunnen vragen stellen over waar data wordt verwerkt, hoe leveranciersafhankelijkheid wordt beheerst en welke afspraken gelden bij opschaling.

Daarmee wordt draagvlak onderdeel van het ontwerp. Een AI-roadmap die alleen rekent in tokens, latency en modelkwaliteit mist een bredere realiteit. Zeker bij toepassingen met klantdata, bedrijfsgevoelige informatie of gereguleerde processen is het verstandig om vooraf vast te leggen welke workloads waar mogen draaien. Niet elk experiment vraagt dezelfde governance, maar productieprocessen zonder duidelijke randvoorwaarden worden later vaak duurder om te corrigeren.

Draagvlak betekent ook dat teams begrijpelijk moeten kunnen uitleggen waarom bepaalde infrastructuurkeuzes zijn gemaakt. Waarom cloud? Waarom dedicated capacity? Waarom een bepaalde regio? Waarom een bepaalde mate van vendor lock-in? Als die antwoorden pas worden gezocht nadat de kosten of risico’s oplopen, is de infrastructuur feitelijk al leidend geworden. Dat is precies wat je wilt voorkomen.

Wat AI-teams morgen kunnen beoordelen

Een praktische compute-strategie begint niet met een groot migratieprogramma. Begin met een inventarisatie van workloads. Splits training, fine-tuning, inference, evaluatie, retrieval, batchverwerking en agentic workflows van elkaar. Noteer per workload de latency-eis, voorspelbaarheid, datagevoeligheid, frequentie, kostenimpact en verantwoordelijke eigenaar.

Kijk daarna naar de plekken waar frictie ontstaat. Zijn er wachtrijen die productontwikkeling vertragen? Wordt capaciteit gereserveerd uit angst voor schaarste? Zijn er teams die structureel meer gebruiken dan zichtbaar wordt in de businesscase? Worden kosten geboekt als algemene modelkosten terwijl ze eigenlijk voortkomen uit slecht geplande infrastructuur? Zulke vragen maken duidelijk of het probleem echt capaciteit is, of vooral operating model.

Leg vervolgens vast welke vendor lock-in bewust wordt geaccepteerd. Geen enkele keuze is neutraal. Cloud geeft snelheid en flexibiliteit, maar kan afhankelijkheid vergroten. Eigen infrastructuur geeft controle, maar vraagt expertise en discipline. Gedeelde of gespecialiseerde capaciteit kan aantrekkelijk zijn, maar vraagt scherpere afspraken over beschikbaarheid, data en support. Het punt is niet om lock-in volledig te vermijden; het punt is om niet per ongeluk in een afhankelijkheid te rollen die niemand expliciet heeft goedgekeurd.

Wie dit combineert met duidelijke governance, krijgt een veel sterker gesprek met directie, finance en productteams. Dan gaat het niet meer over ‘AI is duur’, maar over welke AI-workloads waarde opleveren, welke risico’s acceptabel zijn en welke infrastructuurkeuzes daar logisch bij passen. Dat is ook de brug naar commerciële automatisering: AI werkt pas duurzaam in klantprocessen als de technische laag betrouwbaar genoeg is om beloftes waar te maken. Voor organisaties die AI koppelen aan marketing- en salesprocessen is die verbinding met B2B website automatisering essentieel.

Schaal zonder discipline vergroot vooral de rekening

Meer compute kan een terechte investering zijn. Sommige AI-roadmaps lopen simpelweg vast zonder extra capaciteit. Maar capaciteit is geen strategie op zichzelf. Als workloads niet zijn geclassificeerd, prioriteiten onduidelijk blijven en governance pas achteraf wordt toegevoegd, vergroot schaal vooral de rekening en de afhankelijkheid.

Een houdbare AI-strategie begint daarom bij discipline: welk werk draait waar, wanneer, waarom en onder welke voorwaarden? Pas daarna wordt de capaciteitsvraag scherp. Dan is de keuze voor extra GPU’s, cloudcapaciteit, dedicated clusters of gedeelde infrastructuur geen reflex meer, maar een ontwerpbeslissing.

Voor AI-leads, CTO’s en productteams is dat de kern. Behandel compute niet als technische bijlage bij de roadmap, maar als onderdeel van het product- en governanceontwerp. Wie dat doet, bouwt minder op hoop en meer op bestuurbare capaciteit. En dat is in AI vaak waardevoller dan simpelweg de volgende stapel hardware.