Solucionar problemas de implementaciones de SageMaker modelos de Amazon

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

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

Si implementa un SageMaker modelo 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 algunas JVM compatibles con Java 8 y Java 9, así como la mayoría de compatibles con Java 10 y Java 11. Estas máquinas virtuales virtuales 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. SageMakerlas implementaciones aprovechan algunos de los ajustes que utiliza la JVM para administrar estos recursos. En la actualidad, esto hace que el contenedor detecte de forma incorrecta el número de CPU disponibles.

SageMaker no limita el acceso a las CPU de una instancia. Sin embargo, la JVM podría detectar el recuento de CPU como 1 cuando más CPU están 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 que se implemente con una JVM basada en Java8_191 y que tenga cuatro CPU disponibles en la instancia, ejecuta el siguiente 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)

Muchas de las JVM afectadas por este problema tiene una opción de deshabilitar este comportamiento y restablecer el acceso completo a todas las CPU de la instancia. Deshabilite el comportamiento no deseado y establezca acceso completo a todas las CPU de instancia incluyendo el parámetro -XX:-UseContainerSupport al iniciar 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 el acceso a todas las CPU en las instancias.

También es posible que se produzca este problema al utilizar indirectamente una JVM en contenedores. SageMaker 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.

• Usa el modo local en el SageMaker SDK para imitar el entorno hospedado implementando el modelo en un punto final local. Para obtener más información, consulte Modo local.

• Usa los comandos vanilla docker para probar si el contenedor responde a /ping e /invocations. Para obtener más información, consulte local_test.