Выбираем MLOps инструменты с учётом зрелости команды

MLOps — это набор практик и процессов для управления жизненным циклом ML-моделей: от обучения ^[1] до продакшна и поддержки. Если копнуть глубже, окажется, что решений куча и выбор неочевиден.

Разберем, почему не всё так просто и как принимать решения о внедрении MLOps инструментов.

MLOps: почему столько инструментов?

В MLOps включают всё, от трекинга экспериментов до CI/CD и инференса. Инструменты множатся и умирают, путаницы становится только больше.

Отмечу несколько особенностей:

• Основной стек сегодня — kubernetes-центричен. Потому многие начинают с kubeflow ^[2] для обучения и kserve ^[3] для инференса.

• Кодовая база: в основном python, реже C++, Go, Rust.

• Hadoop/Java есть в многих больших компаниях. В моем окружении их особо не любят.
  Хотя, Trino, говорят, достаточно крутой.

Итак, под каждую задачу куча различных репозиториев. Но по факту живут, развиваются и используются из них единицы. В интернете много MLOps карт, в них обычно собрано все подряд. Карту живых и используемых приложил в статью:

Все почему-то пишут свое

Несмотря на обилие инструментов, компании продолжают писать самостоятельно.
Несколько примеров:

• Запускалки задач: Netflix Metaflow ^[5], uber Airflow ^[6], Яндекс Нирвана ^[7], Doordash workbench ^[8] и другие

• Фичесторы: Домклик ^[9], Delivery hero ^[10] и другие.

Чем больше команда и сложнее процессы — тем выше шанс, что опенсорс не подойдёт. Внедрение превращается в долгую и дорогую адаптацию под себя. Забегая вперед, самостоятельно обычно пишут “платформенные инструменты”, описывающие бизнес процессы, построенные на “кубиках”.

Open-source: три типа, три проблемы

Условно открытые репозитории можно поделить на 3 типа:

1. Открытые версии SaaS продуктов — как правило, имеют ограниченный функционал. Что-то придется дописывать.

2. Фреймворки, выпущенные из больших компаний — часто перегружены и тяжело адаптируемы.

3. Проекты от энтузиастов — нестабильны, поддержка непредсказуема, их развитие иногда зависит исключительно от субъективного мнения разработчика.

Кроме того, подходы в построении прода в вашей команде могут отличаться от идей команды фреймворка. По этим причинам Plug-and-play часто не работает. Интеграция занимает до 6-12 месяцев. Оказывается, что за это время проще написать что-то своё, чем адаптировать чужое.

Платформы и кубики

Инструментарий MLOps можно разделить на:

• Кубики — обособленные инструменты под узкие задачи (например, база данных).

• Платформы — связывают процессы и кубики в единую систему (например, Kubeflow).

Не все однозначно так классифицируется. Feature Store, например, скорее является кубиком в общей системе. Однако без бизнес процессов и интеграции с другой инфраструктурой и процессами – он просто красивая идея.

Для кубиков и платформ разная логика ^[11] выбора

Платформы

Чем больше компания, тем больше у нее бизнес процессов. И тем сложнее интегрировать платформенный инструмент, имеющий собственные паттерны.

Начинающие команды (1–3 ML-инженера)

Процессов в команде еще нет. Можно взять любой понравившийся инструмент. Тут же часто начинают с SaaS решений и открытых решений, продающихся компаниями/облаками по модели SaaS.

Ограничения фреймворков скорее всего еще не будут заметны.
А когда они станут проблемой, их должно быть относительно просто выкинуть и заменить на более сложное решение.

Средние команды (3-10 человек)

По мере роста команды, развития процессов и интеграции тулзов, начинает расти количество “клея” между ними.
Здесь пришлось написать костыль, там коннектор, тут запатчить сборку и тд.

Возможно появление первых велосипедов для основных процессов.
Но, в целом, тут почти всегда возможно подогнать процессы под возможности OpenSource. И именно так команды стараются делать.

Зрелые команды (10+ человек)

Накапливаются 2 тренда:

1. Бизнес процессы становятся глубже и сложнее.

2. Количество клея между компонентами становится все больше. Поддерживать и управлять им все сложнее.

Наступает ситуация, когда “а давайте внедрим фреймворк Х?” занимает 6-12 месяцев.

У технарей есть выбор:

1. Копаться в OpenSource, фиксить кучу багов, фиксить сборку, писать костыли под себя. И потом все это поддерживать в своем fork-е.

2. Написать все с нуля на кубиках, точно описав процессы.

И вот тут мы приходим к тому, что написание своего велосипеда, во-первых, хорошо описывает внутренний бизнес сценарий, а, во-вторых, кратно снижает количество костылей вокруг решения.

Если в малых и средних командах первое решение занимает в разы больше времени, то, в больших, написание своего вполне может оказаться быстрее и правильнее (да еще и компетенция команды вырастет).

Кубики

Тут логика прямо противоположная. Чем больше компания, тем важнее для нее качественные кубики.

Начинающие команды (1–3 ML-инженера):

Делаем MVP: процессы неустойчивы, про большую нагрузку и надежность нужно пока не думать. Если вы сразу будете делать “Enterprise-grade-solution” – вы потонете. Я в таком участвовал, в итоге весь продукт пришлось закопать.

Главное – нужна скорость и как можно быстрое начало тестирования пользователями.

По этой причине можно использовать все, что попадется под руку, и с чем вы уже умеете работать. Тут часто появляются странные вещи, типа хранения логики на s3 или объектных данных в postgress. Если подумать – это не так ужасно на данном этапе.

Если продукт зайдет, то, под давлением реальных пользователей, вы лучше поймете как переписать. А если юзеров не будет, то вы просто сэкономите время и перейдете к следующим более перспективным идеям.

Средние (3-10 человек):

Вот тут MVP сталкивается с кейсами использования. Тут начинает все валиться.
Синие глаза, полуночный дебаг, куча 500 на проде и тд.

Можно снизить масштаб таких проблем, но они все равно возникнут. Команда не может все идеально понять и где-то сделает неоптимально. Софт – услуга и инструмент, а не конечная ценность. Поэтому есть приверженность к моде, частые смены повесток, модные фреймворки и неправильно составленные планы.

Тут приходит осознание важности качественных кубиков. Но нагрузки обычно мало. Замеры производительности и качественные оптимизации редки (или просты).
Поэтому использование чего-нибудь модного, популярного, но не сильно сырого – норм идея.

Зрелые (10+ человек):

Бизнес процессы огромны, но относительно стабильны.

Нагрузка становится большой. Стоимость инфраструктуры начинает измеряться сотнями тысяч и миллионами рублей в месяц на проект. Неправильно выбранный кубик приводит к неэффективности всей системы. Юзеры грустят. Оказывается, что даже хороший OpenSource нужно правильно настраивать и оптимизировать.

Модные кубики могут вообще не выдерживать такую нагрузку или приводить к огромным чекам на инфраструктуру.

Написание кубиков с нуля очень трудоемко и требует узкой дорогой компетенции. Наверное, именно по этому, идейных/процессных MLOps платформ куча, а производительных кубиков единицы.

И как следствие:

1. Реализуя процессы, их стараются подогнать под возможности кубиков

2. Вендоры OpenSource и собственно разработанных кубиков становятся очень полезны и нужны. Чем большую надежность и ответственность они берут на себя, тем больше денег им готовы за это платить.

Что же внедрять?

• Начинающим – берите что хотите, лишь бы оно быстро разворачивалось и настраивалось.

• Небольшим и средним командам — берите то, что:

  • На слуху, но появилось не вчера

  • Относительно легко заносится

  • Позже можно выкинуть, не переписывая всю систему

• Зрелым командам — обсуждать требования, смотреть код, тестировать и страдать.

Заключения

MLOps — это не цель, а способ организовать работу и уменьшить хаос. Инструменты, подходы и архитектуры сильно зависят от зрелости команды и специфики задач. Универсальных решений нет — важно понимать контекст и находить баланс между готовыми решениями и своими разработками.

Канал автора в телеграм @deploy_ml ^[12]