Christian Stano, felt-CTO i Anyscale – Intervju-serie

Christian Stano, felt-CTO i Anyscale, har bygget en karriere i skjæringspunktet mellom stor skala AI-infrastruktur, maskinlæringsplattformer og distribuert dataverking. Før han ble med i Anyscale, ledet han AI/ML-plattformorganisasjonen i Attentive, der han skalerte infrastruktur som støttet personliggjøring for over en halv milliard abonnenter og hjalp til å drive adopsjonen av Ray-baserte enhetlige beregningsystemer som forbedret utviklingshastigheten samtidig som de reduserte driftskostnadene. Tidligere i sin karriere arbeidet han med sikkerhet, skyarkitektur og offentlige sektors AI-initiativer i organisasjoner som Coalfire og Deloitte, der han bidro til ett av USAs forsvardepartements første maskinlæringsplattformer. Hans bakgrunn omfatter AI-plattformingeniørvitenskap, MLOps, skygnaturlig infrastruktur, utviklermuliggjøring og organisatorisk skalerbarhet, noe som gir ham dypt erfaring i å hjelpe bedrifter å operasjonalisere AI på produksjonsskala.

Anyscale er selskapet bak Ray, det åpne distribuerte beregningsrammeverket som er mye brukt for å skalerer AI- og Python-arbeidsbelastninger over kluster av CPU-er og GPU-er. Grunnlagt av de opprinnelige skaperne av Ray fra UC Berkeley’s RISELab, fokuserer selskapet på å forenkle deployering, orkestrering og styring av stor skala AI-infrastruktur for opplæring, inferens, datahandsaming og agensbasert AI-arbeidsbelastninger. Plattformen deres muliggjør at organisasjoner kjører distribuerte AI-systemer over sky- og lokale miljøer samtidig som de tilbyr overvåkning, styring og ytelsesoptimaliseringer designet for moderne AI-applikasjoner. Ray har blitt en sentral del av den fremvoksende AI-infrastruktur-stakken, og hjelper utviklere å skalerer arbeidsbelastninger fra en enkelt maskin til tusenvis av noder med minimal endring av eksisterende Python-kode.

Du har arbeidet med sikkerhet, offentlig sektor ML-plattformer og hyperskala personliggjøringsystemer. Hva er mønsterene du har sett når organisasjoner prøver å gå fra AI-piloter til produksjon?

Over industrier, viser tre mønster seg jevnt. Først har teamene ikke en pålitelig vei fra utvikling til produksjon. De kan bygge en modell i en notebook, men det er ingen standardisert måte å få den til å kjøre i produksjon på. Hver deployering blir en enkeltstående hendelse, og hver feil er en overraskelse. Andre, kan infrastrukturen ikke skalerer med behovene. Systemet som fungerte i en pilot kollapser når du mater det med reelle datavolumer eller reell trafikk. Tredje, har teamene ikke overvåkning for å vite hvordan systemene deres faktisk fungerer, hvor de er i ferd med å bryte sammen og når de skal gripe inn.

Hva forbinder alle tre er den samme grunnleggende utfordring — teamene har ikke en solid mental modell for å skalerer ut. De prøver å løse alt på en gang i stedet for å være bevisste på sekvensen. Jeg tenker på det som tre faser: få det til å fungere, få det rett, få det raskt. Disse fasene er ikke en-gangs-milepæler — disse fasene er iterative. Du prioriterer konstant mellom hva som er brutt akkurat nå og hva som kommer til å bryte neste. Teamene som lykkes, vet hvilken fase de er i og holder seg disiplinerte om ikke å hoppe foran før grunnlaget er solidt.

I Anyscale ser vi team komme inn på alle stadier. Noen er fortsatt prøvende å få det til å fungere — de trenger en pålitelig vei fra utvikling til produksjon. Andre har det, men drukner i operasjonell kompleksitet og trenger å få det rett. Og mange kommer til oss fordi de har bygget noe som fungerer, men ikke kan pushe det til skalaen bedriften krever. Et enhetlig beregningslag hjelper på hver fase, men inngangspunktet avhenger av hvor smerten er skarpest.

I Attentive, hjalp du å skalerer AI-systemer som støttet hundredvis av millioner av brukere. Hva var de største arkitektoniske eller organisatoriske flaskenakkene du måtte overvinne for å nå det nivået av skala?

Den største flaskenakken var S-kurven av infrastrukturkompleksitet. Da vi presset modellene våre for å inkorporere mer data og tjene flere kunder, traff vi et beregningsinfleksjonspunkt der selv de største vertikalt skalerte nodene kastet ut-av-minne-feil, og naivt horisontalt skaleringsløsning var ikke nok. Vår beregning kunne ikke holde tritt med skalaen av vår data.

Den naturlige responsen var å lagre på flere verktøy for å arbeide rundt begrensningene. Dette var min interne spillbok fra tidligere erfaring. Hvert verktøy løste et smalt problem, men la til operasjonell kompleksitet. Vår ML-pipeline møtte å bli en patchwork av integrasjoner, og hver nytt brukstilfelle betydde mer sying, flere feilmodi, høyere kostnader og mer overhead for plattformteamet.

Hva til slutt låste skala for oss, var å forene datahandsaming, opplæring, inferens og serving på Ray og Anyscale. Effekten var umiddelbar: med dramatisk lavere infrastrukturkostnader, betydelig raskere opplæringscykler selv når datavolumer vokste, og evnen til å skalerer modeller til flere størrelsesordener flere kunder.

Hva motiverte din beslutning om å gå med i Anyscale på dette stadiet, og hvordan ser du på rollen til felt-CTO i å forme bedrifts AI-adoptsjon?

Min erfaring med å bringe Anyscale inn i Attentive endret fundamentalt min spillbok for å bygge ML-plattformer. Før det, var en betydelig del av plattformingeniørvitenskapen kostnaden av å sy sammen fragmenterte systemer. Med Anyscale, kunne vi eliminere mye av denne overheaden og i stedet fokusere på utvikleropplevelse, pålitelighet og ytelse. Denne skiftet hadde en enorm innvirkning på både teamproduktivitet og systemresultater. Å gå med i Anyscale var en mulighet til å arbeide på dette problemet fullt ut og hjelpe andre organisasjoner å navigere gjennom samme overgangen. Som felt-CTO, er min rolle virkelig om å ta disse virkelige leksjonene og omdanne dem til gjentakende mønster som våre kunder kan bruke når de skalerer AI.

Mange bedrifter er fortsatt fast i «pilotfasen» av AI. Fra din perspektiv, hva er det spesifikke som bryter når selskaper prøver å skalerer disse tidlige eksperimentene til produksjonssystemer?

Når selskaper flytter fra AI-eksperimenter til produksjon, er det sjelden bare modellen som bryter — det er omgivelsessystemet og operasjonene. I noen tilfeller, treff teamene infrastrukturbegrensninger tidlig og kan ikke trene eller tjene på skalaen de ønsker. De må begrense antallet kunder eller brukstilfeller modellen tjener som resultat. Mer ofte, oppstår problemer i produksjon gjennom uventede kanttilfeller eller endringer i data. En av de vanligste feilpunktene er minne: når datastørrelse, distribusjon eller modalitet endrer seg, kjører jobbene ut av minne og feiler. Disse problemene er vanskelige å forutse og enda vanskeligere å auto-gjenopprette fra. Virkeligheten er at feil er uunngåelige i produksjons-AI. Målet er ikke å unngå det fullstendig, men å oppdage det raskt, forstå det og bygge selv-helede systemer for å løse det før det påvirker bedriften.

Ray, det distribuerte beregningsrammeverket skapt av teamet bak Anyscale, vinner terreng som en grunnleggende del av AI-arbeidsbelastninger. Hvorfor blir distribuert eksekvering en så kritisk lag i moderne AI-infrastruktur?

Distribuert eksekvering og arbeidsbelastningsstyring er blitt en nødvendighet for AI-pipelines. Moderne AI-arbeidsbelastninger er innebygget paralleller og ressursintensive. Opplæring, inferens og datahandsaming krever alle koordinering av store mengder oppgaver over CPU-er og GPU-er, ofte dynamisk. I dagens beregningslandskap, er kompleksiteten av å håndtere disse arbeidsbelastningene over knappe ressurser en massiv operasjonell byrde. Tradisjonelle systemer var ikke designet for dette nivået av kompleksitet eller skala. Rammer som Ray er kritiske fordi de tillater team å skalerer arbeidsbelastninger sømløst fra en enkelt maskin til tusenvis av noder ved å automatisere den underliggende koordineringen. Denne skiftet reflekterer en bredere bevegelse mot AI-nativt beregning, hvor infrastruktur er designet spesifikt for mønsterene av AI-arbeidsbelastninger i stedet for å være tilpasset fra eldre paradigmer.

Når flere selskaper adopterer Ray gjennom Anyscales plattform, hva er forskjellene du ser mellom organisasjoner som standardiserer på en enhetlig tilnærming versus de som syr sammen fragmentert verktøy?

Forskjellen mellom enhetlige plattformer og fragmentert verktøy kommer til slutt ned til fokus og effisiens. Når teamene avhenger av flere separate systemer, tilbringer de en betydelig mengde tid på å sy sammen disse systemene, håndtere inkonsistenser og reagere på feil over forskjellige miljøer. Dette skaper operasjonell overhead og sakter ned eksperimentering. I motsetning, tillater en enhetlig tilnærming teamene å konsentrere sine anstrengelser om å forbedre ett enkelt system, noe som leder til bedre pålitelighet, sterkere ytelse og en mer strømlinjeformet utvikleropplevelse. Det forenkler også on-call og feilsøkingsprosesser fordi mønster er konsistente og enklere å forstå. Resultatet er ikke bare teknisk effisiens, men også organisatorisk klarhet.

Basert på din erfaring med å bygge end-to-end ML-plattformer, hvor viktig er utvikleropplevelse (DevEx) i å akselerere AI-adoptsjon over team?

Utvikleropplevelse er ett av de høyest-leverende områdene for å akselerere AI-adoptsjon. Når plattformteam investerer i å gjøre systemer enklere å bruke gjennom standardiserte arbeidsflyter, maler, og redusert infrastrukturfriksjon, forsterker de produktiviteten til hver enkelt ingeniør i organisasjonen. Dette er spesielt viktig i AI hvor tempoet av endring er ekstremt raskt og teamene trenger å iterere raskt for å holde seg konkurransedyktige. Forbedringer i utvikleropplevelse oversettes direkte til raskere eksperimentering, raskere tid til produksjon og til slutt mer bedriftsinnvirkning. AI-kodingverktøy forsterker disse DevEx-grunnleggende prinsippene. På mange måter er det den mest skalerbare måten å øke hastighet over en organisasjon.

Kostnadseffisiens blir en stor bekymring når AI-arbeidsbelastninger skalerer. Hva er noen av de mest oversette måtene bedrifter kan redusere infrastrukturkostnader uten å ofre ytelse?

Når AI-arbeidsbelastninger skalerer, blir kostnadsstyring både viktigere og mer kompleks. En av de mest oversette utfordringene er hvor raskt kostnader kan spiralere på grunn av ineffisienser, spesielt med GPU-basert infrastruktur. Store kluster kan starte tusenvis av noder, og hvis ressurser ikke håndteres eller avsluttes korrekt, akkumulerer kostnadene raskt. Dette skaper en form for AI-spesifikk sprening, hvor beregningsbruk vokser raskere enn teamene kan spore eller kontrollere. Å håndtere dette, krever en kombinasjon av sterk styring, overvåkning og automatisering, som autoskalerings-, auto-avslutnings- og sentral ressursstyring. På skala, er kostnadseffisiens ikke bare en operasjonell bekymring, men en fundamental del av systemdesign.

Du har arbeidet med alt fra funksjonsbutikker til sanntids-inferenssystemer. Hvordan tror du balansen mellom batch og sanntids AI-arbeidsbelastninger utvikler seg?

Balansen mellom batch og sanntids AI-arbeidsbelastninger har ikke endret seg fundamentalt — det forblir et spørsmål om bedriftsbehov. Batch-behandling er vanligvis mer kostnadseffektiv og enklere å operere, noe som gjør det egnet for mange brukstilfeller. Sanntids-systemer, på den andre siden, er essensielle når forsinkelse direkte påvirker brukeropplevelsen eller bedriftsresultatet, som i chat-applikasjoner eller svindelfordringsdeteksjon. Begge tilnærmingene vil fortsette å coeksistere, og nøkkel for organisasjoner er å bygge plattformer som kan støtte begge effektivt. Avgjørelsen kommer til slutt ned til avveininger mellom kostnad, forsinkelse og pålitelighet.

Ser fremover, hva ser en «moden» bedrifts AI-plattform ut som om 2–3 år — og hvordan passer verktøy som Ray og plattformer som Anyscale inn i denne fremtiden?

Over de neste årene, vil modne bedrifts AI-plattformer bli definert av noen nøkkelkarakteristika. De vil avhenge av enhetlig infrastruktur som støtter hele AI-livssyklusen, fra datahandsaming til opplæring til inferens, i stedet for en samling av separate verktøy. De vil ha sterk Day 2-operasjoner, med agent-automatisert overvåkning, pålitelighet og rask feilsøking. Kostnadsstyring vil være forutsigbar og styrt, og tillater organisasjoner å skalerer bærekraftig. Og kanskje viktigst, vil de aktivere høy utviklerhastighet, og gjøre det enkelt for team å gå fra idé til produksjon raskt. Plattformer som Ray og Anyscale spiller en sentral rolle i denne fremtiden ved å tilby den AI-naturlige grunnlaget som gjør dette nivået av skala og effisiens mulig.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, kan besøke Anyscale.