Denise Muyco, medgrunnlegger og administrerende direktør i RAVEL – intervjuserie

Denise Muyco er medgrunnlegger og administrerende direktør i RAVEL, der hun leder utviklingen av programvare for orkestrering av kompleks datakraft og AI-infrastruktur. Hun er utdannet ingeniør og har arbeidet med kraftinfrastruktur, prosessoptimalisering, digitale medier, datasentre og virtuelle studioer. Før hun begynte å fokusere på AI, bidro hun til å utvikle en felles infrastruktur for høyytelsesdatabehandling for Vancouvers miljø for visuelle effekter, slik at rundt 30 studioer fikk tilgang til datakraft og sikker tilkobling. Denne erfaringen formet hennes tilnærming til koordinering av kostbare og begrensede ressurser. I RAVEL bruker hun et systemteknisk perspektiv på plassering av arbeidsbelastninger, utnyttelse av infrastruktur, samvirkeevne og de økende kravene fra distribuerte og suverene AI-miljøer.

RAVEL utvikler programvare som hjelper organisasjoner med å ta i bruk, administrere og skalere arbeidsbelastninger for datakraft og AI på tvers av skybasert, lokal og hybrid infrastruktur. Produktene omfatter RAVEL Orchestrate for virtuelle arbeidsstasjoner med høy ytelse, RAVEL Orchestrate AI for automatisering og optimalisering av arbeidsbelastninger, og Boost for programvarelisenser og telemetri. Selskapets verktøy kobler sammen infrastruktur, applikasjoner, virtualisering og sikkerhet, samtidig som de gir sentralisert kontroll og operasjonell oversikt. RAVEL betjener datasentre, tjenesteleverandører, IT-team i bedrifter, AI-forskningsgrupper og kreative studioer. Med utgangspunkt i selskapets røtter innen digital innholdsproduksjon fokuserer det på å forenkle komplekse miljøer og hjelpe team med å utnytte infrastrukturen de har til rådighet, mer effektivt.

Du grunnla RAVEL etter flere år med arbeid i skjæringspunktet mellom ingeniørfag, medieinfrastruktur og distribuert databehandling. Hva var det til slutt som fikk deg til å starte selskapet, og hvordan har RAVELs oppdrag utviklet seg etter hvert som generativ AI har økt etterspørselen etter datakraft dramatisk?

Jeg er utdannet ingeniør og har arbeidet i skjæringspunktet mellom kraft, datakraft og infrastruktur lenge før dagens AI-boom. Tidlig i karrieren hadde jeg praksis ved et atomkraftverk, og senere gjorde arbeidet mitt innen medier og visuelle effekter meg kjent med GPU-er, store behov for datakraft og begrensningene ved fysisk infrastruktur.

For rundt 16 år siden møtte den voksende industrien for visuelle effekter i Vancouver disse begrensningene direkte. Studioene trengte enorme mengder datakraft med høy ytelse for å behandle (eller rendre) stadig mer komplekst film- og TV-innhold til prosjekter med høy verdi, men få av dem kunne forsvare å bygge nok dedikert infrastruktur til å dekke toppbehovet i et sikkert miljø. Tilgangen på strøm ble også en begrensning. Vi utviklet en felles infrastruktur som ga rundt 30 studioer tilgang til høyytelsesdatabehandling og sikker tilkobling med høy båndbredde.

Deling av infrastruktur løste ett problem, men skapte et annet: Hvordan fordeler man kostbare og begrensede ressurser effektivt mellom organisasjoner og arbeidsbelastninger? Denne erfaringen førte til slutt til RAVELs tilnærming til intelligent infrastrukturorkestrering.

AI er en langt større utgave av den samme grunnleggende utfordringen – med langt større kompleksitet og mer kapital på spill. Arbeidsbelastningene og infrastrukturen har endret seg, men behovet for å få kostbare og begrensede ressurser til å fungere effektivt sammen har bare blitt viktigere.

Før RAVEL bidro du til å opprette et konsortium bestående av rundt 30 studioer, lydscener, produksjonsselskaper og selskaper innen visuelle effekter i Vancouver, som kunne dele tilgangen til en infrastruktur for høyytelsesdatabehandling. Hva lærte denne erfaringen deg om distribuert databehandling, og hvilke paralleller ser du mellom Hollywoods utfordringer med rendering den gangen og infrastrukturutfordringene i dagens AI-bransje?

Arbeidet mitt med bransjen for visuelle effekter lærte meg at det å bygge og konfigurere infrastrukturen bare var halve utfordringen. Kostbar datakraft måtte deles på en sikker måte og brukes effektivt, samtidig som den øvrige infrastrukturen – blant annet et sikkert nettverk som kunne overføre enorme filer – måtte fungere som en helhet. Arbeidsbelastninger måtte planlegges, kapasitet fordeles og enorme datamengder flyttes, samtidig som produksjonsteamene ønsket stadig mer ambisiøse resultater innenfor stramme budsjetter og tidsfrister. Infrastrukturen måtte optimaliseres kontinuerlig med tanke på utnyttelse og ytelse.

AI er en langt større utgave av den samme grunnleggende utfordringen. Organisasjoner investerer tungt i infrastruktur, men økt kapasitet alene garanterer ikke at kostbare ressurser blir brukt effektivt. AI-infrastruktur blir også stadig mer distribuert på tvers av steder, leverandører og miljøer, drevet av krav knyttet til strøm, kapasitet, sikkerhet, økonomi, geografi, regelverk og suverenitet. Rendering og AI kan innebære svært ulike arbeidsbelastninger, men de deler en viktig utfordring knyttet til infrastruktur og økosystem: Begge er avhengige av at høyytelsesdatakraft, nettverk, sikkerhet og lagring fungerer effektivt sammen.

Etter hvert som AI-infrastrukturen blir mer kompleks, løser det ikke den operasjonelle utfordringen med å utnytte kapasiteten effektivt å bare legge til mer datakraft. Her blir orkestrering og retningslinjene som styrer det bredere infrastrukturøkosystemet, avgjørende. Sammen hjelper de organisasjoner med å utnytte kostbare og begrensede ressurser bedre, samtidig som de koordinerer arbeidsbelastninger på tvers av stadig mer distribuerte miljøer.

RAVEL beskriver seg selv som et orkestreringslag for distribuerte AI-fabrikker. Hva betyr en «AI-fabrikk» for deg, og hva mangler i dagens infrastrukturstakk som gjør et orkestreringslag nødvendig?

Slik jeg ser det, er en AI-fabrikk mer enn GPU-er og høyytelsesklynger; det er et integrert infrastrukturekosystem som samler beregningskapasitet, nettverk, lagring, sikkerhet, strømforsyning, kjøling og driftslagene som trengs for å kjøre AI-arbeidsbelastninger. AI-fabrikker utvikler seg fra isolerte klynger til økosystemer av sammenkoblede ressurser på tvers av flere steder og regioner. Denne kompleksiteten blir stadig vanskeligere å håndtere manuelt eller med usammenhengende punktløsninger. Et orkestreringslag løser dette ved å koordinere de ulike og komplekse delene av stakken og abstrahere noe av den underliggende kompleksiteten, slik at infrastrukturen blir enklere for operatørene å administrere som et samordnet system.

Når organisasjoner tilpasser eksisterende datasentre for AI, er mange anlegg ikke opprinnelig utformet for å dekke behovene til dagens AI-arbeidsbelastninger. AI står i dag overfor et strukturelt misforhold som kan deles inn i tre hovedproblemer. Det første er strømforsyning, eller å finne et sted med nok pålitelig strøm til å kjøre arbeidsbelastninger i stor skala. Det andre er fragmentering av økosystemet, ettersom AI-stakker ofte er fordelt på isolerte miljøer og ikke er utformet for å fungere sammen. Det tredje er begrenset innsyn i de samlede drifts- og eierkostnadene, noe som kan skjule de reelle kostnadene ved AI-infrastruktur. Resultatet kan være at arbeidsbelastninger ikke blir tilstrekkelig optimalisert, at maskinvare utnyttes for dårlig, og at uventede driftskostnader øker de samlede eierkostnadene, noe som til slutt bidrar til høyere tokenkostnader.

AI-infrastruktur er i økende grad fordelt på hyperskalerte skytjenester, private datasentre, lokale systemer og spesialiserte GPU-leverandører. Hvilke utfordringer møter organisasjoner oftest når de prøver å administrere AI-arbeidsbelastninger på tvers av disse ulike miljøene?

I flere år har kappløpet om AI-infrastruktur vært drevet av en enkel antakelse: bygg større. Større datasentre. Større klynger. Flere GPU-er. Større kapasitet. Men modellen om å bygge stadig større møter i økende grad fysiske, økonomiske og regulatoriske begrensninger.

Strømforsyningen er begrenset. Det tar tid å få tilgang til strømnettet. Økonomi, geografi og suverenitet avgjør i stadig større grad hvor infrastrukturen kan og bør bygges. Den nye utfordringen handler ikke bare om hvordan man bygger mer AI-infrastruktur, men om hvordan man bygger riktig infrastruktur på de riktige stedene, samtidig som alle disse miljøene får til å fungere som et samordnet system. Dette blir særlig vanskelig når kapasiteten er fordelt på hyperskalerte skytjenester, private datasentre, lokal infrastruktur og spesialiserte leverandører som ikke nødvendigvis er utformet for å fungere sammen.

Strømforsyning er den mest presserende av disse begrensningene. Tilgangen på strøm avgjør i stadig større grad hvor AI-infrastruktur bygges i utgangspunktet.

Det er her føderering blir avgjørende. Den kobler sammen infrastruktur på tvers av ulike miljøer og skaper et felles driftsmiljø. Intelligent orkestrering avgjør deretter hvor arbeidsbelastninger bør kjøres, basert på kapasitet, strømforsyning, ytelse, kostnader, retningslinjer, robusthet og suverenitet.

Etter hvert som AI-infrastrukturen blir mer spredt, enten på tvers av geografiske steder eller leverandører, vil konkurransefortrinnet ikke bare komme av å eie mer kapasitet. Det vil komme av å få kapasiteten til å fungere sammen. Føderering skaper infrastrukturen for denne nye virkeligheten, mens intelligent orkestrering gjør det mulig å drifte den modellen i stor skala.

Dette er modellen en av kundene våre, RT-One, utvikleren av Latin-Amerikas største AI-teknologiparker og datasentre, følger når selskapet planlegger føderert infrastruktur på tvers av Amerika: å koble sammen distribuert kapasitet slik at den til slutt kan administreres som ett samordnet miljø.

Knapphet på GPU-er har fått enorm oppmerksomhet, men det å legge til flere akseleratorer gir ikke nødvendigvis mer nyttig AI-beregningskapasitet. Hvor finner du de største kildene til ineffektivitet i dagens AI-infrastruktur, og hvor mye ekstra kapasitet kan selskaper frigjøre gjennom bedre orkestrering?

Kappløpet om AI-infrastruktur har i stor grad dreid seg om hvor mange gigawatt med ny kapasitet som er planlagt, og hvor mye kapital som skal investeres i å bygge den ut. Det er fristende å se på AI-infrastrukturproblemet som et rent spørsmål om mangel på GPU-er eller kapasitet, men dette perspektivet overser hvor ineffektiviteten faktisk ligger. Det er viktig å merke seg at planlagt kapasitet ikke er det samme som brukbar kapasitet.

GPU-klynger kan se ut til å være fullt opptatt, men dyre GPU-er kan likevel stå ubrukt når flaskehalser oppstår andre steder i stakken. Dette kan skyldes gjennomstrømming i lagringen, datapipelines, overbelastning av nettverket, ineffektiv jobbplanlegging, sikkerhetskrav og manglende samsvar mellom arkitektur, applikasjoner, drivere og avhengigheter. Flere GPU-er gir ikke alltid mer brukbar beregningskapasitet.

Mer infrastruktur fører ikke automatisk til høyere effektivitet. I mange tilfeller skaper det flere siloer og øker kostnadene.

Organisasjoner trenger bedre oversikt og kontroll for å kunne utnytte ressursene bedre, automatisere beslutninger om infrastruktur og tilpasse arbeidsbelastninger bedre til tilgjengelige ressurser og forretningsprioriteringer. Bedre oversikt og kontroll kan bidra til å gjøre en samling infrastrukturressurser til et mer koordinert driftsmiljø. Det finnes ikke noe nøyaktig eller universelt tall for hvor mye kapasitet som kan frigjøres gjennom orkestrering; hver arbeidsbelastning har unike krav. Men én ting er klart: Løsningen på kapasitet som står ubrukt eller utnyttes for dårlig, er ikke ganske enkelt å kjøpe eller bygge mer.

RAVEL har lagt vekt på samvirke mellom infrastruktur, virtualiseringsteknologier, identitetssystemer og applikasjoner. Hvorfor blir samvirke særlig viktig etter hvert som KI-arbeidsbelastninger blir mer komplekse og distribuerte?

Etter hvert som infrastrukturen blir mer heterogen, trenger organisasjoner fleksibilitet til å bruke ulike teknologier og miljøer uten å skape flere isolerte infrastruktursiloer. Samvirke gjør det mulig for datakraft, lagring, nettverk og applikasjoner fra ulike leverandører og miljøer å fungere sammen, slik at valgfriheten bevares etter hvert som infrastrukturen utvikler seg. Men samvirke alene avgjør ikke hvordan disse ressursene bør brukes.

Det er her orkestrering kommer inn – den koordinerer hvor arbeidsbelastninger kjøres, hvordan de flyttes, og hvordan retningslinjer håndheves på tvers av miljøer. Etter hvert som KI-infrastrukturen blir stadig mer distribuert og føderert, gir samvirke fleksibilitet til å arbeide på tvers av teknologier, mens orkestrering gjør disse ressursene til et koordinert driftsmiljø.

RAVEL Orchestrate AI tilbyr et felles orkestreringslag for datakraft, lagring, nettverk og andre infrastrukt teknologier, og koordinerer KI-arbeidsbelastninger på tvers av skybaserte, lokale og hybride miljøer.

Datasuverenitet blir stadig viktigere for myndigheter og bedrifter som tar i bruk KI. Hvordan påvirker veksten i suveren KI-infrastruktur måten organisasjoner må tenke på plassering av arbeidsbelastninger, dataflyt, sikkerhet og orkestrering?

Suveren KI er nå en strategisk prioritet. Med dette dukker et mer grunnleggende spørsmål opp: Hva vil det egentlig si å være suveren? Samtalen har i stor grad dreid seg om hvor data lagres, men jeg mener at denne definisjonen er for snever.

Jeg definerer suveren KI som en nasjons, bedrifts, offentlig etats eller annen organisasjons evne til å opprettholde policystyrt kontroll over KI-arbeidsbelastningene sine – inkludert dataene, modellene, datakraftinfrastrukturen, tilgangen, sikkerheten, driften og jurisdiksjonen som gjelder for disse arbeidsbelastningene. Suverenitet innebærer ikke nødvendigvis at alle arbeidsbelastninger må forbli i ett datasenter eller på infrastruktur som eies av én enkelt organisasjon. Det betyr snarere at organisasjonen fastsetter hvor en arbeidsbelastning kan kjøres, hvor dataene dens kan lagres eller overføres, hvem som kan få tilgang til dem, hvilken infrastruktur som kan kjøre den, og hvilke krav til sikkerhet, regelverk, geografi, drift og forretning som alltid må ivaretas. Denne arbeidsbelastningssentrerte definisjonen samsvarer med den bredere utviklingen i bransjen, der suverenitet forstås som kontroll over hele KI-miljøet snarere enn bare hvor data lagres.

RAVELs tilnærming skiller seg særlig ut når suveren KI møter føderering. RAVEL Orchestrate AI kan behandle suverenitetskrav som begrensninger i orkestrerings- og policylaget: En arbeidsbelastning kan være kvalifisert til å kjøre på tvers av et føderert nettverk av lokasjoner, skyer, datasentre, kantlokasjoner eller annen infrastruktur, men bare på ressurser som oppfyller suverenitetskravene for den aktuelle arbeidsbelastningen. Innenfor denne godkjente grensen kan RAVEL deretter finne den best egnede infrastrukturen ut fra faktorer som strømforbruk, kostnader, ytelse, kapasitet, ressursutnyttelse, nettverksegenskaper, lokasjon og prioritet. Føderering opphever ikke suverenitet; den kan tvert imot foregå innenfor grensene som suverenitetskravene setter. En sensitiv arbeidsbelastning for myndighetene kan for eksempel forbli utelukkende innenfor godkjente amerikanske anlegg, samtidig som den orkestreres dynamisk mellom flere autoriserte lokasjoner. Resultatet er en modell der organisasjoner kan dra nytte av bedre ressursutnyttelse og økt robusthet med distribuert KI-infrastruktur uten å gi fra seg kontrollen over hvor og hvordan de mest sensitive arbeidsbelastningene deres kjøres.

RAVEL oppsto i bransjer som medier, underholdning, spill og design, der arbeidsbelastningene kan være svært beregningsintensive. Hvordan har kravene til generativ KI endret plattformen sammenlignet med infrastrukturutfordringene dere opprinnelig skulle løse for kreative fagfolk?

RAVEL ble til for å løse infrastrukturproblemer for kunstnere og ingeniører som allerede kjørte omfattende arbeidsbelastninger innen gjengivelse, simulering og innholdsproduksjon på kostbare dataressurser, lagringsløsninger og nettverksressurser. Den grunnleggende utfordringen var hvordan man kunne gjøre heterogen infrastruktur enklere å få tilgang til, dele og orkestrere, samtidig som ressursutnyttelsen og ytelsen ble maksimert.

Generativ KI har økt omfanget og kompleksiteten i denne samme utfordringen dramatisk. I stedet for hovedsakelig å orkestrere applikasjoner og renderingsoppgaver må vi nå ta hensyn til KI-modeller, KI-motorer, agenter, arbeidsbelastninger for trening og inferens, ulike GPU-arkitekturer, programvarestakker i rask endring, enorme datamengder som må flyttes og betydelig strengere krav til strømforbruk, kostnader, sikkerhet og tilgjengelighet.

Som følge av dette har RAVEL utviklet seg fra hovedsakelig å orkestrere datakraft til å tilby et intelligent styrings- og optimaliseringslag for AI-infrastruktur. Orchestrate AI bruker telemetri og policyer til å avgjøre ikke bare om infrastrukturen er tilgjengelig, men også hvor og hvordan en arbeidsbelastning bør kjøres, basert på faktorer som kostnader, hastighet, strømforbruk, ytelse, utnyttelsesgrad, lokasjon og suverenitetskrav.

Federering har også blitt stadig viktigere, fordi AI-infrastruktur ikke lenger kan behandles som en samling isolerte datasentre. Organisasjoner må kunne utnytte kapasitet på tvers av lokasjoner på en intelligent måte, samtidig som de ivaretar styring og sikkerhet. På mange måter endret ikke generativ AI det grunnleggende problemet RAVEL skulle løse – den gjorde det dramatisk større og mer komplekst, og dermed ble intelligent orkestrering, optimalisering og federering stadig viktigere.

Karrieren din har ført deg fra maskinteknikk og prosessoptimalisering hos Starbucks til digitale medier, datasentre, virtuelle studioer og nå AI-infrastruktur. Hvordan har ingeniørbakgrunnen din påvirket måten du bygger selskaper og løser infrastrukturproblemer på?

Ingeniørbakgrunnen min har sannsynligvis påvirket nesten alt ved måten jeg bygger selskaper på. Maskinteknikk lærer deg å se på et system – ikke bare en enkelt komponent – og spørre hvor begrensningene ligger, hvor energi eller ressurser går til spille, og hvordan hele systemet kan fungere bedre. Hos Starbucks brukte jeg denne tankegangen til prosessoptimalisering. Senere, innen digitale medier og visuelle effekter, besto systemet av datakraft, lagring, nettverk, applikasjoner og etter hvert hele datasentre. Teknologien endret seg, men måten jeg gikk løs på problemet, gjorde det egentlig ikke. Jeg spør alltid: Hvor er flaskehalsen? Hva utnyttes for lite? Hva kan vi forenkle? Og hvordan får vi hele systemet til å fungere bedre i stedet for bare å optimalisere én del av det?

Det er i stor grad slik vi bygde RAVEL. Jeg mener ikke at problemet med AI-infrastruktur bare handler om å skaffe flere GPU-er eller bygge flere datasentre. Det er et systemteknisk problem som omfatter datakraft, strøm, lagring, nettverk, programvare, arbeidsbelastninger, mennesker og i stadig større grad geografi og suverenitet. Du kan ha verdens raskeste GPU, men hvis resten av systemet ikke er optimalisert, har du bare skapt en svært kostbar flaskehals. Derfor går RAVELs tilnærming ut på å gjøre selve infrastrukturen mer intelligent – ved hjelp av telemetri, policyer, orkestrering og federering som fortløpende avgjør hvordan og hvor arbeidsbelastninger bør kjøres. Jeg startet karrieren med å optimalisere fysiske systemer. I dag bruker vi den samme ingeniørmessige disiplinen til å optimalisere infrastrukturen som driver AI.

Hvordan tror du AI-infrastrukturen vil utvikle seg framover, etter hvert som modeller, agenter og applikasjoner krever stadig større mengder distribuert datakraft? Ser du for deg at AI-fabrikker blir et standardisert lag i virksomheters infrastruktur, på samme måte som nettskyen ble det det siste tiåret?

Jeg er helt overbevist om at AI-fabrikker vil bli et grunnleggende lag i virksomheters infrastruktur, omtrent slik nettskyen ble det – men jeg tror ikke de vil se ut som ett enkelt, standardisert datasenter eller én enkelt nettsky. Etter hvert som modeller, agenter og applikasjoner bruker stadig større mengder datakraft, vil virksomheter benytte en sammensatt blanding av GPU-er, CPU-er, privat infrastruktur, neoclouds, hyperskalere, kantmiljøer og spesialiserte AI-systemer.

Tilgang på strøm, kostnader, suverenitet, ytelse og lokasjon blir like viktig som tilgang på datakraft. Den virkelige utfordringen blir ikke bare å bygge mer infrastruktur, men å få all denne distribuerte infrastrukturen til å fungere som ett intelligent system. Framtidens AI-fabrikk er ikke én enkelt bygning – den er et føderert infrastrukturlandskap som omfatter datakraft, strøm, data og ressursene som trengs for å kjøre AI-arbeidsbelastninger der det gir mest mening.

Det er her jeg tror det neste store infrastrukturlaget vil oppstå. Nettskyen abstraherte bort serverne og gjorde datakraft enklere å ta i bruk. Neste steg er å abstrahere bort kompleksiteten i hele AI-infrastrukturlaget. Virksomheter bør ikke måtte avgjøre manuelt hvilken GPU, hvilket datasenter, hvilken nettsky, hvilken strømkilde eller hvilket geografisk område som skal kjøre hver modell eller agent. Infrastrukturen bør i stadig større grad ta disse beslutningene selv, ved hjelp av telemetri og policyer for å optimalisere kostnader, hastighet, strømforbruk, ytelse, tilgjengelighet og suverenitet. Det er denne framtiden vi bygger mot i RAVEL: et intelligent orkestreringslag som gjør det mulig å flytte arbeidsbelastninger mellom føderert AI-infrastruktur, samtidig som organisasjonens policyer og kontrollmekanismer ivaretas. Nettskyen gjorde datakraft tilgjengelig på forespørsel. Jeg tror neste generasjon AI-infrastruktur vil gjøre optimalisering tilgjengelig på forespørsel.

Takk for et flott intervju. Lesere som ønsker å lære mer om orkestrering av AI-arbeidsbelastninger på tvers av distribuert infrastruktur, bør besøke RAVEL.