Compartir por

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

  • Artigo

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 una incidencia de soporte técnico para una solicitud con error, adjunte el identificador de la solicitud con error 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 cuando llega a 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

Para depurar el script de puntuación localmente, también se puede usar el paquete de Python del servidor HTTP de inferencia de Azure Machine Learning. 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 se puede realizar localmente con la CLI de Azure o el SDK de Python. Estudio de Azure Machine Learning 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.

Obtención de 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 contiene la salida de las funciones de impresión y registro del código descore.py del script de puntuación.
  • 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.

Consulta de la salida del registro de los contenedores

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

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

Or

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. Para obtener registros del contenedor de inicializadores de almacenamiento, utilice –-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: ImageBuildFailure

Este error se devuelve cuando se compila el entorno de una imagen de Docker. Para más información al respecto, puede consultar el registro de compilación. 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 proceso de compilación de imágenes no se ha 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 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.

Tiempo de espera de compilación de imágenes

Los tiempos de expiración en la compilación de imágenes suelen deberse a que la imagen es demasiado grande para poder realizar la compilació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. Examine también la configuración de sondeo predeterminada si tiene tiempos de expiración 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 podría 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 poder implementar cualquier modelo, debe tener suficiente cuota de proceso. 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 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.

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

Cuota de Kubernetes

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. 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 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 el valor de 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: BadArgument

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 del contenedor de usuarios del registro de contenedor del área de trabajo y monta el modelo del usuario y los artefactos del 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 permiso de lector de datos de Storage Blob en la cuenta de almacenamiento del área de trabajo y el permiso AcrPull en el registro de contenedor del área de trabajo. Asegúrese de que la identidad asignada por el usuario tenga los permisos correctos.

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`

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

La característica de red privada con un formato de modelo de MLflow no se puede usar si se usa 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 correcta 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, ya que se supera el umbral de error. En este caso, ajuste la configuración del sondeo para permitir más tiempo para inicializar el contenedor. O bien, pruebe una SKU de máquina virtual admitida mayor, 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: ResourceNotFound

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. Vuelva a comprobar la ruta de acceso o las especificaciones de nombre para saber si es precisa y su 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 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 dé la instrucción necesaria para no modificar ni compilar la imagen.

Si esta mitigación se realiza correctamente, no hace falta compilar la imagen y la dirección final de la imagen es la 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. Aprovisione la red virtual administrada del área de trabajo antes de crear 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: OperationCanceled

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 que 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. Si vuelve a intentar la operación después de esperar menos de 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 problema se produce por uno de los siguientes motivos:

  • 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 o de los almacenes de claves, a pesar de que la definición de implementación especificara 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 de los secretos 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 una incidencia de soporte técnico 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 Azure Machine Learning o de Kubernetes habilitado para Azure Arc.

  • 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 se debe a que la identidad del clúster de Kubernetes no está establecida correctamente, y por eso la extensión no puede obtener una credencial de entidad de seguridad 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. La dirección URL del punto de conexión del área de trabajo la puede encontrar 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: ACRAuthenticationChallengeFailed

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 aparece porque el token de Microsoft Entra ID aún no está autorizado, por lo que se produce un error en el token de Container Registry del intercambio clústeres 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. Compruebe la directiva de red en clúster y el registro de contenedor del área de trabajo para ver si el clúster puede extraer imágenes del registro de contenedor.

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 que se ha configurado para la implementación. Puede intentar actualizar la implementación y establecer un límite de memoria mayor.

ERROR: NamespaceNotFound

Este error puede aparecer al crear o actualizar puntos de conexión en línea de Kubernetes porque el espacio de nombres que ha usado el proceso de Kubernetes no está disponible en el clúster. Compruebe el proceso de Kubernetes en el portal del área de trabajo y compruebe el espacio de nombres en el clúster de Kubernetes. Si el espacio de nombres no está disponible, desasocie el proceso heredado y vuelva a asociarlo para crear uno, y especifique un espacio de nombres 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: EndpointAlreadyExists

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, en el caso el clúster de AKS, o el recurso del nodo, en el caso del 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

Este error puede aparecer al crear o actualizar implementaciones o puntos de conexión en línea de Kubernetes porque la extensión k8s-extension del clúster de Kubernetes no se puede conectar. En ese caso, desasocie el proceso y vuelva a asociarlo.

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.

Problema 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 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 encontrará 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 que aparecen cuando las solicitudes de REST consumen puntos de conexión en línea administrados:

status code 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 puntuación, o el token ha expirado o está en el formato incorrecta. 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 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 en los sondeos de ejecución o preparación, considere la posibilidad de ajustar ProbeSettings para dar más tiempo para sondear la 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:

status code 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 de 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 Tiempo de espera de la solicitud agotado 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 contenedores 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, pero que se creen con un umbral de uso 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 el nuevo número mínimo de réplicas que puede controlar, es posible que vuelva a recibir un códigos de estado 503. 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 V1LegacyMode == true

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

Para deshabilitar v1_legacy_mode, consulte Aislamiento de red con v2.

Importante

Antes de deshabilitar v1_legacy_mode consúltelo con su equipo de seguridad de red, ya que puede que lo hayan habilitado por algún motivo.

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

Use el siguiente comando para usar la lista de reglas de red de la instancia de Azure Key Vault para su á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 código 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á disabled para la implementación. Si la 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 código de respuesta, compruebe que en el campo status se ha seleccionado Approved. Si no es así, 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, por ejemplo:

    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:

    • En el caso del 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 el punto de conexión es HTTP, la dirección IP se encuentra en el identificador URI del punto de conexión, que puede obtener desde la interfaz de usuario del estudio.
    • En Protección del punto de conexión en línea de Kubernetes, puede encontrar más formas de obtener la dirección IP del punto de conexión.

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

Puntos de conexión en línea administrados

  1. Use el siguiente comando para comprobar si existe un registro D en la zona privada del servidor 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 desde el DNS personalizado funciona correctamente.

dig endpointname.westcentralus.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 también si azureml-fe funciona como cabría esperar, para lo que debe usar 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"

    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 curl HTTPs no se ejecuta o supera el tiempo de expiración pero HTTP funciona, compruebe si el certificado es válido.

  4. Si el proceso anterior no resuelve el registro D, compruebe si la resolución funciona desde Azure DNS (168.63.129.16).

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

  5. Si el comando anterior hace que todo funcione correctamente, solucione los problemas del reenviador condicional del vínculo privado en el DNS personalizado.

No se pueden puntuar las implementaciones en línea

  1. Ejecute el siguiente comando para ver si la implementación se ha realizado correctamente:

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

    En ese caso, 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 de su punto de conexión.

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

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

    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 la implementación se han establecido 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>

  4. Examine los registros para ver si hay algún problema al ejecutar el código de puntuación cuando se envía 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 los problemas que puedan aparecer con los paquetes instalados.

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

  2. Confirme 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 Azure Machine Learning que se muestra en el registro de inicio.

    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 el entorno, quite estos elementos.

    • Los paquetes dependientes incluyen flask, jinja2, itsdangerous, werkzeug, markupsafe y click.
    • flask aparece como una dependencia en el paquete de servidor. 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 recibe automáticamente las actualizaciones del paquete a medida que están disponibles.

Comprobar versión del servidor

El paquete de servidor azureml-inference-server-http se publica en PyPI. La página PyPI enumera el registro de cambios y todas las versiones anteriores.

Si usa una versión anterior del paquete, actualice la configuración a la 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 Agrupadas en imágenes de entrenamiento con fecha de 20220601 o anterior y versiones .1.34 de paquete azureml-defaults a través de 1.43. La versión estable más reciente es 0.4.13. En las versiones del servidor anteriores a la 0.4.11, es posible que encuentre problemas de dependencia de Flask, como "can't import name Markup from jinja2". Realice la actualización a las versiones 0.4.13 o 0.8.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. N/D N/D
0.7.x Admite Flask 2. La versión estable más reciente es 0.7.7. N/D N/D
0.8.x Se ha cambiado el formato de registro. Finalizó la compatibilidad con Python 3.6. N/D N/D

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 especificó el paquete azureml-defaults en el entorno de Python, el paquete azureml-inference-server-http es dependiente. La dependencia se instala automáticamente.

Sugerencia

Si usa el SDK de Python v1 y no especifica explícitamente el paquete azureml-defaults en el entorno de Python, es posible que el SDK agregue automáticamente el paquete. Sin embargo, la versión del empaquetador está bloqueada en relación con la versión del SDK. Por ejemplo, si la versión del SDK es 1.38.0, la entrada azureml-defaults==1.38.0 se agrega a los requisitos pip del entorno.

TypeError durante el inicio del servidor

Es posible que encuentre los siguientes TypeError 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

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 la versión del paquete azureml-inference-server-http 0.7.0 y versiones posteriores, y la versión del paquete azureml-defaults 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 julio de 2022 o posterior.

    La versión de la imagen la pueden encontrar en los registros del contenedor. Por ejemplo:

    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 registro de contenedor, la imagen no está actualizada y debe actualizarse. Si usa una imagen de arquitectura de dispositivo unificado de proceso (CUDA) y no encuentra una imagen más reciente, compruebe si la imagen está en desuso en AzureML-Containers. Puede encontrar reemplazos designados para imágenes en desuso.

    Si usa el servidor con un punto de conexión en línea, también puede encontrar los registros en la sección Registros de la página Puntos de conexión de 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 servidor aplica el paquete openmpi4.1.0-ubuntu20.04 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 instala la versión del paquete openmpi4.1.0-ubuntu20.04:20220616 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 al servidor para instalar la versión anterior con flask 1.0.x.

ImportError o ModuleNotFoundError durante el inicio del servidor

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

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

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

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 de Standard_F4s_v2 es un buen tamaño de SKU inicial, pero es posible que necesite máquinas virtuales mayores en función 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