Контекст:

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

(Все диаграммы в документе взяты из предварительного издания Deep Learning System Design Book)

Что такое модель?

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

Артефакт модели. К артефактам относится код, который обучает модели и делает выводы, а также любые сгенерированные данные
, такие как обученные модели, выводы и метрики.

  • График модели
  • Вес модели
  • Словарный запас
  • Вложения

Метаданные модели. Метаданные — это любые данные, которые описывают артефакт или отношения между артефактами.

  • Владелец
  • Отметка времени
  • Идентификатор модели
  • Версия
  • Версия обучающих данных
  • URL-адрес хранилища артефактов модели

Служба прогнозирования модели

Рабочий процесс прогнозирования модели

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

  1. Монолитный дизайн: загрузка модели и запуск предсказания модели внутри процесса пользовательского приложения. Например, мобильное приложение для проверки идентичности цветов может загружать модель классификации изображений непосредственно в свой локальный процесс и предсказывать идентичность растений по предоставленным фотографиям. Вся загрузка и обслуживание модели происходит в приложении модели локально (на телефоне), без обращения к другим процессам или удаленным серверам.
  2. Служба моделей:
  3. Служба модели означает работающую модель, обслуживающую серверную часть. Для каждой отдельной модели, каждой версии модели или каждого типа модели мы создаем для нее специальный веб-сервис. Этот веб-сервис предоставляет API прогнозирования модели через интерфейсы HTTP или gRPC.
  4. Служба модели управляет полным жизненным циклом обслуживания модели, включая извлечение файла модели из хранилища артефактов модели, загрузку модели, выполнение алгоритма прогнозирования модели по запросу клиента и выгрузку модели для восстановления ресурсов сервера.
  5. Сервер моделей
  6. Подход с использованием сервера моделей предназначен для обработки нескольких типов моделей по принципу «черного ящика». Независимо от алгоритма модели и версии модели сервер моделей может обслуживать эти модели с помощью унифицированного API веб-прогнозирования.
  7. Многие библиотеки и сервисы для обслуживания моделей с открытым исходным кодом, такие как Tensorflow serve, TorchServe и Nvidia Triton, предлагают серверные решения для моделей. Что нам нужно сделать, так это создать настраиваемую логику поверх этих инструментов для решения наших собственных бизнес-потребностей, включая управление маршрутизацией запросов модели, API доступа к модели, файлы модели модели, метаданные модели и обработку входных/выходных данных.

Единая модель обслуживания

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

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

Плюсы

  • быстро загружается и легко разрабатывается
  • минималистичный дизайн

Минусы

  • может обслуживать только один тип модели
  • может обслуживать только одну версию модели

Многопользовательское приложение

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

Компоненты

Модель, обслуживающая глубокое погружение

A. Модель высокого уровня, обслуживающая сквозной рабочий процесс

Этот пример службы состоит из внешнего компонента интерфейса и внутреннего предсказателя. Внешний интерфейс выполняет три вещи:

  1. Хостинг API общедоступных прогнозов
  2. Загрузка файлов модели из хранилища метаданных на общий том диска
  3. Пересылка запроса на предсказание внутреннему предсказателю.

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

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

Б. Внешняя служба

Процесс

  1. Пользователь отправляет запрос прогноза с идентификатором модели «A» в веб-интерфейс;
  2. Веб-интерфейс вызывает диспетчер соединений предиктора для обслуживания этого запроса;
  3. Диспетчер соединений Predictor запрашивает хранилище метаданных для получения метаданных модели путем поиска идентификатора модели, равного «A», возвращенные метаданные модели содержат тип алгоритма модели и URL-адрес файла модели;
  4. В зависимости от типа алгоритма модели менеджер предикторов выбирает правильный внутренний клиент предиктора для обработки запроса. В этом случае он выбирает CustomGrpcPredictorBackend, так как мы демонстрируем самодельную модель, обслуживающую контейнер для классификации намерений;
  5. Клиент CustomGrpcPredictorBackend сначала проверяет наличие файла модели на общем диске с файлами модели для модели «А». Если модель не была загружена ранее, она использует URL-адрес модели (из метаданных модели) для загрузки файлов модели из облачного хранилища на общий файловый диск;
  6. Затем клиент CustomGrpcPredictorBackend вызывает предиктор модели, предварительно зарегистрированный для этого внутреннего клиента в файле конфигурации службы. В этом примере CustomGrpcPredictorBackend вызовет предиктор самосборки

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

С. Серверная служба прогнозирования

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

Факел служить

TorchServe — это производительный, гибкий и простой в использовании инструмент для обслуживания моделей в активном режиме PyTorch и сценариев torch. Подобно обслуживанию Tensorflow, TorchServe использует подход модельного сервера для обслуживания всех типов моделей PyTorch с помощью унифицированного API. Разница в том, что TorchServe предоставляет набор API-интерфейсов управления, который делает управление моделями очень удобным и гибким. Например, мы можем программно регистрировать и отменять регистрацию моделей или разных версий модели. И мы также можем увеличивать и уменьшать масштаб обслуживания рабочих процессов для моделей и версий модели.

Поддержка AWS: https://aws.amazon.com/blogs/machine-learning/deploying-pytorch-models-for-inference-at-scale-using-torchserve/

На изображении выше мы видим, что добавлены два серых прямоугольника: это серверный клиент TorchServe GRPC PredictorBackend (TorchGrpcPredictorBackend) и сервер TrochServe. Ответ TorchGrpcPredictorBackend на загрузку файлов модели и отправку запросов прогнозирования в контейнер TorchServe.

TorchServe — это инструмент, созданный командой PyTorch для обслуживания моделей PyTorch (нетерпеливый режим или сценарий факела). TorchServe работает как черный ящик и предоставляет интерфейсы HTTP и gRPC для прогнозирования моделей и управления внутренними ресурсами. На приведенном выше рисунке показан рабочий процесс использования TorchServe в этом примере.

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

Сервер TorchServe состоит из трех компонентов: внешнего интерфейса, внутреннего интерфейса и хранилища моделей. Интерфейс обрабатывает запрос/ответ TorchServe. Он также управляет жизненными циклами моделей. Бэкэнд на самом деле представляет собой список обработчиков моделей, эти обработчики отвечают за фактический вывод моделей. Магазин моделей — это каталог, в котором существуют
загружаемые модели. Это может быть папка облачного хранилища или локальная папка хоста.

На рисунке выше показаны два рабочих процесса: вывод модели и управление моделью.

Для выведения модели сначала пользователь отправляет запрос прогноза в конечную точку вывода для модели,
например, /predictions/{model_name}/{version}; затем запрос на вывод направляется
одному из рабочих процессов, который уже загрузил модель. Затем рабочий процесс будет
считывать файлы модели из хранилища моделей и позволит обработчику модели загрузить модель, предварительно обработать
входные данные и запустить модель, чтобы получить результат прогнозирования.

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

Функции

  • Может обслуживать несколько моделей или несколько версий одной и той же модели.
  • Унифицированные конечные точки gRPC и HTTP для вывода модели.
  • Поддержка пакетного прогнозирования запроса и настройки производительности.
  • Поддержка рабочего процесса для создания моделей Pytorch и функций Python в последовательных и параллельных конвейерах.
  • Предоставьте API-интерфейс управления для регистрации/отмены регистрации модели и масштабирования рабочих процессов.
  • Версии моделей для A/B-тестирования и экспериментов.