Поделиться через

Использование пользовательского контейнера для развертывания модели в сетевой конечной точке

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ:Расширение машинного обучения Azure CLI версии 2 (current)Python SDK azure-ai-ml версии 2 (current)

Узнайте, как использовать пользовательский контейнер для развертывания модели в веб-конечной точке в Машинное обучение Azure.

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

В следующей таблице перечислены различные примеры развертывания, использующие настраиваемые контейнеры, такие как TensorFlow Service, TorchServe, Triton Inference Server, пакет Plumber R и Машинное обучение Azure минимальное изображение вывода.

Пример Скрипт (CLI) Description
минимальное или многомодельное deploy-custom-container-min-multimodel Разверните несколько моделей в одном развертывании, расширив Машинное обучение Azure минимальное изображение вывода.
минимальная/одна модель deploy-custom-container-min-single-model Разверните одну модель, расширив Машинное обучение Azure минимальное изображение вывода.
mlflow/multideployment-scikit deploy-custom-container-mlflow-multideployment-scikit Разверните две модели MLFlow с различными требованиями Python к двум отдельным развертываниям за одной конечной точкой с помощью минимального образа вывода Машинное обучение Azure.
r/multimodel-plumber deploy-custom-container-r-multimodel-plumber Развертывание трех моделей регрессии в одной конечной точке с помощью пакета Plumber R
tfserving/half-plus-two deploy-custom-container-tfserving-half-plus-two Разверните модель Half Plus Two с помощью настраиваемого контейнера TensorFlow, используя стандартный процесс регистрации модели.
tfserving/half-plus-two-integrated deploy-custom-container-tfserving-half-plus-two-integrated Разверните модель Half Plus Two с помощью настраиваемого контейнера TensorFlow Для обслуживания с моделью, интегрированной в образ.
torchserve/densenet deploy-custom-container-torchserve-densenet Разверните одну модель с помощью пользовательского контейнера TorchServe.
triton/single-model deploy-custom-container-triton-single-model Развертывание модели Triton с помощью пользовательского контейнера

В этой статье рассматривается обслуживание модели TensorFlow с помощью TensorFlow (TF).

Предупреждение

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

Необходимые компоненты

Перед выполнением действий, описанных в этой статье, убедитесь, что выполнены следующие необходимые условия:

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

  • Для локального развертывания необходимо, чтобы подсистема Docker запускалась локально. Настоятельно рекомендуется выполнить этот этап. Это помогает отлаживать проблемы.

Скачивание исходного кода

Чтобы следовать этому руководству, клонируйте исходный код из GitHub.

git clone https://github.com/Azure/azureml-examples --depth 1
cd azureml-examples/cli

Инициализация переменных среды

Определение переменных среды:

BASE_PATH=endpoints/online/custom-container/tfserving/half-plus-two
AML_MODEL_NAME=tfserving-mounted
MODEL_NAME=half_plus_two
MODEL_BASE_PATH=/var/azureml-app/azureml-models/$AML_MODEL_NAME/1

Загрузите модель TensorFlow.

Загрузите и распакуйте модель, которая делит входные данные на два и добавляет 2 к результату:

wget https://aka.ms/half_plus_two-model -O $BASE_PATH/half_plus_two.tar.gz
tar -xvf $BASE_PATH/half_plus_two.tar.gz -C $BASE_PATH

Запустите образ TF Serving локально, чтобы проверить, работает ли он.

Используйте Docker, чтобы локально запустить образ для тестирования:

docker run --rm -d -v $PWD/$BASE_PATH:$MODEL_BASE_PATH -p 8501:8501 \
 -e MODEL_BASE_PATH=$MODEL_BASE_PATH -e MODEL_NAME=$MODEL_NAME \
 --name="tfserving-test" docker.io/tensorflow/serving:latest
sleep 10

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

Во-первых, убедитесь, что контейнер жив, то есть процесс внутри контейнера по-прежнему выполняется. Вы должны получить ответ "200 (ОК)".

curl -v http://localhost:8501/v1/models/$MODEL_NAME

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

curl --header "Content-Type: application/json" \
  --request POST \
  --data @$BASE_PATH/sample_request.json \
  http://localhost:8501/v1/models/$MODEL_NAME:predict

Остановка образа

Теперь, когда вы проверили локально, остановите изображение:

docker stop tfserving-test

Развертывание сетевой конечной точки в Azure

Теперь следует развернуть сетевую конечную точку в Azure.

Создайте файл YAML для конечной точки и развертывания

С помощью YAML можно настроить облачное развертывание. Взгляните на выборку YAML для этого примера:

tfserving-endpoint.yml

$schema: https://azuremlsdk2.blob.core.windows.net/latest/managedOnlineEndpoint.schema.json
name: tfserving-endpoint
auth_mode: aml_token

tfserving-deployment.yml

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: tfserving-deployment
endpoint_name: tfserving-endpoint
model:
  name: tfserving-mounted
  version: {{MODEL_VERSION}}
  path: ./half_plus_two
environment_variables:
  MODEL_BASE_PATH: /var/azureml-app/azureml-models/tfserving-mounted/{{MODEL_VERSION}}
  MODEL_NAME: half_plus_two
environment:
  #name: tfserving
  #version: 1
  image: docker.io/tensorflow/serving:latest
  inference_config:
    liveness_route:
      port: 8501
      path: /v1/models/half_plus_two
    readiness_route:
      port: 8501
      path: /v1/models/half_plus_two
    scoring_route:
      port: 8501
      path: /v1/models/half_plus_two:predict
instance_type: Standard_DS3_v2
instance_count: 1

В этом параметре YAML/Python есть несколько важных понятий:

Базовый образ

Базовый образ указывается в качестве параметра в среде и docker.io/tensorflow/serving:latest используется в этом примере. При проверке контейнера можно найти, что этот сервер используется ENTRYPOINT для запуска скрипта точки входа, который принимает переменные среды, такие как иMODEL_NAME, и предоставляет такие порты, как MODEL_BASE_PATH 8501. Эти сведения являются всеми конкретными сведениями для выбранного сервера. Это понимание сервера можно использовать для определения развертывания. Например, если вы задаете переменные среды для MODEL_BASE_PATH определения развертывания и MODEL_NAME в определении развертывания, сервер (в данном случае служба TF) принимает значения для запуска сервера. Аналогичным образом, если вы задаете порт для маршрутов, которые будут находиться 8501 в определении развертывания, запрос пользователя к таким маршрутам будет правильно перенаправлен на сервер обслуживания TF.

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

Конфигурация вывода

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

Маршрут готовности и маршрут активности

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

Дополнительные сведения о пробах активности и готовности в целом см. в документации Kubernetes.

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

Маршрут оценки

Сервер API, на который вы выбрали, предоставит способ получения полезных данных для работы. В контексте вывода машинного обучения сервер получит входные данные через определенный маршрут. Определите этот маршрут для сервера API при локальном тестировании контейнера на предыдущем шаге и укажите его при определении развертывания для создания. Обратите внимание, что успешное создание развертывания обновит параметр scoring_uri конечной точки, с помощью которого можно проверить az ml online-endpoint show -n <name> --query scoring_uri.

Определение местоположения подключенной модели

При развертывании модели в качестве подключенной конечной точки Машинное обучение Azure подключает эту модель к конечной точке. Подключение модели позволяет развертывать новые версии модели, не создавая новый образ Docker. По умолчанию модель, зарегистрированная с именем foo и версией 1 , будет находиться по следующему пути внутри развернутого контейнера: /var/azureml-app/azureml-models/foo/1

Например, если у вас есть структура каталога /azureml-examples/cli/endpoints/online/custom-container на локальном компьютере, где модель называется half_plus_two:

Схема представления структуры локальных каталогов в виде дерева.

И tfserving-deployment.yml содержит следующее:

model:
    name: tfserving-mounted
    version: 1
    path: ./half_plus_two

Затем модель будет находиться в разделе /var/azureml-app/azureml-models/tfserving-deployment/1 в развертывании:

Схема представления структуры каталогов развертывания в виде дерева.

При необходимости можно настроить model_mount_path. Он позволяет изменить путь, в котором подключена модель.

Внимание

model_mount_path должен быть допустимым абсолютным путем в Linux (ОС образа контейнера).

Например, можно иметь параметр model_mount_path в tfserving-deployment.yml:

name: tfserving-deployment
endpoint_name: tfserving-endpoint
model:
  name: tfserving-mounted
  version: 1
  path: ./half_plus_two
model_mount_path: /var/tfserving-model-mount
.....

Затем модель находится в папке /var/tfserving-model-mount/tfserving-deployment/1 в развертывании. Обратите внимание, что он больше не находится в azureml-app/azureml-models, но в указанном пути подключения:

Схема представления структуры каталогов развертывания в виде дерева пр использовании mount_model_path.

Создание конечной точки и развертывания

Теперь, когда вы узнаете, как был создан YAML, создайте конечную точку.

az ml online-endpoint create --name tfserving-endpoint -f endpoints/online/custom-container/tfserving-endpoint.yml

Создание развертывания может занять несколько минут.

az ml online-deployment create --name tfserving-deployment -f endpoints/online/custom-container/tfserving-deployment.yml --all-traffic

Вызов конечной точки

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

RESPONSE=$(az ml online-endpoint invoke -n $ENDPOINT_NAME --request-file $BASE_PATH/sample_request.json)

Удаление конечной точки

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

az ml online-endpoint delete --name tfserving-endpoint

Связанный контент