Tankeledere

Broen mellom infrastruktur og produktteam: Lærdommer fra bygging av GenAI-plattformer

mm
Legg til Unite.AI blant dine foretrukne kilder på Google

Det er ingen tvil om det: Generative AI, eller GenAI, er emnet for dagen, og har vært det i løpet av de siste par årene. Uansett om målet er å automatisere prosesser, generere nye produkt-design, skape innhold eller en rekke andre funksjoner over domener, er det nå på tide for organisasjoner å begynne å gjøre det arbeidet som betyr mest og sette sine GenAI-strategier i bevegelse.

Suksessen med GenAI, som omfatter arbeidsbelastninger fra forskning til trening og til slutt inferens, avhenger av tett koordinering rundt distribusjon, overvåkbarhet, kostnadsstyring, telemetri og latensmål for den underliggende infrastrukturen og tjenestene. Disse hjelper med å drive en niveau av oppnåelig effisiens for AI-arbeidsbelastningen, og sikrer en effektiv balanse mellom beregning og kommunikasjon, og sikrer at GPUer alltid har nødvendige data.

Utfordringen er at det ofte er en strukturell gap: Infrastrukturteknologi fokuserer på beregnings- og distribusjonsstakken, mens programvare- og produktteam konsentrerer seg om å bygge bruker-orienterte applikasjoner som bringer GenAI inn i den virkelige verden. Når disse gruppene ikke er fullstendig samordnet, resulterer det ofte i leveringsforsinkelser, ytelsesproblemer og brukerproblemer.

Så, hva ser denne gapen ut som i den virkelige verden, og hva strategier kan organisasjoner bruke til å samordne infrastruktur og produktteam for GenAI-suksess?

Problemer med misalignement

Når infrastruktur og produktteam er misalignert, er symptomene ofte åpenbare, men ikke alltid adressert raskt nok. Et kjennetegn på usammenhengende team er mismatchede antagelser om latensforventninger eller modellkapasiteter. For eksempel kan infrastrukturteknologi-team planlegge funksjoner eller distribusjoner som antar ytelsesnivåer som den faktiske infrastrukturdesignet ikke matcher. Dette fører til senere omarbeid, endringer i omfang og leveringsforsinkelser.

Misalignement kan også føre til dårlig ytelse på grunn av distribusjon på ikke-jernbane-optimert infrastruktur, som manifesterer seg i latensvariasjoner og skalerbarhetsproblemer som påvirker ytelsen av trening eller store distribuerte inferensjobber. Nedstrøms sikkerhets- og retningslinjerisiko er også kjennetegn på team-misalignement, da mangelen på tidlig samarbeid mellom de to teamene betyr at data-privatitet og retningslinjer kan oversees.

Og til slutt, fører team-misalignement til dårlig brukeropplevelse, som får infrastrukturteknologi-team til å bruke midler når begrensninger er uklare, og sakte iterasjons-sykluser og øke teknisk gjeld. Selvfølgelig kan misalignement mellom produkt- og infrastrukturteam være kostbart i ethvert programvareprosjekt, men med GenAI i særdeleshet, er innsatsen mye høyere — økte operasjonelle ineffisienser, erosjon av en konkurransefordel og sikkerhetsrisiko blant dem.

Bro til suksess

GenAI-suksess avhenger ikke bare av å ha robust infrastruktur, men også av å skape en taktisk ramme som kobler infrastruktur- og produktprosesser. Ta for eksempel ideen om interne selvbetjenings-APIer for GPU-tilrettelegging. For infrastrukturteam, standardiserer disse API-ene tilgang, reduserer billett-overhodet og sikrer retningslinjer; for produktteam, gir de rask, forutsigbar tilgang til beregning uten å vente i en kø. Resultatet er at begge grupper arbeider fra samme API-“kontrakt”, fjerner flaskhalser og klargjør forventninger.

Sanntids-bruksgrafikker spiller en lignende rolle. De gir infrastrukturteknologer synlighet inn i systemlast og effisiens samtidig som de viser produktteam hvordan deres arbeidsbelastninger oversettes til faktisk forbruk. Fordi begge sider ser samme data, blir diskusjoner om ytelse eller flaskhalser mer samarbeidende og mindre konfronterende — det er en enkelt kilde til sannhet.

Auto-skalerings er en annen samordnende mekanisme. Den lettet infrastrukturteknologer fra konstant brannslukking samtidig som den sikrer at produktutviklere ikke treffer ytelses-tak under arbeidsbelastnings-spor. Hva som ellers kunne være en tug-of-war mellom stabilitet og fleksibilitet blir en felles strategi: Skala styres automatisk, i tråd med både operasjonell motstandskraft og produkt-ytelse-mål.

Til slutt, legger kostnadsinnsikt en finansiell dimensjon til denne felles visningen. Infrastrukturteam kan optimalisere tildelinger og rettferdiggjøre kapasitetsplanlegging, mens produktteam får en forståelse for hvordan deres arkitektoniske eller modellvalg påvirker utgifter. Denne gjennomsiktigheten fremmer felles ansvar, og gjør effisiens til en kollektiv ansvar i stedet for en skjult bekymring.

Men samordning krever mer enn felles verktøy — det krever også en felles visjon. Dette er der joint roadmaps kommer inn: Hver team må ikke bare forstå de overordnede målene, men også de trinnene som er nødvendige for å nå dem. For infrastruktur, betyr det å se bort fra dype tekniske røtter i maskinvare og programvare til å engasjere seg med hvordan utviklere og sluttbrukere faktisk opplever systemet. For produktteam, krever det en respekt for begrensninger som latens, kostnad og modell-effisiens, og å verdsette de operasjonelle realitetene som gjør innovasjon bærekraftig.

Til slutt, kan ingen partnerskap vare uten en gjensidig forpliktelse til sikkerhet og retningslinjer. Uansett om SOC2, HIPAA, ISO eller andre rammer gjelder, varierer de spesifikke kravene med kunde-base og industri-vertikal — men ansvaret er delt. Begge infrastruktur- og produktteam må internalisere disse forpliktelsene, og erkjenne at retningslinjer ikke er en boks-avkryssings-øvelse, men en grunn til tillit med brukere.

Tatt sammen, syr disse praksisene og holdningene infrastruktur og produkt sammen til en samordnet enhet, med felles språk, felles synlighet og felles ansvar for fremgang, motstandskraft og tillit.

Kunnskapsrike team

Å ha rett mennesker er like viktig som å ha rett systemer. Ideelt sett, bør teamene inkludere teammedlemmer som allerede kjenner veien rundt GenAI, eller de som kommer fra høy-ytelses datalagrings- og hyperskala-data-senter-bakgrunner. Det som virkelig betyr noe, er praktisk erfaring og lærdommene du bare får fra å bygge og støtte GPU-tilretteleggingsplattformer. Det betyr å forstå hvordan GPUer snakker med hverandre, hvordan tett koblet trening kjører, og hvor sensitive de er til latens, synkronisering og levering av data.

Ettersom modellene fortsatt vokser og distribusjonene skalerer opp, må teamene også gå tilbake og tenke på hele kunde-reisen. Det begynner med tidlig forskning og eksperimentering, går inn i stor-skala-trening, deretter fin-justering og til slutt inferens. Hver av disse fasene ser litt annerledes ut, og behovene endrer seg underveis. Den iterative naturen til modellutvikling lærer oss stadig hva slags infrastruktur, arbeidsflyter og evner som er nødvendige for å holde en GenAI-datalagringsenhet i stand.

For ofte opererer infrastruktur- og produktteam i sine egne bobler. For ethvert selskap som er alvorlig om å skalerer GenAI inn i produksjon, må det endre seg. Suksess avhenger av å bryte ned disse siloene og skape felles eierskap av plattformen. Med rett mennesker, en klar visjon og en praktisk ramme, kan begge sider samordne seg på samme spilleregler — en som hjelper dem å flytte raskere, holde ansvar og til slutt levere suksessfulle GenAI-distribusjoner.

Drew Pletcher er Principal Architect og Network Engineer i Voltage Park, der han leder designet av neste generasjons AI-fabrikker, store datasentre som er spesialbygget for alle aspekter av AI-arbeidsbelastninger med avanserte AI-modeller. Han fokuserer på å integrere beregning, nettverk og lagring i skalerbare, resiliente og energieffektive systemer som muliggjør Voltage Parks AI-fabrikker. Med erfaring fra Cisco Systems, 3Com og lederroller som CTO for en handelsstartup, og arbeidet nært med mange av de største hyperskala-miljøene, har Drew designet løsninger som spenner fra ultra-lav-latens handelsinfrastruktur til AI-plattformer for anomali-deteksjon og analyse av menneskelig atferd. Han ble anerkjent som en verdensomspennende ekspert på høy-ytelsesregning og lav-latens nettverking, noe som resulterte i at han representerte Cisco på Ferrari Formula 1 Technical Advisory Board.

Drew er kjent for å kombinere avansert FoU med produksjons-skala infrastruktur, og hjelper organisasjoner med å forutse den neste bølgen av databehandling. I dag former han blåkopien for fremtidens AI-datasentre, der ytelse, automatisering og bærekraft konvergerer.