Solución de problemas de una implementación de modelo remota

  • Artículo

Aprenda a solucionar errores comunes, o a proporcionar soluciones alternativas, que se producen al implementar un modelo en Azure Container Instances y Azure Kubernetes Service mediante Azure Machine Learning.

Nota

Si va a implementar un modelo en Azure Kubernetes Service (AKS), le recomendamos que habilite Azure Monitor para ese clúster. Esto le ayudará a comprender el estado general y el uso de recursos del clúster. Puede que le resulten de utilidad los siguientes recursos:

Si intenta implementar un modelo en un clúster con un estado incorrecto o sobrecargado, se espera que experimente problemas. Si necesita ayuda para solucionar problemas del clúster de AKS, póngase en contacto con el departamento de soporte técnico de AKS.

Requisitos previos

Pasos para la implementación de Docker de modelos de Machine Learning

Al implementar un modelo en un proceso no local en Azure Machine Learning, ocurre lo siguiente:

  1. El Dockerfile que especificó en el objeto de entorno de InferenceConfig se envía a la nube, junto con el contenido del directorio de origen.
  2. Si una imagen compilada anteriormente no está disponible en el registro de contenedor, se compilará una nueva imagen de Docker en la nube y se almacenará en el registro de contenedor predeterminado del área de trabajo.
  3. La imagen de Docker del registro de contenedor se descarga en el destino de proceso.
  4. El almacén de blobs predeterminado del área de trabajo se monta en el destino de proceso, lo que le permite acceder a los modelos registrados.
  5. El servidor web se inicializa ejecutando la función init() del script de entrada.
  6. Cuando el modelo implementado recibe una solicitud, la función run() la administra.

La principal diferencia cuando se usa una implementación local es que la imagen del contenedor se crea en la máquina local, por lo que es necesario tener instalado Docker para realizar una implementación local.

La comprensión de estos pasos de alto nivel le ayudará a entender dónde se producen los errores.

Obtención de los registros de implementación

El primer paso en la depuración de errores es obtener los registros de implementación. En primer lugar, siga estas instrucciones para conectarse al área de trabajo.

SE APLICA A:Extensión de ML de la CLI de Azure v1

Para obtener los registros de un servicio web implementado, haga lo siguiente:

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

Depuración local

Si tiene problemas al implementar un modelo en ACI o AKS, impleméntelo como servicio web local. El uso de un servicio web local facilita la solución de problemas. Para solucionar problemas de implementación en un entorno local, consulte el artículo de solución de problemas en un entorno local.

Servidor HTTP de inferencia de Azure Machine Learning

El servidor de inferencia local permite depurar rápidamente el script de entrada (score.py). En caso de que el script de puntuación subyacente tenga un error, el servidor no podrá inicializar ni atender el modelo. Se producirá una excepción con la ubicación donde se produjeron los problemas. Más información sobre el servidor HTTP de inferencia de Azure Machine Learning

  1. Instale el paquete azureml-inference-server-http desde la fuente pypi:

    python -m pip install azureml-inference-server-http

  2. Inicie el servidor y establezca score.py como script de entrada:

    azmlinfsrv --entry_script score.py

  3. Envíe una solicitud de puntuación al servidor mediante curl:

    curl -p 127.0.0.1:5001/score

Nota:

Obtenga información sobre las preguntas frecuentes sobre el servidor HTTP de inferencia de Azure Machine Learning.

No se puede programar el contenedor

Al implementar un servicio en un destino de proceso de Azure Kubernetes Service, Azure Machine Learning intentará programar el servicio con la cantidad de recursos solicitada. Si pasados 5 minutos no hay ningún nodo disponible en el clúster con la cantidad adecuada de recursos disponibles, no se realizará la implementación. El mensaje de error es Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. Para solucionar este error, se pueden agregar más nodos, cambiar el SKU de los nodos o cambiar los requisitos de recursos del servicio.

El mensaje de error suele indicar el recurso del cual se necesita más. Por ejemplo, si ve un mensaje de error que indica 0/3 nodes are available: 3 Insufficient nvidia.com/gpu, significa que el servicio necesita GPU y que hay tres nodos en el clúster que no tienen GPU disponibles. Esto se puede solucionar mediante la agregación de más nodos si se usa una SKU de GPU, el cambio a una SKU habilitada para GPU si no se estaba usando o el cambio del entorno para que no se necesite GPU.

Error en el inicio del servicio

Después de que la imagen se haya compilado correctamente, el sistema intenta iniciar un contenedor con el uso de la configuración de implementación. Como parte del proceso de puesta en marcha del contenedor, el sistema invoca la función init() en el script de puntuación. Si hay excepciones no detectadas en la función init(), es posible que vea el error CrashLoopBackOff en el mensaje de error.

Use la información del artículo Inspección del registro de Docker.

Error al iniciar el contenedor azureml-fe-aci

Al implementar un servicio en un destino de proceso de Azure Container Instance, Azure Machine Learning intenta crear un contenedor front-end llamado azureml-fe-aci para la solicitud de inferencia. Si azureml-fe-aci se bloquea y desea ver los registros, ejecute az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. Puede seguir el mensaje de error en los registros para realizar la corrección.

El error más común de azureml-fe-aci es que el certificado SSL o la clave proporcionados no son válidos.

Error en la función: get_model_path()

A menudo, en la función init() en el script de puntuación, se llama a la función Model.get_model_path() para buscar un archivo de modelo o una carpeta de archivos de modelo en el contenedor. Si no se encuentra el archivo de modelo o la carpeta, se produce un error en la función. La manera más fácil de depurar este error es ejecutar el siguiente código de Python en el shell del contenedor:

SE APLICA A:Azure ML del SDK de Python v1

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

En este ejemplo se imprime la ruta de acceso local (relativa a /var/azureml-app) en el contenedor donde el script de puntuación espera encontrar el archivo o la carpeta del modelo. A continuación, puede comprobar si el archivo o la carpeta están realmente donde se espera que estén.

Establecer el nivel de registro en DEBUG puede provocar el registro de información adicional, que puede resultar útil para identificar el error.

Error en la función: run(input_data)

Si el servicio se implementa correctamente, pero se bloquea al publicar datos en el punto de conexión de puntuación, puede agregar una instrucción de captura de errores en la función run(input_data) para que devuelva un mensaje de error detallado en su lugar. Por ejemplo:

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

Nota: La devolución de mensajes de error de la llamada run(input_data) se debe realizar solo con fines de depuración. Por motivos de seguridad, no debe devolver los mensajes de error de esta manera en un entorno de producción.

Código de estado HTTP 502

Un código de estado 502 indica que el servicio ha producido una excepción o se ha bloqueado en el método run() del archivo score.py. Utilice la información de este artículo para depurar el archivo.

Código de estado HTTP 503

Las implementaciones de Azure Kubernetes Service admiten el escalado automático, que permite que las réplicas se agreguen para admitir la carga adicional. El escalador automático está diseñado para controlar cambios de carga graduales. Si recibe grandes picos en las solicitudes por segundo, los clientes pueden recibir un código de estado HTTP 503. Aunque el escalador automático reacciona con rapidez, AKS tarda mucho tiempo en crear más contenedores.

Las decisiones de escalar o reducir verticalmente se basan en el uso de las réplicas de contenedores actuales. El número de réplicas que están ocupadas (procesando una solicitud) dividido por el número total de réplicas actuales es el uso actual. Si este número supera autoscale_target_utilization, se crean más réplicas. Si es menor, se reducen las réplicas. Las decisiones de agregar réplicas son diligentes y rápidas (aproximadamente un segundo). Las decisiones de quitar réplicas son conservadoras (aproximadamente un minuto). De forma predeterminada, se establece el uso de destino de escalado automático en el 70 % , lo que significa que el servicio puede controlar picos de solicitudes por segundo (RPS) de hasta un 30 % .

Hay dos cosas que ayudan a impedir los códigos de estado 503:

Sugerencia

Estos dos enfoques se pueden utilizar individual o conjuntamente.

  • Cambiar el nivel de uso en el que el escalado automático crea nuevas réplicas. Puede ajustar el objetivo de uso mediante el establecimiento de autoscale_target_utilization en un valor inferior.

    Importante

    Este cambio no hace que las réplicas se creen más rápidamente. En lugar de eso, se crean con un umbral de uso más bajo. En lugar de esperar a que el servicio se use en un 70 %, si se cambia el valor a un 30 %, las réplicas se crearán cuando se produzca este 30 % de uso.

    Si el servicio web ya usa el número máximo de réplicas actuales y siguen apareciendo los códigos de estado 503, aumente el valor de autoscale_max_replicas con el fin de aumentar el número máximo de réplicas.

  • Cambie el número mínimo de réplicas. El aumento en el número mínimo de réplicas proporciona un grupo más grande para controlar los picos entrantes.

    Para aumentar el número mínimo de réplicas, establezca autoscale_min_replicas en un valor superior. Puede calcular las réplicas necesarias mediante el código siguiente, reemplazando los valores por valores específicos del proyecto:

    from math import ceil
# target requests per second
targetRps = 20
# time to process the request (in seconds)
reqTime = 10
# Maximum requests per container
maxReqPerContainer = 1
# target_utilization. 70% in this example
targetUtilization = .7

concurrentRequests = targetRps * reqTime / targetUtilization

# Number of container replicas
replicas = ceil(concurrentRequests / maxReqPerContainer)

    Nota

    Si recibe picos de solicitudes más grandes que el número mínimo nuevo de réplicas que se puede controlar, es posible que reciba códigos de estado 503 otra vez. Por ejemplo, a medida que el tráfico al servicio aumente, es posible que deba aumentar el número mínimo de réplicas.

Para obtener más información sobre cómo configurar autoscale_target_utilization, autoscale_max_replicas, y autoscale_min_replicas, vea la referencia de módulo AksWebservice.

Código de estado HTTP 504

Un código de estado 504 indica que la solicitud ha agotado el tiempo de espera. El tiempo de espera predeterminado es 1 minuto.

Puede aumentar el tiempo de espera o intentar acelerar el servicio modificando el archivo score.py para quitar llamadas innecesarias. Si estas acciones no solucionan el problema, use la información de este artículo para depurar el archivo score.py. El código puede estar en un estado sin respuesta o en un bucle infinito.

Otros mensajes de error

Realice estas acciones para los siguientes errores:

Error Resolución
Error de conflicto 409 Cuando una operación ya está en curso, cualquier operación nueva en ese mismo servicio web responderá con un error de conflicto 409. Por ejemplo, si la operación de creación o actualización del servicio web está en curso y desencadena una nueva operación de eliminación, se producirá un error.
Error de creación de imágenes al implementar el servicio web Agregar "pynacl==1.2.1" como una dependencia pip al archivo de Conda para la configuración de la imagen.
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Cambie la SKU de las máquinas virtuales usadas en la implementación por otra que tenga más memoria.
Error de FPGA No podrá implementar modelos en FPGA hasta que haya solicitado y se haya aprobado para la cuota FPGA. Para solicitar acceso, rellene el formulario de solicitud de cuota: https://aka.ms/aml-real-time-ai

Depuración avanzada

Es posible que tenga que depurar interactivamente el código de Python incluido en la implementación de modelo. Por ejemplo, si el script de entrada produce errores y no se puede determinar el motivo mediante un registro adicional. Mediante el uso de Visual Studio Code y debugpy, puede conectarse al código que se ejecuta en el contenedor de Docker.

Para más información, visite la guía de depuración interactiva en VS Code.

Foro de usuarios de implementación de modelos

Pasos siguientes

Más información acerca de la implementación: