Denise Muyco, medgrundare och vd för RAVEL – intervjuserie

Denise Muyco är medgrundare och vd för RAVEL, där hon leder utvecklingen av orkestreringsprogramvara för komplex beräknings- och AI-infrastruktur. Hon är utbildad ingenjör och har under sin karriär arbetat med energiinfrastruktur, processoptimering, digitala medier, datacenter och virtuella studior. Innan hon började fokusera på AI bidrog hon till att utveckla en gemensam infrastruktur för högpresterande databehandling åt Vancouvers bransch för visuella effekter, vilket gav omkring 30 studior tillgång till beräkningsresurser och säker anslutning. Den erfarenheten formade hennes syn på hur kostsamma och begränsade resurser ska samordnas. På RAVEL tillämpar hon ett systemtekniskt perspektiv på placering av arbetsbelastningar, infrastrukturanvändning, interoperabilitet och de växande behoven i distribuerade och suveräna AI-miljöer.

RAVEL utvecklar programvara som hjälper organisationer att driftsätta, hantera och skala upp beräknings- och AI-arbetsbelastningar i molnbaserad, lokal och hybrid infrastruktur. Bland företagets produkter finns RAVEL Orchestrate för virtuella arbetsstationer med hög prestanda, RAVEL Orchestrate AI för automatisering och optimering av arbetsbelastningar samt Boost för programvarulicenser och telemetri. Företagets verktyg kopplar samman infrastruktur, applikationer, virtualisering och säkerhet och ger samtidigt centraliserad styrning och insyn i driften. RAVEL vänder sig till datacenter, tjänsteleverantörer, företags IT-team, AI-forskningsgrupper och kreativa studior. Med rötter i digital innehållsproduktion fokuserar företaget på att förenkla komplexa miljöer och hjälpa team att använda den infrastruktur de har tillgång till mer effektivt.

Du grundade RAVEL efter många år i skärningspunkten mellan teknik, medieinfrastruktur och distribuerad databehandling. Vad fick dig till slut att starta företaget, och hur har RAVEL:s uppdrag utvecklats i takt med att generativ AI kraftigt har ökat efterfrågan på beräkningskapacitet?

Jag är ingenjör i grunden och har arbetat i skärningspunkten mellan energi, beräkningskapacitet och infrastruktur långt före dagens AI-boom. I början av karriären praktiserade jag på ett kärnkraftverk, och senare fick jag genom mitt arbete inom medier och visuella effekter erfarenhet av grafikprocessorer, omfattande beräkningsbehov och den fysiska infrastrukturens begränsningar.

För omkring 16 år sedan började den växande branschen för visuella effekter i Vancouver att direkt stöta på de här begränsningarna. Studior behövde enorma mängder högpresterande beräkningskapacitet för att bearbeta (eller rendera) allt mer komplext film- och tv-innehåll för värdefulla projekt, men få kunde motivera att bygga tillräckligt mycket egen infrastruktur för att klara toppbelastningen i en säker miljö. Även tillgången på el började bli en begränsning. Vi utvecklade en gemensam infrastruktur som gav omkring 30 studior tillgång till högpresterande databehandling och säker anslutning med hög bandbredd.

Att dela infrastruktur löste ett problem men skapade ett annat: hur fördelar man kostsamma och begränsade resurser effektivt mellan olika organisationer och arbetsbelastningar? Den erfarenheten ledde så småningom till RAVEL:s strategi för intelligent infrastrukturorkestrering.

AI är en betydligt större version av samma grundläggande utmaning – med mycket större komplexitet och kapital på spel. Arbetsbelastningarna och infrastrukturen har förändrats, men behovet av att få kostsamma och begränsade resurser att fungera effektivt tillsammans har bara blivit viktigare.

Innan RAVEL hjälpte du till att skapa ett konsortium med omkring 30 studior, ljudscener, produktionsbolag och företag inom visuella effekter i Vancouver, som kunde dela på tillgången till en infrastruktur för högpresterande databehandling. Vad lärde den erfarenheten dig om distribuerad databehandling, och vilka paralleller ser du mellan Hollywoods renderingsutmaningar då och AI-branschens infrastrukturutmaningar i dag?

Mitt arbete med branschen för visuella effekter lärde mig att själva uppbyggnaden och konfigureringen av infrastrukturen bara var halva utmaningen. Kostsamma beräkningsresurser behövde delas på ett säkert sätt och användas effektivt, samtidigt som den bredare infrastrukturen – däribland ett säkert nätverk som kunde överföra enorma filer – behövde fungera som en helhet. Arbetsbelastningar behövde schemaläggas, kapacitet fördelas och enorma datamängder flyttas, samtidigt som produktionsteamen strävade efter allt mer ambitiösa resultat inom strama budgetar och tidsramar. Infrastrukturen behövde kontinuerligt optimeras för resursutnyttjande och prestanda.

AI är en betydligt större version av samma grundläggande utmaning. Organisationer investerar stort i infrastruktur, men ökad kapacitet i sig garanterar inte att kostsamma resurser används effektivt. AI-infrastrukturen blir också allt mer distribuerad mellan olika platser, leverantörer och miljöer, drivet av behov kopplade till elförsörjning, kapacitet, säkerhet, ekonomi, geografi, reglering och suveränitet. Rendering och AI kan innebära mycket olika arbetsbelastningar, men de delar en viktig infrastruktur- och ekosystemutmaning: båda är beroende av att högpresterande databehandling, nätverk, säkerhet och lagring fungerar effektivt tillsammans.

När AI-infrastrukturen blir mer komplex räcker det inte att bara lägga till beräkningskapacitet för att lösa den operativa utmaningen att använda den effektivt. Här blir orkestrering och de policyer som styr det bredare infrastrukturekosystemet avgörande. Tillsammans hjälper de organisationer att få bättre nytta av kostsamma och begränsade resurser och samtidigt samordna arbetsbelastningar i allt mer distribuerade miljöer.

RAVEL beskriver sig som ett orkestreringslager för distribuerade AI-fabriker. Vad betyder en ”AI-fabrik” för dig, och vad saknas i dagens infrastrukturlager som gör ett orkestreringslager nödvändigt?

Som jag ser det är en AI-fabrik mer än GPU:er och högpresterande kluster. Det är ett integrerat infrastrukturekosystem som samlar beräkningskapacitet, nätverk, lagring, säkerhet, elförsörjning, kylning och de driftlager som krävs för att köra AI-arbetsbelastningar. AI-fabriker utvecklas från isolerade kluster till ekosystem av sammankopplade resurser som sträcker sig över flera platser och regioner. Den komplexiteten blir allt svårare att hantera manuellt eller med fristående punktlösningar. Ett orkestreringslager hanterar detta genom att samordna stackens olika och komplexa delar och abstrahera en del av den underliggande komplexiteten, så att operatörerna enklare kan hantera infrastrukturen som ett samordnat system.

När organisationer anpassar befintliga datacenter för AI är många anläggningar inte ursprungligen utformade för dagens AI-arbetsbelastningar. Dagens AI står inför en strukturell obalans som kan delas upp i tre centrala problem. Det första är elförsörjningen, eller att hitta en plats med tillräckligt stabil el för att köra arbetsbelastningar i stor skala. Det andra är ett splittrat ekosystem, eftersom AI-stackar ofta är uppdelade mellan isolerade miljöer och inte är utformade för att fungera tillsammans. Det tredje är bristande insyn i de totala drift- och ägandekostnaderna, vilket kan göra det svårt att se den verkliga kostnaden för AI-infrastruktur. Följden kan bli att arbetsbelastningar inte optimeras, att hårdvara utnyttjas för lite och att oväntade driftskostnader driver upp den totala ägandekostnaden, vilket i slutändan bidrar till högre tokenkostnader.

AI-infrastruktur är i allt högre grad utspridd mellan hyperskaliga moln, privata datacenter, lokala system och specialiserade GPU-leverantörer. Vilka är de största utmaningarna för organisationer som försöker hantera AI-arbetsbelastningar i dessa olika miljöer?

Under de senaste åren har kapplöpningen om AI-infrastruktur präglats av ett enkelt antagande: bygg större. Större datacenter. Större kluster. Fler GPU:er. Större kapacitet. Men modellen att bygga större stöter allt oftare på fysiska, ekonomiska och regulatoriska begränsningar.

Tillgången på el är begränsad. Det tar tid att få tillgång till elnätet. Ekonomi, geografi och suveränitet avgör i allt högre grad var infrastruktur kan och bör byggas. Den nya utmaningen är inte bara hur man bygger mer AI-infrastruktur, utan hur man bygger rätt infrastruktur på rätt platser och samtidigt får alla dessa miljöer att fungera som ett samordnat system. Det blir särskilt svårt när kapaciteten är utspridd mellan hyperskaliga moln, privata datacenter, lokal infrastruktur och specialiserade leverantörer som inte nödvändigtvis är utformade för att fungera tillsammans.

Eltillgången är den mest påtagliga av dessa begränsningar. I allt högre grad avgör tillgången på el var AI-infrastruktur byggs från första början.

Det är här federering blir avgörande. Den kopplar samman infrastruktur i olika miljöer till en gemensam driftsmiljö. Intelligent orkestrering avgör sedan var arbetsbelastningar ska köras utifrån kapacitet, elförsörjning, prestanda, kostnad, policy, motståndskraft och suveränitet.

I takt med att AI-infrastrukturen sprids ytterligare, mellan olika platser eller leverantörer, kommer konkurrensfördelen inte bara av att äga mer kapacitet. Den kommer av att få kapaciteten att fungera tillsammans. Federering skapar den infrastrukturmodell som krävs för denna nya verklighet, medan intelligent orkestrering gör det möjligt att använda modellen operativt i stor skala.

Det här är den modell som en av våra kunder, RT-One, utvecklaren av Latinamerikas största AI-teknikparker och datacenter, satsar på när företaget planerar federerad infrastruktur i hela Amerika: att koppla samman utspridd kapacitet så att den i slutändan kan hanteras som en samordnad miljö.

Bristen på GPU:er har fått enorm uppmärksamhet, men att bara lägga till fler acceleratorer leder inte nödvändigtvis till mer användbar AI-beräkningskapacitet. Var ser du de största källorna till ineffektivitet i dagens AI-infrastruktur, och hur mycket extra kapacitet skulle företag kunna frigöra genom bättre orkestrering?

Kapplöpningen om AI-infrastruktur har i hög grad handlat om hur många gigawatt ny kapacitet som planeras och hur mycket kapital som satsas på att bygga ut den. Det är frestande att se AI-infrastrukturens problem som en ren brist på GPU:er eller kapacitet, men då förbiser man var ineffektiviteten egentligen finns. Det är viktigt att komma ihåg att planerad kapacitet inte är detsamma som användbar kapacitet.

GPU-kluster kan verka fullbokade, men dyra GPU:er kan ändå stå oanvända när flaskhalsar uppstår på andra håll i stacken. Det kan handla om lagringens dataöverföringskapacitet, datapipelines, överbelastning i nätverket, ineffektiv schemaläggning av jobb, säkerhetskrav och bristande överensstämmelse mellan arkitektur, applikationer, drivrutiner och beroenden. Fler GPU:er innebär inte alltid mer användbar beräkningskapacitet.

Mer infrastruktur leder inte automatiskt till högre effektivitet. I många fall skapar den fler silor och driver samtidigt upp kostnaderna.

Organisationer behöver bättre insyn och kontroll för att kunna förbättra resursutnyttjandet, automatisera beslut om infrastrukturen och bättre anpassa arbetsbelastningar efter tillgängliga resurser och verksamhetens prioriteringar. Bättre insyn och kontroll kan bidra till att omvandla en samling infrastrukturtillgångar till en mer samordnad driftsmiljö. Det finns ingen exakt eller allmängiltig siffra för hur mycket kapacitet som kan frigöras genom orkestrering; varje arbetsbelastning har unika krav. Men en sak är klar: lösningen på outnyttjad eller underutnyttjad kapacitet är inte helt enkelt att köpa eller bygga mer.

RAVEL har betonat vikten av interoperabilitet mellan infrastruktur, virtualiseringsteknik, identitetssystem och applikationer. Varför blir interoperabilitet särskilt viktig när AI-arbetsbelastningar blir mer komplexa och distribuerade?

I takt med att infrastrukturen blir mer heterogen behöver organisationer flexibilitet att använda olika tekniker och miljöer utan att skapa fler isolerade infrastruktursilos. Interoperabilitet gör att beräkningsresurser, lagring, nätverk och applikationer från olika leverantörer och miljöer kan fungera tillsammans, vilket bevarar valfriheten när infrastrukturen utvecklas. Men interoperabilitet avgör inte i sig hur resurserna ska användas.

Det är här orkestrering kommer in – den samordnar var arbetsbelastningar körs, hur de flyttas och hur policyer tillämpas i olika miljöer. I takt med att AI-infrastrukturen blir alltmer distribuerad och federerad ger interoperabilitet flexibilitet att arbeta med olika tekniker, medan orkestrering omvandlar resurserna till en samordnad driftsmiljö.

RAVEL Orchestrate AI tillhandahåller ett gemensamt orkestreringslager för beräkningsresurser, lagring, nätverk och annan infrastrukturteknik och samordnar AI-arbetsbelastningar i moln-, lokala och hybrida miljöer.

Datasuveränitet blir allt viktigare för regeringar och företag som implementerar AI. Hur förändrar utbyggnaden av suverän AI-infrastruktur organisationers sätt att tänka kring placering av arbetsbelastningar, dataförflyttning, säkerhet och orkestrering?

Suverän AI är nu en strategisk prioritering. I samband med detta uppstår en mer grundläggande fråga: Vad innebär det egentligen att vara suverän? Diskussionen har till stor del handlat om var data lagras, men jag anser att den definitionen är alltför snäv.

Jag definierar suverän AI som en nations, ett företags, en myndighets eller en annan organisations förmåga att upprätthålla policydefinierad kontroll över sina AI-arbetsbelastningar – inklusive data, modeller, beräkningsinfrastruktur, åtkomst, säkerhet, drift och den jurisdiktion som styr arbetsbelastningarna. Suveränitet innebär inte nödvändigtvis att varje arbetsbelastning måste stanna i ett enda datacenter eller ens på infrastruktur som ägs av en enda organisation. Det innebär snarare att organisationen bestämmer var en arbetsbelastning får köras, var dess data får lagras eller färdas, vem som får åtkomst till den, vilken infrastruktur som får köra den och vilka säkerhetsmässiga, regulatoriska, geografiska, operativa och affärsmässiga policyer som alltid måste upprätthållas. Den här arbetsbelastningscentrerade definitionen stämmer överens med den bredare branschutvecklingen mot att se suveränitet som kontroll över hela AI-miljön, snarare än enbart över var data lagras.

RAVELs arbetssätt skiljer sig särskilt från mängden när suverän AI kombineras med federation. RAVEL Orchestrate AI kan behandla suveränitetskrav som begränsningar i orkestrerings- och policylagret: en arbetsbelastning kan vara tillåten att köras i en federation av platser, moln, datacenter, edge-miljöer eller annan infrastruktur, men enbart på resurser som uppfyller arbetsbelastningens suveränitetspolicyer. Inom dessa godkända ramar kan RAVEL sedan välja lämplig infrastruktur utifrån faktorer som effektförbrukning, kostnad, prestanda, kapacitet, resursutnyttjande, nätverksegenskaper, plats och prioritet. Federation upphäver inte suveräniteten; den kan i stället fungera inom de ramar som suveräniteten anger. En känslig arbetsbelastning för en myndighet kan till exempel hållas helt inom godkända anläggningar i USA och samtidigt orkestreras dynamiskt mellan flera auktoriserade platser. Resultatet är en modell där organisationer kan dra nytta av bättre resursutnyttjande och högre motståndskraft från distribuerad AI-infrastruktur utan att förlora kontrollen över var och hur deras mest känsliga arbetsbelastningar körs.

RAVEL växte fram i branscher som medier, underhållning, spel och design, där arbetsbelastningarna kan vara extremt beräkningsintensiva. Hur har kraven från generativ AI förändrat plattformen jämfört med de infrastrukturutmaningar ni ursprungligen löste åt kreatörer?

RAVEL kom till för att lösa infrastrukturproblem där konstnärer och ingenjörer redan körde omfattande arbetsbelastningar för rendering, simulering och innehållsskapande med dyra beräkningsresurser, lagringslösningar och nätverksresurser. Den grundläggande utmaningen var att göra heterogen infrastruktur lättare att komma åt, dela och orkestrera, samtidigt som resursutnyttjande och prestanda maximerades.

Generativ AI har dramatiskt ökat omfattningen och komplexiteten i samma problem. I stället för att främst orkestrera applikationer och renderingsarbetsbelastningar måste vi nu ta hänsyn till AI-modeller, motorer, agenter, tränings- och inferensarbetsbelastningar, olika GPU-arkitekturer, snabbt föränderliga programvarustackar, enorma datamängder som ska flyttas och betydligt större begränsningar vad gäller effektförbrukning, kostnad, säkerhet och tillgänglighet.

Därför har RAVEL utvecklats från att främst orkestrera beräkningsresurser till att erbjuda ett intelligent styrnings- och optimeringslager för AI-infrastruktur. Orchestrate AI använder telemetri och policyer för att avgöra inte bara om infrastrukturen är tillgänglig, utan också var och hur en arbetslast bör köras utifrån faktorer som kostnad, hastighet, energiförsörjning, prestanda, utnyttjandegrad, geografisk placering och suveränitetskrav.

Federering har också blivit allt viktigare, eftersom AI-infrastruktur inte längre kan betraktas som en samling isolerade datacenter. Organisationer behöver kunna använda kapacitet på olika platser på ett intelligent sätt och samtidigt upprätthålla styrning och säkerhet. På många sätt förändrade generativ AI inte det grundläggande problem som RAVEL tog sig an – den gjorde problemet dramatiskt större och mer komplext, vilket har gjort intelligent orkestrering, optimering och federering allt viktigare.

Din karriär har tagit dig från maskinteknik och processoptimering på Starbucks till digitala medier, datacenter, virtuella studior och nu AI-infrastruktur. Hur har din ingenjörsbakgrund påverkat ditt sätt att bygga företag och lösa infrastrukturproblem?

Min ingenjörsbakgrund har förmodligen påverkat nästan allt i mitt sätt att bygga företag. Maskinteknik lär en att se till ett system – inte bara till en enskild komponent – och fråga sig var begränsningarna finns, var energi eller resurser går till spillo och hur hela systemet kan fungera bättre. På Starbucks tillämpade jag det tankesättet på processoptimering. Senare, inom digitala medier och visuella effekter, kom systemet att omfatta beräkningskapacitet, lagring, nätverk, applikationer och till slut hela datacenter. Tekniken förändrades, men mitt sätt att angripa problemet gjorde det egentligen inte. Jag frågar mig alltid: Var finns flaskhalsen? Vad utnyttjas inte tillräckligt? Vad kan vi förenkla? Och hur får vi hela systemet att fungera bättre i stället för att bara optimera en del av det?

Det är i hög grad så vi byggde RAVEL. Jag tror inte att problemet med AI-infrastruktur bara handlar om att skaffa fler GPU:er eller bygga fler datacenter. Det är ett systemtekniskt problem som omfattar beräkningskapacitet, energi, lagring, nätverk, programvara, arbetslaster, människor och i allt högre grad även geografi och suveränitet. Man kan ha världens snabbaste GPU, men om resten av systemet inte är optimerat har man bara skapat en mycket dyr flaskhals. Därför är vår strategi med RAVEL att göra själva infrastrukturen mer intelligent – med hjälp av telemetri, policyer, orkestrering och federering för att kontinuerligt avgöra hur och var arbetslaster bör köras. Jag inledde min karriär med att optimera fysiska system. I dag tillämpar vi samma ingenjörsmässiga noggrannhet för att optimera infrastrukturen som driver AI.

Med blicken framåt, hur tror du att AI-infrastrukturen kommer att utvecklas när modeller, agenter och applikationer kräver allt större mängder distribuerad beräkningskapacitet? Tror du att AI-fabriker kommer att bli ett standardiserat lager i företagens infrastruktur, ungefär som molntjänster har blivit under det senaste decenniet?

Jag är övertygad om att AI-fabriker kommer att bli ett grundläggande lager i företagens infrastruktur, ungefär som molntjänster blev – men jag tror inte att de kommer att se ut som ett enda standardiserat datacenter eller moln. I takt med att modeller, agenter och applikationer förbrukar allt större mängder beräkningskapacitet kommer företag att använda en heterogen blandning av GPU:er, CPU:er, privat infrastruktur, neomoln, hyperskalare, edge-miljöer och specialiserade AI-system.

Tillgången till energi, kostnad, suveränitet, prestanda och geografisk placering kommer att bli lika viktiga som tillgången till beräkningskapacitet. Den verkliga utmaningen blir inte bara att bygga mer infrastruktur, utan att få all denna distribuerade infrastruktur att fungera som ett enda intelligent system. Framtidens AI-fabrik är inte en enda byggnad – den är en federerad infrastrukt miljö som omfattar beräkningskapacitet, energi, data och de resurser som krävs för att köra AI-arbetslaster där det är mest ändamålsenligt.

Det är där jag tror att nästa stora infrastrukturlager växer fram. Molntjänster abstraherade servrar och gjorde det enklare att använda beräkningskapacitet. Nästa steg är att abstrahera komplexiteten i hela AI-infrastrukturstacken. Företag ska inte behöva avgöra manuellt vilken GPU, vilket datacenter, moln, vilken energikälla eller geografisk plats som ska användas för varje modell eller agent. Infrastrukturen bör i allt högre grad fatta de besluten själv och använda telemetri och policyer för att optimera kostnad, hastighet, energiförsörjning, prestanda, tillgänglighet och suveränitet. Det är den framtid vi arbetar mot på RAVEL: ett intelligent orkestreringslager som gör det möjligt för arbetslaster att flyttas mellan olika delar av en federerad AI-infrastruktur, samtidigt som organisationens policyer och kontroller upprätthålls. Molnet gjorde beräkningskapacitet tillgänglig på begäran. Jag tror att nästa generation av AI-infrastruktur kommer att göra optimering tillgänglig på begäran.

Tack för den fina intervjun. Läsare som vill veta mer om orkestrering av AI-arbetslaster i distribuerad infrastruktur kan besöka RAVEL.