Solucionar problemas de implementación de modelos de Amazon SageMaker AI

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Si encuentra algún problema al implementar modelos de aprendizaje automático en Amazon SageMaker AI, consulte la siguiente guía.

Errores de detección en la cuenta de la CPU activa

Si despliega un modelo de SageMaker IA con una máquina virtual Java (JVM) de Linux, es posible que se produzcan errores de detección que impidan utilizar los recursos de CPU disponibles. Este problema afecta a algunos dispositivos JVMs compatibles con Java 8 y Java 9, y a la mayoría de los que admiten Java 10 y Java 11. Estos JVMs implementan un mecanismo que detecta y gestiona el número de CPU y la memoria máxima disponible cuando se ejecuta un modelo en un contenedor de Docker y, de manera más general, dentro de los taskset comandos o grupos de control (cgroups) de Linux. SageMaker Las implementaciones de IA aprovechan algunos de los ajustes que utiliza la JVM para administrar estos recursos. Actualmente, esto hace que el contenedor detecte incorrectamente el número de disponibles. CPUs

SageMaker La IA no limita el acceso CPUs a una instancia. Sin embargo, es posible que la JVM detecte el recuento de CPU 1 cuando haya más CPU CPUs disponibles para el contenedor. Como resultado, la JVM se ajusta toda la configuración interna para que se ejecute como si solo 1 núcleo de CPU está disponible. Esta configuración afecta a la recopilación de elementos no utilizados, bloqueos, subprocesos de compilador y otros elementos internos de la JVM que afectan negativamente a la simultaneidad, rendimiento y latencia del contenedor.

Como ejemplo de detección errónea, en un contenedor configurado para SageMaker IA que se implementa con una JVM basada en Java8_191 y que tiene cuatro disponibles en la instancia, ejecuta el siguiente CPUs comando para iniciar la JVM:

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintActiveCpus -version

Esto genera la salida siguiente:

active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Muchos de los JVMs afectados por este problema tienen la opción de deshabilitar este comportamiento y restablecer el acceso total a todos los componentes de la instancia. CPUs Deshabilite este comportamiento no deseado y establezca un acceso total a todas CPUs las instancias incluyendo el -XX:-UseContainerSupport parámetro al iniciar las aplicaciones Java. Por ejemplo, ejecute el comando java para iniciar su JVM tal y como se indica a continuación:

java -XX:-UseContainerSupport -XX:+UnlockDiagnosticVMOptions -XX:+PrintActiveCpus -version

Esto genera la salida siguiente:

active_processor_count: sched_getaffinity processor count: 4
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: sched_getaffinity processor count: 4
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Compruebe si la JVM que se usa en el contenedor es compatible con el parámetro -XX:-UseContainerSupport. En caso afirmativo, pase el parámetro siempre al iniciar la JVM. Esto proporciona acceso a todas CPUs las instancias.

También es posible que te encuentres con este problema cuando utilices indirectamente una JVM en contenedores de SageMaker IA. Por ejemplo, cuando se utiliza una JVM para admitir SparkML Scala. El parámetro -XX:-UseContainerSupport también afecta a la salida que devuelve la API Runtime.getRuntime().availableProcessors() de Java .

Problemas al implementar un archivo model.tar.gz

Al implementar un modelo mediante un archivo model.tar.gz, el tarball del modelo no debe incluir ningún symlink. Los symlinks provocan un error en la creación del modelo. Además, recomendamos que no incluya ningún archivo innecesario en el tarball.

El contenedor principal no superó las comprobaciones de estado de ping

Si el contenedor principal no supera las comprobaciones de estado de ping y aparece el siguiente mensaje de error, esto indica que hay un problema con el contenedor o el script:

The primary container for production variant beta did not pass the ping health check. Please check CloudWatch Logs logs for this endpoint.

Para solucionar este problema, deberías comprobar los CloudWatch registros de registro del terminal en cuestión para comprobar si hay algún error o problema que impida que el contenedor responda a /ping o. /invocations Los registros pueden incluir un mensaje de error que podría indicar el problema. Una vez que haya identificado el error y el motivo del mismo, debe resolverlo.

También es una buena práctica probar la implementación local del modelo antes de crear un punto de conexión.