Christian Stano, Field CTO ve společnosti Anyscale – Interview Series

Christian Stano, Field CTO ve společnosti Anyscale, vybudoval kariéru na rozhraní velkých AI infrastruktur, platforem strojového učení a distribuovaného výpočtu. Předtím, než se připojil k Anyscale, vedl organizaci AI/ML Platform v Attentive, kde škáloval infrastrukturu podporující personalizaci pro více než půl miliardy odběratelů a pomáhal zavádět systémy Ray-based unified compute, které zlepšovaly vývojovou rychlost a snižovaly provozní náklady. V počátcích své kariéry pracoval v oblasti kybernetické bezpečnosti, cloudové architektury a veřejných sektorových AI iniciativ v organizacích, jako jsou Coalfire a Deloitte, kde se podílel na jedné z prvních platforem strojového učení Ministerstva obrany USA. Jeho zkušenosti zahrnují inženýrství AI platforem, MLOps, cloudovou infrastrukturu, umožnění vývojářů a organizační škálování, což mu dává hluboké zkušenosti s tím, jak pomoci podnikům provozovat AI ve velkém měřítku.

Anyscale je společnost za Ray, otevřenou distribuovanou výpočetní platformou, která se široce používá pro škálování AI a Pythonových zátěží napříč clusterem CPU a GPU. Založena byla původními tvůrci Ray z RISELab na University of California, Berkeley, a společnost se zaměřuje na zjednodušení nasazení, orchestrace a správy velkých AI infrastruktur pro školení, inferenci, zpracování dat a agentic AI zátěže. Jejich platforma umožňuje organizacím spouštět distribuované AI systémy napříč cloudovými a on-premise prostředími, zatímco poskytuje pozorovatelnost, správu a optimalizaci výkonu navrženou pro moderní AI aplikace. Ray se stal základním vrstvem v novém AI infrastrukturním balíčku, který pomáhá vývojářům škálovat zátěže z jednoho stroje na tisíce uzlů s minimálními změnami stávajícího Python kódu.

Pracoval jste v oblastech kybernetické bezpečnosti, veřejných sektorových ML platforem a hyperškálových personalizačních systémů. Jaké vzorce jste konzistentně viděl, když organizace přecházejí z AI pilotních projektů do produkční fáze?

V různých odvětvích se objevují tři vzorce pravidelně. První, týmy nemají spolehlivou cestu z vývoje do produkční fáze. Mohou postavit model v poznámkách, ale není standardizovaný způsob, jak ho spustit v produkční fázi. Každé nasazení se stává jednorázovým a každé selhání je překvapením. Druhý, infrastruktura nemůže škálovat s potřebami. Systém, který fungoval v pilotním projektu, selže, když mu budete krmit skutečné objemy dat nebo skutečný provoz. Třetí, týmy létají naslepo. Nemají pozorovatelnost, aby věděli, jak jejich systémy skutečně fungují, kde se chystají rozbit, a kdy zasáhnout.

Co spojuje všechny tři, je stejná základní výzva — týmy nemají správný mentální model pro škálování. Snaží se vyřešit vše najednou, místo aby byli úmyslní při sekvenování. Myslím si to jako tři fáze: udělat to fungovat, udělat to správně, udělat to rychle. Tyto fáze nejsou jednorázové milníky — tyto fáze jsou iterativní. Vous jste neustále priorizovali mezi tím, co je právě rozbité, a tím, co se bude rozbit v budoucnu. Týmy, které uspějí, vědí, v které fázi jsou, a zůstávají disciplinovaní, aby nepřeskočili předtím, než je základna pevná.

V Anyscale vidíme týmy, které přicházejí ve všech fázích. Některé jsou stále snaží se udělat to fungovat — potřebují spolehlivou cestu z vývoje do produkční fáze. Jiné mají to, ale tonou v provozní komplexitě a potřebují udělat to správně. A mnohé přicházejí k nám, protože postavily něco, co funguje, ale nemohou ho tlačit do měřítka, které podnik vyžaduje. Unified compute layer pomáhá v každé fázi, ale vstupní bod závisí na tom, kde je bolest nejostřejší.

V Attentive jste pomáhal škálovat AI systémy, které podporují stovky milionů uživatelů. Jaké byly největší architektonické nebo organizační zátarasy, které jste museli překonat, aby jste dosáhli tohoto měřítka?

Největším zátarasem byla S-křivka infrastrukturní komplexity. Když jsme tlačili naše modely, aby zahrnovaly více dat a obsluhovaly více zákazníků, narazili jsme na výpočetní inflexní bod, kde i největší vertikálně škálované uzly vyhodily chyby out-of-memory, a naivní horizontální škálování nebylo dostatečné. Naše výpočetní prostředky nemohly držet krok se škálováním našich dat.

Přirozenou reakcí bylo vrstvit další nástroje, aby se pracovalo kolem omezení. To byla moje interní příručka z předchozích zkušeností. Každý nástroj řešil úzký problém, ale přidával provozní komplexitu. Naše ML pipeline čelila riziku, že se stane patchworkem integrací, a každý nový případ použití znamenal více šití, více režimů selhání, vyšší náklady a více režie pro platformový tým.

Co nakonec odemklo škálování pro nás, bylo sjednocení zpracování dat, školení, inference a obsluhy na Ray a Anyscale. Dopad byl okamžitý: s dramaticky nižšími infrastrukturními náklady, významně rychlejšími školicími cykly, i když se zvyšovaly objemy dat, a schopností škálovat modely na řádově více zákazníků.

Co vás motivovalo k rozhodnutí připojit se k Anyscale v této fázi, a jak vidíte roli Field CTO při formování podnikové AI adopce?

Mé zkušenosti s přivedením Anyscale do Attentive fundamentálně změnily mou příručku pro stavbu ML platforem. Předtím, než byla významná část platformového inženýrství náklad na šití fragmentovaných systémů. S Anyscale jsme mohli eliminovat velkou část této režie a místo toho se zaměřit na vývojářský zážitek, spolehlivost a výkon. Tato změna měla obrovský dopad na produktivitu týmu a výsledky systému. Připojení se k Anyscale byla příležitost pracovat na tomto problému na plný úvazek a pomoci jiným organizacím procházet stejnou transformací. Jako Field CTO je moje role vlastně o převodu těch reálných lekcí na opakující se vzorce, které naši zákazníci mohou aplikovat, když škáluje AI.

Mnohé podniky jsou stále uvízlé v „pilotní fázi“ AI. Z vašeho pohledu, co specificky selže, když společnosti snaží škálovat tyto rané experimenty do produkčních systémů?

Když společnosti přecházejí z AI experimentů do produkční fáze, co selže, je zřídka jen model — je to okolní systém a operace. V některých případech týmy narazí na infrastrukturní limity brzy a nemohou školoval nebo obsluhoval ve škálování, které chtějí. Musí omezit počet zákazníků nebo případů použití, které jejich model obsluhuje, v důsledku toho. Více často, problémy se objevují v produkční fázi prostřednictvím neočekávaných edge případů nebo změn v datech. Jedním z nejčastějších bodů selhání je paměť: když se velikost dat, distribuce nebo modalita změní, úkoly vyčerpají paměť a selžou. Tyto problémy jsou obtížné předvídat a ještě obtížnější automaticky se zotavit. Realita je, že selhání je nevyhnutelné v produkční AI. Cílem není úplně se mu vyhnout, ale detekovat ho rychle, pochopit ho a postavit samoopravné systémy, aby se vyřešilo, než to dopadne na podnik.

Ray, distribuovaný výpočetní rámec vytvořený týmem za Anyscale, získává trakci jako základ pro AI zátěže. Proč se distribuovaná execuce stává tak kritickou vrstvou v moderní AI infrastruktuře?

Distribuovaná execuce a správa zátěže se staly základními požadavky pro AI pipeline. Moderní AI zátěže jsou inherentně paralelní a náročné na zdroje. Školení, inference a zpracování dat všechny vyžadují koordinaci velkého počtu úkolů napříč CPU a GPU, často dynamicky. V dnešním výpočetním krajínu je komplexita správy těchto zátěží napříč vzácnými zdroji obrovským provozním břemenem. Tradiční systémy nebyly navrženy pro tuto úroveň komplexity nebo škálovatelnosti. Rámce, jako je Ray, jsou kritické, protože umožňují týmům škálovat zátěže bezproblémově z jednoho stroje na tisíce uzlů, automatizací základní koordinace. Tato změna odráží širší posun směrem k AI-nativní výpočetní, kde infrastruktura je navržena specificky pro vzorce AI zátěží, spíše než adaptována ze starších paradigmat.

Jako více společností přijímá Ray prostřednictvím platformy Anyscale, jaké rozdíly vidíte mezi organizacemi, které standardizují na jednotný přístup, a těmi, které šijí fragmentované nástroje?

Rozdíl mezi jednotnými platformami a fragmentovanými nástroji nakonec spočívá v zaměření a efektivitě. Když týmy spoléhají na více nesouvisejících systémů, tráví významné množství času šitím těchto systémů, správou nesrovnalostí a reagováním na selhání v různých prostředích. To vytváří provozní režii a zpomaluje experimentování. Naopak, jednotný přístup umožňuje týmům soustředit své úsilí na zlepšování jednoho systému, což vede k lepší spolehlivosti, silnějšímu výkonu a více proudovému vývojářskému zážitku. To také zjednodušuje procesy on-call a debugging, protože vzorce jsou konzistentnější a snazší pochopit. Výsledek není jen technická efektivita, ale organizační jasnost.

Za vašich zkušeností s budováním koncových ML platforem, jak důležité je pro urychlení AI adopce napříč týmy vývojářský zážitek (DevEx)?

Vývojářský zážitek je jednou z nejvyšších pák pro urychlení AI adopce. Když platformové týmy investují do toho, aby systémy byly snazší na použití prostřednictvím standardizovaných workflow, šablon a snížené infrastrukturní tření, zesilují produktivitu každého inženýra v organizaci. To je especialmente důležité v AI, kde je tempo změny extrémně rychlé a týmy potřebují iterovat rychle, aby zůstaly konkurenceschopné. Zlepšení vývojářského zážitku se přímo překládají do rychlejšího experimentování, rychlejšího času do produkční fáze a nakonec více obchodního dopadu. AI kódovací nástroje zesilují tyto DevEx základy. Ve mnoha ohledech je to nejškálovatelnější způsob, jak zvýšit rychlost napříč organizací.

Nákladová efektivita se stává hlavní starostí, jakmile se AI zátěže škáluje. Jaké jsou některé z nejvíce přehlížených způsobů, jak podniky mohou snížit infrastrukturní náklady, aniž by obětovaly výkon?

Jakmile se AI zátěže škáluje, správa nákladů se stává jak důležitější, tak komplexnější. Jedním z nejvíce přehlížených výzev je, jak rychle náklady mohou spirálovat kvůli neefektivitám, zejména s GPU-založenou infrastrukturou. Velké klastry mohou spustit tisíce uzlů, a pokud nejsou zdroje řádně spravovány nebo ukončeny, náklady se rychle hromadí. To vytváří formu AI-specifické sprawlu, kde výpočetní využití roste rychleji, než týmy mohou sledovat nebo kontrolovat. Řešení tohoto problému vyžaduje kombinaci silné správy, viditelnosti a automatizace, jako je autoscaling, auto-ukončení a centralizovaná správa zdrojů. Ve škálování je nákladová efektivita nejen provozní starostí, ale fundamentální součástí systémového designu.

Pracoval jste na všem od feature stores po real-time inferenční systémy. Jak se vyvíjí rovnováha mezi batch a real-time AI zátěžemi?

Rovnováha mezi batch a real-time AI zátěžemi se nezásadně nezměnila — zůstává otázkou obchodních požadavků. Batch zpracování je typicky více nákladově efektivní a snazší na provoz, což z něj činí vhodné pro mnoho případů použití. Real-time systémy jsou nezbytné, když latence přímo ovlivňuje uživatelský zážitek nebo obchodní výsledek, jako je v chat aplikacích nebo detekci podvodu. Oba přístupy budou pokračovat v koexistenci, a klíčem pro organizace je postavit platformy, které mohou podporovat obě efektivně. Rozhodnutí nakonec závisí na kompromisu mezi náklady, latencí a spolehlivostí.

Pohledem do budoucna, co vypadá „zralá“ podniková AI platforma za 2–3 roky — a jak se do toho zapojují nástroje, jako je Ray a platformy, jako je Anyscale?

V příštích letech budou zralé podnikové AI platformy definovány několika klíčovými charakteristikami. Bude se spoléhat na jednotnou infrastrukturu, která podporuje celý AI životní cyklus, od zpracování dat po školení a inferenci, spíše než na sbírku nesouvisejících nástrojů. Bude mít silné Day 2 operace, s agent-automatizovanou pozorovatelností, spolehlivostí a rychlým debugováním. Nákladová správa bude předvídatelná a řízená, umožňující organizacím škálovat udržitelně. A možná nejdůležitěji, umožní vysokou vývojářskou rychlost, dělají to snadné pro týmy, aby se pohybovaly od nápadu k produkční fázi rychle. Platformy, jako je Ray a Anyscale, hrají centrální roli v tomto budoucím vývoji, poskytují AI-nativní základnu, která umožňuje tuto úroveň škálovatelnosti a efektivnosti.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Anyscale.