Сравнение инструментов обслуживания моделей машинного обучения — KServe, Seldon Core, BentoML

вступление

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

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

Настройка сравнения

Мы сосредоточили наше исследование на 9 основных областях инструментов обслуживания моделей:

• возможность обслуживать модели из стандартных фреймворков, включая Scikit-Learn, PyTorch, Tensorflow и XGBoost
• возможность обслуживания пользовательских моделей/моделей из нишевых фреймворков
• возможность предварительной обработки/постобработки данных
• влияние на рабочий процесс разработки и существующую кодовую базу
• наличие документации
• Удобство DevOps
• возможности автомасштабирования
• доступные интерфейсы для получения прогнозов
• управление инфраструктурой

В этом посте для сравнения мы выбрали следующие инструменты: KServe, Seldon Core и BentoML. В следующем посте будут рассмотрены облачные управляемые инструменты обслуживания.

Чтобы сравнить инструменты, мы создали проект машинного обучения, который включал стандартный конвейер, включающий: загрузку данных, предварительную обработку данных, разделение набора данных, а также обучение и тестирование регрессионной модели. Конвейер требовал, чтобы вывод модели включал этап предварительной обработки (вызов пользовательской функции Python), чтобы можно было протестировать различные аспекты инструментов обслуживания. Сам конвейер позволял легко менять модель, поэтому можно было использовать различные среды моделирования.

Общий обзор инструментов обслуживания моделей машинного обучения

KServe

KServe (ранее, до того, как версия 0.7 называлась KFServing) — это инструмент с открытым исходным кодом на основе Kubernetes, обеспечивающий пользовательскую абстракцию (определение пользовательского ресурса Kubernetes) для определения возможностей обслуживания модели машинного обучения. Основное внимание уделяется тому, чтобы скрыть основную сложность таких развертываний, чтобы пользователям нужно было сосредоточиться только на частях, связанных с ML. Он поддерживает множество расширенных функций, таких как автоматическое масштабирование, масштабирование до нуля, канареечное развертывание, автоматическую пакетную обработку запросов, а также множество популярных готовых платформ машинного обучения. Его используют такие компании, как Bloomberg, NVIDIA, Samsung SDS, Cisco.

Селдон Кор

Seldon Core — это инструмент с открытым исходным кодом, разработанный Seldon Technologies Ltd в качестве составного элемента более крупного (платного) решения Seldon Deploy. Он похож на KServe с точки зрения подхода — он обеспечивает высокий уровень Kubernetes CRD и поддерживает канареечное развертывание, A/B-тестирование, а также развертывание Multi-Armed-Bandit.

БентоМЛ

BentoML — это платформа Python для переноса моделей машинного обучения в развертываемые сервисы. Он предоставляет простой объектно-ориентированный интерфейс для упаковки моделей машинного обучения и создания для них HTTP-сервисов. BentoML предлагает глубокую интеграцию с популярными платформами машинного обучения, поэтому вся сложность, связанная с упаковкой моделей и их зависимостей, скрыта. Модели, упакованные в BentoML, могут быть развернуты во многих средах выполнения, включая простые кластеры Kubernetes, Seldon Core, KServe, Knative, а также бессерверные решения с облачным управлением, такие как AWS Lambda, Azure Functions или Google Cloud Run. Подробное сравнение

Сравнение включает описание каждой области в каждом инструменте, а также визуализацию того, насколько хорошо инструмент решает эту проблему. Шкала является субъективной, основанной на усилиях, необходимых для достижения поставленной цели, чем правее (зеленая область), тем лучше инструмент подходит к данному аспекту.

Обслуживание стандартных моделей

Эта область сравнения была сосредоточена на возможностях инструментов для обслуживания моделей, обученных в одной из популярных сред, в том числе: Scikit-Learn, PyTorch, TensorFlow и XGBoost.

KServe

Все протестированные фреймворки довольно просты в обслуживании. Стандартные фреймворки являются неотъемлемой частью KServe, поскольку они предоставляют предварительно созданные образы докеров для их запуска, а также прямое определение в InferenceService (пользовательский ресурс для Kubernetes, определенный KServe).

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

Селдон Кор

Seldon Core может легко обслуживать модели Scikit-Learn, XGBoost и TensorFlow. Нет встроенной поддержки PyTorch, которую можно было бы реализовать с помощью Triton Server, но это требует больших дополнительных усилий и требует использования протокола Seldon v2. Использование протокола v2 также применяется при использовании MLServer (новый рекомендуемый способ развертывания моделей с использованием Seldon Core), что приводит к некоторым проблемам на последующих этапах — см. раздел о предварительной/постобработке ниже.

БентоМЛ

Использование BentoML сводится к реализации собственного класса Python, который наследуется от класса фреймворка, что в результате означает, что можно использовать любой фреймворк Python. Существует встроенная поддержка всех стандартных платформ, которые обрабатывают сериализацию модели, десериализацию, зависимости, а также обработку ввода/вывода. Реализовать интерфейс класса BentoService BentoML очень просто, и обычно он умещается в несколько строк кода.

Обслуживание нестандартных моделей

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

KServe

KServe позволяет использовать любой образ докера как часть развертывания, поэтому можно использовать практически любой фреймворк/код/язык (в некоторой степени). Инструмент предоставляет Python SDK с абстрактным классом (KFModel), который можно наследовать, чтобы упростить интеграцию пользовательского кода.

Селдон Кор

Как и в случае с KServe, можно использовать любой образ докера. Разница между Seldon Core и KServe в этой области заключается в том, что в то время как KServe предоставляет SDK с классами, которые должны быть реализованы, Seldon предоставляет SDK с классами, которые могут быть реализованы (SeldonComponent), но вы также можете подписаться на утиную печать Python.

БентоМЛ

Поскольку использование BentoML требует реализации кода Python, с его помощью можно выполнить любую настройку.

Возможность предварительной обработки/постобработки данных

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

KServe

Абстракция InferenceService в KServe позволяет указать преобразователь, который может выполнять как предварительную, так и последующую обработку данных. Реализация требует подготовки пользовательского образа докера с классом, унаследованным от KServe SDK, аналогично реализации пользовательских моделей.

Селдон Кор

Помимо стандартной предварительной и последующей обработки, которую можно определить как TRANSFORMER и реализовать как класс Python (с наследованием или утиным вводом, см. Обслуживание пользовательских моделей), Seldon Core предлагает абстракцию графов вывода. Это может включать не только преобразование данных, но и настраиваемый ROUTER (например, динамическое решение, в какую из многих моделей, являющихся частью одного и того же SeldonDeployment, отправлять данные), а также COMBINER, который позволяет напрямую создавать ансамбль моделей. изнутри развертывания. Благодаря этой функциональности развертывание Multi-Armed-Bandit легко достижимо. Нужно иметь в виду, что при использовании MLServer или Triton Server преобразования будут невозможны — см. соответствующий выпуск GitHub https://github.com/SeldonIO/MLServer/issues/287.

БентоМЛ

Как и в предыдущих областях, любой код может быть запущен как часть развертывания BentoML.

Влияние на рабочий процесс разработки и существующую кодовую базу

Здесь мы сосредоточимся на том, требует ли использование инструментов изменений в рабочем процессе разработки (например, адаптация к новому набору API, внесение некоторых изменений в существующую настройку CI/CD, изменение кода обучения и использование нового хранилища артефактов для моделей и т. д.).

KServe

KServe хорошо интегрируется с обоими существующими конвейерами DevOps для развертывания (будь то непосредственно из манифестов Kubernetes, диаграмм Helm или других), поскольку для развертывания требуется простое определение ресурсов. С точки зрения специалистов по данным/инженеров по машинному обучению, корректировки минимальны — модели можно обслуживать из любого облачного хранилища, такого как S3 или GCS. Существующие конвейеры CI/CD, которые создают образы Docker, можно оставить нетронутыми. Изменения самих образов Docker необязательны и требуются только в том случае, если необходимо запустить пользовательский код.

Селдон Кор

Как и KServe, Seldon Core не влияет на существующие рабочие процессы DevOps/Software Engineering. Развертывания выполняются из манифестов Kubernetes. Пока используется одна из поддерживаемых платформ, требуются минимальные усилия со стороны специалистов по обработке и анализу данных / инженеров по машинному обучению, однако любая настройка или использование нестандартных платформ может усложнить рабочий процесс, а некоторые функции могут стать недоступными (из-за того, что они не реализовано еще, см. «Возможность предварительной/постобработки данных»).

БентоМЛ

Хотя реализация классов Python не является сложной задачей, процесс доставки сервисов на основе BentoML в среду выполнения (например, кластер Kubernetes) потребует изменений в конвейере CI/CD. BentoML сохраняет унаследованный от BentoService класс с сериализованной моделью, кодом Python и всеми зависимостями в отдельный архив/каталог. Архив содержит файл Dockerfile, который позволяет создать автономный образ контейнера для обслуживания. Поскольку архив BentoML создается как артефакт, конвейер CI/CD должен использовать его и запускать другую сборку. С точки зрения развертывания все должно обрабатываться вручную, что в случае Kubernetes означает написание определений развертывания.

Наличие документации

Быстрая адаптация сервисных инструментов возможна только при наличии хорошей документации. Также рассматривалась поддержка сообщества через GitHub/Slack.

KServe

Документация охватывает важные аспекты. Нетривиальные варианты использования требуют исследования проблем GitHub или опроса других на канале Slack, где сообщество довольно активно.

Селдон Кор

Документация охватывает в основном тривиальные варианты использования, множество ссылок ведут на 404 страницы. Расширенные сценарии можно найти на GitHub, но некоторые из них устарели.

БентоМЛ

Довольно надежная документация с множеством актуальных примеров. И код, и концепции хорошо описаны.

Удобство DevOps

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

KServe

Стек KServe основан на хорошо зарекомендовавших себя инструментах с открытым исходным кодом: KNative и Istio, которые в первую очередь относятся к Dev-Ops и Kubernetes-native. Мониторинг основан на широко распространенном Prometheus. Развертывание можно выполнять с помощью любого совместимого с Kubernetes решения, будь то непосредственно из kubectl, Helm или Helmsman. Ведение журнала легко настраивается, а сообщения обычно носят описательный характер. Канарские развертывания доступны из коробки.

Селдон Кор

Для работы Seldon требуется только доступность Istio или Ambassador. Мониторинг также осуществляется через Prometheus. Как и в случае с KServe, можно использовать любое решение для развертывания Kubernetes. Логирование можно легко настроить, но для некоторых частей логов вообще нет. Канарские развертывания, а также развертывания для A/B-тестирования доступны в готовом виде.

БентоМЛ

Поскольку BentoML ориентирован на код, поддержка DevOps может быть настроена благодаря множеству интеграций с инструментами трассировки (например, Jaeger) и мониторинга (Prometheus). Однако конфигурация, а также развертывание в Kubernetes требуют ручной реализации. Однако BentoML можно использовать со многими существующими решениями для обслуживания или даже без обслуживания, поскольку в конечном итоге конечным результатом является простой образ Docker.

Возможности автомасштабирования

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

KServe

Благодаря тесной интеграции с KNative, KServe предлагает лучшие в своем классе функции автоматического масштабирования. Развернутые модели можно масштабировать не только за счет использования показателя использования ЦП Kubernetes, но и за счет показателей высокого уровня, таких как количество запросов в секунду или параллелизм (сколько запросов может одновременно обрабатываться одним контейнером с моделью). KServe также предлагает масштабирование до нуля с быстрой активацией, что упрощает поддержание низких общих затрат на кластер. Также имеется встроенная поддержка автоматической пакетной обработки запросов, которая помогает лучше использовать ресурсы модулей.

Селдон Кор

Поскольку Seldon Core является родным для Kubernetes, можно использовать стандартный автомасштабатор Horizontal Pod с такими показателями, как использование ЦП и памяти. Требуется дополнительная установка KEDA и интеграция с ней, если желательно использовать метрики на основе событий. Благодаря интеграции с KEDA становится возможным масштабирование до нуля с помощью собственных источников событий KEDA. Для нулевого масштабирования HTTP требуются еще другие надстройки для KEDA.

БентоМЛ

Поскольку BentoML — это фреймворк, основанный на коде, он не предлагает никаких функций автоматического масштабирования, поскольку они полностью зависят от выбранной среды выполнения (BentoML также можно развернуть в KServe, Seldon Core, SageMaker Endpoints и многих других облачных решениях). Однако платформа поддерживает автоматическую группировку запросов, что позволяет настраивать производительность обслуживания (в некоторой степени) после развертывания.

Доступные интерфейсы для получения прогнозов

Обычно модели обслуживаются как службы на основе HTTP(s) с вводом/выводом JSON. Для различных вариантов использования могут потребоваться разные форматы запросов/ответов или использование более быстрых бинарных протоколов, таких как GRPC, поэтому инструменты обслуживания также должны их поддерживать.

KServe

Хотя KServe не накладывает ограничений на используемые протоколы, метод обслуживания по умолчанию основан на HTTP. Для ввода/вывода, отличного от json, требуется специальный преобразователь. Конфигурация позволяет использовать GRPC или любой другой протокол, но для работы с такими протоколами требуется ручная настраиваемая реализация.

Селдон Кор

Как и KServe, Seldon Core не ограничивает использование протоколов. Кроме того, он предоставляет реализации по умолчанию для методов обслуживания HTTP и GRPC, так что каждая развернутая модель может автоматически отвечать как на запросы HTTP, так и на запросы GRPC. Форматы запросов и ответов можно обрабатывать с помощью пользовательской реализации в TRANSFORMER.

БентоМЛ

Поддерживается только HTTP (похоже, GRPC находится в устаревшем состоянии https://github.com/bentoml/BentoML/issues/703). Опять же, поскольку BentoML ориентирован на код, возможна обработка любого запроса. Платформа предлагает несколько предварительно реализованных методов обработки, так что запросы можно анализировать из CSV, JSON и других.

Управление инфраструктурой

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

KServe / Seldon Core

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

БентоМЛ

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

Матрица функций инструментов обслуживания моделей машинного обучения

Краткое содержание

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

Вам понравился наш пост? Если вы хотите узнать больше, скачайте нашу бесплатную электронную книгу «MLOps: Power Up Machine Learning Process. Введение в Vertex AI, Snowflake и dbt Cloud».

Автор блога: Marcin Zabłocki —архитектор MLOps

Первоначально опубликовано на https://getindata.com.