Depuración de puntos finales de SageMaker con Docker.
SageMaker endpoint debugging with Docker.
Una alternativa a SageMaker Local Mode
Un problema al empezar con SageMaker Real-Time Inference es que a veces es difícil depurar. Al crear un punto final, hay varios elementos que debes asegurarte de que estén correctamente configurados para implementar con éxito.
- La estructura de archivos adecuada de los artefactos del modelo dependiendo del servidor de modelos y contenedor que estés utilizando. Esencialmente, el modelo.tar.gz que proporcionas debe estar en un formato que cumpla con el modelo del servidor.
- Si tienes un script de inferencia personalizado que implementa el procesamiento previo y posterior para tu modelo, debes asegurarte de que los manejadores implementados cumplan con tu servidor de modelos y que no haya errores de script a nivel de código.
Anteriormente, hemos hablado de SageMaker Local Mode, pero en el momento de escribir este artículo, Local Mode no admite todas las opciones de alojamiento y servidores de modelos que están disponibles para SageMaker Deployment.
Para superar esta limitación, veremos cómo usar Docker con un modelo de ejemplo y cómo podemos probar/depurar nuestros artefactos de modelo y script de inferencia antes de la implementación de SageMaker. En este ejemplo específico, utilizaremos el modelo BART que cubrí en mi último artículo y veremos cómo podemos alojarlo con Docker.
NOTA: para aquellos de ustedes que son nuevos en AWS, asegúrense de crear una cuenta en el siguiente enlace si quieren seguir los pasos. El artículo también asume un conocimiento intermedio de SageMaker Deployment, sugiero seguir este artículo para comprender mejor la implementación/inferencia. Un nivel intermedio de comprensión de Docker también será útil para comprender completamente este ejemplo.
¿Cómo funciona el alojamiento de SageMaker?
Antes de poder llegar a la parte del código de este artículo, veamos cómo SageMaker realmente sirve solicitudes. En su núcleo, la inferencia de SageMaker tiene dos construcciones:
- Conoce a FinGPT Un modelo de lenguaje financiero de gran tamaño (LL...
- Este documento prueba el sentido del humor de ChatGPT Más del 90% d...
- ¿Cómo está haciendo la IA que los bosques sean más seguros contra l...
- Contenedor: Esto establece el entorno de tiempo de ejecución para el modelo, también está integrado con el servidor de modelos que estás utilizando. Puedes utilizar uno de los contenedores de aprendizaje profundo existentes (DLC) o crear tu propio contenedor.
- Artefactos del modelo: En la llamada CreateModel API, especificamos una URL de S3 con los datos del modelo presentes en el formato de un modelo.tar.gz (tarball). Estos datos del modelo se cargan en el directorio opt/ml/modelo en el contenedor, lo que incluye cualquier script de inferencia que proporcionas.
La clave aquí es que el contenedor necesita un servidor web implementado que responda al puerto 8080 en los caminos /invocations y /ping. Un ejemplo de servidor web que hemos implementado con estos caminos es Flask durante un ejemplo de Bring Your Own Container.
Con Docker, lo que haremos es exponer este puerto y apuntar hacia nuestro script y artefactos de modelo locales, de esta manera simulamos la forma en que se espera que se comporte un punto final de SageMaker.
Pruebas con Docker
Por simplicidad, utilizaremos mi ejemplo de BART de mi último artículo, puedes obtener los artefactos de este repositorio. Aquí deberías ver los siguientes archivos:
- model.py: Este es el script de inferencia en el que estamos trabajando. En este caso, estamos utilizando DJL Serving, que espera un model.py con una función de controlador que implementa la inferencia. Tu script de inferencia aún debe ser compatible con el formato que espera el servidor de modelos.
- requirements.txt: Cualquier dependencia adicional que requiera tu script model.py. Para DJL Serving, PyTorch ya está instalado de antemano, usamos numpy para el procesamiento de datos.
- serving.properties: Este es también un archivo específico de DJL, aquí puedes definir cualquier configuración a nivel de modelo (por ejemplo: trabajadores por modelo).
Tenemos nuestros artefactos de modelo, ahora necesitamos el contenedor que utilizaremos. En este caso, podemos recuperar la imagen existente de DJL DeepSpeed. Para obtener una lista exhaustiva de las imágenes que ya proporciona AWS, consulta esta guía. También puedes construir tu propia imagen localmente y apuntar hacia ella. En este caso, estamos operando en un entorno de instancia de cuaderno SageMaker Classic, que viene con Docker preinstalado también.
Para trabajar con las imágenes proporcionadas por AWS, primero necesitamos iniciar sesión en AWS Elastic Container Registry (ECR) para recuperar la imagen, lo cual podemos hacer con el siguiente comando de shell.
$(aws ecr get-login --region us-east-1 --no-include-email --registry-ids 763104351884)Debería ver un mensaje de inicio de sesión exitoso similar al siguiente.
Una vez iniciada la sesión, podemos acceder a la ruta donde se almacenan nuestros artefactos de modelo y ejecutar el siguiente comando que iniciará el servidor de modelo. Si aún no ha recuperado la imagen, esta también se extraerá de ECR.
docker run \-v /home/ec2-user/SageMaker:/opt/ml/model \--cpu-shares 512 \-p 8080:8080 \763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.21.0-deepspeed0.8.0-cu117 \serveAlgunos puntos clave aquí:
- Estamos exponiendo el puerto 8080 como espera SageMaker Inference.
- También apuntamos hacia la imagen existente. Esta cadena depende de la región y el modelo en el que está operando. También puede utilizar la llamada de API retrieve image_uri del SDK de Python de SageMaker para identificar la imagen apropiada para extraer aquí.
Después de extraer la imagen, verá que el servidor de modelo se ha iniciado.
También podemos verificar que este contenedor se está ejecutando utilizando el siguiente comando de Docker.
docker container ls
Vemos que la API se expone a través del puerto 8080 al cual podemos enviar solicitudes de muestra a través de curl. Observe que especificamos la ruta /invocations que esperan los contenedores de SageMaker.
curl -X POST http://localhost:8080/invocations -H "Content-type: text/plain" "Esto es una cadena de prueba de muestra"Luego vemos la inferencia devuelta para la solicitud y también el servidor de modelo rastreando la respuesta y emitiendo nuestras declaraciones de registro de nuestro script de inferencia.
Veamos nuestro modelo.py y veamos si podemos capturar el error temprano con Docker. Aquí, en la función de inferencia, agrego una declaración de impresión sintácticamente incorrecta y reinicio mi servidor de modelo para ver si se captura este error.
def inference(self, inputs): """ Custom service entry point function. :param inputs: the Input object holds the text for the BART model to infer upon :return: the Output object to be send back """ #sample error print("=)Luego podemos ver este error capturado por el servidor de modelo cuando ejecutamos el comando docker run.
Tenga en cuenta que no está limitado a utilizar solo curl para probar su contenedor. También podemos utilizar algo como la biblioteca de solicitudes de Python para interactuar y trabajar con el contenedor. Una solicitud de ejemplo se vería así:
import requestsheaders = { 'Content-type': 'text/plain',}response = requests.post('http://localhost:8080/invocations', headers=headers)Utilizando algo como solicitudes, puede ejecutar pruebas de carga a gran escala en el contenedor. Tenga en cuenta que el hardware en el que se ejecuta el contenedor es lo que se está utilizando (piense en esto como su equivalente a la instancia detrás de un punto de enlace de SageMaker).
Recursos adicionales y conclusión
GitHub – RamVegiraju/SageMaker-Docker-Local: Cómo probar localmente la inferencia de SageMaker con Docker
Cómo probar localmente la inferencia de SageMaker con Docker – GitHub – RamVegiraju/SageMaker-Docker-Local: Cómo probar localmente…
github.com
Puede encontrar el código de todo el ejemplo en el enlace de arriba. Con SageMaker Inference, desea evitar el dolor de esperar a que se cree el punto final para capturar cualquier error. Utilizando este enfoque, puede trabajar con cualquier contenedor de SageMaker para probar y depurar sus artefactos de modelo y scripts de inferencia.
Como siempre, siéntase libre de dejar cualquier comentario o pregunta, ¡gracias por leer!
Si disfrutó de este artículo, no dude en conectarse conmigo en LinkedIn y suscribirse a mi boletín informativo de Zepes. Si es nuevo en Zepes, regístrese usando mi referencia de membresía.
