Christian Stano, Field CTO hos Anyscale – Intervieuserie

Christian Stano, Field CTO hos Anyscale, har bygget en karriere ved skæringen af storstile AI-infrastruktur, maskinlæringsplatforme og distribueret beregning. Før han kom til Anyscale, ledede han AI/ML-platformorganisationen hos Attentive, hvor han skalaerede infrastruktur til at understøtte personalisering for mere end en halv milliard abonnenter og hjalp med at fremme adoption af Ray-baserede unified compute-systemer, der forbedrede udviklingshastighed og reducerede operationelle omkostninger. Tidligere i sin karriere arbejdede han med cybersikkerhed, cloud-arkitektur og offentlige sektors AI-initiativer hos organisationer som Coalfire og Deloitte, hvor han bidrog til et af USAs forsvarsministeriums første maskinlæringsplatforme. Hans baggrund omfatter AI-platformsingeniørarbejde, MLOps, cloud-native infrastruktur, udvikleraktivering og organisationsmæssig skala, hvilket giver ham dyb erfaring i at hjælpe virksomheder med at operationalisere AI i produktionsskala.

Anyscale er det selskab bag Ray, det open-source distribuerede beregningsframework, der er vidt brugt til at skala AI- og Python-arbejdsbelastninger på tværs af CPU’er og GPU’er. Grundlagt af de oprindelige skabere af Ray fra UC Berkeley’s RISELab, fokuserer selskabet på at simplificere installation, orkestrering og administration af storstile AI-infrastruktur til træning, inferens, dataprocessing og agentic AI-arbejdsbelastninger. Dets platform giver organisationer mulighed for at køre distribuerede AI-systemer på tværs af cloud- og on-premise-miljøer, samtidig med at den tilbyder overvågning, styring og ydelsesoptimering designet til moderne AI-applikationer. Ray er blevet en central del af den opdyrkende AI-infrastrukturstak, hvilket hjælper udviklere med at skala arbejdsbelastninger fra en enkelt maskine til tusinder af noder med minimale ændringer i eksisterende Python-kode.

DU har arbejdet med alt fra cybersecurity til offentlige sektors ML-platforme og hyperskala-personaliseringssystemer. Hvad er de mønstre, du konsekvent har set, når organisationer forsøger at flytte fra AI-piloter til produktion?

På tværs af brancher viser tre mønstre sig konsekvent. Først har holdene ikke en pålidelig vej fra udvikling til produktion. De kan bygge en model i en notesbog, men der er ingen standardiseret måde at få den til at køre i produktion på. Hver enkelt installation bliver en enkeltstående sag, og hver fejl er en overraskelse. Andet har infrastrukturen ikke evne til at skala med behovene. Systemet, der fungerede i en pilot, bryder sammen, når du giver det rigtige data-volumener eller rigtig trafik. Tredje har holdene ikke overblik over, hvordan deres systemer faktisk fungerer, hvor de er ved at bryde sammen, og hvornår de skal gribe ind.

Det, der forbinder alle tre, er det samme grundlæggende udfordring — holdene har ikke en solid mental model for at skala ud. De forsøger at løse alt på én gang i stedet for at være bevidste om sekvensen. Jeg tænker på det som tre faser: gør det til at fungere, gør det rigtigt, gør det hurtigt. Disse faser er ikke enkeltstående milepæle — disse faser er iterative. Du prioriterer konstant mellem, hvad der er brudt lige nu, og hvad der vil bryde næste gang. De hold, der lykkes, ved, hvilken fase de er i, og holder sig disciplinerede om ikke at springe foran, før grundlaget er solidt.

Hos Anyscale ser vi hold komme ind på alle stadier. Nogle er stadig ved at forsøge at gøre det til at fungere — de har brug for en pålidelig vej fra udvikling til produktion. Andre har det, men er druknede i operationel kompleksitet og har brug for at gøre det rigtigt. Og mange kommer til os, fordi de har bygget noget, der fungerer, men ikke kan skubbe det til den skala, forretningsvirksomheden kræver. En unified compute-lag hjælper på hver fase, men indgangspunktet afhænger af, hvor smerterne er skarpeste.

Hos Attentive hjalp du med at skala AI-systemer, der understøttede hundredvis af millioner af brugere. Hvad var de største arkitektoniske eller organisationsmæssige flaskeshals, du havde at overvinde for at nå det niveau af skala?

Den største flaskeshals var S-kurven for infrastrukturkompleksitet. Da vi skubbede vores modeller til at inkludere mere data og servicere flere kunder, ramte vi et beregningsinfleksionspunkt, hvor selv de største lodret skalerede noder kastede out-of-memory-fejl, og naiv horisontal skalaering ikke var nok. Vores beregning kunne ikke følge med skalaen af vores data.

Den naturlige reaktion var at lagre flere værktøjer på for at arbejde rundt om begrænsningerne. Dette var min interne playbook fra tidligere erfaring. Hvert værktøj løste et smalt problem, men tilføjede operationel kompleksitet. Vores ML-pipeline stod over for at blive et patchwork af integrationer, og hver ny brugsmodel betød mere syning, flere fejlmodi, højere omkostninger og mere overhæng for platformholdet.

Det, der ultimativt låste skala for os, var at unificere dataprocessing, træning, inferens og serving på Ray og Anyscale. Effekten var øjeblikkelig: med dramatisk lavere infrastrukturkost, betydeligt hurtigere træningscykler, selvom data-volumener voksede, og evnen til at skala modeller til størrelsesordener mere kunder.

Hvad motiverede din beslutning om at tilslutte sig Anyscale på dette stadium, og hvordan ser du på rollen som Field CTO i formning af virksomheds AI-adoption?

Min erfaring med at bringe Anyscale ind i Attentive ændrede fundamentalt min playbook for at bygge ML-platforme. Før det var en betydelig del af platformingeniørarbejdet omkostningerne ved at sy sammen fragmenterede systemer. Med Anyscale kunne vi eliminere meget af denne overhæng og i stedet fokusere på udvikleroplevelsen, pålideligheden og ydelsen. Denne ændring havde en enorm effekt på både teamets produktivitet og systemets resultater. At tilslutte sig Anyscale var en mulighed for at arbejde fuldtid med dette problem og hjælpe andre organisationer med at navigere samme overgang. Som Field CTO er min rolle virkelig om at tage disse virkelige lektioner og omdanne dem til gentagne mønstre, som vores kunder kan anvende, når de skalerer AI.

Mange virksomheder er stadig fastlåst i “pilotfasen” af AI. Fra din synsvinkel, hvad er det specifikt, der går galt, når virksomheder forsøger at skala disse tidlige eksperimenter til produktionssystemer?

Når virksomheder flytter fra AI-eksperimenter til produktion, er det sjældent kun modellen, der går galt — det er det omgivende system og operationerne. I nogle tilfælde rammer hold infrastrukturgrænser tidligt og kan ikke træne eller servicere i den skala, de ønsker. De må begrænse antallet af kunder eller brugsmodeller, deres model servicerer, som følge. Mere hyppigt opstår problemer i produktion gennem uventede edge-cases eller ændringer i data. En af de mest almindelige fejlpunkter er hukommelse: når datas størrelse, distribution eller modalitet skifter, køres job ud af hukommelse og fejler. Disse problemer er svære at forudse og endnu sværere at automatisk genskabe fra. Virkeligheden er, at fejl er uundgåelige i produktion AI. Målet er ikke at undgå det helt, men at opdage det hurtigt, forstå det og bygge selvhealende systemer til at løse det, før det påvirker forretningsvirksomheden.

Ray, det distribuerede beregningsframework skabt af teamet bag Anyscale, vinder frem som en grundlæggende del af AI-arbejdsbelastninger. Hvorfor bliver distribueret udførelse en så kritisk lag i moderne AI-infrastruktur?

Distribueret udførelse og arbejdsbelastningsstyring er blevet en tabelstol for AI-pipelines. Moderne AI-arbejdsbelastninger er inherent parallelle og ressourcekrævende. Træning, inferens og dataprocessing kræver alle koordinering af store mængder af opgaver på tværs af CPU’er og GPU’er, ofte dynamisk. I dagens beregningslandskab er kompleksiteten ved at styre disse arbejdsbelastninger på tværs af knappe ressourcer en enorm operationel byrde. Traditionelle systemer var ikke designet til dette niveau af kompleksitet eller skala. Frameworks som Ray er kritiske, fordi de giver hold mulighed for at skala arbejdsbelastninger uden besvær fra en enkelt maskine til tusinder af noder ved at automatisere den underliggende koordinering. Denne ændring afspejler en bredere bevægelse mod AI-naturlig beregning, hvor infrastruktur er designet specifikt til AI-arbejdsbelastningens mønstre i stedet for tilpasset fra ældre paradigmer.

Når flere virksomheder adopterer Ray gennem Anyscale’s platform, hvad er forskellene, du ser mellem organisationer, der standardiserer på en samlet tilgang, og dem, der syr sammen fragmenterede værktøjer?

Forskellen mellem samlede platforme og fragmenterede værktøjer kommer ultimativt ned til fokus og effektivitet. Når hold afhænger af multiple uafhængige systemer, bruger de en betydelig mængde tid på at sy disse systemer sammen, styre inkonsistenser og reagere på fejl på tværs af forskellige miljøer. Dette skaber operationel overhæng og langsommere eksperimenter. I modsætning giver en samlet tilgang hold mulighed for at koncentrere deres indsats om at forbedre et enkelt system, hvilket fører til bedre pålidelighed, stærkere ydelse og en mere strømlinet udvikleroplevelse. Det simplificerer også on-call- og fejlfindingsprocesser, fordi mønstre er konsistente og lettere at forstå. Resultatet er ikke kun teknisk effektivitet, men også organisationsklarhed.

Baseret på din erfaring med at bygge end-to-end ML-platforme, hvor vigtig er udvikleroplevelsen (DevEx) i at accelerere AI-adoption på tværs af hold?

Udvikleroplevelsen er et af de højeste udvindingsområder for at accelerere AI-adoption. Når platformhold investerer i at gøre systemer lettere at bruge gennem standardiserede arbejdsprocesser, skabeloner og reduceret infrastrukturfriction, forstærker de produktiviteten af hver enkelt ingeniør i organisationen. Dette er særligt vigtigt i AI, hvor ændringstakten er ekstremt høj, og hold har brug for at iterere hurtigt for at holde trit. Forbedringer i udvikleroplevelsen oversætter direkte til hurtigere eksperimenter, hurtigere tid til produktion og ultimativt mere forretningsindvirkning. AI-kodningsværktøjer forstærker disse DevEx-fundamentaler. På mange måder er det den mest skalerbare måde at øge hastighed på tværs af en organisation.

Kosteffektivitet bliver en stor bekymring, når AI-arbejdsbelastninger skalerer. Hvad er nogle af de mest oversete måder, virksomheder kan reducere infrastrukturkost without at ofre ydelse?

Når AI-arbejdsbelastninger skalerer, bliver koststyring både vigtigere og mere kompleks. En af de mest oversete udfordringer er, hvor hurtigt kost kan spiralere på grund af ineffektiviteter, især med GPU-baseret infrastruktur. Store clusters kan starte tusinder af noder, og hvis ressourcer ikke er ordentligt styret eller lukket, akkumulerer kost hurtigt. Dette skaber en form for AI-specifik sprawl, hvor beregningsbrug vokser hurtigere, end hold kan spore eller kontrollere. At løse dette kræver en kombination af stærk styring, overblik og automatisering, såsom autoskalering, auto-afslutning og central ressourcestyring. På skala er kosteffektivitet ikke kun en operationel bekymring, men en fundamental del af systemdesign.

DU har arbejdet med alt fra feature-butikker til realtidsinference-systemer. Hvordan tror du, balancen mellem batch- og realtids AI-arbejdsbelastninger udvikler sig?

Balancen mellem batch- og realtids AI-arbejdsbelastninger har ikke fundamentalt ændret sig — det er stadig et spørgsmål om forretningskrav. Batchprocessing er typisk mere kosteffektivt og lettere at operere, hvilket gør det egnet til mange brugsmodeller. Realtids-systemer er essentielle, når latency direkte påvirker brugeroplevelsen eller forretningsresultatet, såsom i chat-applikationer eller svindelforebyggelse. Begge tilgange vil fortsætte med at coexistere, og nøglen for organisationer er at bygge platforme, der kan understøtte begge effektivt. Beslutningen kommer ultimativt ned til kompromiser mellem kost, latency og pålidelighed.

Settende fremad, hvad ser en “moden” virksomheds AI-platform ud til i 2-3 år — og hvordan passer værktøjer som Ray og platforme som Anyscale ind i denne fremtid?

Over de næste par år vil modne virksomheds AI-platforme være defineret af nogle få nøglekarakteristika. De vil afhænge af samlet infrastruktur, der understøtter hele AI-livscyklussen, fra dataprocessing til træning til inferens, i stedet for en samling af uafhængige værktøjer. De vil have stærke Day 2-operationer med agent-automatiseret overblik, pålidelighed og hurtig fejlfinding. Koststyring vil være forudsigelig og styret, hvilket giver virksomheder mulighed for at skala bæredygtigt. Og måske aller vigtigst vil de give udviklerne høj hastighed, hvilket gør det let for hold at flytte fra idé til produktion hurtigt. Platforme som Ray og Anyscale spiller en central rolle i denne fremtid ved at give den AI-naturlige grundlæggelse, der gør dette niveau af skala og effektivitet muligt.

Tak for det store interview, læsere, der ønsker at lære mere, skal besøge Anyscale.