Compartir vía


Uso de un contenedor personalizado para implementar un modelo en un punto de conexión en línea

SE APLICA A:Extensión ML de la CLI de Azure v2 (actual)SDK de Python azure-ai-ml v2 (actual)

Aprenda a usar un contenedor personalizado para implementar un modelo en un punto de conexión en línea en Azure Machine Learning.

Las implementaciones de contenedores personalizados pueden usar servidores web distintos del servidor Python Flask predeterminado que usa Azure Machine Learning. Los usuarios de estas implementaciones todavía pueden aprovechar las ventajas de la supervisión, el escalado, las alertas y la autenticación integradas de Azure Machine Learning.

En la tabla siguiente se enumeran varios ejemplos de implementación que usan contenedores personalizados como TensorFlow Serving, TorchServe, Triton Inference Server, el paquete de Plumber R y la imagen mínima de inferencia de Azure Machine Learning.

Ejemplo Script (CLI) Descripción
minimal/multimodel deploy-custom-container-minimal-multimodel Implemente varios modelos en una sola implementación mediante la extensión de la imagen mínima de inferencia de Azure Machine Learning.
minimal/single-model deploy-custom-container-minimal-single-model Implemente un único modelo mediante la extensión de la imagen mínima de inferencia de Azure Machine Learning.
mlflow/multideployment-scikit deploy-custom-container-mlflow-multideployment-scikit Implemente dos modelos de MLFlow con distintos requisitos de Python en dos implementaciones independientes detrás de un único punto de conexión por medio de la imagen mínima de inferencia de Azure Machine Learning.
r/multimodel-plumber deploy-custom-container-r-multimodel-plumber Implemente tres modelos de regresión en un punto de conexión mediante el paquete de Plumber R
tfserving/half-plus-two deploy-custom-container-tfserving-half-plus-two Implemente un modelo de Half Plus mediante un contenedor personalizado de TensorFlow Serving usando un proceso de registro de modelos estándar.
tfserving/half-plus-two-integrated deploy-custom-container-tfserving-half-plus-two-integrated Implemente un modelo de Half Plus Two mediante un contenedor personalizado de TensorFlow Serving con el modelo integrado en la imagen.
torchserve/densenet deploy-custom-container-torchserve-densenet Implemente un único modelo mediante un contenedor personalizado de TorchServe.
triton/single-model deploy-custom-container-triton-single-model Implemente un modelo de Triton mediante un contenedor personalizado

En este artículo se abordan las prestaciones de servicios a un modelo de TensorFlow con TensorFlow (TF) Serving.

Advertencia

Es posible que Microsoft no pueda ayudar a solucionar los problemas derivados de una imagen personalizada. Si tiene problemas, se le pedirá que use la imagen predeterminada o una de las imágenes que proporciona Microsoft para ver si el problema es específico de la imagen.

Requisitos previos

Antes de seguir los pasos de este artículo, asegúrese de que tiene los siguientes requisitos previos:

  • Usted, o la entidad de servicio que use, debe tener acceso Colaborador al grupo de recursos de Azure que contiene el área de trabajo. Tendrá un grupo de recursos de este tipo si ha configurado el área de trabajo según el artículo de inicio rápido.

  • Para realizar la implementación localmente, debe tener el motor de Docker ejecutándose en local. Se recomienda encarecidamente realizar este paso. Este artículo le ayuda a depurar problemas.

Descarga del código fuente

Para seguir este tutorial, clone el código fuente de GitHub.

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

Inicialización de las variables de entorno

Defina las variables de entorno:

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

Descarga de un modelo de TensorFlow

Descargue y descomprima un modelo que divide una entrada entre dos y agrega 2 al resultado:

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

Ejecución local de una imagen de TF Serving para probar que funciona

Use Docker para ejecutar la imagen localmente para realizar pruebas:

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

Comprobar que pueden enviar solicitudes de ejecución y puntuación a la imagen

En primer lugar, compruebe que el contenedor está activo, lo que significa que el proceso dentro del contenedor todavía está en ejecución. Debería obtener una respuesta 200 (OK).

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

A continuación, compruebe que puede obtener predicciones sobre datos sin etiquetar:

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

Detención de la imagen

Ahora que ha realizado las pruebas localmente, detenga la imagen:

docker stop tfserving-test

Implementación del punto de conexión en línea en Azure

A continuación, implemente el punto de conexión en línea en Azure.

Creación de un archivo YAML para el punto de conexión y la implementación

Puede configurar la implementación en la nube mediante YAML. Eche un vistazo al YAML de muestra para este ejemplo:

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

Hay algunos conceptos importantes que debe tener en cuenta en este parámetro de YAML/Python:

Imagen base

La imagen base se especifica como parámetro en el entorno y se usa docker.io/tensorflow/serving:latest en este ejemplo. A medida que inspecciona el contenedor, puede encontrar que este servidor usa ENTRYPOINT para iniciar un script de punto de entrada, que toma las variables de entorno, como MODEL_BASE_PATH y MODEL_NAME, y expone puertos como 8501. Todos estos detalles son información específica para este servidor elegido. Puede usar esta comprensión del servidor para determinar cómo definir la implementación. Por ejemplo, si establece variables de entorno para MODEL_BASE_PATH y MODEL_NAME en la definición de implementación, el servidor (en este caso, TF Serving) tomará los valores para iniciar el servidor. Del mismo modo, si establece el puerto para que las rutas sea 8501 en la definición de implementación, la solicitud del usuario a dichas rutas se enrutará correctamente al servidor TF Serving.

Tenga en cuenta que este ejemplo específico se basa en el caso de TF Serving, pero puede usar cualquier contenedor que se mantenga activo y responda a las solicitudes que lleguen a las rutas de ejecución, preparación y puntuación. Puede consultar otros ejemplos y ver cómo se forma el Dockerfile (por ejemplo, mediante CMD en lugar de ENTRYPOINT) para crear los contenedores.

Configuración de inferencia

La configuración de inferencia es un parámetro en el entorno y especifica el puerto y la ruta de acceso de tres tipos de ruta: ejecución, preparación y puntuación. Se requiere la configuración de inferencia si desea ejecutar su propio contenedor con un punto de conexión en línea administrado.

Ruta de preparación frente a ruta de ejecución

El servidor de API que elija puede proporcionar una manera de comprobar el estado del servidor. Hay dos tipos de ruta que puede especificar: ejecución y preparación. Se usa una ruta de ejecución para comprobar si el servidor se está ejecutando. Se usa una ruta de preparación para comprobar si el servidor está listo para realizar trabajo. En el contexto de la inferencia de aprendizaje automático, un servidor podría responder 200 OK a una solicitud de ejecución antes de cargar un modelo, y el servidor podría responder 200 OK a una solicitud de preparación solo después de que el modelo se haya cargado en la memoria.

Revise la documentación de Kubernetes para más información sobre los sondeos de ejecución y preparación en general.

Las rutas de ejecución y preparación serán determinadas por el servidor API de su elección, como habrá identificado al probar el contenedor localmente en el paso anterior. Tenga en cuenta que la implementación de ejemplo de este artículo usa la misma ruta de acceso para la ejecución y la preparación, ya que TF Serving solo define una ruta de ejecución. Consulte otros ejemplos de patrones diferentes para definir las rutas.

Ruta de puntuación

El servidor API que elija le proporcionará una forma de recibir la carga útil en la que trabajar. En el contexto de la inferencia de aprendizaje automático, un servidor recibiría los datos de entrada a través de una ruta específica. Identifique esta ruta para el servidor API mientras prueba el contenedor localmente en el paso anterior y especifíquela cuando defina la implementación a crear. Tenga en cuenta que la creación correcta de la implementación actualizará también el parámetro scoring_uri del punto de conexión, que puede comprobar con az ml online-endpoint show -n <name> --query scoring_uri.

Búsqueda del modelo montado

Al implementar un modelo como un punto de conexión en línea, Azure Machine Learning monta el modelo en el punto de conexión. El montaje del modelo le permite implementar nuevas versiones del modelo sin tener que crear una nueva imagen de Docker. De manera predeterminada, un modelo registrado con el nombre foo y la versión 1 se ubicaría en la siguiente ruta de acceso dentro del contenedor implementado: /var/azureml-app/azureml-models/foo/1

Por ejemplo, si tiene una estructura de directorio de /azureml-examples/cli/endpoints/online/custom-container en el equipo local, donde el modelo se denomina half_plus_two:

Diagrama que muestra una vista de árbol de la estructura de directorios local.

Y tfserving-deployment.yml contiene:

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

Entonces el modelo se ubicará en /var/azureml-app/azureml-models/tfserving-deployment/1 en la implementación:

Diagrama que muestra una vista de árbol de la estructura de directorios de implementación.

Opcionalmente, puede configurar model_mount_path. Le permite cambiar la ruta de acceso donde se monta el modelo.

Importante

model_mount_path debe ser una ruta de acceso absoluta válida en Linux (el sistema operativo de la imagen de contenedor).

Por ejemplo, puede tener el parámetro model_mount_path en 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
.....

A continuación, puede encontrar el modelo en /var/tfserving-model-mount/tfserving-deployment/1 en la implementación. Tenga en cuenta que ya no está en azureml-app/azureml-models, sino en la ruta de acceso de montaje que ha especificado:

Diagrama que muestra una vista de árbol de la estructura de directorios de implementación al usar mount_model_path.

Creación del punto de conexión y la implementación

Ahora que comprende cómo se construye el código YAML, cree el punto de conexión.

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

Es posible que la creación de una implementación tarde unos minutos.

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

Invocación del punto de conexión

Una vez completada la implementación, compruebe si puede realizar una solicitud de puntuación al punto de conexión implementado.

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

Eliminación del punto de conexión

Ahora que ha realizado la puntuación correctamente con el punto de conexión, puede eliminarlo:

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