Compartir a través de

Solución de problemas de implementación y puntuación de puntos 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)

En este artículo se describe cómo solucionar problemas comunes de implementación y puntuación de puntos de conexión en línea de Azure Machine Learning.

La estructura de este documenta refleja la forma en que se 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

Seguimiento de solicitudes

Hay dos encabezados de seguimiento admitidos:

  • x-request-id está reservado para el seguimiento del servidor. Azure Machine Learning anula este encabezado para asegurarse de que es un GUID válido. Cuando cree un ticket de soporte para una solicitud fallida, adjunte el identificador de la solicitud fallida para acelerar la investigación. Como alternativa, proporcione el nombre de la región y el nombre del punto de conexión.

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

Implementación local

Implementación local significa implementar un modelo en un entorno de Docker local. La implementación local admite la creación, actualización y eliminación de un punto de conexión local, y permite no solo invocar registros del punto de conexión, sino también obtenerlos. La implementación local es útil para pruebas y depuración antes de su implementación en la nube.

Sugerencia

También puedes utilizar el paquete de Python del servidor HTTP de inferencia de Azure Machine Learning para depurar tu script de puntuación localmente. La depuración con el servidor de inferencia le ayuda a depurar el script de puntuación antes de implementarlo en los puntos de conexión locales, de manera que pueda depurar sin que le afecten las configuraciones del contenedor de implementación.

La implementación se puede realizar localmente con la CLI de Azure o el SDK de Python. Azure Machine Learning Studio no admite la implementación local ni los puntos de conexión locales.

Para usar la implementación local, es preciso agregar --local al comando adecuado.

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

En la implementación local se llevan a cabo los siguientes pasos:

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

Para más información, consulte Implementación y depuración locales mediante un punto de conexión local.

Sugerencia

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

Obtener registros de contenedor

No puede obtener acceso directo a las máquinas virtuales en las que se implementa un modelo, pero puede obtener los registros de algunos de los contenedores que se ejecutan en la máquina virtual. La cantidad de información que obtiene depende del estado de aprovisionamiento de la implementación. Si el contenedor especificado está en funcionamiento, se ve la salida de la consola. De lo contrario, aparece mensaje que sugiere volver a intentarlo más adelante.

Puede obtener registros de los siguientes tipos de contenedores:

  • El registro de consola del servidor de inferencia de contiene la salida de las funciones de impresión y registro del script de puntuación score.py código.
  • Los registros del inicializador de almacenamiento 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.

En el caso de los puntos de conexión en línea de Kubernetes, los administradores pueden acceder directamente al clúster donde se implementa el modelo para consultar los registros en Kubernetes. Por ejemplo:

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

Nota:

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

Consulte la salida del registro de los contenedores.

Para ver la salida de logs de un contenedor, use el siguiente comando:

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

De forma predeterminada, los registros se extraerán del servidor de inferencia. Puede obtener registros del contenedor del inicializador de almacenamiento pasando –-container storage-initializer.

Agregue --resource-group y --workspace-name a los comandos si aún no ha establecido estos parámetros mediante az configure. Para ver información sobre cómo establecer estos parámetros o si hay tiene valores establecidos, ejecute el siguiente comando:

az ml online-deployment get-logs -h

Para ver más información, agregue --help o --debug a los comandos.

Errores de implementación frecuentes

El estado de la operación de implementación puede notificar los siguientes errores comunes:

Si vas a crear o actualizar una implementación en línea de Kubernetes, puedes consultar Errores comunes específicos de las implementaciones de Kubernetes.

ERROR: FalloEnLaConstrucciónDeImagen

Este error se devuelve cuando se compila el entorno de imagen de Docker. Puede consultar el registro de compilación para obtener más información sobre la falla. 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, como por ejemplo "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

En las siguientes secciones de describen escenarios comunes de error de compilación de imágenes:

Error de autorización de Azure Container Registry

Un mensaje de error menciona "container registry authorization failure" cuando no se puede acceder al registro del contenedor con las credenciales actuales. Este error puede aparecer debido a la desincronización de las claves de los recursos del área de trabajo y su sincronización automática tarda un tiempo. Sin embargo, se puede solicitar manualmente una sincronización de claves con az ml workspace sync-keys, 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 no están configurados correctamente. Compruebe que la red virtual está configurada correctamente.

El cómputo de construcción de imágenes no está configurado en un espacio de trabajo privado con red virtual

Si el mensaje de error menciona "failed to communicate with the workspace's container registry" y usa una red virtual, y el registro de contenedor del área de trabajo es privado y está configurado con un punto de conexión privado, debes permitir que Azure Container Registry compile imágenes en la red virtual.

Se agota el tiempo de compilación de imágenes

Los tiempos de espera de compilación de imágenes suelen deberse a que una imagen es demasiado grande para poder completar la creación dentro del período de tiempo de creación de la implementación. Compruebe los registros de compilación de imágenes en la ubicación que especifica el error. Los registros se cortan en el momento en que se agotó el tiempo de espera de compilación de la imagen.

Para resolver el problema, compile la imagen por separado, con el fin de que solo sea necesario extraerla durante la creación de la implementación. Revise también la configuración predeterminada de sondeo si tiene problemas de tiempo de espera en ImageBuild.

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

Para más información sobre el error, consulte el registro de compilación. Si no se encuentra ningún error obvio en el registro de compilación y la última línea es Installing pip dependencies: ...working..., es posible que el error lo provoque alguna dependencia. Anclar las dependencias de la versión en el archivo conda puede corregir este problema.

Pruebe a realizar una implementación local para probar y depurar los modelos localmente antes de realizar la implementación en la nube.

ERROR: OutOfQuota

Los siguientes recursos podrían quedarse sin cuota al usar servicios de Azure:

Solo en el caso de los puntos de conexión en línea de Kubernetes, el recurso de Kubernetes también podría quedarse sin cuota.

Cuota de CPU

Para implementar un modelo, necesita tener suficiente cuota de recursos computacionales. La cuota de CPU define la cantidad de núcleos virtuales que hay disponibles por suscripción, área de trabajo, SKU y región. Cada implementación resta de la cuota disponible y la agrega después de la eliminación, en función del tipo de SKU.

Puede comprobar si hay implementaciones sin usar que se puedan eliminar, o bien puede solicitar un aumento de cuota.

Cuota de clúster

El error OutOfQuota se produce cuando no se dispone de suficiente cuota de clústeres de proceso de Azure Machine Learning. Esta cuota define el número total de clústeres por suscripción que se pueden usar simultáneamente para implementar nodos de CPU o GPU en la nube de Azure.

Cuota de disco

El error OutOfQuota aparece cuando el tamaño del modelo es mayor que el espacio en disco disponible, lo que impide que se descargue el modelo. Pruebe a usar una SKU con más espacio en disco o reduzca el tamaño de la imagen y del modelo.

Cuota de memoria

El error OutOfQuota aparece 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 se 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 alcanza el límite de asignación de roles, intente eliminar algunas asignaciones de roles sin usar en esta suscripción. Para comprobar todas las asignaciones de roles, seleccione Control de acceso en su suscripción de Azure en Azure Portal.

Cuota de punto 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, pruebe a 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.

Kubernetes quota

El error OutOfQuota aparece 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 estar acordonados, o no estar disponibles por cualquier otro motivo.

El mensaje de error habitualmente indica la insuficiencia de recursos en el clúster, por ejemplo, OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Este mensaje significa que hay demasiados pods en el clúster y que no hay suficientes recursos para implementar el nuevo modelo en función de su solicitud.

Para afrontar este problema, puede probar las siguientes mitigaciones:

  • Los operadores de TI que mantienen el clúster Kubernetes puede intentar agregar 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 probar a reducir la solicitud de recursos de la implementación.

    • Si define directamente la solicitud de recursos en la configuración de la implementación en la sección de recursos, intente reducir la solicitud de recursos.
    • Si usa instance_type para definir un recurso para la implementación del modelo, póngase en contacto con el operador de TI para ajustar la configuración de recursos del tipo de instancia. Para más información, consulte Creación y administración de tipos de instancias.

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. Vuelva a intentarlo más adelante o intente realizar la implementación en otra región.

Otras cuotas

Para ejecutar el archivo score.py que proporciona como parte de la implementación, Azure crea un contenedor que incluye todos los recursos que score.py necesita. Luego, Azure Machine Learning ejecuta el script de puntuación en ese contenedor. Si el contenedor no se puede iniciar, no se puede realizar la puntuación. Puede que el contenedor solicite más recursos de los que instance_type puede admitir. Considere la posibilidad de actualizar la instance_type de la implementación en línea.

Para conocer el motivo exacto del error, realice la siguiente acción.

Ejecute el siguiente comando:

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

ERROR: ArgumentoIncorrecto

Este error puede aparecer al usar tanto puntos de conexión en línea administrados como puntos de conexión en línea de Kubernetes por los siguientes motivos:

Este error también puede aparecer cuando se usan solo puntos de conexión en línea de Kubernetes, por los siguientes motivos:

La suscripción no existe

La suscripción de Azure a la que se hace referencia debe existir y estar activa. Este error se produce cuando Azure no encuentra el identificador de suscripción especificado. El error puede deberse a un error tipográfico en el identificador de la suscripción. Compruebe que el identificador de suscripción se ha especificado correctamente y que está activo actualmente.

Error de autorización

Después de aprovisionar el recurso de proceso al crear una implementación, Azure extrae la imagen de contenedor de usuario del registro de contenedor del área de trabajo y monta el modelo de usuario y los artefactos de código en el contenedor de usuarios desde la cuenta de almacenamiento del área de trabajo. Azure utiliza identidades administradas para acceder tanto a la cuenta de almacenamiento como al registro de contenedor.

Si crea el punto de conexión asociado con una identidad asignada por el usuario, la identidad administrada del usuario debe tener el permiso de lector de datos de Storage Blob en la cuenta de almacenamiento del área de trabajo y el permiso de AcrPull en el registro de contenedores del área de trabajo. Asegúrese de que la identidad asignada por el usuario tenga los permisos correctos.

Cuando MDC está habilitado, la identidad administrada del usuario debe tener el permiso Colaborador de datos de Storage Blob en la cuenta de almacenamiento del área de trabajo. Para obtener más información, consulte Error de autorización de blobs de almacenamiento cuando MDC está habilitado.

Si crea el punto de conexión asociado con la 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. Para más información, consulte Error de autorización del registro de contenedor.

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 tanto el nombre de la asignación de la directiva como la definición de la directiva para ayudarle a depurar este error. Para obtener sugerencias para evitar errores de plantilla, consulte Conceptos básicos de la estructura de definiciones de Azure Policy.

No se puede descargar la imagen del contenedor de usuario

Es posible que no se encuentre el contenedor de usuarios. Para más detalles, compruebe los registros del contenedor.

Asegúrese de que la imagen del contenedor está disponible en el registro de contenedor del área de trabajo. Por ejemplo, si la imagen es testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, puede usar el siguiente comando para comprobar el repositorio:

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. Para más detalles, compruebe los registros del contenedor. Asegúrese de que ha 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, realice la siguiente acción. Debe especificar la versión o etiqueta para obtener la información del modelo.

Ejecute el siguiente comando:

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

Compruebe también 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 el siguiente comando para comprobar si existe:

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

Si el blob existe, puede usar el siguiente 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`

No se admite el formato del modelo de MLflow con red privada

No puedes usar la característica de red privada con un formato de modelo de MLflow si estás utilizando el método de aislamiento de red heredado para los puntos de conexión en línea administrados. Si necesita implementar un modelo de MLflow con el enfoque de implementación sin código, pruebe a usar una 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, Azure Machine Learning establece los valores predeterminados al asociar el proceso a un área de trabajo. Los límites se pueden consultar en Azure Portal o mediante el comando az ml compute show.

Azureml-fe no está listo

El componente azureml-fe del front-end que enruta las solicitudes de inferencia entrantes a los servicios implementados se instala durante la instalación de la extensión k8s-extension y se escala automáticamente a medida que sea necesario. Este componente debe tener al menos una réplica saludable en el clúster.

Este error aparece si el componente no está disponible al desencadenar un punto de conexión en línea de Kubernetes o una solicitud de creación o actualización de una implementación. Para corregir este problema, compruebe el estado del pod y los registros. También puede intentar actualizar la extensión k8s-extension instalada en el clúster.

ERROR: ResourceNotReady

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

  • Hay un error en score.py. Use get-logs para diagnosticar los problemas comunes, como:

    • Un paquete que score.py intenta importar que no está incluido en el entorno de Conda
    • Un error de sintaxis
    • Un error en el método init()

    Si get-logs no genera registros, normalmente significa que el contenedor no se ha iniciado. Para depurar este problema, pruebe a realizar una implementación local.

  • Los sondeos de preparación o ejecución no están configurados correctamente.

  • La inicialización del contenedor tarda demasiado tiempo, por lo que el sondeo de preparación o ejecución produce 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 admitida más grande, lo que acelera la inicialización.

  • Hay un error en la configuración del entorno del contenedor, como una dependencia que falta.

    Cuando aparezca el error TypeError: register() takes 3 positional arguments but 4 were given, compruebe la dependencia entre flask v2 y azureml-inference-server-http. Para más información, consulte Solución de problemas del servidor HTTP.

ERROR: RecursoNoEncontrado

Este error aparece al usar tanto un punto de conexión en línea administrado como un punto de conexión en línea de Kubernetes por los siguientes motivos:

Resource Manager no encuentra un recurso

Este error se produce cuando Azure Resource Manager no encuentra un recurso necesario. Por ejemplo, este error puede aparecer si no se encuentra una cuenta de almacenamiento en la ruta de acceso especificada. Revise la ruta de acceso o las especificaciones de nombre para verificar la precisión y la ortografía. Para más información, consulte Resolución de errores en Recurso no encontrado.

Error de autorización del registro de contenedor

Este error aparece cuando se proporciona una imagen que pertenece a un registro de contenedor privado, o al que no se puede acceder por cualquier otro motivo, para la implementación. Las API de Azure Machine Learning no pueden aceptar credenciales de registro privadas.

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

  1. Conceda el rol de acrPull del registro privado a la identidad del sistema del punto de conexión en línea.
  2. En la definición del entorno, especifique la dirección de su imagen privada e indique que no modifique ni construya la imagen.

Si esta 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 más información de diagnóstico, consulte Uso del diagnóstico del área de trabajo.

ERROR: WorkspaceManagedNetworkNotReady

Este error se produce al intentar crear una implementación en línea que habilita una red virtual administrada del área de trabajo, pero la red no está aprovisionada. Prepare la red virtual administrada del área de trabajo antes de realizar una implementación en línea.

Para aprovisionar manualmente la red virtual administrada del área de trabajo, siga las instrucciones que encontrará en Aprovisionamiento manual de una VNET administrada. A partir de ese momento puede empezar a crear implementaciones en línea. Para obtener más información, consulte Aislamiento de red con un punto de conexión en línea administrado y Protección de los puntos de conexión en línea administrados con aislamiento de red.

ERROR: Operación cancelada

Este error aparece al usar tanto un punto de conexión en línea administrado como un punto de conexión en línea de Kubernetes por los siguientes motivos:

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 con una prioridad más alta invalida la suya. El reintento de la operación podría permitir que se realizara 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 encuentran condiciones de carrera. Este error se produce cuando la operación enviada es la misma que otra operación. En la actualidad, la otra operación espera la confirmación de que ha recibido el bloqueo para poder continuar.

Puede haber enviado una solicitud similar demasiado pronto después de la solicitud inicial. Volver a intentar la operación después de esperar hasta un minuto podría permitir 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 los almacenes de claves. Este problema se produce por uno de los siguientes motivos:

  • La identidad del punto de conexión no tiene permiso de RBAC de Azure para leer los secretos de las conexiones del área de trabajo o los almacenes de claves, aunque la definición de implementación especificó los secretos como referencias asignadas a variables de entorno. La asignación de roles puede tardar tiempo en que los cambios surtan efecto.

  • El formato de las referencias secretas no es válido o los secretos especificados no existen en las conexiones del área de trabajo ni 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

Este error significa que hay algún problema con Azure Machine Learning Service que debe corregirse. Envíe un incidencia de soporte al cliente con toda la información necesaria para solucionar el problema.

Errores comunes específicos de las implementaciones de Kubernetes

Errores de identidad y autenticación:

Errores de Crashloopbackoff:

Errores de script de puntuación:

Otros errores:

ERROR: ACRSecretError

Al crear o actualizar las implementaciones en línea de Kubernetes, este error puede aparecer por uno de los siguientes motivos:

  • No se ha completado la asignación de roles. Espere unos segundos y vuelva a intentarlo.

  • El clúster de Kubernetes habilitado para Azure Arc o la extensión Azure Machine Learning de AKS no están instalados o configurados correctamente. Compruebe la configuración y el estado de la extensión de Kubernetes habilitado para 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.

  • Su clúster de AKS privado no tiene los puntos de conexión adecuados. Asegúrese de configurar puntos de conexión privados para Container Registry, la cuenta de almacenamiento y el área de trabajo en la red virtual de AKS.

  • La versión de la extensión de Azure Machine Learning es la 1.1.25, o alguna inferior. Asegúrese de que la versión de la extensión sea mayor que la 1.1.25.

ERROR: TokenRefreshFailed

Este error ocurre porque la identidad del clúster de Kubernetes no está establecida correctamente; por lo tanto, la extensión no puede obtener una credencial de entidad principal de Azure. Vuelva a instalar la extensión de Azure Machine Learning e inténtelo de nuevo.

ERROR: GetAADTokenFailed

Este error aparece porque la solicitud por parte del clúster de Kubernetes de un token de Microsoft Entra ID no se ha realizado o ha superado el tiempo de espera. Compruebe el acceso de red y vuelva a intentarlo.

  • Siga las instrucciones que encontrará en Uso del proceso de Kubernetes para comprobar el proxy de salida y asegurarse de que el clúster puede conectarse al área de trabajo. Puede encontrar la dirección URL del punto de conexión del área de trabajo en la definición de recursos personalizados (CRD) del punto de conexión en línea en el clúster.

  • Compruebe si el área de trabajo permite el acceso público. Independientemente de si el propio clúster de AKS es público o privado, si un área de trabajo privada deshabilita el acceso de red público, el clúster de Kubernetes solo puede comunicarse con esa área de trabajo a través de un vínculo privado. Para más información, consulte ¿Qué es un entorno de inferencia de AKS seguro?

ERROR: Reto de Autenticación ACR Fallido

Este error se produce porque el clúster de Kubernetes no puede acceder al servicio Container Registry del área de trabajo para realizar un desafío de autenticación. Compruebe la red, sobre todo el acceso de red público de Container Registry, y vuelva a intentarlo. Puede seguir los pasos de solución de problemas en GetAADTokenFailed para comprobar la red.

ERROR: ACRTokenExchangeFailed

Este error ocurre porque el token de Microsoft Entra ID aún no está autorizado, por lo que falla el intercambio del token del registro de contenedor del clúster de Kubernetes. La asignación de roles tarda un tiempo en llevarse a cabo, así que espere un minuto y vuelva a intentarlo.

Este error también puede deberse a que hay demasiadas solicitudes simultáneas al servicio Container Registry. Este error debería ser transitorio y puede volver a intentarlo más tarde.

ERROR: KubernetesUnaccessible

Es posible que aparezca 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 mitigar este error, puede rotar el certificado de AKS para el clúster. El nuevo certificado debería actualizarse al cabo de 5 horas, por lo que puede esperar 5 horas para volver a implementarlo. Para más información, consulte Rotación de certificados en Azure Kubernetes Service (AKS).

ERROR: ImagePullLoopBackOff

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque no puede descargar las imágenes del registro de contenedor, lo que provoca un error en la extracción de imágenes. Revise la política de red del clúster y el registro de contenedores del espacio de trabajo para verificar si el clúster puede extraer imágenes de allí.

ERROR: DeploymentCrashLoopBackOff

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque el contenedor de usuarios se bloqueó 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 que genera excepciones al inicializarse.
  • El pod de implementación necesita más memoria que su límite.

Para mitigar este error, primero debes comprobar los registros de implementación para ver si hay excepciones en los scripts de usuario. Si el error no desaparece, intente ampliar el límite de memoria del tipo de instancia o recurso.

ERROR: KubernetesCrashLoopBackOff

Este error puede aparecer al crear o actualizar implementaciones o puntos de conexión en línea de Kubernetes por uno de los siguientes motivos:

  • Uno o varios pods se bloquean en estado CrashLoopBackoff. Compruebe si el registro de implementación existe y si hay mensajes de error en él.
  • Hay un error en score.py y el contenedor se ha bloqueado al inicializar el código de puntuación. Siga las instrucciones de ERROR: ResourceNotReady.
  • El proceso de puntuación necesita más memoria que el límite de configuración de implementación. Puede intentar actualizar la implementación y establecer un límite de memoria mayor.

ERROR: NamespaceNotFound

Es posible que reciba este error al crear o actualizar puntos de conexión en línea de Kubernetes porque el espacio de nombres que usa el proceso de Kubernetes no está disponible en el clúster. Revise la computación de Kubernetes en el portal de su área de trabajo y verifique el espacio de nombres en su clúster de Kubernetes. Si el espacio de nombres no está disponible, desasocie el recurso de computación heredado y vuelva a asociarlo para crear un nuevo espacio de nombres, especificando uno que ya existe en el clúster.

ERROR: UserScriptInitFailed

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque la función init del archivo score.py cargado generó una excepción. Compruebe los registros de implementación para ver los detalles del mensaje de la excepción y corregir la excepción.

ERROR: UserScriptImportError

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque el archivo score.py que ha cargado importa paquetes no disponibles. Compruebe los registros de implementación para ver los detalles del mensaje de la excepción y corregir la excepción.

ERROR: UserScriptFunctionNotFound

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque el archivo score.py que ha cargado no tiene ninguna función denominada init() o run(). Comprueba el código y agrega la función.

ERROR: EndpointNotFound

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque el sistema no encuentra el recurso del punto de conexión de la implementación en el clúster. Cree la implementación en un punto de conexión existente, o bien cree este punto de conexión primero en el clúster.

ERROR: El punto final ya existe

Este error puede aparecer al crear un punto de conexión en línea de Kubernetes 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, así que debe crear un punto de conexión con otro nombre.

ERROR: ScoringFeUnhealthy

Este error puede aparecer al crear o actualizar una implementación o un punto de conexión en línea de Kubernetes, ya que el servicio del sistema azureml-fe que se ejecuta en el clúster no se encuentra o está en mal estado. Para mitigar este problema, vuelva a instalar o actualice la extensión de Azure Machine Learning en el clúster.

ERROR: ValidateScoringFailed

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque se produjo un error en la validación de la dirección URL de solicitud de puntuación al procesar el modelo. Compruebe la dirección URL del punto de conexión y, después, vuelva a intentar realizar la implementación.

ERROR: InvalidDeploymentSpec

Este error puede aparecer al crear o actualizar implementaciones en línea de Kubernetes porque la especificación de la implementación no es válida. Compruebe el mensaje de error para asegurarse de que instance count es válido. Si ha habilitado la escalabilidad automática, asegúrese de que tanto minimum instance count como maximum instance count son válidos.

ERROR: PodUnschedulable

Este error puede aparecer al crear o actualizar implementaciones o puntos de conexión en línea de Kubernetes por uno de los siguientes motivos:

  • El sistema no puede programar el pod en los nodos debido a que no hay recursos suficientes en el clúster.
  • Ninguno de los nodos coincide con el selector de afinidad de nodos.

Para solucionar el error, siga estos pasos:

  1. 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.
  2. Compruebe el 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 habilitado para Azure Arc.
  3. Si el clúster tiene pocos recursos, reduzca el requisito de recursos del tipo de instancia o use otro tipo de instancia que tenga menos requisitos de recursos.
  4. Si el clúster no tiene más recursos para cumplir el requisito de la implementación, elimine algunas implementaciones para liberar recursos.

ERROR: PodOutOfMemory

Este error puede aparecer al crear o actualizar una implementación en línea porque el límite de memoria que asignó para la implementación no es suficiente. Para solucionarlo, puede establecer un valor mayor como límite de memoria, o bien usar un tipo de instancia mayor.

ERROR: InferencingClientCallFailed

Es posible que reciba este error al crear o actualizar puntos de conexión o implementaciones en línea de Kubernetes porque la extensión k8s del clúster de Kubernetes no se puede conectar. En este caso, desasocie y vuelva a adjuntar el proceso.

Para solucionar errores mediante una nueva asociación, asegúrese de volver a realizar la asociación con la misma configuración que el proceso desasociado, como el nombre de proceso y el espacio de nombres, ya que así se evitan otros posibles errores. Si sigue sin funcionar, pida 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 consumo de modelos

Los errores comunes de consumo de modelos derivados del estado de la operación invoke del punto de conexión incluyen problemas de límite de ancho de banda, la directiva de CORS y varios códigos de estado HTTP.

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. La configuración del límite se puede encontrar 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 del ancho de banda, use la métrica Bytes de red para conocer el uso actual del ancho de banda. Para más información, consulte Supervisión de puntos de conexión en línea administrados.

Se devuelven dos finalizadores de respuesta si se aplica el límite de ancho de banda:

  • ms-azureml-bandwidth-request-delay-ms es el tiempo de retraso, en milisegundos, que tardó en transferirse el flujo de la solicitud.
  • ms-azureml-bandwidth-response-delay-ms es el tiempo de retraso, en milisegundos, que tardó en transferirse el flujo de la respuesta.

Bloqueado por la directiva de CORS

Los puntos de conexión en línea V2 no admiten Intercambio de Recursos de Origen Cruzado (CORS) de forma nativa. Si una aplicación web intenta invocar el punto de conexión sin el control adecuado de las solicitudes preparatorias 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.

Puede usar Azure Functions, Azure Application Gateway u otro servicio como capa provisional para controlar las solicitudes preparatorias de CORS.

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. En las secciones siguientes se muestran detalles sobre cómo se asignan los errores de invocación y predicción del punto 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 que aparecen cuando las solicitudes de REST consumen puntos de conexión en línea administrados:

código de estado Motivo Descripción
200 Aceptar El modelo se ejecutó correctamente dentro de los límites de latencia.
401 No autorizado No tiene permiso para realizar la acción solicitada, como calificación, o su token ha expirado o está en el formato incorrecto. Para más información, consulte Autenticación para puntos de conexión en línea administrados y Autenticación de clientes para puntos de conexión en línea.
404 No encontrado El punto de conexión no tiene ninguna implementación válida con un 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 de Requests Per Minute en el punto de conexión Explorador de métricas de Azure Monitor. 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 ProbeSettings 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. Para garantizar un funcionamiento sin problemas, Azure Machine Learning permite procesar un máximo de 2 * max_concurrent_requests_per_instance * instance_count requests en paralelo en un momento dado. Las solicitudes que superen este máximo se rechazan.

Puede examinar la configuración de la implementación del modelo en las secciones request_settings y scale_settings para comprobar y ajustar estos valores. Asegúrese también de que la variable de entorno WORKER_COUNT se usa correctamente, como se describe en RequestSettings.

Si aparece este error cuando usa la escalabilidad automática, significa que el modelo recibe solicitudes más rápidamente de lo que el sistema puede escalarse verticalmente. Considere la posibilidad de volver a enviar las solicitudes con un retroceso exponencial para dar tiempo al sistema para realizar el ajuste. También puede aumentar el número de instancias mediante el código para calcular el recuento de instancias. Combine estos pasos con la configuración de la escalabilidad automática para tener la certeza absoluta 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 de los puntos de conexión en línea de Kubernetes

La tabla siguiente contiene códigos de error que suelen aparecer cuando solicitudes REST consumen puntos de conexión en línea de Kubernetes:

código de estado Error Descripción
409 Error de conflicto Cuando una operación ya está en curso, cualquier operación nueva que se realice en ese mismo punto de conexión en línea responde con un error de conflicto 409. Por ejemplo, si una operación de creación o actualización de un punto de conexión en línea está en curso y se desencadena una nueva operación de eliminación, se produce un error.
502 Excepción o bloqueo en el método run() del archivo score.py Cuando haya un error en score.py, por ejemplo, un paquete importado que no existe en el entorno de Conda, un error de sintaxis o un error en el método init(), consulte ERROR: ResourceNotReady para depurar el archivo.
503 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 llegar a 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. Consulte Cómo evitar errores de código de estado 503.
504 Se agota el tiempo de espera de la solicitud Un código de estado 504 indica que se ha superado el tiempo de expiración de la solicitud. El valor predeterminado del tiempo de expiración es 5 segundos. Puede aumentar este tiempo o intentar acelerar el punto de conexión modificando el archivo score.py para quitar llamadas innecesarias. Si estas acciones no corrigen el problema, podría deberse a que el código está en un estado de no respuesta o en un bucle infinito. Siga ERROR: ResourceNotReady para depurar el archivo score.py.
500 Error interno del servidor Se produce un error en la infraestructura aprovisionada de Azure Machine Learning.

Cómo evitar errores del código de estado 503

Las implementaciones en línea de Kubernetes admiten la escalabilidad automática, que permite agregar réplicas para admitir la carga adicional. Para más información, consulte Router de inferencia de Azure Machine Learning. La decisión de escalar o reducir verticalmente se basa en el uso de las réplicas de contenedor actuales.

Hay dos acciones pueden ayudar a evitar errores de código de estado 503: cambiar el nivel de uso para crear réplicas, o bien cambiar el número mínimo de réplicas. Estos métodos se pueden usar individualmente o en combinación.

  • Cambie el destino de uso en el que la escalabilidad automática crea réplicas seleccionando un valor inferior en autoscale_target_utilization. Este cambio no hace que las réplicas se creen más rápidamente, sino que se crean con un umbral de utilización inferior. Por ejemplo, si se cambia el valor a un 30 %, las réplicas se crearán cuando haya un 30 % de utilización, en lugar de esperar a que el nivel de utilización del registro sea de un 70 %.

  • Cambie el número mínimo de réplicas para proporcionar un grupo mayor que pueda controlar los picos entrantes.

Cálculo del recuento de instancias

Para aumentar el número de instancias, puede calcular las réplicas necesarias de la siguiente manera:

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 mayores que las nuevas réplicas mínimas pueden controlar, puede recibir 503 de nuevo. 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.

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 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.

Problemas de aislamiento de red

En esta sección encontrará información sobre los 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 sobre el modo heredado v1

Los puntos de conexión en línea administrados son una característica de la plataforma de API de Azure Machine Learning v2. Si el área de trabajo de Azure Machine Learning está configurada para el modo heredado v1, los puntos de conexión en línea administrados no funcionan. Específicamente, si la configuración del v1_legacy_mode workspace está establecida en true, el modo heredado v1 está activado y no se admite compatibilidad con las API v2.

Para ver cómo desactivar el modo heredado v1, consulte Cambio de aislamiento de red con nuestra nueva plataforma de API en Azure Resource Manager.

Importante

Consulte con su equipo de seguridad de red antes de cambiar v1_legacy_mode a false, porque el modo heredado v1 podría estar activado por un motivo.

Se produce un error en la creación de puntos de conexión en línea con autenticación basada en claves

Utilice el siguiente comando para listar las reglas de red del Azure Key Vault para su área de trabajo. Reemplace <key-vault-name> por el nombre del almacén de claves.

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

La respuesta para este comando es similar al siguiente código JSON:

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

Si el valor de bypass no es AzureServices, use las instrucciones de Configurar configuración de red de Azure Key Vault 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 este método, Azure Machine Learning crea una red virtual administrada para cada implementación en un punto de conexión.

  1. Compruebe si la egress-public-network-access marca tiene un valor de disabled para la implementación. Si esta opción está habilitada y la visibilidad del registro de contenedor es privada, este fallo es esperado.

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

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

    En el código de respuesta, compruebe que en el campo status se ha seleccionado Approved. Si el valor no es Approved, use el siguiente comando para aprobar la conexión. Reemplace por <private-endpoint-connection-ID> el identificador que devuelve el comando anterior.

    az network private-endpoint-connection approve --id <private-endpoint-connection-ID> --description "Approved"

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 nslookup comando en el nombre de host del punto de conexión para recuperar la información de la dirección IP:

    nslookup <endpoint-name>.<endpoint-region>.inference.ml.azure.com

    Por ejemplo, el comando podría tener un aspecto similar al siguiente:

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

    La respuesta contiene una dirección que debe estar en el rango 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) especificado en el clúster de Kubernetes.
    • Si el punto de conexión usa HTTP, la dirección IP se encuentra en el URI del punto de conexión, que puede obtener de la interfaz de usuario de Studio.
    • Para obtener más formas de obtener la dirección IP del punto de conexión, consulte Actualización del DNS con un FQDN.

  3. Si el nslookup comando no resuelve el nombre de host, realice las acciones de una de las secciones siguientes.

Puntos de conexión en línea administrados

  1. Use el siguiente comando para comprobar si existe un registro A en la zona privada del sistema de nombres de dominio (DNS) de la red virtual.

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

    Los resultados deberían 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 usa un servidor DNS personalizado, ejecute el siguiente comando para comprobar que la resolución del servidor DNS personalizado funciona correctamente:

    dig <endpoint-name>.<endpoint-region>.inference.ml.azure.com

Puntos de conexión en línea de Kubernetes

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

  2. Compruebe si el enrutador de inferencia de Azure Machine Learning, azureml-fe, funciona según lo previsto. Para realizar esta comprobación, siga estos pasos:

    1. Ejecute el siguiente comando en el azureml-fe pod:

      kubectl exec -it deploy/azureml-fe -- /bin/bash

    2. Ejecute uno de los siguientes comandos:

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

      En el caso de HTTP, use el siguiente comando:

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

  3. Si se produce un error en el comando HTTPS de curl o se agota el tiempo de espera, pero el comando HTTP funciona, compruebe si el certificado es válido.

  4. Si el proceso anterior no se resuelve en el registro A, use el siguiente comando para comprobar si la resolución funciona desde la dirección IP pública virtual de Azure DNS, 168.63.129.16:

    dig @168.63.129.16 <endpoint-name>.<endpoint-region>.inference.ml.azure.com

  5. Si el comando anterior se ejecuta correctamente, solucione los problemas del reenviador condicional para Azure Private Link en un DNS personalizado.

No se pueden puntuar las implementaciones en línea

  1. Ejecute el comando siguiente para ver el estado de una implementación que no se puede puntuar:

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

    Un valor de Succeeded para el state campo indica una implementación correcta.

  2. Para una implementación correcta, use el siguiente comando para comprobar que el tráfico está asignado a la implementación:

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

    La respuesta de este comando debe enumerar el porcentaje de tráfico asignado a cada implementación.

    Sugerencia

    Este paso no es necesario si se usa el encabezado azureml-model-deployment en la solicitud cuyo objetivo es esta implementación.

  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:

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

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

Problemas del servidor de inferencia

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

Compruebe los paquetes instalados

Siga estos pasos para solucionar problemas con los paquetes instalados:

  1. Recopile información sobre los paquetes instalados y las versiones del entorno de Python.

  2. En el archivo de entorno, compruebe la versión del azureml-inference-server-http paquete de Python especificado. En los registros de inicio del servidor HTTP de inferencia de Azure Machine Learning, compruebe la versión del servidor de inferencia que se muestra. Confirme que las dos versiones coinciden.

    En algunos casos, el solucionador de dependencias pip instala versiones de paquete inesperadas. Es posible que tenga que ejecutar pip para corregir los paquetes y versiones instalados.

  3. Si especifica Flask o sus dependencias en su entorno, elimine esos elementos.

    • Los paquetes dependientes incluyen flask, jinja2, itsdangerous, werkzeug, markupsafe y click.
    • El flask paquete se muestra como una dependencia en el paquete del servidor de inferencia. El mejor enfoque es permitir que el servidor de inferencia instale el paquete flask.
    • Cuando el servidor de inferencia está configurado para admitir nuevas versiones de Flask, el servidor de inferencia recibe automáticamente las actualizaciones del paquete a medida que están disponibles.

Comprobación de la versión del servidor de inferencia

El paquete de servidor azureml-inference-server-http se publica en PyPI. En la página PyPI se muestra el registro de cambios y todas las versiones del paquete.

Si usa una versión temprana del paquete, actualice la configuración a la versión más reciente. En la tabla siguiente se resumen las versiones estables, los problemas comunes y los ajustes recomendados:

Versión del paquete Descripción Problema Resolución
0.4.x Agrupado en imágenes de entrenamiento con fecha 20220601 o versiones anteriores y azureml-defaults de paquetes 0.1.34 a 1.43. La versión estable más reciente es 0.4.13. En el caso de las versiones de servidor anteriores a 0.4.11, es posible que encuentre problemas de dependencia de Flask, como can't import name Markup from jinja2. Actualice a la versión 0.4.13 o 1.4.x, la versión más reciente, si es posible.
0.6.x Preinstalado en imágenes de inferencia con fecha de 20220516 y versiones anteriores. La versión estable más reciente es 0.6.1. No disponible No disponible
0.7 x Admite Flask 2. La versión estable más reciente es 0.7.7. No disponible No disponible
0.8.x Usa un formato de registro actualizado. Finaliza la compatibilidad con Python 3.6. No disponible No disponible
1.0.x Finaliza la compatibilidad con Python 3.7. No disponible No disponible
1.1.x Migra a pydantic 2.0. No disponible No disponible
1.2.x Agrega compatibilidad con Python 3.11. Actualiza gunicorn a la versión 22.0.0. Actualiza werkzeug a la versión 3.0.3 y versiones posteriores. No disponible No disponible
1.3.x Agrega compatibilidad con Python 3.12. certifi Se actualiza a la versión 2024.7.4. flask-cors Actualiza a la versión 5.0.0. Actualiza los paquetes gunicorn y pydantic. No disponible No disponible
1.4.x waitress Actualiza a la versión 3.0.1. Finaliza la compatibilidad con Python 3.8. Quita la capa de compatibilidad que evita que la actualización de Flask 2.0 rompa el código del objeto de solicitud. Si depende de la capa de compatibilidad, es posible que el código del objeto de solicitud no funcione. Migre el script de puntuación a Flask 2.

Comprobar dependencias del paquete

Los paquetes dependientes más relevantes para el paquete de servidor azureml-inference-server-http incluyen:

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

Si especifica el paquete azureml-defaults en su entorno de Python, el paquete azureml-inference-server-http es un paquete dependiente. La dependencia se instala automáticamente.

Sugerencia

Si utiliza el SDK de Azure Machine Learning para Python v1 y no especifica explícitamente el paquete en el entorno de Python, el SDK podría agregar automáticamente el paquete. Sin embargo, la versión del paquete está bloqueada en relación con la versión del SDK. Por ejemplo, si la versión del SDK es 1.38.0, la azureml-defaults==1.38.0 entrada se agrega a los requisitos pip del entorno.

TypeError durante el inicio del servidor de inferencia

Es posible que encuentre lo siguiente TypeError durante el inicio del servidor de inferencia:

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

Este error se produce cuando tiene Flask 2 instalado en el entorno de Python, pero la versión del paquete azureml-inference-server-http no es compatible con Flask 2. La compatibilidad con Flask 2 está disponible en el azureml-inference-server-http paquete 0.7.0 y versiones posteriores, y el azureml-defaults paquete 1.44 y versiones posteriores.

  • Si no usa el paquete Flask 2 en una imagen de Docker de Azure Machine Learning, use la versión más reciente del paquete de azureml-inference-server-http o azureml-defaults.

  • Si usa el paquete flask 2 en una imagen de Docker de Azure Machine Learning, confirme que la versión de compilación de la imagen es July 2022 o posterior.

    La versión de la imagen la pueden encontrar en los registros del contenedor. Por ejemplo, consulte las siguientes declaraciones de registro:

    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, Materialization 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 la notación Materialization Build. En el ejemplo anterior, la versión de la imagen es 20220708, o el 8 de julio de 2022. La imagen de este ejemplo es compatible con Flask 2.

    Si no ve un mensaje similar en el log de su contenedor, su imagen está desactualizada y debe actualizarse. Si usa una imagen de arquitectura de dispositivo unificado de proceso (CUDA) y no encuentra una imagen más reciente, compruebe el repositorio AzureML-Containers para ver si la imagen está en desuso. Puede encontrar reemplazos designados para imágenes en desuso.

    Si usa el servidor de inferencia con un punto de conexión en línea, también puede encontrar los registros en Azure Machine Learning Studio. En la página del punto de conexión, seleccione la pestaña Registros .

Si implementa con el SDK v1 y no especifica explícitamente una imagen en la configuración de implementación, el servidor de inferencia aplica el openmpi4.1.0-ubuntu20.04 paquete con una versión que coincida con el conjunto de herramientas del SDK local. Sin embargo, es posible que la versión instalada no sea la versión más reciente disponible de la imagen.

Para la versión 1.43 del SDK, el servidor de inferencia instala la openmpi4.1.0-ubuntu20.04:20220616 versión del paquete de forma predeterminada, pero esta versión del paquete no es compatible con SDK 1.43. Asegúrese de usar el SDK más reciente para la implementación.

Si no puede actualizar la imagen, puede evitar temporalmente el problema anclando las entradas azureml-defaults==1.43 o azureml-inference-server-http~=0.4.13 en el archivo de entorno. Estas entradas dirigen el servidor de inferencia para instalar la versión anterior con flask 1.0.x.

ImportError o ModuleNotFoundError durante el inicio del servidor de inferencia

Es posible que encuentre un ImportError o ModuleNotFoundError en módulos específicos, como opencensus, jinja2, markupsafe o click, durante el inicio del servidor de inferencia. En el ejemplo siguiente se muestra el mensaje de error:

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

Los errores de importación y módulo se producen cuando se usa la versión 0.4.10 o versiones anteriores del servidor de inferencia que no anclan la dependencia de Flask a una versión compatible. Para evitar el problema, instale una versión posterior del servidor de inferencia.

Otros problemas comunes

Otros problemas comunes de los puntos de conexión en línea tienen que ver con la instalación y la escalabilidad automática de Conda.

Problemas de instalación de Conda

Los problemas con la implementación de MLflow habitualmente se deben a problemas con la instalación del entorno de usuario especificado en el archivo conda.yml.

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 ha bloqueado 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.
    • La instalación del paquete de Conda se produce en tiempo de ejecución, por lo que si el tamaño de la SKU es demasiado pequeño para alojar todos los paquetes en el archivo de entorno conda.yml, el contenedor puede bloquearse.
    • Una máquina virtual tipo Standard_F4s_v2 es un buen tamaño de SKU inicial, pero es posible que necesite máquinas virtuales más grandes dependiendo de las dependencias que especifique el archivo de Conda.
    • En el caso del 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.

Problemas de escalado automático

Si tiene problemas con la escalabilidad automática, consulte Solución de problemas de escalabilidad automática de Azure Monitor.

En el caso de los puntos de conexión en línea de Kubernetes, el router de inferencia de Azure Machine Learning es un componente del front-end que controla la escalabilidad automática para todas las implementaciones de modelos en el clúster de Kubernetes. Para más información, consulte Escalabilidad automática del enrutamiento de inferencias de Kubernetes.

Contenido relacionado