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

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

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

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

Компоненты

Давайте разберем это изображение, на котором изображен весь рабочий процесс API, и разберемся с каждым компонентом.

  • Клиент: клиентом в архитектуре может быть любое устройство или стороннее приложение, которое пытается запросить сервер, на котором размещена архитектура, для прогнозов модели. Пример: Facebook пытается отметить ваше лицо на недавно загруженном изображении.
  • Балансировщик нагрузки: балансировщик нагрузки пытается распределить рабочую нагрузку (запросы) между несколькими серверами или экземплярами в кластере. Цель балансировщика нагрузки - минимизировать время отклика и максимизировать пропускную способность, избегая перегрузки любого отдельного ресурса. На изображении выше балансировщик нагрузки является общедоступным объектом и распределяет все запросы от клиентов на несколько серверов Ubuntu в кластере.
  • Nginx: Nginx - это веб-сервер с открытым исходным кодом, но его также можно использовать в качестве балансировщика нагрузки. Nginx известен своей высокой производительностью и небольшим объемом памяти. Он может успешно работать при большой нагрузке, порождая рабочие процессы, каждый из которых может обрабатывать тысячи подключений. На изображении nginx является локальным для одного сервера или экземпляра для обработки всех запросов от общедоступного балансировщика нагрузки. Альтернативой nginx является HTTP-сервер Apache.
  • Gunicorn: это HTTP-сервер Python Интерфейс шлюза веб-сервера (WSGI). Портирован из проекта Ruby’s Unicorn. Это модель воркеров до форка, что означает, что мастер создает несколько форков, которые называются воркерами для обработки запросов. Поскольку Python не является многопоточным, мы пытаемся создать несколько воркеров-пулеметчиков, которые представляют собой отдельные процессы, которые имеют свои собственные распределения памяти, чтобы компенсировать параллелизм при обработке запросов. Gunicorn работает с различными веб-фреймворками Python, и хорошо известной альтернативой является uWSGI.
  • Flask: это микро-веб-фреймворк, написанный на Python. Это помогает нам разработать интерфейс прикладного программирования (API) или веб-приложение, которое отвечает на запрос. Другими альтернативами Flask являются Django, Pyramid и web2py. Расширение Flask для добавления поддержки быстрого создания REST API предоставляется Flask-RESTful.
  • Keras: это библиотека нейронной сети с открытым исходным кодом, написанная на Python. Он может работать поверх TensorFlow, CNTK, Theano или MXNet. Есть множество альтернатив Keras: TensorFlow, Caffe2 (Caffe), CNTK, PyTorch, MXNet, Chainer и Theano (прекращено).
  • Облачная платформа: Если есть одна платформа, которая объединяет все вышеперечисленные компоненты, то это облако. Это один из основных катализаторов распространения исследований в области искусственного интеллекта, будь то компьютерное зрение, обработка естественного языка, машинное обучение, машинный перевод, робототехника или медицинская визуализация. Облако сделало вычислительные ресурсы доступными для более широкой аудитории по разумной цене. Немногие из известных облачных веб-сервисов - это Amazon Web Services (AWS), Google Cloud и Microsoft Azure.

Настройка архитектуры

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

Примечание. Эта архитектура будет основана на Python.

Настройка разработки

  • Обучение модели: Первый шаг - обучить модель на основе варианта использования с помощью Keras, TensorFlow или PyTorch. Убедитесь, что вы делаете это в виртуальной среде, поскольку это помогает изолировать несколько сред Python, а также упаковывает все необходимые зависимости в отдельную папку.
  • Создайте API: Когда модель готова к использованию в API, вы можете использовать Flask или Django, чтобы построить их в соответствии с требованиями. В идеале вы должны создать Restful APIs, поскольку это помогает разделить клиент и сервер; улучшает видимость, надежность и масштабируемость; он не зависит от платформы. Выполните тщательный тест, чтобы убедиться, что модель отвечает правильными прогнозами от API.
  • Веб-сервер: Настало время протестировать веб-сервер на предмет наличия созданного вами API. Gunicorn - хороший выбор, если вы создали API с помощью Flask. Пример команды для запуска веб-сервера Gunicorn.
gunicorn --workers 1 --timeout 300 --bind 0.0.0.0:8000 api:app
- workers (INT): The number of worker processes for handling requests.
- timeout (INT): Workers silent for more than this many seconds are killed and restarted.
- bind (ADDRESS): The socket to bind. [['127.0.0.1:8000']]
- api: The main Python file containing the Flask application.
- app: An instance of the Flask class in the main Python file 'api.py'.
  • Балансировщик нагрузки: вы можете настроить nginx для обработки всех тестовых запросов для всех воркеров, где каждый воркер имеет свой собственный API с моделью DL. Обратитесь к этому ресурсу, чтобы понять настройку между nginx и gunicorn.
  • Тестирование нагрузки / производительности. Попробуйте Apache Jmeter, приложение с открытым исходным кодом, предназначенное для нагрузочного тестирования и измерения производительности. Это также поможет понять распределение нагрузки nginx. Альтернатива - Locust.

Настройка производства

  • Облачная платформа: после того, как вы выбрали облачную службу, настройте машину или экземпляр из стандартного образа Ubuntu (желательно последней версии LTS). Выбор машины с ЦП действительно зависит от модели DL и варианта использования. После запуска машины настройте nginx, виртуальную среду Python, установите все зависимости и скопируйте API. Наконец, попробуйте запустить API с моделью (загрузка всех моделей может занять некоторое время в зависимости от количества рабочих, определенных для gunicorn).
  • Пользовательский образ API. Убедитесь, что API работает без сбоев, а затем сделайте снимок экземпляра, чтобы создать пользовательский образ, содержащий API и модели. Снимок сохранит все настройки приложения. Справка: AWS, Google, Azure.
  • Балансировщик нагрузки. Создайте балансировщик нагрузки из облачной службы, он может быть общедоступным или частным в зависимости от требований. Справка: AWS, Google, Azure.
  • Кластер экземпляров: используйте ранее созданный пользовательский образ API для запуска кластера экземпляров. Справка: AWS, Google, Azure.
  • Балансировщик нагрузки для кластера. Теперь свяжите кластер экземпляров с балансировщиком нагрузки, это обеспечит равномерное распределение работы подсистемы балансировки нагрузки между всеми экземплярами. Справка: AWS, Google, Azure.
  • Тест нагрузки / производительности. Подобно тестированию нагрузки / производительности при разработке, аналогичная процедура может быть воспроизведена в производственной среде, но теперь с миллионами запросов. Попробуйте сломать архитектуру, чтобы проверить ее стабильность и надежность (не всегда рекомендуется).
  • Подведение итогов. Наконец, если все работает должным образом, у вас будет первая архитектура DL на рабочем уровне, способная обслуживать миллионы запросов.

Дополнительная настройка (надстройки)

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

  • Автоматическое масштабирование. Это функция облачной службы, которая помогает масштабировать экземпляры приложения в зависимости от количества полученных запросов. Мы можем масштабироваться при резком увеличении количества запросов и увеличивать масштаб при их уменьшении. Справка: AWS, Google, Azure.
  • Обновления приложений. Наступает время, когда вам нужно обновить приложение до последней модели DL или обновить функции приложения, но как обновить все экземпляры, не влияя на поведение приложения в производственной среде . Облачные сервисы позволяют выполнять эту задачу различными способами, и они могут быть очень специфичными для конкретного поставщика облачных услуг. Справка: AWS, Google, Azure.
  • Непрерывная интеграция: это относится к этапам сборки и модульного тестирования процесса выпуска программного обеспечения. Каждая зафиксированная ревизия запускает автоматическую сборку и тестирование. Это можно использовать для развертывания последних версий моделей в производстве.

Альтернативные платформы

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

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

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

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

Дополнительные ресурсы

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

Если вам понравилась эта статья, я буду очень признателен, если вы нажмете кнопку Нравится, чтобы порекомендовать ее другим. Вы также можете подписаться на меня в Twitter и Medium. Мир! 😎

Первоначально опубликовано на maheshkumar.xyz 25 июня 2018 г.

📝 Прочтите этот рассказ позже в Журнале.

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