Християн Стано, технічний директор компанії Anyscale – Серія інтерв’ю

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

Anyscale – це компанія, яка стоїть за Ray, відкритою розподіленою обчислювальною рамкою, широко використовуваною для масштабування штучного інтелекту та робіт з Python на кластерах процесорів та графічних процесорів. Заснована оригінальними творцями Ray з RISELab Університету Каліфорнії в Берклі, компанія зосереджена на спрощенні розгортання, оркеструванні та керуванні великомасштабною інфраструктурою штучного інтелекту для навчання, висновку, обробки даних та агентських робіт з штучним інтелектом. Її платформа дозволяє організаціям запускати розподілені системи штучного інтелекту в хмарному та локальному середовищі, забезпечуючи спостережуваність, керування та оптимізацію продуктивності, призначені для сучасних застосунків штучного інтелекту. Ray став ключевим шаром у майбутній інфраструктурі штучного інтелекту, допомагаючи розробникам масштабувати робочі процеси з однієї машини до тисяч вузлів з мінімальними змінами існуючого коду Python.

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

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

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

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

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

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

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

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

Що мотивувало ваше рішення приєднатися до Anyscale на цьому етапі, і як ви бачите роль технічного директора у формуванні прийняття штучного інтелекту в підприємствах?

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

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

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

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

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

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

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

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

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

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

По мірі того, як робочі процеси штучного інтелекту масштабуються, керування витратами стає як більш важливим, так і більш складним. Одним з найбільш пропущених викликів є те, як швидко витрати можуть зростати через неефективності, особливо з інфраструктурою на основі графічних процесорів. Великі кластери можуть запустити тисячі вузлів, а якщо ресурси не належним чином керуються чи не зупиняються, витрати швидко зростають. Це створює певний вид розсіювання штучного інтелекту, де використання обчислень зростає швидше, ніж команди можуть відстежувати чи контролювати. Подолання цього вимагає комбінації сильного керування, спостережуваності, автоматизації, chẳng hạn як автомасштабування, авто-відміна та централізоване керування ресурсами. У масштабі ефективність витрат не тільки операційна проблема, а й фундаментальна частина проекту системи.

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

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

Оглядаючи вперед, що виглядає “зрілий” підприємства платформа штучного інтелекту за 2-3 роки – і як інструменти, такі як Ray, та платформи, такі як Anyscale, входять у це майбутнє?

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

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