Denise Muyco, medstifter og administrerende direktør for RAVEL – interviewserie

Denise Muyco er medstifter og administrerende direktør for RAVEL, hvor hun leder udviklingen af software til orkestrering af kompleks computerkraft og AI-infrastruktur. Hun er uddannet ingeniør, og hendes karriere spænder over energiinfrastruktur, procesoptimering, digitale medier, datacentre og virtuelle studier. Før hun fokuserede på AI, var hun med til at udvikle en fælles infrastruktur til højtydende databehandling for Vancouvers visuelle effektbranche, så omkring 30 studier fik adgang til computerkraft og sikre forbindelser. Den erfaring prægede hendes tilgang til at koordinere dyre og knappe ressourcer. Hos RAVEL anvender hun et systemteknisk perspektiv på placering af arbejdsbelastninger, udnyttelse af infrastruktur, interoperabilitet og de voksende krav fra distribuerede og suveræne AI-miljøer.

RAVEL udvikler software, der hjælper organisationer med at implementere, administrere og skalere computerkraft og AI-arbejdsbelastninger på tværs af cloud-, lokal og hybrid infrastruktur. Produkterne omfatter RAVEL Orchestrate til virtuelle arbejdsstationer med høj ydeevne, RAVEL Orchestrate AI til automatisering og optimering af arbejdsbelastninger samt Boost til softwarelicensering og telemetri. Virksomhedens værktøjer forbinder infrastruktur, applikationer, virtualisering og sikkerhed og giver samtidig centraliseret styring og operationelt overblik. RAVEL betjener datacentre, tjenesteudbydere, it-teams i virksomheder, AI-forskningsgrupper og kreative studier. Med udgangspunkt i sine rødder inden for digital indholdsproduktion fokuserer virksomheden på at forenkle komplekse miljøer og hjælpe teams med at udnytte deres tilgængelige infrastruktur mere effektivt.

Du grundlagde RAVEL efter i årevis at have arbejdet i krydsfeltet mellem ingeniørarbejde, medieinfrastruktur og distribueret databehandling. Hvad fik dig til at starte virksomheden, og hvordan har RAVELs mission udviklet sig, efter at generativ AI har øget efterspørgslen på computerkraft markant?

Jeg er uddannet ingeniør og har arbejdet i krydsfeltet mellem energi, computerkraft og infrastruktur længe før nutidens AI-boom. Tidligt i min karriere var jeg praktikant på et atomkraftværk, og senere gav mit arbejde inden for medier og visuelle effekter mig indblik i GPU’er, store behov for computerkraft og de begrænsninger, der følger med fysisk infrastruktur.

For omkring 16 år siden mærkede Vancouvers voksende visuelle effektbranche disse begrænsninger på nært hold. Studierne havde brug for enorme mængder computerkraft med høj ydeevne til at behandle (eller rendere) stadig mere komplekst film- og tv-indhold til værdifulde projekter, men kun få havde råd til at opbygge tilstrækkelig dedikeret infrastruktur til at dække spidsbelastninger i et sikkert miljø. Strømforsyningen var også ved at blive en begrænsning. Vi udviklede en fælles infrastruktur, som gav omkring 30 studier adgang til højtydende databehandling og sikre forbindelser med høj båndbredde.

Deling af infrastruktur løste ét problem, men skabte et andet: Hvordan fordeler man dyre og knappe ressourcer effektivt mellem organisationer og arbejdsbelastninger? Den erfaring førte i sidste ende til RAVELs tilgang til intelligent infrastrukturorkestrering.

AI er en langt større udgave af den samme grundlæggende udfordring – med langt større kompleksitet og kapital på spil. Arbejdsbelastningerne og infrastrukturen har ændret sig, men behovet for at få dyre og knappe ressourcer til at fungere effektivt sammen er kun blevet vigtigere.

Før RAVEL var du med til at skabe et konsortium af omkring 30 studier, lydscener, produktionsselskaber og visuelle effektstudier i Vancouver, som kunne dele adgangen til en infrastruktur til højtydende databehandling. Hvad lærte den erfaring dig om distribueret databehandling, og hvilke paralleller ser du mellem Hollywoods udfordringer med rendering dengang og AI-branchens infrastrukturudfordringer i dag?

Mit arbejde med VFX-branchen lærte mig, at opbygning og konfiguration af infrastrukturen kun var halvdelen af problemet. Den dyre computerkraft skulle deles sikkert og udnyttes effektivt, samtidig med at den bredere infrastruktur – herunder et sikkert netværk, der kunne overføre enorme filer – skulle fungere som en helhed. Arbejdsbelastninger skulle planlægges, kapacitet fordeles og enorme datamængder flyttes, alt imens produktionsteams stræbte efter stadig mere ambitiøse resultater inden for stramme budgetter og tidsfrister. Infrastrukturen skulle løbende optimeres med hensyn til udnyttelse og ydeevne.

AI er en langt større udgave af den samme grundlæggende udfordring. Organisationer investerer massivt i infrastruktur, men øget kapacitet alene er ingen garanti for, at dyre ressourcer bliver udnyttet effektivt. AI-infrastrukturen bliver også stadig mere distribueret på tværs af lokationer, udbydere og miljøer, drevet af krav til strøm, kapacitet, sikkerhed, økonomi, geografi, regulering og suverænitet. Rendering og AI kan være meget forskellige arbejdsbelastninger, men de deler en vigtig udfordring, når det gælder infrastruktur og økosystem: Begge kræver, at højtydende databehandling, netværk, sikkerhed og lagring fungerer effektivt sammen.

Efterhånden som AI-infrastrukturen bliver mere kompleks, løser det ikke den operationelle udfordring med at udnytte kapaciteten effektivt blot at tilføje mere computerkraft. Her bliver orkestrering og de politikker, der styrer det bredere infrastrukturekosystem, afgørende. Tilsammen hjælper de organisationer med at udnytte dyre og knappe ressourcer bedre, samtidig med at arbejdsbelastninger koordineres på tværs af stadig mere distribuerede miljøer.

RAVEL beskriver sig selv som et orkestreringslag til distribuerede AI-fabrikker. Hvad betyder en »AI-fabrik« for dig, og hvad mangler der i infrastrukturen i dag, som gør et orkestreringslag nødvendigt?

Sådan som jeg ser det, er en AI-fabrik mere end GPU’er og højtydende klynger; det er et integreret infrastrukturøkosystem, der samler beregningskraft, netværk, lagring, sikkerhed, strømforsyning, køling og de driftslag, der er nødvendige for at køre AI-arbejdsbelastninger. AI-fabrikker udvikler sig fra isolerede klynger til økosystemer af sammenkoblede ressourcer på tværs af flere lokationer og regioner. Den kompleksitet bliver stadig vanskeligere at håndtere manuelt eller med usammenhængende enkeltløsninger. Et orkestreringslag løser dette ved at koordinere de forskelligartede og komplekse dele af stakken og abstrahere noget af den underliggende kompleksitet, så infrastrukturen bliver lettere for operatører at administrere som et samlet system.

Når organisationer tilpasser eksisterende datacentre til AI, er mange af faciliteterne ikke oprindeligt designet til at imødekomme kravene fra nutidens AI-arbejdsbelastninger. AI står i dag over for et strukturelt misforhold, der består af tre centrale problemer. Det første er strømforsyning, altså at finde en lokation med tilstrækkelig pålidelig strøm til at afvikle arbejdsbelastninger i stor skala. Det andet er et fragmenteret økosystem, da AI-stakke ofte er fordelt på isolerede miljøer og ikke er designet til at fungere sammen. Det tredje er begrænset indsigt i de samlede drifts- og ejerskabsomkostninger, hvilket kan sløre de reelle omkostninger ved AI-infrastruktur. Derfor bliver arbejdsbelastninger måske ikke optimeret, hardware bliver måske ikke udnyttet fuldt ud, og uventede driftsomkostninger kan øge de samlede ejerskabsomkostninger og i sidste ende bidrage til højere tokenomkostninger.

AI-infrastruktur er i stigende grad fordelt på hyperskalerende cloudmiljøer, private datacentre, lokale systemer og specialiserede GPU-udbydere. Hvilke er de største udfordringer, organisationer møder, når de forsøger at administrere AI-arbejdsbelastninger på tværs af disse forskellige miljøer?

I flere år har kapløbet om AI-infrastruktur været præget af en enkel antagelse: Byg større. Større datacentre. Større klynger. Flere GPU’er. Mere kapacitet. Men modellen med at bygge større støder i stigende grad på fysiske, økonomiske og lovgivningsmæssige begrænsninger.

Strømforsyningen er begrænset. Det tager tid at få adgang til elnettet. Økonomi, geografi og suverænitet afgør i stigende grad, hvor infrastruktur kan og bør bygges. Den nye udfordring er ikke blot, hvordan man bygger mere AI-infrastruktur, men hvordan man bygger den rette infrastruktur de rette steder, samtidig med at alle disse miljøer får til at fungere som et koordineret system. Det bliver særligt vanskeligt, når kapaciteten er fordelt på hyperskalerende cloudmiljøer, private datacentre, lokal infrastruktur og specialiserede udbydere, som ikke nødvendigvis er designet til at fungere sammen.

Strømforsyningen er den mest kritiske af disse begrænsninger. I stigende grad er det adgangen til strøm, der afgør, hvor AI-infrastrukturen overhovedet bliver bygget.

Det er her, føderering bliver afgørende. Den forbinder infrastruktur på tværs af miljøer i et fælles driftsmiljø. Intelligent orkestrering afgør derefter, hvor arbejdsbelastninger skal afvikles, ud fra kapacitet, strømforsyning, ydeevne, omkostninger, politikker, robusthed og suverænitet.

Efterhånden som AI-infrastrukturen bliver mere udbredt, hvad enten det er på tværs af lokationer eller udbydere, vil den konkurrencemæssige fordel ikke blot komme af at eje mere kapacitet. Den kommer af at få kapaciteten til at fungere sammen. Føderering skaber infrastrukturmodellen for denne nye virkelighed, mens intelligent orkestrering gør det muligt at drive modellen i stor skala.

Det er den model, en af vores kunder, RT-One, der udvikler Latinamerikas største AI-teknologiparker og datacentre, følger i sine planer om fødereret infrastruktur på tværs af Amerika: at forbinde distribueret kapacitet, så den i sidste ende kan administreres som ét koordineret miljø.

Manglen på GPU’er har fået enorm opmærksomhed, men det betyder ikke nødvendigvis, at man får mere nyttig AI-beregningskapacitet ved blot at tilføje flere acceleratorer. Hvor ser du de største kilder til ineffektivitet i nutidens AI-infrastruktur, og hvor meget ekstra kapacitet kunne virksomheder frigøre med bedre orkestrering?

Kapløbet om AI-infrastruktur har i høj grad handlet om, hvor mange gigawatt ny kapacitet der planlægges, og hvor meget kapital der afsættes til at opføre den. Det er fristende at betragte AI’s infrastrukturproblem som en simpel mangel på GPU’er eller kapacitet, men den forståelse overser, hvor ineffektiviteten reelt ligger. Det er vigtigt at bemærke, at planlagt kapacitet ikke er det samme som brugbar kapacitet.

GPU-klynger kan se ud til at være fuldt booket, men dyre GPU’er kan stadig stå stille, når der opstår flaskehalse i ydeevnen andre steder i stakken. Det kan blandt andet skyldes lagergennemløb, datapipelines, overbelastning af netværket, ineffektiv jobplanlægning, sikkerhedskrav og manglende overensstemmelse mellem arkitektur, applikationer, drivere og afhængigheder. Flere GPU’er giver ikke altid mere brugbar beregningskapacitet.

Mere infrastruktur øger ikke automatisk effektiviteten. I mange tilfælde skaber det flere siloer og øger samtidig omkostningerne.

Organisationer har brug for større indsigt og kontrol, så de kan forbedre udnyttelsen, automatisere beslutninger om infrastruktur og bedre tilpasse arbejdsbelastninger til tilgængelige ressourcer og forretningsprioriteter. Større indsigt og kontrol kan bidrage til at omdanne en samling infrastrukturressourcer til et mere koordineret driftsmiljø. Der findes ikke noget præcist eller universelt tal for, hvor meget kapacitet der kan frigøres gennem orkestrering; hver arbejdsbelastning har sine egne krav. Men én ting er klar: Løsningen på fastlåst eller underudnyttet kapacitet er ikke blot at købe eller bygge mere.

RAVEL har lagt vægt på interoperabilitet mellem infrastruktur, virtualiseringsteknologier, identitetssystemer og applikationer. Hvorfor bliver interoperabilitet særlig vigtig, efterhånden som AI-arbejdsbelastninger bliver mere komplekse og distribuerede?

Efterhånden som infrastrukturen bliver mere heterogen, har organisationer brug for fleksibilitet til at anvende forskellige teknologier og miljøer uden at skabe flere isolerede infrastruktursiloer. Interoperabilitet gør det muligt for beregning, lagring, netværk og applikationer fra forskellige leverandører og miljøer at fungere sammen, så valgmulighederne bevares, efterhånden som infrastrukturen udvikler sig. Men interoperabilitet alene afgør ikke, hvordan disse ressourcer skal anvendes.

Det er her, orkestrering kommer ind i billedet – den koordinerer, hvor arbejdsbelastningerne afvikles, hvordan de flyttes, og hvordan politikker håndhæves på tværs af miljøer. Efterhånden som AI-infrastrukturen bliver stadig mere distribueret og fødereret, giver interoperabilitet fleksibilitet til at arbejde på tværs af teknologier, mens orkestrering samler ressourcerne i et koordineret driftsmiljø.

RAVEL Orchestrate AI leverer et fælles orkestreringslag på tværs af beregning, lagring, netværk og andre infrastrukturt teknologier og koordinerer AI-arbejdsbelastninger på tværs af cloud-, lokale og hybride miljøer.

Datasuverænitet er ved at blive en vigtig overvejelse for regeringer og virksomheder, der implementerer AI. Hvordan ændrer væksten i suveræn AI-infrastruktur den måde, organisationer bør forholde sig til placering af arbejdsbelastninger, dataflytning, sikkerhed og orkestrering på?

Suveræn AI er nu en strategisk prioritet. Med den følger et mere grundlæggende spørgsmål: Hvad vil det egentlig sige at være suveræn? Samtalen har i vid udstrækning fokuseret på, hvor data opbevares, men jeg mener, at denne definition er for snæver.

Jeg definerer suveræn AI som en nations, virksomheds, offentlig myndigheds eller anden organisations evne til at opretholde politikfastlagt kontrol over sine AI-arbejdsbelastninger – herunder de data, modeller, beregningsinfrastruktur, adgang, sikkerhed, drift og jurisdiktion, der regulerer arbejdsbelastningerne. Suverænitet betyder ikke nødvendigvis, at hver arbejdsbelastning skal forblive i ét datacenter eller endda på infrastruktur, der ejes af én enkelt organisation. Det betyder derimod, at organisationen fastlægger, hvor en arbejdsbelastning må afvikles, hvor dens data må befinde sig eller bevæge sig hen, hvem der må få adgang til dem, hvilken infrastruktur der må afvikle den, og hvilke sikkerhedsmæssige, lovgivningsmæssige, geografiske, driftsmæssige og forretningsmæssige politikker der altid skal overholdes. Denne arbejdsbelastningscentrerede definition stemmer overens med den bredere udvikling i branchen, hvor suverænitet betragtes som kontrol over hele AI-miljøet frem for alene som spørgsmålet om, hvor data opbevares.

RAVELs tilgang adskiller sig især, når suveræn AI møder føderering. RAVEL Orchestrate AI kan behandle suverænitetskrav som begrænsninger i orkestrerings- og politiklaget: En arbejdsbelastning kan være egnet til afvikling på tværs af en føderation af lokationer, clouds, datacentre, edge-lokationer eller anden infrastruktur, men kun på ressourcer, der opfylder arbejdsbelastningens suverænitetspolitikker. Inden for denne godkendte grænse kan RAVEL derefter finde den passende infrastruktur ud fra faktorer som strømforbrug, omkostninger, ydeevne, kapacitet, udnyttelse, netværksegenskaber, placering og prioritet. Føderering ophæver ikke suverænitet; den kan tværtimod fungere inden for de grænser, som suveræniteten fastlægger. En følsom offentlig arbejdsbelastning kan for eksempel forblive helt inden for godkendte amerikanske faciliteter, samtidig med at den dynamisk orkestreres mellem flere autoriserede lokationer. Resultatet er en model, hvor organisationer kan opnå fordelene ved højere udnyttelse og større robusthed fra distribueret AI-infrastruktur uden at give afkald på kontrollen over, hvor og hvordan deres mest følsomme arbejdsbelastninger afvikles.

RAVEL opstod i brancher som medier, underholdning, gaming og design, hvor arbejdsbelastninger kan være ekstremt beregningstunge. Hvordan har kravene fra generativ AI ændret platformen sammenlignet med de infrastrukturudfordringer, I oprindeligt løste for kreative fagfolk?

RAVEL blev skabt for at løse infrastrukturproblemer for kunstnere og ingeniører, der allerede afviklede omfattende arbejdsbelastninger inden for rendering, simulering og indholdsskabelse på tværs af dyre beregnings-, lager- og netværksressourcer. Den grundlæggende udfordring var at gøre heterogen infrastruktur lettere at tilgå, dele og orkestrere, samtidig med at udnyttelse og ydeevne blev maksimeret.

Generativ AI har øget omfanget og kompleksiteten af det samme problem dramatisk. I stedet for primært at orkestrere applikationer og renderingsopgaver skal vi nu tage højde for AI-modeller, motorer, agenter, trænings- og inferensarbejdsbelastninger, forskellige GPU-arkitekturer, softwarestakke i hastig forandring, omfattende dataflytning og betydeligt større begrænsninger med hensyn til strømforbrug, omkostninger, sikkerhed og tilgængelighed.

Som følge heraf har RAVEL udviklet sig fra primært at orkestrere beregningskapacitet til også at levere et intelligent kontrol- og optimeringslag til AI-infrastruktur. Orchestrate AI bruger telemetri og politikker til ikke blot at afgøre, om infrastrukturen er tilgængelig, men også hvor og hvordan en arbejdsbelastning skal køres ud fra faktorer som omkostninger, hastighed, strømforbrug, ydeevne, udnyttelsesgrad, placering og krav til suverænitet.

Føderering er også blevet stadig vigtigere, fordi AI-infrastruktur ikke længere kan betragtes som en samling isolerede datacentre. Organisationer har brug for at kunne udnytte kapacitet på tværs af lokationer på en intelligent måde og samtidig opretholde styring og sikkerhed. På mange måder ændrede generativ AI ikke det grundlæggende problem, RAVEL havde sat sig for at løse – den gjorde problemet langt større og mere komplekst og øgede dermed betydningen af intelligent orkestrering, optimering og føderering.

Din karriere har ført dig fra maskinteknik og procesoptimering hos Starbucks til digitale medier, datacentre, virtuelle studier og nu AI-infrastruktur. Hvordan har din ingeniørbaggrund præget din tilgang til at opbygge virksomheder og løse infrastrukturproblemer?

Min ingeniørbaggrund har sandsynligvis præget næsten alt ved den måde, jeg opbygger virksomheder på. Maskinteknik lærer én at se på et system – ikke kun på de enkelte komponenter – og spørge, hvor begrænsningerne er, hvor energi eller ressourcer går til spilde, og hvordan hele systemet kan fungere bedre. Hos Starbucks brugte jeg den tankegang til procesoptimering. Senere, inden for digitale medier og visuelle effekter, bestod systemet af beregningskapacitet, lagerplads, netværk, applikationer og efterhånden hele datacentre. Teknologien ændrede sig, men min tilgang til problemet gjorde det egentlig ikke. Jeg spørger altid: Hvor er flaskehalsen? Hvad udnyttes ikke fuldt ud? Hvad kan vi forenkle? Og hvordan får vi hele systemet til at fungere bedre i stedet for kun at optimere én del af det?

Det er i høj grad sådan, vi har opbygget RAVEL. Jeg mener ikke, at udfordringen med AI-infrastruktur blot handler om at skaffe flere GPU’er eller bygge flere datacentre. Det er et systemteknisk problem, der involverer beregningskapacitet, strøm, lagerplads, netværk, software, arbejdsbelastninger, mennesker og i stigende grad også geografi og suverænitet. Man kan have verdens hurtigste GPU, men hvis resten af systemet ikke er optimeret, har man blot skabt en meget dyr flaskehals. Derfor går vores tilgang hos RAVEL ud på at gøre selve infrastrukturen mere intelligent – ved hjælp af telemetri, politikker, orkestrering og føderering, så vi løbende kan afgøre, hvordan og hvor arbejdsbelastninger skal køres. Jeg begyndte min karriere med at optimere fysiske systemer; i dag bruger vi den samme ingeniørmæssige disciplin til at optimere den infrastruktur, der driver AI.

Hvordan forventer du, at AI-infrastrukturen vil udvikle sig, efterhånden som modeller, agenter og applikationer kræver stadig større mængder distribueret beregningskapacitet? Forestiller du dig, at AI-fabrikker bliver et standardiseret lag i virksomheders infrastruktur, sådan som cloud computing blev det i løbet af det seneste årti?

Jeg er helt overbevist om, at AI-fabrikker bliver et grundlæggende lag i virksomheders infrastruktur, ligesom cloud computing blev det – men jeg tror ikke, at de kommer til at ligne ét enkelt standardiseret datacenter eller én cloud. Efterhånden som modeller, agenter og applikationer bruger stadig større mængder beregningskapacitet, vil virksomheder benytte en mangfoldig blanding af GPU’er, CPU’er, privat infrastruktur, neoclouds, hyperscalere, edge-miljøer og specialiserede AI-systemer.

Adgang til strøm, omkostninger, suverænitet, ydeevne og placering bliver lige så vigtige som adgang til beregningskapacitet. Den egentlige udfordring bliver ikke blot at bygge mere infrastruktur, men at få al den distribuerede infrastruktur til at fungere som ét intelligent system. Fremtidens AI-fabrik er ikke én enkelt bygning – den er et fødereret infrastrukturlandskab, der spænder over beregningskapacitet, strøm, data og de ressourcer, der skal til for at køre AI-arbejdsbelastninger dér, hvor det giver bedst mening.

Jeg tror, det er her, det næste store infrastrukturlag opstår. Cloud computing abstraherede servere og gjorde det nemmere at bruge beregningskapacitet; næste skridt er at abstrahere kompleksiteten i hele AI-infrastrukturstakken. Virksomheder bør ikke være nødt til manuelt at afgøre, hvilken GPU, hvilket datacenter, hvilken cloud, hvilken strømkilde eller hvilken geografisk placering der skal bruges til hver enkelt model eller agent. Infrastrukturen bør i stigende grad træffe disse beslutninger selv og bruge telemetri og politikker til at optimere omkostninger, hastighed, strømforbrug, ydeevne, tilgængelighed og suverænitet. Det er den fremtid, vi arbejder hen imod hos RAVEL: et intelligent orkestreringslag, der gør det muligt at flytte arbejdsbelastninger på tværs af en fødereret AI-infrastruktur og samtidig bevare organisationens politikker og kontrolmekanismer. Cloud gjorde beregningskapacitet tilgængelig efter behov. Jeg tror, at næste generation af AI-infrastruktur vil gøre optimering tilgængelig efter behov.

Tak for et godt interview. Læsere, der gerne vil vide mere om orkestrering af AI-arbejdsbelastninger på tværs af distribueret infrastruktur, kan besøge RAVEL.