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

Меня зовут Александр Волынский, я технический менеджер Cloud ML Platform в VK Cloud. В этой статье я сравню подходы к работе с MLOps на основе Open Source и проприетарного ПО и расскажу, какие инструменты и почему мы выбрали для Cloud ML Platform.

Немного об MLOps


По статистике, до 87% ML-моделей не доходят до продакшена. Это связано с тем, что управлять инфраструктурой для ML и организовывать работу с данными на разных этапах жизненного цикла в больших проектах сложно. Да и переход от экспериментирования к выводу в прод и построению сервиса создает трудности: одно дело проводить эксперименты в Jupyter Notebook, а другое — упаковать все в Docker-образ, поднять в Kubernetes, организовать мониторинг и логирование. MLOps помогает все это упорядочить.

MLOps — современный подход к работе с ML-моделями и управлению проектами машинного обучения. Он помогает:

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

MLOps решает перечисленные задачи с помощью различных инструментов и процессов. 

На чем строить MLOps: проприетарные инструменты vs Open Source


Для MLOps можно использовать как проприетарные, так и Open-Source-инструменты. Проприетарное ПО часто выбирают, чтобы получать поддержку вендора, стабильные обновления, а в ряде случаев — возможность влиять на роадмап. В то же время Open-Source-инструменты можно гибче адаптировать под свой проект, а также легче осваивать: как правило, вокруг таких решений выстраивается целое комьюнити, которое делится материалами, отвечает на вопросы и помогает решать возникающие проблемы.

Преимущества и недостатки есть у каждого из подходов. В этой статье сравним варианты по нескольким параметрам.

Качество кода


Вендорские решения часто воспринимают как более надежные и оптимизированные. Но даже в платных инструментах могут быть баги и «костыли», из-за которых решение при том или ином сценарии работает некорректно. При этом пользователь не имеет доступа к коду, не может исправить ошибку — приходится ждать устранения багов с обновлениями от вендора.

В Open Source исходный код инструментов открыт и доступен всем. Комьюнити изучает код и устраняет ошибки, чтобы инструмент стал лучше. Правда, это касается только распространенного ПО — в небольшом проекте может быть иначе из-за малой аудитории.

Применимость и универсальность


В проприетарных решениях часто превалирует концепция «включил и пользуйся» — с настройками из коробки. Каждый разработчик стремится внедрить в свои решения новые наработки и практики, способные сделать его лучше конкурентов. Это удобно и практично. Однако в случае ухода вендора с рынка и прекращения поддержки экспертиза в одном инструменте, наработанная годами, может оказаться бесполезной. 

ПО на основе Open Source часто строят с учетом общепринятых практик и подходов. Поэтому во многих Open-Source-решениях реализованы схожие функции и возможности — это упрощает освоение новых инструментов. Более того, компании и команды по разным причинам чаще используют именно Open-Source-инструменты — то есть экспертиза в таких решениях обеспечивает универсальность навыка и упрощает поиск специалистов в команду и их онбординг. Правда, работу «из коробки» для Open Source никто обычно не ожидает — инструмент придется настраивать.

Модульность


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

Программное обеспечение с открытым исходным кодом обычно более гибкое в настройке и больше ориентировано на интеграцию с другими платформами. Open-Source-инструменты для MLOps похожи на конструктор: любую часть можно заменить, добавить или удалить, чтобы получить решение конкретно под свои задачи. Правда, такой адаптацией придется заниматься отдельно, что требует от инженеров определенных навыков.

Стабильность версий


Одно из преимуществ продуктов вендоров — регулярные обновления и лицензионная поддержка. Но наряду с преимуществами у этого есть и несколько недостатков. Во-первых, вендоры могут выпускать обновления реже, а в Open Source они выкатываются чаще. Во-вторых, нет возможности откатиться до стабильной версии, если вдруг обновление по каким-то причинам не устраивает: вендор стремится к унификации и поддерживать две версии одного продукта вряд ли захочет.

В Open Source обновления надо выкатывать в продакшен самостоятельно. Это увеличивает нагрузку на разработчиков, работающих с такими решениями. Стабильность версий может варьироваться от продукта к продукту. Однако баги обычно оперативно исправляются. В целом релизы популярных Open Source обычно выходят гораздо чаще, что позволяет быстро исправлять ошибки и реализовывать новую функциональность. 

Подытожим


Проприетарные решения лучше выбирать, когда:

  • в команде нет опыта работы с Open Source и экспертизы в дописывании инструментов под себя;
  • проект большой и сложный, нужна поддержка со стороны вендора;
  • есть бюджет на лицензионное решение по работе с данными.

MLOps-инструменты на основе Open Source больше подойдут, если:

  • хочется в числе первых иметь доступ к новым фичам, которые зачастую быстрее появляются в Open Source;
  • нужно решение, которое можно полностью адаптировать под свои задачи и дополнять нужными модулями;
  • требуется универсальное решение, с которого легко перейти на аналог;
  • важна поддержка сообщества — даже если Open-Source-инструмент станет совсем недоступен, комьюнити совместно решит, куда и как с него переходить;
  • проект небольшой или краткосрочный, покупать проприетарное ПО нерентабельно;
  • важно снизить риски Vendor Lock-in на случай его ухода с рынка.

Обзор Open-Source-инструментов для MLOps


Типовой стек задач в работе с ML-моделями сводится к нескольким этапам:

  • сбор, подготовка, разметка данных;
  • обучение модели;
  • оценка качества модели;
  • вывод модели в продакшен;
  • мониторинг.

Комплексные решения с открытым исходным кодом позволяют решать эти задачи. Кратко расскажу о пяти основных инструментах. 

Kubeflow 


Комплексный инструмент MLOps с открытым исходным кодом. Упрощает организацию и развертывание рабочих процессов машинного обучения. В него входят Seldon Core, KFServing, Kubeflow Pipelines и другие решения, встроен Jupyter Notebook. 

Kubeflow использует контейнеры Docker для поддержки обслуживания ML-систем. Это позволяет масштабировать ML-модели с помощью сквозных оркестровок и упрощает развертывание проектов машинного обучения.

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

Вместе с тем Kubeflow — решение не для всех. В 2022 году создатели инструмента провели опрос, согласно которому из-за сложности инструмента обычно используют только отдельные его компоненты, а не весь доступный набор сервисов. Более того, большой проблемой при внедрении Kubeflow является нехватка документации и обучающих материалов — разбираться в инструменте часто приходится методом проб и ошибок. Поэтому с ним, как правило, работают только опытные специалисты.

MLflow


Open-Source-платформа управления жизненным циклом ML. Включает в себя стек компонентов, которые закрывают большинство потребностей в MLOps:

  • MLflow Tracking — обеспечивает логирование параметров, метрик, кода и других артефактов;
  • MLflow Models — отвечает за упаковку в контейнеры и за деплой моделей;
  • Model Registry — выступает централизованным хранилищем для разных ML-моделей;
  • MLflow Projects — отвечает за преобразование кода и проекта для обеспечения воспроизводимости и повторного использования или передачи в продакшен.

MLflow интегрируется с различными библиотеками машинного обучения, включая TensorFlow и Pytorch. Позволяет управлять экспериментами по машинному обучению и метаданными с помощью CLI, Python, R, Java и REST API.

Работу с MLflow можно попробовать в сервисе Cloud ML Platform, в нем MLflow доступен как преднастроенный компонент, его можно подключить за пару минут.

Pachyderm 


Инструмент контроля версий для ML и обработки данных. Построен на Docker и Kubernetes, что позволяет запускать и развертывать проекты машинного обучения на любой облачной платформе. Обеспечивает версионирование данных и пайплайнов, а также воспроизводимость результатов.

Основные функции инструмента:

  1. Версионирование данных. Одна из ключевых фичей Pachyderm. Полное версионирование всех данных и пайпланов. Эту функциональность можно сравнить с DVC, но Pachyderm лучше подходит для работы с объемами в петабайты данных. К тому же версионируются не только данные, а весь пайплайн целиком, включая данные и код, что позволяет решать задачу воспроизводимости результатов работы пайплайнов. 
  2. Автоматическая дедупликация. Pachyderm интегрируется с объектными хранилищами (S3) для хранения больших объемов данных. При этом при изменении датасета создается копия только измененной части, а не всего датасета. Это позволяет значительно уменьшить объем хранящейся информации, при этом оставляя возможность откатиться к любой предыдущей точке. Как и в предыдущем случае, эта функциональность обеспечивает воспроизводимость.
  3. Data-Driven-пайлайны. Есть возможность при обновлении данных автоматически запустить пайплайны, использующие эти данные как зависимости. То есть фактически речь идет о триггерах для запуска пайплайнов при изменении исходных данных.  
  4. Гибкое масштабирование. Поддерживается автоматическое масштабирование различных этапов пайплайнов на основе возможностей масштабирования Kubernetes.

Pachyderm предполагает большие инвестиции в обучение и внедрение. Использование Kubernetes, с одной стороны, большое преимущество, так как получаем из коробки автомасштабирование и контейнеризацию. Однако установка, настройка и использование Pachyderm без глубокого понимания Kubernetes будет проблематичной, то есть вам точно понадобится выделенный админ или целая команда. К тому же перенос существующих пайплайнов в Pachyderm также потребует значительных трудозатрат. Если у вас уже есть множество потоков данных, то переход на Pachyderm будет отдельным большим вызовом на многие месяцы. Поэтому, вероятно, этот инструмент можно рассматривать в самом начале создания платформы данных, после длительных тестов, понимая все сложности. 
 

Seldon Core


Платформа MLOps с открытым исходным кодом, которая позволяет относительно легко деплоить ML-модели в Kubernetes. С ее помощью можно быстро получить из ML-модели Production Ready REST/GRPS-сервис. Инструмент достаточно популярен (3600 звезд на Github), является одним из стандартов в отрасли для задач деплоя. Seldon Core интегрирован в Kubeflow, может работать вместе с MLflow. 

Кроме деплоя, Seldon Core позволяет:

  • решать задачи мониторинга и логирования;
  • относительно просто организовывать A/B-тесты. 

В решении также предусмотрена интеграция с инструментами для обнаружения дрейфа данных и выявления выбросов в них (Outlier, Adversarial и Drift Detection). 

Кратко End-to-end-схема работы с Seldon Core описана ниже.



Подробно ознакомиться с ней и алгоритмом работы инструмента можно по ссылке.

В целом, если перед вами стоит задача организовать деплой ML-модели в K8s, однозначно стоит протестировать Seldon Core.

Metaflow 


Metaflow разработан Netflix для решения задач Data Scientists и ML-инженеров. Инструмент — универсальный комбайн, который отчасти похож на Pachyderm. Из коробки в Metaflow есть:

  • интеграция с Kubernetes;
  • версионирование данных;
  • оркестрация пайплайнов и выделение ресурсов для пайплайнов.

Metaflow в данном случае выступает в качестве прослойки между Data Scientist и Kubernetes, инфраструктурой.



Подробнее об этом можно почитать здесь и здесь

Для Data-Science-специалиста Metaflow может выступать Python-библиотекой для описания необходимых шагов при работе с ML-моделью в виде DAG. Опыт работы с Airflow, предположительно, может помочь погрузиться в Metaflow. Вопрос в том, насколько вы готовы переписать существующие пайплайны в парадигме Metaflow. При этом 6400 звезд на Github — веский аргумент в пользу знакомства с инструментом.

Издержки работы с Open Source, и как получить максимум


Несмотря на явные преимущества Open-Source-инструментов для MLOps, работа с ними так или иначе сопряжена с издержками. Например, разработчики сами должны:

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

Это повышает нагрузку на ИТ-специалистов, увеличивает Time-to-Market и повышает затраты на разработку. 

Чтобы нивелировать эти издержки и предоставить разработчикам удобную преднастроенную среду, мы разработали Cloud ML Platform. Это облачный сервис для ML-разработки полного цикла для работы Data Scientists и ML-инженеров на готовой, масштабируемой облачной инфраструктуре. В ML Platform из коробки доступны два инструмента: JupyterHub и MLflow. Это популярные MLOps-решения, которые:

  • многим знакомы;
  • не требуют много времени для изучения;
  • позволяют решать основные MLOps-задачи.

Для большего удобства мы интегрировали и предварительно настроили JupyterHub и MLflow — пользователям не надо тратить время на администрирование и разбираться в его тонкостях.

В Cloud ML Platform мы сделали ставку на Open-Source-инструменты по нескольким причинам:

  1. Низкий порог входа — основные инструменты многим знакомы и уже предварительно настроены. Начинать работать можно сразу после запуска.
  2. Можно безопасно выстраивать процессы — нет рисков Vendor Lock-in в случае ухода вендора с рынка.
  3. Гибкая кастомизация инструментов платформы.

Также в облаке VK Cloud доступны дополнительные инструменты для Data Engineering: Hadoop, Greenplum, Airflow.

Вы можете протестировать Cloud ML Platform от VK Cloud — для теста мы начисляем новым пользователям 3000 бонусных рублей. Будем рады вашей обратной связи.

Комментарии (3)


  1. fuwiak
    00.00.0000 00:00

    Я не совсем понимаю, почему все сравнивают MLFlow с Kubeflow. Действительно, у них есть общая функциональность, но сама идея Kubeflow гораздо шире, чем просто мониторинг и версионирование модели. Но я полностью согласен с автором, Kubeflow проблематичен в установке и поддержке, после многих проблем с ним у моих клиентов, я предлагаю другие решения((что угодно, только не Kubeflow :):):)), которые не создают таких частых проблем.


    1. volinski Автор
      00.00.0000 00:00

      MLflow и Kubeflow позиционируют себя как платформы полного цикла при решения MLOps задач. Поэтому и сравнивают)
      При этом инструменты сильно отличаются по функционалу между собой.

      Делают акцент на разные фичи. MLflow больше про воспроизводимость и трекинг экспериментов, единый реестр моделей, а Kubeflow больше про пайплайны внутри кубера плюс управление ресурсами внутри кубера под задачи DS.


  1. Abrikos
    00.00.0000 00:00
    +2

    Я бы добавил в список ClearML. Умеет трекать модели, версионировать данные (в т.ч. поддержка S3/minio), запуск пайплайнов по триггерам и/или шедулеру, сервинг моделей, составление репортов, HPO на агентах и прочие мелкие радости.