Thought leaders

Brug tussen infrastructuur en productteams overbruggen: lessen uit de bouw van GenAI-platforms

mm
Voeg Unite.AI toe aan je voorkeursbronnen op Google

Er is geen twijfel over mogelijk: Generatieve AI, of GenAI, is het onderwerp van de dag, en dat is al een paar jaar zo. Of het doel nu is om processen te automatiseren, nieuwe productontwerpen te genereren, inhoud te creëren of een van de vele andere functies in domeinen, nu is het tijd voor organisaties om het werk te doen dat het meest telt en hun GenAI-strategieën in beweging te zetten.

Het succes van GenAI, dat werklasten omvat van onderzoek tot training en uiteindelijk inferentie, hangt af van een nauwe coördinatie rond implementatie, observatie, kostenbeheer, telemetrie en latentiedoelen van de onderliggende infrastructuur en services. Deze helpen een niveau van haalbare efficiëntie voor de AI-werklast te bereiken, waardoor een effectieve balans tussen berekening en communicatie ontstaat, waardoor GPUs altijd de benodigde gegevens hebben.

De uitdaging is dat er vaak een structurele kloof is: infrastructuurtechniek richt zich op de compute- en implementatiestack, terwijl software- en productteams zich concentreren op het bouwen van gebruikersgerichte toepassingen die GenAI in de echte wereld brengen. Wanneer deze groepen niet volledig zijn afgestemd, resulteert dit vaak in vertragingen bij de levering, prestatieproblemen en gebruikersproblemen.

Dus, hoe ziet deze kloof er in de praktijk uit, en welke strategieën kunnen organisaties gebruiken om infrastructuur- en productteams voor GenAI-succes af te stemmen?

De problemen met misalignement

Wanneer infrastructuur- en productteams niet zijn afgestemd, zijn de symptomen vaak duidelijk, maar worden ze niet altijd snel genoeg aangepakt. Een kenmerk van niet-afgestemde teams is de mismatch tussen verwachtingen over latentie of modelmogelijkheden. Bijvoorbeeld, infrastructuurtechniekteams kunnen functies of implementaties plannen die prestatieniveaus aannemen die het daadwerkelijke infrastructuurontwerp niet kan bijhouden. Dit leidt tot late herwerking, wijzigingen in het bereik en vertragingen bij de levering.

Misalignement kan ook leiden tot slechte prestaties vanwege het implementeren op niet-rail-geoptimaliseerde infrastructuur, wat zich manifesteert in latentievariaties en schaalbaarheidsproblemen die de prestaties van de training of grote gedistribueerde inferentiebanen beïnvloeden. Downstreambeveiligings- en compliance-risico’s zijn ook kenmerken van teammisalignement, aangezien een gebrek aan vroege samenwerking tussen de twee teams betekent dat gegevensbeschermings- en compliance-eisen kunnen worden genegeerd.

En ten slotte leidt teammisalignement tot een slechte gebruikerservaring, waardoor infrastructuurtechniekteams genoodzaakt worden om workarounds te gebruiken wanneer beperkingen onduidelijk zijn, waardoor iteratiecycli vertragen en technische schulden toenemen. Natuurlijk kan misalignement tussen product- en infrastructuurteams in elk softwareproject kostbaar zijn, maar met GenAI in het bijzonder zijn de inzetten veel hoger – toegenomen operationele inefficiënties, erosie van een concurrentievoordeel en beveiligingsrisico’s onder andere.

Brug naar succes

GenAI-succes hangt niet alleen af van het hebben van robuuste infrastructuur, maar ook van het creëren van een tactisch kader dat infrastructuur- en productprocessen verbindt. Neem bijvoorbeeld het idee van interne self-service-API’s voor GPU-toewijzing. Voor infrastructuurteams standaardiseren deze API’s de toegang, verminderen ze de ticketoverhead en waarborgen ze compliance; voor productteams bieden ze snelle, voorspelbare toegang tot compute zonder in een wachtrij te hoeven wachten. Het resultaat is dat beide groepen werken vanuit hetzelfde API-“contract”, waardoor bottlenecks worden verwijderd en verwachtingen worden verduidelijkt.

Realtime-gebruiksdashboards spelen een soortgelijke rol. Ze geven infrastructuurtechnici zichtbaarheid in systeemlading en efficiëntie, terwijl ze tegelijkertijd aan productteams laten zien hoe hun workloads worden vertaald in daadwerkelijke consumptie. Omdat beide partijen dezelfde gegevens zien, worden discussies over prestaties of bottlenecks meer collaboratief en minder tegenstrijdig – er is één enkele bron van waarheid.

Autoscaling is een ander unificerend mechanisme. Het verlicht infrastructuurtechnici van constant brandweerwerk, terwijl het ervoor zorgt dat productontwikkelaars geen prestatieplafonds bereiken tijdens workloadspikes. Wat anders een trek aan de touw tussen stabiliteit en flexibiliteit zou kunnen zijn, wordt een gezamenlijke strategie: schaal wordt automatisch beheerd, afgestemd op zowel operationele veerkracht als productprestatiedoelen.

Ten slotte voegen kosteninzichten een financiële dimensie toe aan deze gedeelde visie. Infrastructuurteams kunnen toewijzingen optimaliseren en capaciteitsplanning rechtvaardigen, terwijl productteams een waardering krijgen voor hoe hun architectonische of modelkeuzes de uitgaven beïnvloeden. Deze transparantie bevordert gezamenlijke verantwoordelijkheid, waardoor efficiëntie een collectieve verantwoordelijkheid wordt in plaats van een verborgen zorg.

Maar afstemming vereist meer dan gedeelde tools – het vereist ook een gedeelde visie. Dit is waar gezamenlijke roadmaps binnenkomen: elk team moet niet alleen de overkoepelende doelen begrijpen, maar ook de stappen die nodig zijn om ze te bereiken. Voor infrastructuur betekent dit dat men moet kijken beyond de diepe technische wortels in hardware en software om te engageren met hoe ontwikkelaars en eindgebruikers daadwerkelijk de systeem ervaren. Voor productteams betekent dit dat men respect moet hebben voor beperkingen zoals latentie, kosten en model-efficiëntie, waardering voor de operationele realiteiten die innovatie duurzaam maken.

Ten slotte kan geen enkele partnership standhouden zonder een wederzijdse toewijding aan beveiliging en compliance. Of het nu gaat om SOC2, HIPAA, ISO of andere kaders, de specifieke vereisten variëren met de klantbasis en de industrieverticale – maar de verantwoordelijkheid is gedeeld. Zowel infrastructuur- als productteams moeten deze verplichtingen internaliseren, erkennend dat compliance geen oefening in het afvinken van vakjes is, maar een fundament van vertrouwen met gebruikers.

Al deze praktijken en mentaliteiten verweven infrastructuur en product tot een coherente eenheid, met een gedeelde taal, gedeelde zichtbaarheid en gedeelde verantwoordelijkheid voor vooruitgang, veerkracht en betrouwbaarheid.

Kundige teams

Het hebben van de juiste mensen is net zo belangrijk als het hebben van de juiste systemen. Idealerwijze zouden teams moeten bestaan uit teamleden die al bekend zijn met GenAI, of die afkomstig zijn uit high-performance computing en hyperscale datacenter-achtergronden. Wat echt telt, is praktische ervaring en de lessen die je alleen maar kunt leren door GPU-as-a-service-platforms te bouwen en te ondersteunen. Dat betekent dat je begrijpt hoe GPUs met elkaar communiceren, hoe strak gekoppelde trainingsruns zich gedragen en hoe gevoelig ze zijn voor latentie, synchronisatie en gegevenslevering.

Terwijl modellen blijven groeien en implementaties opschalen, moeten teams ook een stap terug doen en nadenken over de volledige klantreis. Het begint met vroeg onderzoek en experimenten, gaat verder met grootschalige training, vervolgens fijnslijpen en uiteindelijk inferentie. Elk van deze fasen ziet er een beetje anders uit, en de behoeften veranderen onderweg. De iteratieve aard van modelontwikkeling leert ons voortdurend wat voor soort infrastructuur, workflows en mogelijkheden nodig zijn om een GenAI-datacenter geschikt te maken voor zijn doel.

Te vaak opereren infrastructuur- en productteams in hun eigen bubbel. Voor elk bedrijf dat serieus is over het opschalen van GenAI naar productie, moet dat veranderen. Succes hangt af van het afbreken van die silo’s en het creëren van gedeelde eigendom van het platform. Met de juiste mensen, een duidelijke visie en een praktisch kader kunnen beide partijen zich afstemmen op hetzelfde spelboek – een dat hen helpt om sneller te bewegen, verantwoordelijk te blijven en uiteindelijk succesvolle GenAI-implementaties te leveren.

Drew Pletcher is Principal Architect en Netwerkengineer bij Voltage Park, waar hij de ontwerp leidt van de volgende generatie AI-fabrieken, grote dataservers die speciaal zijn ontwikkeld voor alle aspecten van AI-werklasten met behulp van geavanceerde AI-modellen. Hij richt zich op het integreren van compute, netwerken en opslag in schaalbare, robuuste en energie-efficiënte systemen die de AI-fabrieken van Voltage Park mogelijk maken. Met ervaring bij Cisco Systems, 3Com en leiderschapsrollen als CTO voor een handelsstartup, en het werken met veel van de grootste hyperscale-omgevingen, heeft Drew oplossingen ontwikkeld die variëren van ultra-lage latentie handelsinfrastructuur tot AI-platforms voor anomaliedetectie en menselijk gedragsanalyse. Hij werd erkend als een wereldwijd expert in high-performance computing en low-latency netwerken, wat resulteerde in zijn vertegenwoordiging van Cisco in de Ferrari Formula 1 Technical Advisory Board.

Drew is bekend met het verbinden van geavanceerd onderzoek en ontwikkeling met productieschaalinfrastructuur, waardoor organisaties de volgende golf van computing kunnen anticiperen. Vandaag de dag vormt hij de blauwdruk van de toekomstige AI-datacenters, waar prestaties, automatisering en duurzaamheid samenkomen.