Christian Stano, Field CTO i Anyscale – intervjuserie

Christian Stano, Field CTO i Anyscale, har bygget en karriere i skjæringspunktet mellom storskala AI-infrastruktur, maskinlæringsplattformer og distribuert databehandling. Før han begynte i Anyscale, ledet han AI/ML-plattformorganisasjonen i Attentive. Der skalerte han infrastruktur som støttet personalisering for over en halv milliard abonnenter, og bidro til innføringen av Ray-baserte, enhetlige beregningssystemer som økte utviklingshastigheten og reduserte driftskostnadene. Tidligere arbeidet han med cybersikkerhet, skyarkitektur og AI-initiativer i offentlig sektor hos blant andre Coalfire og Deloitte, der han bidro til en av det amerikanske forsvarsdepartementets første maskinlæringsplattformer. Bakgrunnen hans omfatter utvikling av AI-plattformer, MLOps, infrastruktur utviklet for skyen, støtte til utviklere og oppskalering av organisasjoner. Det har gitt ham bred erfaring med å hjelpe bedrifter å ta AI i bruk i storskala produksjon.

Anyscale er selskapet bak Ray, et rammeverk for distribuert beregning med åpen kildekode som er mye brukt til å skalere AI- og Python-arbeidsbelastninger på tvers av klynger med CPU-er og GPU-er. Selskapet ble grunnlagt av de opprinnelige Ray-utviklerne fra RISELab ved UC Berkeley. Det arbeider med å forenkle utrulling, orkestrering og håndtering av storskala AI-infrastruktur for trening, inferens, databehandling og arbeidsbelastninger for AI-agenter. Plattformen lar organisasjoner kjøre distribuerte AI-systemer både i skyen og i lokale miljøer, med observerbarhet, styring og ytelsesoptimalisering for moderne AI-applikasjoner. Ray har blitt et sentralt lag i den fremvoksende AI-infrastrukturen. Utviklere kan skalere arbeidsbelastninger fra én maskin til tusenvis av noder med minimale endringer i eksisterende Python-kode.

Du har arbeidet med cybersikkerhet, maskinlæringsplattformer i offentlig sektor og personaliseringssystemer i svært stor skala. Hvilke mønstre har du stadig sett når organisasjoner forsøker å gå fra AI-piloter til produksjon?

Tre mønstre går igjen på tvers av bransjer. For det første mangler teamene en pålitelig, etablert vei fra utvikling til produksjon. De kan bygge en modell i et notebook-miljø, men har ingen standardisert måte å få den i produksjon på. Hver utrulling blir en spesialløsning, og hver feil en overraskelse. For det andre kan ikke infrastrukturen skalere i takt med behovene. Systemet som fungerte i piloten, bryter sammen med reelle datamengder eller reell trafikk. For det tredje mangler teamene oversikt. De har ikke observerbarheten som trengs for å vite hvordan systemene faktisk presterer, hvor de nærmer seg bristepunktet, og når de må gripe inn.

Alle tre har samme grunnleggende årsak: Teamene mangler en god forståelse av hvordan de skal skalere ut over flere maskiner. De prøver å løse alt samtidig i stedet for å være bevisste på rekkefølgen. Jeg tenker på det som tre faser: Få det til å virke, få det til å fungere ordentlig, og gjør det raskt. Dette er ikke milepæler man passerer én gang, men faser som gjentas. Man prioriterer hele tiden mellom det som er ødelagt nå, og det som vil svikte neste gang. Teamene som lykkes, vet hvilken fase de er i, og unngår å gå videre før grunnlaget er solid.

Til Anyscale kommer team i alle faser. Noen prøver fortsatt å få systemet til å virke og trenger en pålitelig vei fra utvikling til produksjon. Andre har dette på plass, men drukner i driftskompleksitet og trenger å få orden på systemet. Mange har bygget noe som virker, men klarer ikke å skalere det til nivået virksomheten krever. Et enhetlig beregningslag hjelper i hver fase, men hvor man begynner, avhenger av hvilket problem som er mest akutt.

I Attentive bidro du til å skalere AI-systemer som støttet hundrevis av millioner av brukere. Hva var de største arkitektoniske eller organisatoriske flaskehalsene du måtte overvinne for å nå denne skalaen?

Den største flaskehalsen var infrastrukturkompleksitetens S-kurve. Da modellene skulle håndtere mer data og betjene flere kunder, nådde vi et vendepunkt i beregningskapasiteten. Selv de største vertikalt oppskalerte nodene ga feil på grunn av minnemangel, og enkel horisontal skalering var heller ikke nok. Beregningskapasiteten holdt ikke tritt med datamengdene.

Den naturlige reaksjonen var å legge til flere verktøy for å omgå begrensningene. Dette var fremgangsmåten jeg kjente fra tidligere erfaring. Hvert verktøy løste et avgrenset problem, men økte driftskompleksiteten. ML-pipelinen sto i fare for å bli et lappeteppe av integrasjoner. Hvert nytt bruksområde betydde mer sammenkobling, flere mulige feil, høyere kostnader og merarbeid for plattformteamet.

Det som til slutt gjorde skalering mulig, var å samle databehandling, trening, inferens og tilgjengeliggjøring av modeller på Ray og Anyscale. Effekten kom umiddelbart: kraftig reduserte infrastrukturkostnader, betydelig raskere treningssykluser selv om datamengdene økte, og muligheten til å skalere modellene til kundemengder som var flere størrelsesordener større.

Hva motiverte deg til å begynne i Anyscale på dette tidspunktet, og hvordan ser du at rollen som Field CTO kan påvirke bedriftenes innføring av AI?

Erfaringen med å innføre Anyscale i Attentive endret grunnleggende måten jeg bygger ML-plattformer på. Før gikk en betydelig del av plattformutviklingens kostnader til å koble sammen fragmenterte systemer. Med Anyscale kunne vi fjerne mye av dette merarbeidet og heller konsentrere oss om utvikleropplevelse, pålitelighet og ytelse. Endringen hadde stor innvirkning på både teamets produktivitet og systemenes resultater. Å begynne i Anyscale var en mulighet til å arbeide med problemet på heltid og hjelpe andre organisasjoner gjennom samme overgang. Som Field CTO handler rollen min om å omsette disse praktiske lærdommene til gjentakbare fremgangsmåter som kundene kan bruke når de skalerer AI.

Mange bedrifter sitter fortsatt fast i pilotfasen med AI. Hva er det konkret som svikter når de forsøker å skalere disse tidlige eksperimentene til produksjonssystemer?

Når bedrifter går fra AI-eksperimenter til produksjon, er det sjelden bare modellen som svikter. Det er systemet og driften rundt den. Noen ganger møter teamene infrastrukturbegrensninger tidlig og klarer ikke å trene eller tilgjengeliggjøre modeller i ønsket skala. Dermed må de begrense antallet kunder eller bruksområder modellen betjener. Oftere oppstår problemene i produksjon gjennom uventede spesialtilfeller eller endringer i dataene. Minne er et av de vanligste problemområdene: Når datamengde, fordeling eller datatype endres, går jobbene tomme for minne og feiler. Disse problemene er vanskelige å forutse og enda vanskeligere å hente seg inn fra automatisk. Feil er uunngåelige i AI-systemer i produksjon. Målet er ikke å unngå dem helt, men å oppdage og forstå dem raskt og bygge selvreparerende systemer som løser dem før de rammer virksomheten.

Ray, rammeverket for distribuert beregning laget av teamet bak Anyscale, får økt utbredelse som grunnlag for AI-arbeidsbelastninger. Hvorfor blir distribuert kjøring et så viktig lag i moderne AI-infrastruktur?

Distribuert kjøring og håndtering av arbeidsbelastninger har blitt grunnleggende krav til AI-pipelines. Moderne AI-arbeidsbelastninger er parallelle av natur og krever mye ressurser. Trening, inferens og databehandling krever samordning av store mengder oppgaver på tvers av CPU-er og GPU-er, ofte dynamisk. I dagens beregningsmiljø er håndteringen av slike arbeidsbelastninger på begrensede ressurser en enorm driftsbelastning. Tradisjonelle systemer ble ikke laget for denne kompleksiteten eller skalaen. Rammeverk som Ray er viktige fordi de automatiserer den underliggende samordningen og lar team skalere arbeidsbelastninger sømløst fra én maskin til tusenvis av noder. Dette gjenspeiler en bredere overgang til beregning laget spesielt for AI. Infrastrukturen utformes for mønstrene i AI-arbeidsbelastninger, i stedet for å tilpasses fra eldre løsninger.

Når flere bedrifter tar i bruk Ray gjennom Anyscales plattform, hvilke forskjeller ser du mellom organisasjoner som standardiserer på en enhetlig tilnærming, og dem som kobler sammen separate verktøy?

Forskjellen handler til syvende og sist om fokus og effektivitet. Når team bruker flere atskilte systemer, går mye tid til å koble dem sammen, håndtere uoverensstemmelser og reagere på feil i ulike miljøer. Dette gir merarbeid i driften og bremser eksperimentering. En enhetlig tilnærming lar derimot teamene konsentrere seg om å forbedre ett system, med bedre pålitelighet, ytelse og en mer strømlinjeformet utvikleropplevelse som resultat. Også vaktordninger og feilsøking blir enklere fordi mønstrene er konsistente og lettere å forstå. Resultatet er ikke bare teknisk effektivitet, men også organisatorisk klarhet.

Ut fra erfaringen din med å bygge helhetlige ML-plattformer, hvor viktig er utvikleropplevelse (DevEx) for å øke tempoet i innføringen av AI på tvers av team?

Utvikleropplevelse er et av områdene som har størst effekt på innføringen av AI. Når plattformteam gjør systemene enklere å bruke gjennom standardiserte arbeidsflyter, maler og færre hindringer i infrastrukturen, øker de produktiviteten til hver ingeniør i organisasjonen. Dette er særlig viktig innen AI, der endringstakten er svært høy og team må forbedre løsningene raskt for å være konkurransedyktige. Bedre utvikleropplevelse gir direkte raskere eksperimentering, kortere tid til produksjon og til slutt større verdi for virksomheten. AI-baserte kodeverktøy forsterker disse grunnleggende DevEx-prinsippene. På mange måter er det den mest skalerbare måten å øke tempoet i hele organisasjonen på.

Kostnadseffektivitet blir en stadig større bekymring når AI-arbeidsbelastningene vokser. Hvilke ofte oversette tiltak kan redusere bedriftenes infrastrukturkostnader uten å svekke ytelsen?

Når AI-arbeidsbelastninger vokser, blir kostnadsstyring både viktigere og mer komplisert. En ofte oversett utfordring er hvor raskt kostnadene kan løpe løpsk på grunn av ineffektivitet, særlig med GPU-basert infrastruktur. Store klynger kan starte tusenvis av noder. Hvis ressursene ikke håndteres eller stenges av riktig, hoper kostnadene seg raskt opp. Dette gir en AI-spesifikk form for ukontrollert ressursvekst, der bruken av beregningskapasitet øker raskere enn teamene kan følge med på eller kontrollere. Det krever en kombinasjon av god styring, oversikt og automatisering, som automatisk skalering, automatisk avslutning og sentral ressursstyring. I stor skala er kostnadseffektivitet ikke bare et driftsspørsmål, men en grunnleggende del av systemutformingen.

Du har arbeidet med alt fra feature stores for maskinlæring til systemer for inferens i sanntid. Hvordan mener du balansen mellom batchbaserte AI-arbeidsbelastninger og sanntidsarbeidsbelastninger utvikler seg?

Balansen har ikke endret seg grunnleggende. Den handler fortsatt om virksomhetens behov. Batchbehandling er vanligvis mer kostnadseffektiv og enklere å drifte, og passer derfor til mange bruksområder. Sanntidssystemer er derimot nødvendige når forsinkelse direkte påvirker brukeropplevelsen eller virksomhetens resultater, som i chatteapplikasjoner eller svindelavdekking. Begge tilnærmingene vil bestå, og organisasjoner må bygge plattformer som støtter begge effektivt. Avgjørelsen handler til slutt om avveininger mellom kostnad, forsinkelse og pålitelighet.

Hvordan vil en moden AI-plattform for bedrifter se ut om 2–3 år, og hvordan passer verktøy som Ray og plattformer som Anyscale inn i denne fremtiden?

De neste årene vil modne AI-plattformer for bedrifter kjennetegnes av noen sentrale egenskaper. De vil bygge på enhetlig infrastruktur som støtter hele AI-livssyklusen, fra databehandling til trening og inferens, fremfor en samling separate verktøy. De vil ha god løpende drift etter utrullingen, med agentautomatisert observerbarhet, pålitelighet og rask feilsøking. Kostnadsstyringen vil være forutsigbar og under kontroll, slik at organisasjonene kan skalere bærekraftig. Kanskje viktigst er at de vil muliggjøre høy utviklingstakt og gjøre det enkelt for team å gå raskt fra idé til produksjon. Plattformer som Ray og Anyscale spiller en sentral rolle ved å gi et fundament utformet for AI, som gjør denne skalaen og effektiviteten mulig.

Takk for et flott intervju. Lesere som vil vite mer, kan besøke Anyscale.