Stop met het ontwerpen van AI-infrastructuur rond de GPU

Waarom MSP’s moeten beginnen met de workload, niet met de hardware

Breng je vijf minuten door op een AI-conferentie en je kunt er gemakkelijk van overtuigd raken dat elke succesvolle AI-implementatie begint met het kopen van meer GPU’s. Het is begrijpelijk waarom. Hardware domineert het gesprek. Klanten horen over Blackwell-systemen, InfiniBand-fabrics, hyperscale clouds en steeds grotere AI-clusters. Leveranciers neigen er vanzelf toe de nieuwste versnellers en snelste systemen te omarmen omdat ze spannend, relevant en relatief eenvoudig op de markt te positioneren zijn.

Het probleem is niet dat rekenkracht geen rol speelt. Het is enorm belangrijk.

Het probleem is dat beginnen daar organisaties kan doen de verkeerde vraag stellen. De AI-markt bevindt zich niet langer in de experimenteerfase. AI wordt in productie genomen, bedrijven investeren echt geld en ze verwachten meetbare zakelijke resultaten. Infrastructuurbeslissingen zijn veel consequentialer geworden dan twee jaar geleden. Toch worden onvoldoende beslissingen gedreven door zakelijke eisen – technologische beslissingen blijven de boventoon voeren.

De eerste vraag moet niet zijn: “Welke GPU moeten we kopen?”

“Welke workload proberen we te ondersteunen?” moet de focus zijn.

That seemingly small change affects almost every infrastructure decision that follows.

Er is geen standaard AI-infrastructuur

Een van de grootste misvattingen op de markt is dat er een standaard blauwdruk voor AI-infrastructuur bestaat. Dat is niet zo.

We spreken over AI alsof het één enkele workload is. In werkelijkheid omvat AI een enorm scala aan zakelijke toepassingen met zeer verschillende eisen. Een voice‑AI‑platform heeft niet dezelfde infrastructuurvereisten als medische beeldvorming. Kennisopvraging verschilt van beeldgeneratie. Fraudedetectie ziet er niet uit als voorspellende analyse, en geen van beide lijkt op videobewerking. Ze gebruiken allemaal AI. Ze gebruiken simpelweg infrastructuur op verschillende manieren.

Je ontwerpt niet echt infrastructuur voor “AI”. Je ontwerpt infrastructuur voor een zakelijke applicatie die AI gebruikt. Die nuance is belangrijk. Elke workload stelt unieke eisen aan de ondersteunende infrastructuur. Sommige vereisen aanzienlijke rekenkracht. Andere hangen sterk af van opslagprestaties omdat ze continu grote datasets ophalen. Sommige worden beperkt door netwerkdoorvoer, terwijl een andere kan leven of sterven aan latency omdat elke milliseconde de klantervaring beïnvloedt.

Er is ook een praktische realiteit. De infrastructuur waarvoor een model is ontworpen, is niet altijd beschikbaar op het moment van implementatie. Beschikbaarheid van hardware, lange levertijden of implementatiedeadlines kunnen organisaties dwingen andere GPU’s, versnellers of infrastructuurconfiguraties te gebruiken dan oorspronkelijk gepland. Dat kan betekenen dat het model opnieuw geoptimaliseerd moet worden. Of zelfs dat het model opnieuw ontworpen moet worden rond de hardware die ze daadwerkelijk kunnen inzetten.

Beveiligings- en governance‑eisen zijn evenwel workload‑specifiek. Een applicatie die openbare informatie verwerkt heeft heel andere eisen dan één die financiële transacties, medische dossiers of eigendomsintellectueel eigendom verwerkt. Gegevensbescherming, identiteits- en toegangsbeheer, compliance, soevereiniteit, back‑up, herstel en beschikbaarheid kunnen niet simpelweg na de implementatie worden toegevoegd. Het zijn architecturale beslissingen.

Zakelijke eisen voegen een extra laag toe. Hoe snel moet de applicatie kunnen opschalen? Welke operationele kosten zijn houdbaar? Welk beschikbaarheidsniveau vereist het bedrijf? Hoeveel complexiteit kan de organisatie realistisch beheren? Deze vragen worden per klant anders beantwoord. Daarom bestaat er geen one‑size‑fits‑all AI-infrastructuur.

Organisaties die starten met een voorkeurscloud, hardwareplatform of leverancier krijgen AI-infrastructuur niet goed. De leiders beginnen met de workload en ontwerpen een architectuur rond de zakelijke doelstelling.

Training krijgt de krantenkoppen. Inference levert de zakelijke waarde.

De fascinatie van de industrie voor training is een andere reden waarom AI‑infrastructuurgesprekken de verkeerde kant op kunnen gaan.

Het trainen van een groot taalmodel is een buitengewone technische uitdaging. Enorme datasets, massieve GPU‑clusters, aanzienlijke stroom en infrastructuur die dagen, weken of zelfs maanden op volle capaciteit kan draaien, zijn vereist. Het is duur, technisch indrukwekkend en trekt van nature aandacht.

De meeste organisaties bouwen echter niet aan het volgende frontier‑model. Ze bouwen klantservice‑applicaties, voice‑AI‑systemen, medewerkers‑copiloten, kennisassistenten, zoektools, document‑samenvattingsplatformen, fraudedetectiesystemen en tientallen andere praktische toepassingen met modellen die al getraind zijn.

Dit zijn inference‑workloads, en inference verandert de infrastructuurvergelijking. In plaats van uitsluitend te optimaliseren voor maximale rekencapaciteit, moeten organisaties mogelijk optimaliseren voor snelle responstijden, lage latency, voorspelbare operationele kosten en consistente prestaties.

Een klant geeft niet om hoe krachtig de onderliggende GPU is als een chatbot vijf seconden nodig heeft om te reageren. Een beller geeft niet om de specificaties van het AI‑cluster als een spraakassistent herhaaldelijk verzoeken verkeerd begrijpt of aarzelt tijdens een gesprek. Ze weten simpelweg dat de applicatie niet goed presteert.

Het ontwerpen van elke AI‑omgeving alsof je een foundation‑model traint is daarom meestal de verkeerde aanpak en vaak onnodig duur.

Het doel van de meeste MSP‑klanten is niet om ‘s werelds grootste GPU‑cluster te bouwen. Het doel is AI‑applicaties snel, betrouwbaar, veilig en economisch in productie te krijgen.

The challenge is finding the right balance of performance, security, scalability, resilience, and cost for the workloads they’re actually running.

Misschien is de GPU niet jouw knelpunt

GPU’s zijn de beroemdheden geworden van AI‑infrastructuur. Ze zijn duur, moeilijk te verkrijgen en gemakkelijk te vergelijken, waardoor ze het middelpunt vormen van talloze infrastructuurgesprekken. De GPU is echter mogelijk niet wat een AI‑applicatie in productie tegenhoudt.

“Hoeveel GPU’s hebben we nodig?” is niet de vraag die we zouden moeten stellen, maar eerder “Wat zal deze applicatie over zes maanden vertragen?”

Het antwoord kan ook ergens anders in de architectuur liggen.

Opslag is een goed voorbeeld. Enorme hoeveelheden data worden door AI‑workloads verbruikt – en die datasets groeien in de loop van de tijd. Zelfs een extreem krachtige GPU kan kostbare tijd besteden aan wachten in plaats van werken, als opslag de informatie niet snel genoeg kan leveren. Die data moet ook beschermd, geback‑up, bewaard, beveiligd en gedurende de hele levenscyclus beheerd worden.

Netwerken zijn even belangrijk. Doorvoer, latency, east‑west‑verkeer en communicatie tussen AI‑clusters beïnvloeden allemaal de applicatieprestaties. Een goed ontworpen compute‑omgeving kan een slecht ontworpen netwerk niet eindeloos compenseren.

Ook moet beveiliging vanaf het begin deel uitmaken van de architectuur. Vragen die vóór productie beantwoord moeten worden, omvatten: waar gevoelige data zich bevindt, hoe netwerken gesegmenteerd zijn, of workloads communiceren via privé‑ of publieke verbindingen, en hoe compliance‑ en soevereiniteitseisen worden aangepakt.

Een andere gemakkelijk over het hoofd geziene factor is connectiviteit. Hoewel ze geen opvallende krantenkoppen genereren, kunnen diversiteit in glasvezel, route‑diversiteit, peering‑relaties en geografische nabijheid de gebruikerservaring cruciaal beïnvloeden – om nog maar te zwijgen van de platform‑veerkracht.

Eindklanten weten niet en geven niet om welke GPU in de rack zit. Ze geven om of de applicatie onmiddellijk reageert of hen laat wachten.

Fysieke infrastructuur verdient ook aandacht. Beschikbaarheid van stroom, koelcapaciteit, rack‑dichtheid en uitbreidingscapaciteit bepalen of de succesvolle implementatie van vandaag de groei van morgen kan opvangen.

Dan is er data‑zwaartekracht. Naarmate datasets groeien, wordt het steeds minder efficiënt om petabytes aan informatie tussen locaties te verplaatsen, alleen omdat de compute ergens anders zit. In veel situaties kan het dichter bij de data brengen van compute zowel praktischer als goedkoper zijn.

Dit is waarom architectuur belangrijk is.

Denk aan een raceauto – alleen omdat hij de beste motor heeft, betekent niet dat hij zal winnen. De transmissie, banden, ophanging, circuit en vooral de coureur zijn ook van belang. AI‑infrastructuur werkt op dezelfde manier.

De organisaties die de grootste waarde uit AI halen, zullen niet per se die met de grootste GPU‑clusters zijn. Het zullen degenen zijn die begrijpen hoe elke laag van de infrastructuur samenwerkt.

Dat is het verschil tussen het kopen van infrastructuur en het ontwerpen ervan.

Een workload‑first planningskader

MSP’s hebben de kans om het infrastructuurgesprek te veranderen.

In plaats van te beginnen met:

• Welke GPU?
• Welke cloud?
• Welke leverancier?

Begin met de workload:

• Welk zakelijk probleem lossen we op?
• Is dit een training‑ of inference‑workload?
• Hoeveel latency kan de applicatie tolereren?
• Waar bevindt de data zich, en hoe snel zal deze groeien?
• Welke beveiligings‑, compliance‑ en soevereiniteitseisen zijn van toepassing?
• Hoe zal de workload opschalen?
• Welk beschikbaarheidsniveau vereist het bedrijf?
• Welk niveau van operationeel risico is acceptabel?
• Wat zal deze omgeving kosten om te exploiteren naarmate het gebruik groeit?

De antwoorden moeten de architectuur bepalen. Niet andersom.

De kans voor MSP’s

Deze verschuiving verandert de rol van de MSP.

Klanten hebben niet een extra partner nodig die hen infrastructuur kan verkopen. Wat ze nodig hebben is een partner die hen helpt betere infrastructuurbeslissingen te nemen.

Een workload‑first benadering is een must omdat het MSP’s de mogelijkheid geeft compute, opslag, netwerken, connectiviteit, beveiliging, datalocatie, beschikbaarheid en kosten te evalueren als onderdelen van één architectuur – in plaats van afzonderlijke aankoopbeslissingen.

Op deze manier kun je kosten beheersen, prestaties verbeteren en operationele en beveiligingsrisico’s identificeren voordat applicaties in productie gaan.

Er ontstaat ook een beter businessmodel voor de MSP.

MSP’s kunnen terugkerende diensten met hogere waarde opbouwen rond architectuur, implementatie, optimalisatie, beveiliging, levenscyclusbeheer, capaciteitsplanning en continue verbetering – in plaats van zich voornamelijk te laten concurreren op krimpende hardware‑marges.

De waarde ligt niet in het aanbevelen van de nieuwste GPU of het nieuwste cloudplatform. Het zit in weten wanneer een klant ze nodig heeft, wanneer niet, en wat er nog meer rond hen ontworpen moet worden.

AI‑infrastructuur is uiteindelijk geen hardware‑beslissing. Het is een architectuur‑beslissing die wordt gedreven door de workload, de data en het zakelijke resultaat dat de klant wil bereiken.

De MSP’s die dat onderscheid begrijpen, zullen zich kunnen positioneren als iets veel waardevollers dan infrastructuurleveranciers.

Zij zullen de mensen worden die klanten vertrouwen om te helpen bepalen welke infrastructuur ze daadwerkelijk nodig hebben.