Christian Stano, Field CTO bij Anyscale – Interviewreeks

Christian Stano, Field CTO bij Anyscale, heeft een carrière opgebouwd op het snijvlak van grootschalige AI-infrastructuur, machine learning-platforms en gedistribueerde computing. Voordat hij bij Anyscale kwam, leidde hij de AI/ML-platformorganisatie bij Attentive, waar hij infrastructuur schaalde om personalisatie te ondersteunen voor meer dan de helft van een miljard abonnees en hielp bij het stimuleren van de adoptie van Ray-gebaseerde unified compute-systemen die de ontwikkelingsvelocity verbeterden en de operationele kosten verlaagden. Eerder in zijn carrière werkte hij bij cybersecurity, cloudarchitectuur en openbare sector AI-initiatieven bij organisaties, waaronder Coalfire en Deloitte, waar hij bijdroeg aan een van de eerste machine learning-platforms van het Amerikaanse ministerie van Defensie. Zijn achtergrond omvat AI-platformengineering, MLOps, cloud-native infrastructuur, developer enablement en organisatorische schaalvergroting, waardoor hij diepe ervaring heeft in het helpen van ondernemingen om AI op productieschaal operationeel te maken.

Anyscale is het bedrijf achter Ray, het open-source distributed compute-framework dat breed wordt gebruikt voor het schalen van AI- en Python-workloads over clusters van CPUs en GPUs. Opgericht door de oorspronkelijke makers van Ray van UC Berkeley’s RISELab, richt het bedrijf zich op het vereenvoudigen van de implementatie, orchestratie en beheer van grootschalige AI-infrastructuur voor training, inferentie, gegevensverwerking en agentic AI-workloads. Het platform stelt organisaties in staat om gedistribueerde AI-systemen uit te voeren over cloud- en on-premise-omgevingen, met observabiliteit, governance en prestatie-optimalisaties die zijn ontworpen voor moderne AI-toepassingen. Ray is een core-laag geworden in de opkomende AI-infrastructuurstack, waardoor ontwikkelaars workloads kunnen schalen van één machine tot duizenden knooppunten met minimale wijzigingen in de bestaande Python-code.

U hebt gewerkt aan cybersecurity, openbare sector ML-platforms en hyperschaalpersonalisatiesystemen. Welke patronen ziet u consistent wanneer organisaties proberen over te gaan van AI-piloten naar productie?

Binnen branches zien drie patronen consistent toe. Ten eerste hebben teams geen betrouwbare, geplaveide weg van ontwikkeling naar productie. Ze kunnen een model bouwen in een notitieboek, maar er is geen gestandaardiseerde manier om het in productie te krijgen. Elke implementatie wordt een eenmalige gebeurtenis, en elke fout is een verrassing. Ten tweede kan de infrastructuur niet schalen met de behoeften. Het systeem dat werkte in een pilootproject faalt wanneer u het voedt met echte gegevensvolumes of echte verkeer. Ten derde vliegen teams blind. Ze missen de observabiliteit om te weten hoe hun systemen daadwerkelijk presteren, waar ze op het punt staan om te breken en wanneer ze moeten ingrijpen.

Wat alle drie verbindt, is dezelfde fundamentele uitdaging — teams hebben geen solide mentale model voor het schalen. Ze proberen alles tegelijk op te lossen in plaats van doelgericht te zijn over sequentiëring. Ik denk hierover als drie fasen: het laten werken, het goed maken, het snel maken. Deze fasen zijn geen eenmalige mijlpalen — deze fasen zijn iteratief. U bent constant prioriteit aan het geven tussen wat nu kapot is en wat de volgende breuk zal zijn. De teams die slagen, weten in welke fase ze zich bevinden en blijven gedisciplineerd over niet vooruit te springen voordat de basis solide is.

Bij Anyscale zien we teams op elk niveau binnenkomen. Sommigen zijn nog steeds bezig met het laten werken — ze hebben een betrouwbare weg van ontwikkeling naar productie nodig. Anderen hebben dat, maar verdrinken in operationele complexiteit en hebben hulp nodig om het goed te maken. En velen komen naar ons toe omdat ze iets hebben gebouwd dat werkt, maar het niet kunnen schalen naar het niveau dat het bedrijf eist. Een unified compute-laag helpt op elk niveau, maar het startpunt hangt af van waar de pijn het scherpst is.

Bij Attentive hielp u AI-systemen schalen die honderden miljoenen gebruikers ondersteunen. Wat waren de grootste architectonische of organisatorische bottlenecks die u moest overwinnen om dat niveau van schaal te bereiken?

De grootste bottleneck was de S-curve van infrastructuurcomplexiteit. Toen we onze modellen schaalden om meer gegevens op te nemen en meer klanten te bedienen, bereikten we een compute-inflexiepunt waar zelfs de grootste verticaal geschaalde knooppunten out-of-memory-fouten gooiden en naive horizontale schaling het niet deed. Onze compute kon niet bijhouden met de schaal van onze gegevens.

De natuurlijke reactie was om meer tools te layeren om de beperkingen te omzeilen. Dit was mijn interne playbook vanuit eerder ervaring. Elke tool lost een smal probleem op, maar voegde operationele complexiteit toe. Onze ML-pipeline stond op het punt om een patchwork van integraties te worden, en elke nieuwe use case betekende meer stitching, meer foutmodi, hogere kosten en meer overhead voor het platformteam.

Wat uiteindelijk de schaal voor ons ontgrendelde, was het unificeren van gegevensverwerking, training, inferentie en serving op Ray en Anyscale. De impact was onmiddellijk: met dramatisch lagere infrastructuurkosten, aanzienlijk snellere trainingscycli, zelfs toen de gegevensvolumes groeiden, en de mogelijkheid om modellen te schalen tot bestellingen van grootte meer klanten.

Wat motiveerde uw beslissing om bij Anyscale te komen op dit niveau, en hoe ziet u de rol van Field CTO bij het vormgeven van de adoptie van enterprise AI?

Mijn ervaring met het brengen van Anyscale naar Attentive veranderde fundamenteel mijn playbook voor het bouwen van ML-platforms. Voordat dat, was een aanzienlijk deel van platformengineering de kosten van het samenstellen van gefragmenteerde systemen. Met Anyscale konden we veel van die overhead elimineren en ons in plaats daarvan richten op developer experience, betrouwbaarheid en prestaties. Die verschuiving had een enorme impact op zowel teamproductiviteit als systeemresultaten. Bij Anyscale komen was een kans om fulltime aan dat probleem te werken en andere organisaties te helpen diezelfde overgang te navigeren. Als Field CTO is mijn rol eigenlijk om die real-world lessen om te zetten in herhaalbare patronen die onze klanten kunnen toepassen bij het schalen van AI.

Veel ondernemingen zitten nog vast in de “pilotfase” van AI. Vanuit uw perspectief, wat breekt er specifiek wanneer bedrijven proberen deze vroege experimenten op te schalen naar productiesystemen?

Wanneer bedrijven van AI-experimenten naar productie gaan, breekt het zelden alleen het model — het is het omringende systeem en de operaties. In sommige gevallen raken teams vroeg infrastructuurbeperkingen en kunnen ze niet trainen of serveren op de schaal die ze willen. Ze moeten het aantal klanten of use cases dat hun model dient, beperken als gevolg. Vaker treden problemen op in productie via onverwachte randgevallen of veranderingen in gegevens. Een van de meest voorkomende foutpunten is geheugen: als gegevensgrootte, -verdeling of -modaliteit verschuift, lopen taken uit het geheugen en mislukken. Deze problemen zijn moeilijk te anticiperen en nog moeilijker om automatisch te herstellen. De realiteit is dat fouten onvermijdelijk zijn in productie-AI. Het doel is niet om het helemaal te vermijden, maar om het snel te detecteren, te begrijpen en zelfherstellende systemen te bouwen om het op te lossen voordat het de business beïnvloedt.

Ray, het distributed computing-framework dat is gemaakt door het team achter Anyscale, wint aan populariteit als fundament voor AI-workloads. Waarom wordt gedistribueerde uitvoering zo’n kritieke laag in de moderne AI-infrastructuur?

Gedistribueerde uitvoering en workloadbeheer zijn tabelstaken geworden voor AI-pijpleidingen. Moderne AI-workloads zijn inherent parallel en resource-intensief. Training, inferentie en gegevensverwerking vereisen allemaal het coördineren van grote aantallen taken over CPUs en GPUs, vaak dynamisch. In het huidige compute-landschap is de complexiteit van het beheren van deze workloads over schaarse resources een enorme operationele last. Traditionele systemen waren niet ontworpen voor dit niveau van complexiteit of schaal. Frameworks zoals Ray zijn kritiek omdat ze teams in staat stellen om workloads naadloos te schalen van één machine tot duizenden knooppunten door de onderliggende coördinatie te automatiseren. Deze verschuiving weerspiegelt een bredere beweging naar AI-native computing, waarbij infrastructuur specifiek is ontworpen voor de patronen van AI-workloads in plaats van aangepast vanuit oudere paradigma’s.

Naarmate meer bedrijven Ray adopteren via het platform van Anyscale, welke verschillen ziet u tussen organisaties die standaardiseren op een unified benadering versus die gefragmenteerde tooling samenstellen?

Het verschil tussen unified platforms en gefragmenteerde tooling komt uiteindelijk neer op focus en efficiency. Wanneer teams afhankelijk zijn van meerdere onafhankelijke systemen, besteden ze een aanzienlijke hoeveelheid tijd aan het samenstellen van die systemen, het beheren van inconsistenties en het reageren op fouten over verschillende omgevingen. Dit creëert operationele overhead en vertraagt experimenten. In tegenstelling tot een unified benadering stelt teams in staat om hun inspanningen te concentreren op het verbeteren van één systeem, wat leidt tot betere betrouwbaarheid, sterker presteren en een gestroomlijnder developer-ervaring. Het vereenvoudigt ook on-call- en debugproces omdat patronen consistent zijn en gemakkelijker te begrijpen. Het resultaat is niet alleen technische efficiëntie, maar ook organisatorische duidelijkheid.

Op basis van uw ervaring met het bouwen van eind-tot-eind ML-platforms, hoe belangrijk is developer experience (DevEx) bij het versnellen van AI-adoptie over teams?

Developer experience is een van de hoogste hefboomgebieden voor het versnellen van AI-adoptie. Wanneer platformteams investeren in het maken van systemen gemakkelijker te gebruiken via gestandaardiseerde workflows, templates en verminderde infrastructuurwrijving, verhogen ze de productiviteit van elke engineer in de organisatie. Dit is vooral belangrijk in AI, waar het tempo van verandering extreem snel is en teams snel moeten itereren om concurrerend te blijven. Verbeteringen in developer experience vertalen zich rechtstreeks in snellere experimenten, snellere tijd naar productie en uiteindelijk meer business-impact. AI-codingtools verhogen deze DevEx-fundamenten. Op veel manieren is het de meest schaalbare manier om velocity over een organisatie te vergroten.

Kosten-efficiëntie wordt een groot probleem bij het schalen van AI-workloads. Wat zijn enkele van de meest over het hoofd geziene manieren waarop ondernemingen infrastructuurkosten kunnen verlagen zonder prestaties te offeren?

Bij het schalen van AI-workloads wordt kostenbeheer zowel belangrijker als complexer. Een van de meest over het hoofd geziene uitdagingen is hoe snel kosten kunnen spiralen als gevolg van inefficiënties, vooral met GPU-gebaseerde infrastructuur. Grote clusters kunnen duizenden knooppunten starten, en als resources niet goed worden beheerd of afgesloten, accumuleren kosten snel. Dit creëert een vorm van AI-specifieke sprawl, waarbij compute-gebruik sneller groeit dan teams kunnen bijhouden of controleren. Het aanpakken hiervan vereist een combinatie van sterke governance, zichtbaarheid en automatisering, zoals autoscaling, auto-terminatie en centraal resourcebeheer. Op schaal is kosten-efficiëntie niet alleen een operationele zorg, maar een fundamenteel onderdeel van systeemontwerp.

U hebt gewerkt aan alles, van feature stores tot real-time inferentiesystemen. Hoe denkt u dat de balans tussen batch- en real-time AI-workloads evolueert?

De balans tussen batch- en real-time AI-workloads is niet fundamenteel veranderd — het blijft een kwestie van business-eisen. Batch-verwerking is typisch kostenefficiënter en gemakkelijker te bedienen, waardoor het geschikt is voor veel use cases. Real-time systemen zijn essentieel wanneer latentie direct de gebruikerservaring of business-uitkomst beïnvloedt, zoals in chat-applicaties of fraudeopsporing. Beide benaderingen zullen blijven coëxisteren, en de sleutel voor organisaties is om platforms te bouwen die elk effectief kunnen ondersteunen. De beslissing komt uiteindelijk neer op compromissen tussen kosten, latentie en betrouwbaarheid.

Als we vooruitkijken, wat ziet een “volwassen” enterprise AI-platform er over 2-3 jaar uit — en hoe passen tools zoals Ray en platforms zoals Anyscale in die toekomst?

In de komende jaren zullen volwassen enterprise AI-platforms worden gekenmerkt door een paar sleutelkenmerken. Ze zullen afhankelijk zijn van unified infrastructuur die de hele AI-levenscyclus ondersteunt, van gegevensverwerking tot training tot inferentie, in plaats van een verzameling losse tools. Ze zullen sterke Day 2-operaties hebben, met agent-geautomatiseerde observabiliteit, betrouwbaarheid en snelle debugmogelijkheden. Kostenbeheer zal voorspelbaar en gereguleerd zijn, waardoor organisaties duurzaam kunnen schalen. En misschien wel het belangrijkste, ze zullen hoge developer-velocity mogelijk maken, waardoor het voor teams gemakkelijk wordt om van idee naar productie over te gaan. Platforms zoals Ray en Anyscale spelen een centrale rol in die toekomst door de AI-native foundation te bieden die dit niveau van schaal en efficiëntie mogelijk maakt.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Anyscale bezoeken.