Крістіан Стано, Field CTO компанії Anyscale — серія інтерв’ю

Крістіан Стано, Field CTO компанії Anyscale, побудував кар’єру на перетині великомасштабної інфраструктури ШІ, платформ машинного навчання та розподілених обчислень. До Anyscale він очолював підрозділ платформ ШІ та машинного навчання в Attentive. Там він масштабував інфраструктуру персоналізації для понад пів мільярда абонентів і сприяв упровадженню єдиних обчислювальних систем на базі Ray, які прискорили розробку та знизили операційні витрати. Раніше він працював над кібербезпекою, хмарною архітектурою та ініціативами ШІ в державному секторі в Coalfire, Deloitte та інших організаціях, зокрема долучився до однієї з перших платформ машинного навчання Міністерства оборони США. Його досвід охоплює інженерію платформ ШІ, MLOps, інфраструктуру, спроєктовану для хмари, підтримку розробників і розширення організацій. Завдяки цьому він має значний досвід допомоги підприємствам із запуском ШІ у великомасштабну промислову експлуатацію.

Anyscale — компанія, що розвиває Ray, фреймворк розподілених обчислень із відкритим кодом, який широко використовують для масштабування завдань ШІ та Python у кластерах CPU і GPU. Компанію заснували перші розробники Ray з RISELab Каліфорнійського університету в Берклі. Вона спрощує розгортання, оркестрацію та керування великомасштабною інфраструктурою ШІ для навчання моделей, інференсу, обробки даних і завдань агентів ШІ. Платформа дає змогу запускати розподілені системи ШІ в хмарних і локальних середовищах та забезпечує спостережуваність, управління й оптимізацію продуктивності для сучасних застосунків ШІ. Ray став ключовим шаром нової інфраструктури ШІ: розробники можуть масштабувати завдання з однієї машини до тисяч вузлів, мінімально змінюючи наявний код Python.

Ви працювали з кібербезпекою, платформами машинного навчання для державного сектору й надвеликими системами персоналізації. Які закономірності постійно спостерігаєте, коли організації намагаються перейти від пілотних проєктів ШІ до промислової експлуатації?

У різних галузях регулярно повторюються три закономірності. По-перше, команди не мають надійного, налагодженого шляху від розробки до експлуатації. Вони можуть створити модель у середовищі notebook, але немає стандартного способу запустити її в робочому середовищі. Кожне розгортання стає окремим рішенням, а кожен збій — несподіванкою. По-друге, інфраструктура не масштабується відповідно до потреб. Система, яка працювала в пілотному проєкті, падає під реальними обсягами даних або трафіком. По-третє, команди працюють без належного розуміння ситуації. Їм бракує спостережуваності, щоб знати, як системи насправді працюють, де наближається збій і коли втручатися.

Усі три мають спільну першопричину: команди не розуміють належним чином, як масштабуватися, розподіляючи роботу між більшою кількістю машин. Вони намагаються вирішити все одразу, замість того, щоб свідомо планувати послідовність. Я бачу три фази: запустити, налагодити, прискорити. Це не одноразові етапи, а фази, що повторюються. Потрібно постійно визначати пріоритети між тим, що зламалося зараз, і тим, що зламається далі. Успішні команди знають свою фазу й не рухаються вперед, поки основа не стане міцною.

До Anyscale звертаються команди на всіх етапах. Одні ще намагаються запустити систему й потребують надійного шляху від розробки до експлуатації. Інші вже його мають, але потопають в операційній складності й повинні налагодити роботу. Багато хто вже створив працездатну систему, однак не може довести її до потрібного бізнесу масштабу. Єдиний обчислювальний шар допомагає на кожній фазі, але точка початку залежить від найгострішої проблеми.

В Attentive ви допомагали масштабувати системи ШІ для сотень мільйонів користувачів. Які найбільші архітектурні чи організаційні перешкоди довелося подолати, щоб досягти цього масштабу?

Найбільшою перешкодою була S-подібна крива складності інфраструктури. Коли моделі почали охоплювати більше даних та обслуговувати більше клієнтів, ми досягли переломного моменту в обчисленнях. Навіть найбільші вертикально масштабовані вузли видавали помилки нестачі пам’яті, а простого горизонтального масштабування також було недостатньо. Обчислювальна потужність не встигала за масштабом даних.

Природною реакцією було додавати інструменти для обходу обмежень. Саме так я звик діяти на основі попереднього досвіду. Кожен інструмент розв’язував вузьку проблему, але додавав операційної складності. Наш конвеєр машинного навчання ризикував перетворитися на набір розрізнених інтеграцій. Кожен новий сценарій означав більше роботи зі з’єднання систем, більше можливих збоїв, вищі витрати й додаткове навантаження на команду платформи.

Масштабування зрештою стало можливим завдяки об’єднанню обробки даних, навчання, інференсу та надання моделей на базі Ray і Anyscale. Ефект був миттєвим: суттєво нижчі витрати на інфраструктуру, значно швидші цикли навчання навіть зі зростанням обсягів даних і можливість масштабувати моделі для кількості клієнтів, більшої на кілька порядків.

Що спонукало вас приєднатися до Anyscale саме на цьому етапі і як ви бачите вплив ролі Field CTO на впровадження ШІ в підприємствах?

Досвід упровадження Anyscale в Attentive докорінно змінив мій підхід до побудови платформ машинного навчання. Раніше значна частина витрат на розробку платформи припадала на з’єднання розрізнених систем. З Anyscale ми прибрали чимало цієї додаткової роботи й зосередилися на зручності для розробників, надійності та продуктивності. Це сильно вплинуло і на продуктивність команди, і на результати системи. Перехід до Anyscale дав можливість присвятити проблемі весь робочий час і допомагати іншим організаціям пройти ту саму зміну. Як Field CTO я перетворюю практичні уроки на повторювані підходи, які клієнти можуть застосовувати під час масштабування ШІ.

Багато підприємств досі застрягли на пілотній фазі ШІ. Що, на вашу думку, конкретно відмовляє, коли вони намагаються масштабувати ранні експерименти до систем промислової експлуатації?

Під час переходу від експериментів із ШІ до експлуатації проблема рідко обмежується моделлю. Відмовляють система навколо неї та її операційні процеси. Іноді команди рано досягають меж інфраструктури й не можуть навчати або надавати моделі в бажаному масштабі. Тому доводиться обмежувати кількість клієнтів або сценаріїв, які обслуговує модель. Частіше проблеми виникають у робочому середовищі через неочікувані граничні випадки або зміни даних. Пам’ять — одна з найпоширеніших точок відмови: коли розмір, розподіл або тип даних змінюється, завдання вичерпують пам’ять і завершуються помилкою. Це важко передбачити, а автоматичне відновлення після таких проблем ще складніше. Збої в промисловій експлуатації ШІ неминучі. Мета — не повністю їх уникнути, а швидко виявляти, розуміти й будувати системи із самовідновленням, які усуватимуть проблеми до впливу на бізнес.

Ray, фреймворк розподілених обчислень від команди засновників Anyscale, дедалі частіше стає основою завдань ШІ. Чому розподілене виконання перетворюється на такий важливий шар сучасної інфраструктури ШІ?

Розподілене виконання та керування навантаженнями стали базовими вимогами до конвеєрів ШІ. Сучасні завдання ШІ паралельні за своєю природою й потребують багато ресурсів. Навчання, інференс і обробка даних вимагають координації великої кількості завдань між CPU та GPU, часто динамічної. У сучасному обчислювальному середовищі складність керування цими завданнями за обмежених ресурсів створює величезне операційне навантаження. Традиційні системи не були розраховані на таку складність і масштаб. Ray та подібні фреймворки важливі, бо автоматизують базову координацію й дозволяють плавно масштабувати завдання з однієї машини до тисяч вузлів. Це відображає ширший перехід до обчислень, спочатку спроєктованих для ШІ. Інфраструктуру створюють саме для характерних завдань ШІ, а не адаптують зі старих парадигм.

Коли дедалі більше компаній упроваджують Ray через Anyscale, які відмінності ви бачите між організаціями, що обирають єдиний підхід як стандарт, і тими, що з’єднують окремі інструменти?

Різниця зрештою полягає в зосередженості й ефективності. Команди, що покладаються на кілька відокремлених систем, витрачають багато часу на їх з’єднання, усунення неузгодженостей і реагування на збої в різних середовищах. Це створює додаткову операційну роботу та сповільнює експерименти. Єдиний підхід натомість дозволяє зосередитися на вдосконаленні однієї системи. Результат — вища надійність, краща продуктивність і зручніша робота розробників. Чергування для реагування на інциденти та налагодження також спрощуються, бо підходи послідовні й зрозумілі. Це дає не лише технічну ефективність, а й організаційну ясність.

З огляду на досвід побудови наскрізних платформ машинного навчання, наскільки важливі умови роботи розробників (DevEx) для прискорення впровадження ШІ в різних командах?

DevEx — один із найвпливовіших напрямів для прискорення впровадження ШІ. Коли команди платформ спрощують користування системами через стандартизовані процеси, шаблони й зменшення інфраструктурних перешкод, вони підвищують продуктивність кожного інженера в організації. Це особливо важливо для ШІ, де зміни надзвичайно швидкі й команди мають швидко повторювати цикли розробки, щоб залишатися конкурентоспроможними. Покращення DevEx безпосередньо пришвидшує експерименти, скорочує шлях до промислової експлуатації та зрештою збільшує вплив на бізнес. Інструменти програмування з підтримкою ШІ посилюють ці основи DevEx. У багатьох аспектах це найбільш масштабований спосіб прискорити всю організацію.

Ефективність витрат стає важливим питанням зі зростанням завдань ШІ. Які часто непомічені можливості дозволяють підприємствам знизити витрати на інфраструктуру без погіршення продуктивності?

Зі зростанням завдань ШІ керування витратами стає важливішим і складнішим. Часто не помічають, як швидко витрати можуть вийти з-під контролю через неефективність, особливо в інфраструктурі на базі GPU. Великі кластери можуть запускати тисячі вузлів. Якщо ресурсами неправильно керують або їх не вимикають, витрати швидко накопичуються. Виникає специфічне для ШІ неконтрольоване розростання ресурсів: використання обчислень зростає швидше, ніж команди встигають відстежувати або контролювати. Рішення потребує поєднання сильного управління, видимості й автоматизації, як-от автоматичного масштабування, автоматичного завершення та централізованого керування ресурсами. За великого масштабу ефективність витрат — не лише операційне питання, а базова частина проєктування системи.

Ви працювали з технологіями від сховищ ознак до систем інференсу в реальному часі. Як, на вашу думку, змінюється баланс між пакетними завданнями ШІ та завданнями реального часу?

Цей баланс принципово не змінився: усе ще йдеться про потреби бізнесу. Пакетна обробка зазвичай дешевша й простіша в експлуатації, тому підходить для багатьох сценаріїв. Системи реального часу необхідні, коли затримка прямо впливає на досвід користувача або бізнес-результат, наприклад у чатах чи виявленні шахрайства. Обидва підходи співіснуватимуть. Організаціям потрібні платформи, що ефективно підтримують кожен із них. Рішення зрештою залежить від компромісів між витратами, затримкою та надійністю.

Як виглядатиме зріла корпоративна платформа ШІ через 2–3 роки і як у це майбутнє вписуються інструменти на кшталт Ray та платформи на кшталт Anyscale?

Наступними роками зрілі корпоративні платформи ШІ матимуть кілька ключових характеристик. Вони спиратимуться на єдину інфраструктуру для всього життєвого циклу ШІ — від обробки даних до навчання та інференсу, а не на набір розрізнених інструментів. Повсякденна експлуатація після запуску буде добре організована, зі спостережуваністю, автоматизованою агентами, надійністю та швидким налагодженням. Керування витратами буде передбачуваним і підконтрольним, що дасть організаціям змогу стало масштабуватися. Можливо, найважливіше — платформи забезпечуватимуть високу швидкість розробки й легкий перехід від ідеї до експлуатації. Ray і Anyscale відіграють тут центральну роль, надаючи основу, спроєктовану саме для ШІ, яка уможливлює такий масштаб і ефективність.

Дякуємо за чудове інтерв’ю. Читачі, які хочуть дізнатися більше, можуть відвідати Anyscale.