Att bygga broar mellan infrastruktur- och produktteam: Lärdomar från att bygga GenAI-plattformar

Det råder ingen tvekan om att: Generativ AI, eller GenAI, är det mest omtalade ämnet just nu, och har varit det under de senaste åren. Oavsett om målet är att automatisera processer, generera nya produktutformningar, skapa innehåll eller något annat i olika områden, är det dags för organisationer att börja med det viktigaste arbetet och sätta sina GenAI-strategier i rörelse.

GenAI:s framgång, som omfattar arbetsbelastningar från forskning till utbildning och slutligen inferens, beror på en tät samordning kring distribution, övervakbarhet, kostnadsstyrning, telemetri och latensmål för den underliggande infrastrukturen och tjänsterna. Dessa bidrar till att driva en nivå av uppnåelig effektivitet för AI-arbetsbelastningen, vilket säkerställer en effektiv balans mellan beräkning och kommunikation, och ser till att GPU:er alltid har den data som behövs.

Utmaningen är att det ofta finns en strukturell klyfta: Infrastrukturutveckling fokuserar på beräknings- och distributionsstacken, medan programvaru- och produktteam koncentrerar sig på att bygga användarvänliga applikationer som för GenAI in i den verkliga världen. När dessa grupper inte är fullständigt samordnade, leder det ofta till förseningar i leveransen, prestandaproblem och användbarhetsproblem.

Så, vad ser denna klyfta ut som i den verkliga världen, och vilka strategier kan organisationer använda för att samordna infrastruktur- och produktteam för GenAI:s framgång?

Problem med feljustering

När infrastruktur- och produktteam är feljusterade, är symtomen ofta uppenbara, men inte alltid åtgärdade tillräckligt snabbt. Ett kännetecken för ojusterade team är oeniga antaganden om förväntningar på latens eller modellförmåga. Till exempel kan infrastrukturutvecklingsteam planera funktioner eller distributioner som förutsätter prestandanivåer som den faktiska infrastrukturdesignen inte matchar. Detta leder till sent omarbete, ändringar av omfattning och förseningar i leveransen.

Feljustering kan också leda till dålig prestanda på grund av distribution på icke-järnvägsoptimerad infrastruktur, vilket visar sig i varianter av latens och skalbarhetsproblem som påverkar prestandan för utbildning eller stora distribuerade inferensjobb. Nedströms säkerhets- och regelefterlevnadsrisker är också kännetecken för teamfeljustering, eftersom bristande tidig samverkan mellan de två teamen innebär att kraven på dataskydd och regelefterlevnad kan förbises.

Och slutligen leder teamfeljustering till dålig användarupplevelse, vilket får infrastrukturutvecklingsteam att använda sig av lösningar när begränsningarna är oklara, vilket bromsar itereringscyklerna och ökar den tekniska skulden. Naturligtvis kan feljustering mellan produkt- och infrastrukturteam vara kostsamt i alla mjukvaruprojekt, men när det gäller GenAI i synnerhet är insatserna mycket högre – ökade operativa ineffektiviteter, urholkning av en konkurrensfördel och säkerhetsrisker bland annat.

Bro till framgång

GenAI:s framgång beror inte bara på att ha en robust infrastruktur, utan också på att skapa en taktisk ram som kopplar samman infrastruktur- och produktprocesser. Ta till exempel idén om interna självbetjänings-API:er för GPU-allokering. För infrastrukturteam standardiserar dessa API:er åtkomst, minskar biljettbelastningen och säkerställer regelefterlevnad; för produktteam ger de snabb och förutsägbar åtkomst till beräkning utan att behöva vänta i en kö. Resultatet är att båda grupperna arbetar från samma API-“avtal”, vilket tar bort flaskhalsar och förtydligar förväntningar.

Real-tidsanvändningspaneler spelar en liknande roll. De ger infrastrukturutvecklare synlighet i systembelastning och effektivitet, samtidigt som de visar produktteam hur deras arbetsbelastningar översätts till faktisk konsumtion. Eftersom båda sidor ser samma data, blir diskussioner om prestanda eller flaskhalsar mer samarbetsinriktade och mindre antagonistiska – det finns en enda sanning.

Auto-skala är ett annat enhetande mekanism. Det befriar infrastrukturutvecklare från konstant brandbekämpning, samtidigt som det säkerställer att produktutvecklare inte når prestandatakar under arbetsbelastningstoppar. Det som annars kunde bli en dragkamp mellan stabilitet och agility blir en gemensam strategi: Skala hanteras automatiskt, i linje med både operativ motståndskraft och produktprestandamål.

Slutligen lägger kostnadsinsikter till en finansiell dimension i denna gemensamma vy. Infrastrukturteam kan optimera tilldelningar och motivera kapacitetsplanering, medan produktteam får en uppskattning av hur deras arkitektoniska eller modellval påverkar utgifterna. Denna transparens främjar gemensamt ansvar, vilket förvandlar effektivitet till ett kollektivt ansvar snarare än en dold oro.

Men justering kräver mer än delade verktyg – det kräver också en gemensam vision. Här kommer gemensamma vägkartor in i bilden: Varje team måste inte bara förstå de övergripande målen, utan också de steg som krävs för att uppnå dem. För infrastruktur innebär det att se bortom de tekniska rötterna i hårdvara och programvara och engagera sig i hur utvecklare och slutanvändare faktiskt upplever systemet. För produktteam kräver det en respekt för begränsningar som latens, kostnad och modell-effektivitet, och en uppskattning av de operativa realiteter som gör innovationen hållbar.

Slutligen kan ingen partnerskap bestå utan ett ömsesidigt åtagande till säkerhet och regelefterlevnad. Oavsett om det gäller SOC2, HIPAA, ISO eller andra ramverk, varierar de specifika kraven med kundbas och branschvertikal – men ansvaret är delat. Både infrastruktur- och produktteam måste internalisera dessa skyldigheter, och inse att regelefterlevnad inte är en övning i att bocka av rutor, utan en grund för förtroende med användare.

Tagna tillsammans knyter dessa metoder och attityder samman infrastruktur och produkt till en sammanhängande enhet, med en gemensam språk, gemensam synlighet och gemensamt ansvar för framsteg, motståndskraft och tillförlitlighet.

Kunniga team

Att ha rätt människor är lika viktigt som att ha rätt system. Idealt sett bör teamen bestå av medlemmar som redan känner till GenAI, eller de som kommer från högpresterande datorer och hyperskala datacenterbakgrunder. Det som verkligen spelar roll är praktisk erfarenhet och de lärdomar man bara kan få från att bygga och stödja GPU-as-a-service-plattformar. Det innebär att förstå hur GPU:er pratar med varandra, hur tätt sammankopplade utbildningskörningar beter sig, och hur känsliga de är för latens, synkronisering och dataleverans.

När modellerna fortsätter att växa och distributionerna skalar upp, behöver teamen också ta ett steg tillbaka och tänka på den fullständiga kundresan. Den börjar med tidig forskning och experiment, flyttar sedan till stor skala utbildning, sedan finjustering och slutligen inferens. Var och en av dessa faser ser lite annorlunda ut, och behoven ändras på vägen. Den iterativa naturen av modellutveckling lär oss ständigt vad för sorts infrastruktur, arbetsflöden och förmågor som krävs för att hålla en GenAI-datacenter i skick.

Alltför ofta opererar infrastruktur- och produktteam i sina egna bubblor. För alla företag som är allvarliga med att skala GenAI till produktion, måste det förändras. Framgång beror på att bryta ner dessa silos och skapa en gemensam äganderätt till plattformen. Med rätt människor, en tydlig vision och en praktisk ram, kan båda sidor samordna sig kring samma spelbok – en som hjälper dem att flytta snabbare, hålla sig ansvariga och slutligen leverera lyckade GenAI-distributioner.