Solución de problemas de implementación y puntuación de puntos de conexión en línea

  • Artículo

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

Aprenda a resolver problemas comunes en la implementación y la puntuación de puntos de conexión en línea de Azure Machine Learning.

Este documento se estructura de la manera en que debe abordar la solución de problemas:

  1. Use la implementación local para probar y depurar los modelos localmente antes de realizar la implementación en la nube.
  2. Use los registros de contenedor para ayudar a depurar problemas.
  3. Conozca los errores de implementación comunes que pueden surgir y cómo corregirlos.

En la sección Códigos de estado HTTP se explica cómo se asignan los errores de invocación y predicción a los códigos de estado HTTP al puntuar puntos de conexión con solicitudes REST.

Requisitos previos

Implementación local

Se está implementando un modelo en un entorno de Docker local con la implementación local. La implementación local es útil para pruebas y depuración antes de su implementación en la nube.

Sugerencia

Puede usar el paquete de Python del servidor HTTP de inferencia de Azure Machine Learning para depurar el script de puntuación localmente. La depuración con el servidor de inferencia le ayuda a depurar el script de puntuación antes de implementar en los puntos de conexión locales para que pueda depurar sin verse afectado por las configuraciones del contenedor de implementación.

La implementación local admite la creación, la actualización y la eliminación de un punto de conexión local. También permite invocar y obtener registros desde el punto de conexión.

Para usar la implementación local, agregue --local al comando de la CLI adecuado:

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

Como parte de la implementación local, se llevan a cabo los pasos siguientes:

  • Docker compila una nueva imagen de contenedor o extrae una imagen existente de la caché local de Docker. Se usa una imagen existente si hay una que coincida con la parte del entorno del archivo de especificación.
  • Docker inicia un nuevo contenedor con artefactos locales montados, como archivos de modelo y código.

Para más información, consulte Implementación local en Implementación y puntuación de un modelo de Machine Learning.

Sugerencia

Use Visual Studio Code para probar y depurar los puntos de conexión localmente. Para más información, consulte Depuración local de puntos de conexión en línea en Visual Studio Code.

Instalación de Conda

Por lo general, los problemas con la implementación de MLflow proceden de problemas con la instalación del entorno de usuario especificado en el archivo conda.yaml.

Para depurar problemas de instalación de conda, prueba los siguientes pasos:

  1. Compruebe los registros de instalación de Conda. Si el contenedor se bloqueó o tarda demasiado tiempo en iniciarse, es probable que la actualización del entorno de conda no se resuelva correctamente.

  2. Instale el archivo conda de mlflow localmente con el comando conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. Si hay errores localmente, intente resolver el entorno de Conda y crear uno funcional antes de volver a implementarlo.

  4. Si el contenedor se bloquea incluso si el problema se resuelve localmente, es posible que el tamaño de la SKU que se usa para la implementación sea demasiado pequeño.

    1. La instalación del paquete de Conda se produce en runtime, por lo que si el tamaño de la SKU es demasiado pequeño para alojar todos los paquetes detallados en el archivo de entorno conda.yaml, el contenedor puede bloquearse.
    2. Una máquina virtual Standard_F4s_v2 es un buen tamaño de SKU inicial, pero es posible que sea necesario uno mayor en función de las dependencias especificadas en el archivo Conda.
    3. Para el punto de conexión en línea de Kubernetes, el clúster de Kubernetes debe tener un mínimo de 4 núcleos de CPU virtual y 8 GB de memoria.

Obtención de registros de contenedor

No se puede obtener acceso directo a la máquina virtual donde está implementado el modelo. Sin embargo, puede obtener registros de algunos de los contenedores que se ejecutan en ella. La cantidad de información que obtiene depende del estado de aprovisionamiento de la implementación. Si el contenedor especificado está en funcionamiento, verás su salida de consola; de lo contrario, recibirás un mensaje para volver a intentarlo más tarde.

Hay dos tipos de contenedores de los que puede obtener los registros:

  • Servidor de inferencia: los registros incluyen el registro de consola (del servidor de inferencia) que contiene la salida de las funciones de impresión y registro del script de puntuación (código score.py).
  • Inicializador de almacenamiento: estos registros contienen información sobre si el código y los datos del modelo se descargaron correctamente en el contenedor. El contenedor se ejecuta antes de que se inicie la ejecución del contenedor del servidor de inferencia.

Para ver la salida del registro de un contenedor, use el siguiente comando de la CLI:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

o

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

Agrega --resource-group y --workspace-name a estos comandos si aún no has configurado estos parámetros a través de az configure.

Para ver información sobre cómo establecer estos parámetros y, si actualmente tiene valores establecidos, ejecute:

az ml online-deployment get-logs -h

De forma predeterminada, los registros se extraen del servidor de inferencia.

Nota

Si usa el registro de Python, asegúrese de utilizar el orden de nivel de registro correcto para los mensajes que se van a publicar en los registros. Por ejemplo, INFO.

También puede obtener registros del contenedor de inicializadores de almacenamiento pasando –-container storage-initializer.

Agregue --help o --debug a los comandos para ver más información.

Para el punto de conexión en línea de Kubernetes, los administradores pueden acceder directamente al clúster donde implementa el modelo, que es más flexible para verificar el registro en Kubernetes. Por ejemplo:

kubectl -n <compute-namespace> logs <container-name>

Seguimiento de solicitudes

Hay dos encabezados de seguimiento admitidos:

  • x-request-id está reservado para el seguimiento del servidor. Invalidamos este encabezado para asegurarnos de que es un GUID válido.

    Nota:

    Cuando cree una incidencia de soporte técnico para una solicitud con error, adjunte el identificador de la solicitud con error para acelerar la investigación.

  • x-ms-client-request-id está disponible para escenarios de seguimiento de clientes. Este encabezado está saneado para aceptar solo caracteres alfanuméricos, guiones y caracteres de subrayado, y se trunca en un máximo de 40 caracteres.

Errores de implementación frecuentes

La siguiente lista es de errores de implementación comunes que se notifican como parte del estado de la operación de implementación:

Si estás creando o actualizando una implementación en línea de Kubernetes, puedes ver los errores comunes específicos de las implementaciones de Kubernetes.

ERROR: ImageBuildFailure

Este error se devuelve cuando se compila el entorno (imagen de Docker). Puede consultar el registro de compilación para obtener más información sobre los errores. El registro de compilación se encuentra en el almacenamiento predeterminado del área de trabajo de Azure Machine Learning. Puede que se devuelva la ubicación exacta como parte del error. Por ejemplo, "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

La siguiente lista contiene escenarios comunes de error de compilación de imágenes:

También se recomienda revisar la configuración de sondeo predeterminada si tiene tiempos de espera de ImageBuild.

Error de autorización del registro de contenedor

Si el mensaje de error menciona "container registry authorization failure", significa que no puedes acceder al registro del contenedor con las credenciales actuales. La desincronización de las claves de un recurso de área de trabajo puede provocar este error y la sincronización automática lleva algún tiempo. Sin embargo, puede solicitar manualmente una sincronización de claves, lo que puede resolver el error de autorización.

Los registros de contenedor que están detrás de una red virtual también pueden experimentar este error si están configurados incorrectamente. Debe comprobar que la red virtual está configurada correctamente.

Proceso de compilación de imágenes no establecido en un área de trabajo privada con red virtual

Si el mensaje de error menciona "failed to communicate with the workspace's container registry" y usa redes virtuales y el Azure Container Registry del área de trabajo es privado y está configurado con un punto de conexión privado, deberá habilitar Azure Container Registry para permitir la creación de imágenes en la red virtual.

Error en la compilación de una imagen genérica

Como se ha mencionado anteriormente, puede consultar el registro de compilación para obtener más información sobre el error. Si no se encuentra un error obvio en el registro de compilación y la última línea es Installing pip dependencies: ...working..., entonces puede que una dependencia esté causando el error. Anclar las dependencias de la versión en el archivo conda podría corregir este problema.

También recomendamos utilizar la implementación local para probar y depurar los modelos localmente antes de realizar la implementación en la nube.

ERROR: OutOfQuota

La siguiente lista es de recursos comunes que podrían agotarse la cuota al usar servicios de Azure:

Además, la siguiente lista es de recursos comunes que podrían agotarse solo la cuota para el punto de conexión en línea de Kubernetes:

Cuota de CPU

Antes de implementar un modelo, debe tener suficiente cuota de proceso. Esta cuota define la cantidad de núcleos virtuales disponibles por suscripción, área de trabajo, SKU y región. Cada implementación se resta de la cuota disponible y se vuelve a agregar después de la eliminación, en función del tipo de la SKU.

Una posible mitigación es verificar si hay implementaciones sin usar que puedas eliminar. O bien, puede enviar una solicitud de aumento de cuota.

Cuota de clúster

Este problema se produce cuando no tiene suficiente cuota de clústeres de proceso de Azure Machine Learning. Esta cuota define el número total de clústeres que pueden estar en uso por suscripción en un determinado momento para implementar nodos de CPU o GPU en Azure Cloud.

Una posible mitigación es verificar si hay implementaciones sin usar que puedas eliminar. O bien, puede enviar una solicitud de aumento de cuota. Asegúrese de seleccionar Machine Learning Service: Cluster Quota como tipo de cuota para esta solicitud de aumento de cuota.

Cuota de disco

Este problema se produce cuando el tamaño del modelo es mayor que el espacio en disco disponible y no se puede descargar el modelo. Pruebe una SKU con más espacio en disco o reduzca el tamaño de la imagen y el modelo.

Cuota de memoria

Este problema se produce cuando la superficie de memoria del modelo es mayor que la memoria disponible. Pruebe una SKU con más memoria.

Cuota de asignación de roles

Cuando crea un punto de conexión en línea administrado, se requiere la asignación de roles para que la identidad administrada acceda a los recursos del área de trabajo. Si se alcanza el límite de asignación de roles, intente eliminar algunas asignaciones de roles sin usar en esta suscripción. Para consultar todas las asignaciones de roles en Azure Portal, vaya al menú Control de acceso.

Cuota de puntos de conexión

Pruebe a eliminar algunos puntos de conexión que no utilice de esta suscripción. Si todos los puntos de conexión están en uso activamente, puede intentar solicitar un aumento del límite de puntos de conexión. Para más información sobre el límite de puntos de conexión, consulte Cuota de puntos de conexión con puntos de conexión en línea de Azure Machine Learning y puntos de conexión por lotes.

Cuota de Kubernetes

Este problema se produce cuando la CPU o la memoria solicitadas no se pueden proporcionar debido a que los nodos no se pueden programar para esta implementación. Por ejemplo, los nodos pueden acordonarse o no estar disponibles.

El mensaje de error indica normalmente que los recursos son insuficientes en el clúster, por ejemplo, OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods..., lo que significa que hay demasiados pods en el clúster y no hay recursos suficientes para implementar el nuevo modelo basado en su solicitud.

Puede probar las siguientes mitigaciones para solucionar este problema:

  • Para operaciones de TI que mantienen el clúster Kubernetes, puede intentar añadir más nodos o borrar algunos pods que no se usen en el clúster para liberar algunos recursos.
  • Los ingenieros de aprendizaje automático que implementan modelos pueden intentar reducir la solicitud de recursos de su implementación:
    • Si define directamente la solicitud de recursos en la configuración de implementación a través de la sección de recursos, puede intentar reducir la solicitud de recursos.
    • Si usa instance type para definir el recurso para la implementación de modelo, puede ponerse en contacto con operaciones de TI para ajustar la configuración del recurso de tipo de instancia. Para obtener más información, consulte Cómo gestionar el tipo de instancia de Kubernetes.

Capacidad de máquinas virtuales en toda la región

Debido a la falta de capacidad de Azure Machine Learning en la región, el servicio no pudo aprovisionar el tamaño de máquina virtual especificado. Retry later or try deploying to a different region (ERR_1101: Sin capacidad. El tamaño de máquina virtual especificado no se pudo aprovisionar debido a la falta de capacidad de Azure Machine Learning. Vuelva a intentarlo más tarde o pruebe a realizar la implementación en otra región).

Otras cuotas

Para ejecutar el archivo score.py proporcionado como parte de la implementación, Azure crea un contenedor que incluye todos los recursos que necesita score.py y ejecuta el script de puntuación en ese contenedor.

Si el contenedor no se pudo iniciar, significa que no se pudo realizar la puntuación. Podría ser que el contenedor solicite más recursos de los que instance_type puede admitir. Si es así, considere la posibilidad de actualizar el valor de instance_type de la implementación en línea.

Para conocer el motivo exacto de un error, ejecute:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ERROR: BadArgument

La siguiente lista es de motivos por los que podría encontrarse con este error al usar un punto de conexión en línea administrado o un punto de conexión en línea de Kubernetes:

La siguiente lista es de motivos por los que podría encontrarse con este error solo cuando se usa el punto de conexión en línea de Kubernetes:

La suscripción no existe

La suscripción de Azure especificada debe ser existente. Este error se produce cuando no se encuentra la suscripción de Azure a la que se hace referencia. Es probable que este error se deba a un error tipográfico en el identificador de suscripción. Compruebe que el identificador de suscripción se ha escrito correctamente y que está activo actualmente.

Para obtener más información sobre las suscripciones de Azure, puedes consultar la sección de requisitos previos.

Error de autorización

Después de aprovisionar el recurso de proceso (al crear una implementación), Azure intenta extraer la imagen de contenedor de usuario del área de trabajo Azure Container Registry (ACR). Intenta montar el modelo de usuario y los artefactos de código en el contenedor de usuarios desde la cuenta de almacenamiento del área de trabajo.

Para llevar a cabo estas acciones, Azure utiliza identidades administradas para acceder a la cuenta de almacenamiento y al registro de contenedor.

  • Si creó el punto de conexión asociado a una identidad asignada por el sistema, el permiso de control de acceso basado en roles (RBAC) de Azure se otorga automáticamente y no se necesitan más permisos.

  • Si creó el punto de conexión asociado con la identidad asignada por el usuario, la identidad administrada del usuario debe tener permiso de lector de datos de Storage Blob en la cuenta de almacenamiento para el área de trabajo y el permiso AcrPull en el Azure Container Registry (ACR) para el área de trabajo. Asegúrese de que la identidad asignada por el usuario tenga el permiso correcto.

Para obtener más información, consulta Error de autorización de Container Registry.

Especificación de función de plantilla no válida

Este error se produce cuando una función de plantilla se especificó incorrectamente. Corrija la directiva o quite la asignación de directiva para desbloquear. El mensaje de error puede incluir el nombre de la asignación de la directiva y la definición de la directiva para ayudarle a depurar este error, así como el artículo sobre la estructura de definición de la directiva de Azure en el que se tratan sugerencias para evitar errores de plantilla.

No se puede descargar la imagen del contenedor de usuario

Es posible que no se haya encontrado el contenedor de usuarios. Compruebe los registros de contenedor para obtener más detalles.

Asegúrese de que la imagen de contenedor está disponible en la instancia de ACR del área de trabajo.

Por ejemplo, si la imagen es testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, compruebe el repositorio con az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

Error al descargar el modelo de usuario

Es posible que no se encuentre el modelo de usuario. Compruebe los registros de contenedor para obtener más detalles.

Asegúrate de haber registrado el modelo en la misma área de trabajo que la implementación. Para mostrar los detalles de un modelo en un área de trabajo:

az ml model show --name <model-name> --version <version>

Advertencia

Debe especificar la versión o etiqueta para obtener la información del modelo.

También puede comprobar si los blobs existen en la cuenta de almacenamiento del área de trabajo.

  • Por ejemplo, si el blob es https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, puede usar este comando para comprobar si existe:

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`

  • Si el blob está presente, puede usar este comando para obtener los registros del inicializador de almacenamiento:

    az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

El formato de modelo de MLFlow con red privada no es compatible

Este error se produce al intentar implementar un modelo de MLflow con un enfoque de implementación sin código junto con el método de aislamiento de red heredado para los puntos de conexión en línea administrados. Esta característica de red privada no se puede usar junto con un formato de modelo de MLFlow si usa el método de aislamiento de red heredado. Si necesita implementar un modelo de MLflow con el enfoque de implementación sin código, pruebe a usar red virtual administrada del área de trabajo.

Solicitudes de recursos mayores que los límites

Las solicitudes de recursos deben ser inferiores o iguales a los límites. Si no establece límites, al asociar el proceso a un área de trabajo de Azure Machine Learning, se establecerán los valores predeterminados. Puede comprobar los límites en Azure Portal o utilizando el comando az ml compute show.

azureml-fe no está listo

El componente de front-end (azureml-fe) que enruta las solicitudes de inferencia entrantes a los servicios implementados se escala automáticamente según sea necesario. Se instala durante la instalación de k8s-extension.

Este componente debe estar en buen estado en el clúster, al menos debe haber una réplica en buen estado. Recibe este mensaje de error si no está disponible al desencadenar el punto de conexión en línea de Kubernetes y la solicitud de creación o actualización de implementación.

Compruebe el estado y los registros del pod para corregir este problema. También puede intentar actualizar la k8s-extension instalada en el clúster.

ERROR: ResourceNotReady

Para ejecutar el archivo score.py proporcionado como parte de la implementación, Azure crea un contenedor que incluye todos los recursos que necesita score.py y ejecuta el script de puntuación en ese contenedor. El error en este escenario es que este contenedor se bloquea al ejecutarse, lo que significa que no se puede realizar la puntuación. Este error se produce en los casos siguientes:

  • Hay un error en score.py. Use get-logs para diagnosticar los problemas comunes:
    • Un paquete que score.py intenta importar no se incluye en el entorno de Conda.
    • Especifica un error de sintaxis.
    • Un error en el método init().
  • Si get-logs no genera ningún registro, normalmente significa que el contenedor no se ha podido iniciar. Para depurar este problema, intente realizar una implementación local en su lugar.
  • Los sondeos de preparación o ejecución no están configurados correctamente.
  • La inicialización del contenedor tarda demasiado tiempo para que el sondeo de preparación o ejecución produzca un error más allá del umbral de error. En este caso, ajuste la configuración del sondeo para permitir más tiempo para inicializar el contenedor. O pruebe una SKU de máquina virtual más grande entre las SKU de máquina virtual admitidas, lo que acelera la inicialización.
  • Hay un error en la configuración del entorno del contenedor, como una dependencia que falta.
  • Cuando reciba el error TypeError: register() takes 3 positional arguments but 4 were given, compruebe la dependencia entre flask v2 y azureml-inference-server-http. Para obtener más información, consulte Preguntas más frecuentes sobre el servidor HTTP de inferencia.

ERROR: ResourceNotFound

Esta es una lista de los motivos por los que podrías encontrarte con este error solo cuando usas un punto de conexión en línea administrado o de Kubernetes:

Resource Manager no puede encontrar un recurso

Este error se produce cuando Azure Resource Manager no encuentra un recurso necesario. Por ejemplo, podrás recibir este error si se hizo referencia a una cuenta de almacenamiento, pero no se encuentra en la ruta de acceso en la que se especificó. Asegúrese de comprobar de nuevo los recursos que haya podido proporcionar una ruta de acceso exacta o la ortografía de sus nombres.

Para obtener más información, consulte Solución de errores de recurso no encontrado.

Error de autorización del registro de contenedor

Este error se produce cuando se proporcionó una imagen que pertenece a un registro de contenedor privado o inaccesible para la implementación. En este momento, nuestras API no pueden aceptar credenciales de registro privadas.

Para mitigar este error, asegúrese de que el registro de contenedor no es privado o siga estos pasos:

  1. Conceda el rol de acrPull de su registro privado a la identidad del sistema de su punto de conexión en línea.
  2. En la definición del entorno, especifique la dirección de la imagen privada, y la instrucción para no modificar (compilar) la imagen.

Si la mitigación se realiza correctamente, la imagen no requiere la compilación y la dirección final de la imagen es la dirección de imagen dada. En el momento de la implementación, la identidad del sistema del punto de conexión en línea extrae la imagen del registro privado.

Para obtener más información de diagnóstico, consulte Uso de la API de diagnóstico del área de trabajo.

ERROR: OperationCanceled

La siguiente lista es de motivos por los que podría encontrarse con este error al usar un punto de conexión en línea administrado o un punto de conexión en línea de Kubernetes:

Operación cancelada por otra operación de prioridad más alta

Las operaciones de Azure tienen un determinado nivel de prioridad y se ejecutan de mayor a menor. Este error se produce cuando otra operación invalida la operación que tiene una prioridad más alta.

Reintentar la operación podría permitir que se realice sin una cancelación.

Operación cancelada en espera a la confirmación de bloqueo

Las operaciones de Azure tienen un breve período de espera después de enviarse, durante el cual recuperan un bloqueo para asegurarse de que no se producen condiciones de carrera. Este error se produce cuando la operación enviada es la misma que otra operación. La otra operación está esperando actualmente la confirmación de que ha recibido el bloqueo para continuar. Puede indicar que ha enviado una solicitud similar demasiado pronto después de la solicitud inicial.

Si vuelve a intentar la operación después de esperar unos segundos o un minuto es posible que se realice sin cancelación.

ERROR: SecretsInjectionError

La recuperación e inserción de secretos durante la creación de la implementación en línea usa la identidad asociada al punto de conexión en línea para recuperar secretos de las conexiones del área de trabajo o almacenes de claves. Este error se produce en los casos siguientes:

  • La identidad de punto de conexión no tiene el permiso de Azure RBAC para leer los secretos de las conexiones del área de trabajo y/o almacenes de claves, a pesar de que los secretos han sido especificados por la definición de implementación como referencias (asignadas a variables de entorno). Recuerde que la asignación de roles puede tardar un tiempo en surtir efecto.
  • El formato de las referencias secretas no es válido o los secretos especificados no existen en las conexiones del área de trabajo o en los almacenes de claves.

Para más información, consulte Inyección de secretos en puntos de conexión en línea (versión preliminar) y Acceso a secretos desde la implementación en línea usando la inyección de secretos (versión preliminar).

ERROR: InternalServerError

Aunque hacemos todo lo posible para proporcionar un servicio estable y confiable, a veces las cosas no van como se espera. Si recibe este error, significa que algo no funciona por nuestra parte y es necesario corregirlo. Envía una incidencia de soporte técnico de cliente con toda la información relacionada y podremos solucionar el problema.

Errores comunes específicos de las implementaciones de Kubernetes

Errores relacionados con la identidad y la autenticación:

Errores relacionados con crashloopbackoff:

Errores relacionados con el script de puntuación:

Otros: .

ERROR: ACRSecretError

La siguiente lista es de motivos por los que podría encontrarse con este error al crear o actualizar las implementaciones en línea de Kubernetes:

  • No se ha completado la asignación de roles. En este caso, espere unos segundos e inténtelo de nuevo más tarde.
  • Azure ARC (en el caso de un clúster de Kubernetes para Azure Arc) o la extensión Azure Machine Learning (en el caso de AKS) no está instalado o configurado correctamente. Intente comprobar la configuración y el estado de la extensión de Azure ARC o Azure Machine Learning.
  • El clúster de Kubernetes tiene una configuración de red incorrecta. Compruebe el proxy, la directiva de red o el certificado.
    • Si usa un clúster de AKS privado, es necesario configurar puntos de conexión privados para ACR, cuenta de almacenamiento y el área de trabajo de la red virtual de AKS.
  • Asegúrese de que la versión de la extensión de Azure Machine Learning sea superior a v1.1.25.

ERROR: TokenRefreshFailed

Este error se debe a que la extensión no puede obtener credenciales de entidad de seguridad de Azure porque la identidad del clúster de Kubernetes no está establecida correctamente. Vuelva a instalar la extensión de Azure Machine Learning e inténtelo de nuevo.

ERROR: GetAADTokenFailed

Este error se debe a que el token de Azure AD de solicitud del clúster de Kubernetes produjo un error o a que se agota el tiempo de espera; compruebe la accesibilidad de red y vuelva a intentarlo.

  • Puede seguir las instrucciones de Configurar el tráfico de red necesario para comprobar el proxy saliente y asegurarse de que el clúster puede conectarse al área de trabajo.
  • La dirección URL del punto de conexión del área de trabajo se puede encontrar en la CRD del punto de conexión en línea en el clúster.

Si el área de trabajo es un área de trabajo privada, que deshabilitó el acceso a la red pública, el clúster de Kubernetes solo debe comunicarse con esa área de trabajo privada a través del vínculo privado.

  • Puede comprobar si el acceso al área de trabajo permite el acceso público, independientemente de si un clúster de AKS es público o privado, no puede acceder al área de trabajo privada.
  • Más información puede hacer referencia al entorno de inferencia de Azure Kubernetes Service seguro

ERROR: ACRAuthenticationChallengeFailed

Este error se debe a que el clúster Kubernetes no puede llegar al servicio ACR del área de trabajo para realizar el desafío de autenticación. Compruebe la red, especialmente el acceso a la red pública de ACR y vuelva a intentarlo.

Puede seguir los pasos de solución de problemas en GetAADTokenFailed para comprobar la red.

ERROR: ACRTokenExchangeFailed

Este error se debe a que se produjo un error en el token de ACR de intercambio del clúster de Kubernetes porque el token de Azure AD aún no está autorizado. Dado que la asignación de roles tarda algún tiempo, por lo que puede esperar un momento y volver a intentarlo.

Este error también puede deberse a demasiadas solicitudes al servicio ACR en ese momento; debe ser un error transitorio y puede volver a intentarlo más tarde.

ERROR: KubernetesUnaccessible

Es posible que obtenga el siguiente error durante las implementaciones de modelo de Kubernetes:

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Para solucionar este error, puede:

ERROR: ImagePullLoopBackOff

La razón por la que podrías encontrarte con este error al crear o actualizar implementaciones en línea de Kubernetes es porque no puedes descargar las imágenes del registro del contenedor, lo que provoca un error en la extracción de imágenes.

En este caso, puede comprobar la directiva de red del clúster y el registro de contenedor del área de trabajo para ver si el clúster puede extraer la imagen del registro de contenedor.

ERROR: DeploymentCrashLoopBackOff

La razón por la que podrías encontrarte con este error al crear o actualizar implementaciones en línea de Kubernetes es que el contenedor del usuario se haya bloqueado al inicializarse. Este error se debe a dos motivos posibles:

  • El script de usuario score.py tiene un error de sintaxis o un error de importación y, a continuación, genera excepciones al inicializar.
  • O el pod de implementación necesita más memoria que su límite.

Para mitigar este error, primero puedes verificar los registros de implementación para ver si hay excepciones en los scripts de usuario. Si el error persiste, intenta ampliar el límite de memoria del tipo de instancia o recursos.

ERROR: KubernetesCrashLoopBackOff

La siguiente lista es de motivos por los que podría encontrarse con este error al crear o actualizar los puntos de conexión o implementaciones en línea de Kubernetes:

  • Uno o varios pods detenidos con el estado CrashLoopBackoff: puede comprobar si existe el registro de implementación y si hay mensajes de error en el registro.
  • Hay un error en score.py y el contenedor se bloqueó cuando iniciaste tu código de puntuación. Puedes seguir la parte ERROR: ResourceNotReady.
  • El proceso de puntuación necesita más memoria y el límite de configuración de la implementación no es suficiente. Puede intentar actualizar la implementación con un límite de memoria mayor.

ERROR: NamespaceNotFound

El motivo por el que podría producirse este error al crear o actualizar los puntos de conexión en línea de Kubernetes es porque el espacio de nombres que el proceso de Kubernetes usó no está disponible en el clúster.

Puede comprobar el proceso de Kubernetes en el portal del área de trabajo y comprobar el espacio de nombres en el clúster de Kubernetes. Si el espacio de nombres no está disponible, puedes desasociar el proceso heredado y volver a asociarlo para crear uno nuevo, especificando un espacio de nombres que ya existe en el clúster.

ERROR: UserScriptInitFailed

El motivo por el que podrías encontrarte con este error al crear o actualizar las implementaciones en línea de Kubernetes es porque la función init del archivo cargado score.py generó una excepción.

Puedes comprobar los registros de implementación para ver el mensaje de excepción en detalle y corregir la excepción.

ERROR: UserScriptImportError

El motivo por el que podrías encontrarte con este error al crear o actualizar las implementaciones en línea de Kubernetes es porque el archivo score.py que cargaste tiene importados paquetes no disponibles.

Puedes comprobar los registros de implementación para ver el mensaje de excepción en detalle y corregir la excepción.

ERROR: UserScriptFunctionNotFound

El motivo por el que podrías encontrarte con este error al crear o actualizar las implementaciones en línea de Kubernetes es porque el archivo score.py que cargaste no tiene una función con el nombre init() o run(). Puedes comprobar el código y agregar la función.

ERROR: EndpointNotFound

El motivo por el que podría encontrarse con este error al crear o actualizar implementaciones en línea de Kubernetes es porque el sistema no encuentra el recurso de punto de conexión de la implementación en el clúster. Debe crear la implementación en un punto de conexión existente o crear este punto de conexión primero en el clúster.

ERROR: EndpointAlreadyExists

El motivo por el que podría encontrarse con este error al crear un punto de conexión en línea de Kubernetes es porque el punto de conexión ya existe en el clúster.

El nombre del punto de conexión debe ser único por área de trabajo y por clúster, por lo que, en este caso, deberá crear el punto de conexión con otro nombre.

ERROR: ScoringFeUnhealthy

El motivo por el que podría encontrarse con este error al crear o actualizar un punto de conexión o una implementación en línea de Kubernetes es porque Azureml-fe, que es el servicio del sistema que se ejecuta en el clúster, no se encuentra o es incorrecto.

Para solucionar este problema, puedes volver a instalar o actualizar la extensión de Azure Machine Learning en el clúster.

ERROR: ValidateScoringFailed

El motivo por el que podría encontrarse con este error al crear o actualizar implementaciones en línea de Kubernetes es porque se produjo un error en la validación de la dirección URL de la solicitud de puntuación al procesar la implementación del modelo.

En este caso, primero puedes comprobar la dirección URL del punto de conexión e intentar volver a implementar la implementación.

ERROR: InvalidDeploymentSpec

El motivo por el que podría encontrarse con este error al crear o actualizar implementaciones en línea de Kubernetes es porque la especificación de la implementación no es válida.

En este caso, puede comprobar el mensaje de error.

  • Asegúrese de que el valor de instance count sea válido.
  • Si ha habilitado el escalado automático, asegúrese de que los minimum instance count y maximum instance count sean válidos.

ERROR: PodUnschedulable

La siguiente lista es de motivos por los que podría encontrarse con este error al crear o actualizar los puntos de conexión o implementaciones en línea de Kubernetes:

  • No se puede programar el pod en los nodos, debido a que no hay recursos suficientes en el clúster.
  • No hay ninguna afinidad o selector de nodo que coincida con el nodo.

Para solucionar este error, puedes seguir estos pasos:

  • Compruebe la definición de node selector del instance type que usó y la configuración de node label de los nodos del clúster.
  • Compruebe instance type y el tamaño de la SKU del nodo para el clúster de AKS o el recurso de nodo para el clúster de Kubernetes para Arc.
    • Si el clúster tiene pocos recursos, puede reducir el requisito de recurso del tipo de instancia o usar otro tipo de instancia con un recurso más pequeño necesario.
  • Si el clúster no tiene más recursos para cumplir con el requisito de la implementación, elimine alguna implementación para liberar recursos.

ERROR: PodOutOfMemory

El motivo por el que podrías encontrarte con este error al crear o actualizar la implementación en línea es que el límite de memoria que proporcionas para la implementación es insuficiente. Puedes establecer el límite de memoria en un valor mayor o usar un tipo de instancia más grande para mitigar este error.

ERROR: InferencingClientCallFailed

El motivo por el que podría producirse este error al crear o actualizar el punto de conexión en línea de Kubernetes es porque la extensión k8s del clúster de Kubernetes no se puede conectar.

En este caso, puede desasociar y, a continuación, volver a asociar el proceso.

Nota:

Para solucionar errores mediante una nueva asociación, asegúrate de que lo haces con la misma configuración que el proceso desasociado anteriormente. Por ejemplo, con el mismo nombre de proceso y el mismo espacio de nombres ya que, de lo contrario, puedes encontrar otros errores.

Si sigue sin funcionar, puedes pedirle a un administrador que pueda acceder al clúster que use kubectl get po -n azureml para comprobar si se están ejecutando los pods del servidor de retransmisión.

Problemas de escalado automático

Si tiene problemas con el escalado automático, consulte Solución de problemas de escalado automático de Azure.

Para el punto de conexión en línea de Kubernetes, hay un enrutador de inferencias de Azure Machine Learning, que es un componente de front-end para controlar el escalado automático de todas las implementaciones de modelos del clúster de Kubernetes. Puede encontrar más información en Escalado automático del enrutamiento de inferencia de Kubernetes

Errores habituales del consumo de modelos

La siguiente lista es de errores comunes de consumo del modelo resultantes del estado de la operación de punto de conexión invoke.

Problemas de límite de ancho de banda

Los puntos de conexión en línea administrados tienen límites de ancho de banda para cada punto de conexión. Encontrará la configuración del límite en el artículo sobre los límites para los puntos de conexión en línea. Si el uso de ancho de banda supera su límite, la solicitud se retrasa. Para supervisar el retraso de ancho de banda:

  • Use la métrica "Bytes de red" para comprender el uso actual del ancho de banda. Para más información, consulte Supervisión de puntos de conexión en línea administrados.
  • Hay dos finalizadores de respuesta devueltos si se aplica el límite de ancho de banda:
    • ms-azureml-bandwidth-request-delay-ms: tiempo de retraso en milisegundos que tardó en transferirse el flujo de la solicitud.
    • ms-azureml-bandwidth-response-delay-ms: tiempo de retraso en milisegundos que tardó en transferirse el flujo de la respuesta.

Códigos de estado HTTP

Al acceder a los puntos de conexión en línea con solicitudes REST, los códigos de estado devueltos cumplen los estándares de los códigos de estado HTTP. Estos son los detalles sobre cómo se asignan los errores de predicción e invocación de puntos de conexión a códigos de estado HTTP.

Códigos de error comunes para puntos de conexión en línea administrados

La siguiente tabla contiene códigos de error comunes al consumir puntos de conexión en línea administrados con solicitudes REST:

status code Frase de motivo Motivo de que se devuelva este código.
200 Aceptar El modelo se ejecutó correctamente, dentro del límite de latencia.
401 No autorizado No tiene permiso para realizar la acción solicitada, como puntuación, o el token ha expirado o está en el formato incorrecta. Para más información, consulte el concepto de autenticación de punto de conexión y la autenticación para el punto de conexión.
404 No encontrado El punto de conexión no tiene ninguna implementación válida con peso positivo.
408 Tiempo de espera de solicitud La ejecución del modelo tardó más que el tiempo de espera proporcionado en request_timeout_ms en el elemento request_settings de la configuración de implementación del modelo.
424 Error del modelo Si el contenedor del modelo devuelve una respuesta distinta de 200, Azure devuelve el error 424. Compruebe la dimensión Model Status Code en la métrica Requests Per Minute del Explorador de métricas de Azure Monitor del punto de conexión. O consulte los encabezados de respuesta ms-azureml-model-error-statuscode y ms-azureml-model-error-reason para más información. Si 424 incluye errores de ejecución o sondeo de preparación, considere la posibilidad de ajustar la configuración del sondeo para permitir más tiempo de ejecución o preparación del contenedor.
429 Demasiadas solicitudes pendientes El modelo está recibiendo actualmente más solicitudes de las que puede manejar. Azure Machine Learning ha implementado un sistema que permite procesar en paralelo un máximo de 2 * max_concurrent_requests_per_instance * instance_count requests en cada momento para garantizar un funcionamiento fluido. Se rechazan otras solicitudes que superen este máximo. Puede revisar la configuración de implementación del modelo en las secciones request_settings y scale_settings para comprobar y ajustar esta configuración. Además, como se describe en la definición de YAML para RequestSettings, es importante asegurarse de que la variable de entorno WORKER_COUNT se pasa correctamente.

Si usa el escalado automático y obtiene este error, significa que su modelo está recibiendo solicitudes más rápido de lo que el sistema puede escalar verticalmente. En esta situación, considere la posibilidad de reenviar solicitudes con un retroceso exponencial para darle al sistema el tiempo que necesita ajustarse. También puede aumentar el número de instancias mediante el código para calcular el recuento de instancias. Estos pasos, combinados con la configuración del escalado automático, ayudan a asegurarse de que el modelo está listo para controlar la entrada de solicitudes.
429 Velocidad limitada El número de solicitudes por segundo alcanzó los límites de puntos de conexión en línea administrados.
500 Error interno del servidor Se produce un error en la infraestructura aprovisionada de Azure Machine Learning.

Códigos de error comunes para puntos de conexión en línea de Kubernetes

La tabla siguiente contiene códigos de error comunes al consumir puntos de conexión en línea de Kubernetes con solicitudes REST:

status code Frase de motivo Motivo de que se devuelva este código.
409 Error de conflicto Cuando una operación ya está en curso, cualquier operación nueva en ese mismo punto de conexión en línea responde con un error de conflicto 409. Por ejemplo, si la operación de creación o actualización del punto de conexión en línea está en curso y desencadena una nueva operación de eliminación, se produce un error.
502 Se ha producido una excepción o se ha bloqueado en el método run() del archivo score.py Cuando se produce un error en score.py, por ejemplo, un paquete importado no existe en el entorno de Conda, se produce un error de sintaxis o un error en el método init(). Puede consultar aquí cómo depurar el archivo.
503 Recepción de picos grandes en solicitudes por segundo El escalador automático está diseñado para controlar cambios de carga graduales. Si recibe grandes picos de 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. Puede consultar aquí cómo evitar códigos de estado 503.
504 La solicitud ha agotado el tiempo de espera. Un código de estado 504 indica que la solicitud ha agotado el tiempo de espera. El tiempo de espera predeterminado es de 5 segundos. Puede aumentar el tiempo de espera o intentar acelerar el punto de conexión modificando el archivo score.py para quitar llamadas innecesarias. Si estas acciones no corrigen el problema, puede consultar aquí cómo depurar el archivo score.py. El código puede estar en un estado sin respuesta o en un bucle infinito.
500 Error interno del servidor Se produce un error en la infraestructura aprovisionada de Azure Machine Learning.

Cómo evitar códigos de estado 503

Las implementaciones en línea de Kubernetes admiten el escalado automático, lo que permite agregar réplicas que admitan la carga adicional. Puede encontrar más información en Enrutador de inferencia de Azure Machine Learning. Las decisiones de escalar o reducir verticalmente se basan en el uso de las réplicas de contenedores actuales.

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 punto de conexión en línea de Kubernetes ya usa el número máximo actual de réplicas 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 la cantidad de instancias, puedes calcular las réplicas requeridas siguiendo estos códigos.

    from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

    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 punto de conexión aumente, es posible que deba aumentar el número mínimo de réplicas.

Cálculo del recuento de instancias

Para aumentar el número de instancias, puede calcular las réplicas necesarias con el siguiente código:

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

Bloqueado por la directiva de CORS

Actualmente, los puntos de conexión en línea (v2) no admiten el uso compartido de recursos entre orígenes (CORS) de forma nativa. Si la aplicación web intenta invocar el punto de conexión sin el control adecuado de las solicitudes de verificación previa de CORS, aparecerá el siguiente mensaje de error:

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

Se recomienda usar Azure Functions, Azure Application Gateway o cualquier servicio como una capa provisional para controlar las solicitudes preparatorias de CORS.

Problemas comunes de aislamiento de red

Se produce un error en la creación de puntos de conexión en línea con un mensaje V1LegacyMode == true

El área de trabajo de Azure Machine Learning se puede configurar para v1_legacy_mode, que deshabilita las API v2. Los puntos de conexión en línea administrados son una característica de la plataforma de API v2 y no funcionarán si el parámetro v1_legacy_mode está habilitado para el área de trabajo.

Importante

Póngase en contacto con el equipo de seguridad de red antes de deshabilitar v1_legacy_mode. Es posible que el equipo de seguridad de red haya habilitado este parámetro por algún motivo.

Para obtener información sobre cómo deshabilitar v1_legacy_mode, consulte Aislamiento de red con v2.

Error en la creación de puntos de conexión en línea con autenticación basada en claves

Use el siguiente comando para enumerar las reglas de red de Azure Key Vault del área de trabajo. Reemplace <keyvault-name> por el nombre del almacén de claves:

az keyvault network-rule list -n <keyvault-name>

La respuesta para este comando es similar al siguiente documento JSON:

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

Si el valor de bypass no es AzureServices, use las instrucciones de Configuración de las redes de almacén de claves para establecerlo en AzureServices.

Las implementaciones en línea no se pueden realizar y producen un error de descarga de imagen

Nota:

Este problema se aplica cuando se usa el método de aislamiento de red heredado para los puntos de conexión en línea administrados, en los que Azure Machine Learning crea una red virtual administrada para cada implementación en un punto de conexión.

  1. Compruebe si la marca egress-public-network-access está deshabilitada para la implementación. Si esta marca está habilitada y la visibilidad del registro de contenedor es privada, se espera este error.

  2. Use el siguiente comando para comprobar el estado de la conexión del punto de conexión privado. Reemplace <registry-name> por el nombre de Azure Container Registry para el área de trabajo:

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"

    En el documento de respuesta, compruebe que el campo status está establecido en Approved. Si no se aprueba, use el siguiente comando para aprobarlo. Reemplace <private-endpoint-name> por el nombre que devolvió el comando anterior:

    az network private-endpoint-connection approve -n <private-endpoint-name>

No se puede resolver el punto de conexión de puntuación

  1. Compruebe que el cliente que emite la solicitud de puntuación es una red virtual que puede acceder al área de trabajo de Azure Machine Learning.

  2. Use el comando nslookup en el nombre de host del punto de conexión para recuperar la información de la dirección IP:

    nslookup endpointname.westcentralus.inference.ml.azure.com

    La respuesta contiene una dirección. Esta dirección debe estar en el intervalo proporcionado por la red virtual.

    Nota:

    Para el punto de conexión en línea de Kubernetes, el nombre de host del punto de conexión debe ser el CName (nombre de dominio) que se ha especificado en su clúster de Kubernetes. Si es un punto de conexión HTTP, la dirección IP se incluirá en el URI del punto de conexión que puede obtener directamente en la interfaz de usuario de Studio. Puede consultar más formas de obtener la dirección IP del punto de conexión en Punto de conexión en línea de Kubernetes seguro.

  3. Si el comando nslookup no resuelve el nombre de host:

    Para un punto de conexión en línea administrado,

    1. compruebe si existe un registro A en la zona DNS privada de la red virtual.

      Para comprobar los registros, use el siguiente comando:

      az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

      Los resultados deben contener una entrada similar a *.<GUID>.inference.<region>.

    2. Si no se devuelve ningún valor de inferencia, elimine el punto de conexión privado del área de trabajo y vuelva a crearlo. Para obtener más información, consulte Configuración de un punto de conexión privado.

    3. Si el área de trabajo con un punto de conexión privado se configura mediante un DNS personalizado: Uso de un área de trabajo con un servidor DNS personalizado. Use el siguiente comando para comprobar si la resolución funciona correctamente desde el DNS personalizado.

      dig endpointname.westcentralus.inference.ml.azure.com

    Para un punto de conexión en línea de Kubernetes,

    1. compruebe la configuración de DNS en el clúster de Kubernetes.

    2. Además, puede comprobar si azureml-fe funciona según lo previsto. Use el siguiente comando:

      kubectl exec -it deploy/azureml-fe -- /bin/bash
(Run in azureml-fe pod)

curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

      Para HTTP, use

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

    Si se produce un error de HTTPs de curl (por ejemplo, tiempo de espera), pero HTTP funciona, compruebe que el certificado sea válido.

    Si no se puede resolver en un registro A, compruebe si la resolución funciona desde Azure DNS (168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

    Si esto se realiza correctamente, puede solucionar los problemas del reenviador condicional para el vínculo privado en el DNS personalizado.

No se pueden puntuar las implementaciones en línea

  1. Use el comando siguiente para ver si la implementación se implementó correctamente:

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'

    Si la implementación se completó correctamente, el valor de state será Succeeded.

  2. Si la implementación se realizó correctamente, use el siguiente comando para comprobar que el tráfico está asignado a la implementación. Reemplace <endpointname> por el nombre del punto de conexión:

    az ml online-endpoint show -n <endpointname>  --query traffic

    Sugerencia

    Este paso no es necesario si usa el encabezado azureml-model-deployment en la solicitud para dirigirse a esta implementación.

    La respuesta de este comando debe mostrar el porcentaje de tráfico asignado a las implementaciones.

  3. Si las asignaciones de tráfico (o el encabezado de implementación) se establecen correctamente, use el siguiente comando para obtener los registros del punto de conexión. Reemplace <endpointname> por el nombre del punto de conexión y <deploymentname> por la implementación:

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

    Examine los registros para ver si hay un problema al ejecutar el código de puntuación al enviar una solicitud a la implementación.

Solución de problemas del servidor de inferencia

En esta sección, se proporcionarán sugerencias básicas de solución de problemas para el servidor HTTP de inferencia de Azure Machine Learning.

Pasos básicos

Los pasos básicos para solucionar problemas son:

  1. Recopile información de versión para el entorno de Python.
  2. Asegúrese de que la versión del paquete de Python azureml-inference-server-http especificada en el archivo de entorno coincide con la versión del servidor HTTP de inferencia de AzureML que se muestra en el registro de inicio. A veces, el solucionador de dependencias de PIP conduce a versiones inesperadas de paquetes instalados.
  3. Si especifica Flask (o sus dependencias) en el entorno, quítelos. Las dependencias incluyen Flask, Jinja2, Werkzeugitsdangerous, MarkupSafe y click. Flask aparece como una dependencia en el paquete de servidor y es mejor permitir que nuestro servidor lo instale. De este modo, cuando el servidor admita nuevas versiones de Flask, las obtendrá automáticamente.

Versión del servidor

El paquete azureml-inference-server-http de servidor se publica en PyPI. Puede encontrar nuestro registro de cambios y todas las versiones anteriores en nuestra página de PyPI. Actualice a la versión más reciente si usa una versión anterior.

  • 0.4.x: la versión que se incluye en imágenes de entrenamiento ≤ 20220601 y en azureml-defaults>=1.34,<=1.43. 0.4.13 es la última versión estable. Si usa el servidor antes de la versión 0.4.11, puede ver problemas de dependencia de Flask, como que no se puede importar el nombre Markup desde jinja2. Se recomienda actualizar a 0.4.13 o 0.8.x (la versión más reciente), si es posible.
  • 0.6.x: versión preinstalada en imágenes de inferencia ≤ 20220516. La versión estable más reciente es 0.6.1.
  • 0.7.x: la primera versión que admite Flask 2. La versión estable más reciente es 0.7.7.
  • 0.8.x: el formato de registro ha cambiado y se ha eliminado la compatibilidad con Python 3.6.

Dependencias de paquetes

Los paquetes más relevantes para el servidor azureml-inference-server-http son los siguientes:

  • flask
  • opencensus-ext-azure
  • inference-schema

Si especificó azureml-defaults en su entorno Python, el paquete azureml-inference-server-http es dependiente y se instalará automáticamente.

Sugerencia

Si está usando Python SDK v1 y no especifica explícitamente azureml-defaults en su entorno Python, el SDK puede añadir el paquete por usted. Sin embargo, se bloqueará en la versión en la que se encuentra el SDK. Por ejemplo, si la versión del SDK es 1.38.0, se agregará azureml-defaults==1.38.0 a los requisitos de pip del entorno.

Preguntas más frecuentes

1. He encontrado el siguiente error durante el inicio del servidor:


TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Tiene Flask 2 instalado en el entorno de Python, pero ejecuta una versión de azureml-inference-server-http que no admite Flask 2. La compatibilidad con Flask 2 se agrega en azureml-inference-server-http>=0.7.0, que también está en azureml-defaults>=1.44.

  • Si no usa este paquete en una imagen de Docker de AzureML, use la versión más reciente de azureml-inference-server-http o azureml-defaults.

  • Si usa este paquete con una imagen de Docker de AzureML, asegúrese de que usa una imagen integrada o posterior a julio de 2022. La versión de la imagen está disponible en los registros de contenedor. Debería poder encontrar un registro similar al siguiente:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materializaton Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    La fecha de compilación de la imagen aparece después de "Compilación de materialización", que en el ejemplo anterior es 20220708, o el 8 de julio de 2022. Esta imagen es compatible con Flask 2. Si no ve un banner como este en el registro de contenedor, la imagen no está actualizada y debe actualizarse. Si usa una imagen CUDA y no encuentra una imagen más reciente, compruebe si la imagen está en desuso en AzureML-Containers. Si es así, debería poder encontrar reemplazos.

  • Si está usando el servidor con un punto de conexión en línea, también puede encontrar los registros en "Registros de implementación" en la página del punto de conexión en línea en Estudio de Azure Machine Learning. Si implementa con SDK v1 y no especifica explícitamente una imagen en la configuración de implementación, el valor predeterminado es usar una versión de openmpi4.1.0-ubuntu20.04 que coincida con el conjunto de herramientas del SDK local, que puede que no sea la versión más reciente de la imagen. Por ejemplo, SDK 1.43 usará openmpi4.1.0-ubuntu20.04:20220616 de forma predeterminada, que es incompatible. Asegúrese de usar el SDK más reciente para la implementación.

  • Si por algún motivo no puede actualizar la imagen, puede evitar temporalmente el problema anclando azureml-defaults==1.43 o azureml-inference-server-http~=0.4.13, que instalará el servidor de versiones anterior con Flask 1.0.x.

2. He encontrado un ImportError o ModuleNotFoundError en los módulos opencensus, jinja2, MarkupSafe o click durante el inicio, como el mensaje siguiente:

ImportError: cannot import name 'Markup' from 'jinja2'

Las versiones anteriores (<= 0.4.10) del servidor no anclaban la dependencia de Flask a versiones compatibles. Este problema se ha corregido en la versión más reciente del servidor.

Pasos siguientes