Часть 2 - Развертывание и обслуживание модели

Компании практически во всех отраслях используют технологию машинного обучения (ML). Компании обращаются к платформам инфраструктуры машинного обучения, чтобы помочь им наилучшим образом использовать искусственный интеллект (ИИ).

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

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

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

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

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

Развертывание и обслуживание модели

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

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

Варианты обслуживания моделей для моделей обычно можно разделить на несколько типов:

  • Внутренний исполняемый файл (файл PKL / Java) - контейнерный и неконтейнерный
  • Поставщик облачного машинного обучения - Amazon SageMaker, Azure ML, Google AI
  • Пакетный или потоковый: размещенный и локальный - алгоритм, Spark / Databricks, Paperspace
  • Открытый исходный код - TensorFlow Serving, Kubeflow, Seldon, Anyscale и т. Д.

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

Ключевые вопросы для рассмотрения

  1. Каковы требования к безопасности данных в организации?

Локальные решения машинного обучения могут потребоваться организациям со строгими требованиями к безопасности данных. Хорошим выбором являются Algorithmia, Seldon, Tensorflow, Kubeflow, или собственные проприетарные решения. Некоторые поставщики, такие как Algorithmia, имеют специальные наборы функций безопасности, подробно описанные ниже. Облачные решения могут быть лучшим выбором для тех организаций, которым требуется меньше безопасности, но больше удаленного доступа / виртуализации.

2. Нужны ли команде управляемые или неуправляемые решения для обслуживания моделей?

Управляемые решения, такие как Algorithmia, SageMaker, Google ML, Azure, и Paperspace, являются хорошей идеей для компаний с низким уровнем ИТ-присутствия. Неуправляемое решение, такое как Kubeflow, Seldon, Tensorflow Serving или Anyscale, может быть лучше для технических организаций.

3. Собирается ли каждая команда в организации использовать один и тот же вариант развертывания?

Даже если одна команда выбирает вариант обслуживания, редко вся организация использует один и тот же подход к обслуживанию. Наличие общей платформы управления моделями, такой как ML-Flow, по-прежнему может помочь преодолеть этот пробел.

4. Как выглядит окончательная модель? Есть ли уже установленный интерфейс?

Если модель уже развернута, может не иметь смысла отказываться от системы обслуживания моделей и заменять ее сервером новой модели. Насколько легко будет заменить уже развернутую модель, может зависеть от выбранного сервера модели и его интеграции с другими системами, API и конвейерами функций.

5. Где находится исполняемый файл модели? (например, ML Flow или S3 Bucket)

Важным моментом является простая интеграция с ML-Flow или системами хранения моделей.

6. Нужен ли вывод графического процессора?

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

7. Существуют ли отдельные конвейеры создания функций или они интегрированы в сервер модели?

В зависимости от того, где развернуты ваши конвейеры функций, например Amazon Web Services (AWS), это может направить вас на использование SageMaker. Вероятно, это одна из наиболее распространенных причин использования SageMaker, поскольку данные уже развернуты в AWS.

Подробная информация о развертывании

Формат модели может варьироваться в зависимости от структур, используемых для построения модели, в разных организациях и проектах. Некоторые примеры форматов включают в себя изображение весов / параметров для классификатора, объект Tensorflow SavedModel, модель Pytorch, модель Keras, модель XGBoost, Apache TVM, MXNet, ONNX Runtime и т. Д.

Реализация

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

Контейнеризация

Современный серверный подход состоит в том, чтобы поместить исполняемый файл модели в контейнер, чтобы у моделей был общий интерфейс и общий способ их поддержки. Модель извлекается из системы управления моделями (например, ML-Flow) в контейнер при развертывании. Для этого есть много способов: либо создать собственный контейнер для вашей компании, используя решения с открытым исходным кодом, такие как KubeFlow или Seldon AI, либо использовать общие инструменты облачного провайдера, такие как Алгоритм, SageMaker, Azure или Google AI.

Модель в реальном времени или пакетная модель

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

Ряд обслуживающих платформ позволяет создать единую модель и иметь разные варианты развертывания (пакетное или в реальном времени) для поддержки обоих типов режимов обслуживания.

На что обращать внимание на модельных серверах

Простое масштабирование :

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

Canary A / B Framework :

Фреймворк Canary A / B позволяет разработчикам развертывать программное обеспечение для небольшой группы пользователей для выполнения A / B-тестирования, чтобы выяснить, какие аспекты программного обеспечения наиболее полезны и обеспечивают наилучшую функциональность для пользователей. После развертывания некоторые команды запускают модель A / B (канареечную) параллельно с производственной моделью, первоначально прогнозируя только небольшую часть трафика для новой модели. Это делается в качестве простого теста перед развертыванием новой модели для всего объема прогнозов. Многие команды, с которыми мы общаемся, сами создали свои собственные фреймворки для A / B-тестирования. Тем не менее, некоторые из типовых серверных решений также поддерживают простые развертывания A / B из коробки, например, чтобы выбрать% трафика для модели B одним нажатием кнопки.

Поддержка ансамбля:

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

Обратная поддержка :

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

Безопасность:

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

Поддержка конвейера функций:

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

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

Мониторинг:

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

Примеры платформ инфраструктуры машинного обучения для развертывания и обслуживания включают Datarobot, H2O.ai, Sagemaker, Azure, Google Kubeflow, и Tecton AI.

Наблюдаемость модели против мониторинга модели

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

Тем не менее, если бы это было так, Amazon Cloud Watch убил бы Datadog.

Проблема здесь в том, что вы делаете, когда получаете это предупреждение?

По нашему мнению, разница между решением для мониторинга и платформой Observability заключается в возможности беспрепятственно устранять неполадки и устранять неполадки. В экосистеме машинного обучения эти проблемы проявляются как проблемы, связывающие исследования ИИ с разработкой. Разработана ли платформа снизу вверх для устранения проблем, или система предупреждений была добавлена ​​к некоторым уже существующим графикам? Устранение неполадок моделей + данных в реальном мире - это большое и сложное пространство. Вот почему платформы Observability разрабатываются с нуля, чтобы помочь исследовательским и инженерным группам совместно решать эти проблемы.

Почему сервер модели - не лучшее место для наблюдения:

Сервер моделей не имеет нужных точек данных для связывания сложных слоев, необходимых для анализа моделей. На сервере модели отсутствуют важные данные, такие как обучающие данные, тестовые прогоны, предварительно закодированные данные функций, события истинности / метки и многое другое. В случае данных функций для ряда более крупных моделей, над которыми мы работали, точка вставки в конвейер данных для устранения неполадок - это технология, сильно отличающаяся от технологии сервера моделей. Наконец, многие организации используют столько же подходов к обслуживанию моделей, сколько моделей в производстве, и очень маловероятно, что они перейдут на один сервер, чтобы управлять ими всеми. Что происходит, когда у вас есть несколько обслуживаемых моделей, которые снабжают друг друга данными, но вам нужна целостная картина?

То же самое и с программной инфраструктурой; ваши решения для наблюдения за инфраструктурой не привязаны к самой инфраструктуре.

Следующий

Надеемся, вам понравилась серия статей "Инфраструктура машинного обучения"! Далее мы углубимся в производственный ИИ. Есть так много недостаточно обсуждаемых и чрезвычайно важных тем по внедрению ИИ, в которые мы будем углубляться!

Связаться с нами

Если этот блог привлек ваше внимание и вы хотите узнать больше о Наблюдаемости машинного обучения и Мониторинге моделей, ознакомьтесь с другими нашими блогами и ресурсами по Мониторингу машинного обучения! Не стесняйтесь обращаться к нам с любыми вопросами или комментариями, и найдите наши открытые вакансии здесь, если вы хотите присоединиться к веселой инженерной команде Rockstar, чтобы помочь сделать модели успешными в производстве!