Uso de su propio código de inferencia con servicios de alojamiento - Amazon SageMaker

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.

Uso de su propio código de inferencia con servicios de alojamiento

En esta sección se explica cómo Amazon SageMaker interactúa con un contenedor de Docker que ejecuta tu propio código de inferencia para los servicios de alojamiento. Utilice esta información para escribir el código de inferencia y crear una imagen de Docker.

¿Cómo SageMaker funciona la imagen de inferencia

Para configurar un contenedor para que se inicie como un archivo ejecutable, utilice una instrucción ENTRYPOINT en un Dockerfile. Tenga en cuenta lo siguiente:

  • Para la inferencia de modelos, SageMaker ejecuta el contenedor de la siguiente manera:

    docker run image serve

    SageMaker anula CMD las sentencias predeterminadas de un contenedor especificando el serve argumento después del nombre de la imagen. El argumento serve anula los argumentos que proporciona con el comando CMD en el Dockerfile.

     

  • SageMaker espera que todos los contenedores se ejecuten con usuarios root. Cree su contenedor de modo que solo utilice usuarios raíz. Cuando SageMaker se ejecuta el contenedor, los usuarios que no tienen acceso a nivel raíz pueden provocar problemas de permisos.

     

  • Le recomendamos que utilice la forma exec de la instrucción ENTRYPOINT:

    ENTRYPOINT ["executable", "param1", "param2"]

    Por ejemplo:

    ENTRYPOINT ["python", "k_means_inference.py"]

    La forma exec de la instrucción ENTRYPOINT inicia el archivo ejecutable directamente, no como un elemento secundario de /bin/sh. Esto le permite recibir señales como SIGTERM y SIGKILL desde las operaciones de la SageMaker API, lo cual es obligatorio.

     

    Por ejemplo, cuando utilizas la CreateEndpointAPI para crear un punto final, proporciona el SageMaker número de instancias de procesamiento de aprendizaje automático que requiere la configuración del punto final, que especificas en la solicitud. SageMaker ejecuta el contenedor de Docker en esas instancias.

     

    Si reduces el número de instancias que respaldan el punto final (mediante una llamada a la UpdateEndpointWeightsAndCapacitiesAPI), SageMaker ejecuta un comando para detener el contenedor de Docker en las instancias que se van a terminar. El comando envía la señal SIGTERM y, a continuación, envía la señal SIGKILL 30 segundos más tarde.

     

    Si actualizas el punto final (mediante una llamada a la UpdateEndpointAPI), SageMaker lanzas otro conjunto de instancias de procesamiento de aprendizaje automático y ejecutas los contenedores de Docker que contienen tu código de inferencia. A continuación se ejecuta un comando para detener los contenedores de Docker anteriores. Para detener un contenedor de Docker, el comando envía la señal SIGTERM y, a continuación, envía la señal SIGKILL 30 segundos más tarde.

     

  • SageMaker usa la definición de contenedor que proporcionaste en tu CreateModelsolicitud para establecer las variables de entorno y el nombre de host DNS del contenedor de la siguiente manera:

     

    • Establece las variables de entorno mediante el ContainerDefinition.Environment string-to-string mapa.

    • Establece el nombre de host de DNS mediante ContainerDefinition.ContainerHostname.

       

  • Si tiene previsto utilizar los dispositivos GPU para inferencias de modelos (especificando instancias de computación de ML basadas en GPU en su solicitud CreateEndpointConfig), asegúrese de que los contenedores son compatibles con nvidia-docker. No cree un paquete con controladores de NVIDIA con la imagen. Para obtener más información sobre nvidia-docker, consulte NVIDIA/nvidia-docker.

     

  • No puedes usar el tini inicializador como punto de entrada en los SageMaker contenedores porque los argumentos train y serve lo confunden.

¿Cómo se SageMaker cargan los artefactos de su modelo?

En su solicitud de CreateModelAPI, puede utilizar el S3DataSource parámetro ModelDataUrl o para identificar la ubicación S3 en la que se almacenan los artefactos del modelo. SageMaker copia los artefactos del modelo de la ubicación de S3 al /opt/ml/model directorio para que los utilice el código de inferencia. Su contenedor tiene acceso de solo lectura a /opt/ml/model. No escriba en este directorio.

La ModelDataUrl debe apuntar a un archivo tar.gz. De lo contrario, SageMaker no descargará el archivo.

Si ha entrenado el modelo SageMaker, los artefactos del modelo se guardan como un único archivo tar comprimido en Amazon S3. Si ha entrenado su modelo en un entorno externo SageMaker, debe crear este único archivo tar comprimido y guardarlo en una ubicación S3. SageMaker descomprime este archivo tar en el directorio /opt/ml/model antes de que se inicie el contenedor.

Para implementar modelos de gran tamaño, recomendamos que siga Implementación de modelos sin comprimir.

Cómo debe responder su contenedor a las solicitudes de inferencia

Para obtener inferencias, la aplicación cliente envía una solicitud POST al punto final. SageMaker SageMaker pasa la solicitud al contenedor y devuelve el resultado de la inferencia del contenedor al cliente.

Para obtener más información sobre las solicitudes de inferencia que recibirá tu contenedor, consulta las siguientes acciones en la referencia de la SageMaker API de Amazon:

Requisitos para los contenedores de inferencia

Para responder a las solicitudes de inferencia, su contenedor debe cumplir los siguientes requisitos:

  • SageMaker elimina todos los POST encabezados excepto los admitidos por. InvokeEndpoint SageMaker podría añadir encabezados adicionales. Los contenedores de inferencia deben poder ignorar de forma segura estos encabezados adicionales.

  • Para recibir solicitudes de inferencia, el contenedor debe tener un servidor web que realice la escucha en el puerto 8080 y debe aceptar las solicitudes POST en los punto de conexión /invocations y /ping.

  • Los contenedores de modelo de un cliente deben aceptar las solicitudes de conexión del socket en un plazo de 250 ms.

  • Los contenedores de modelos de un cliente deben responder a las solicitudes en un plazo de 60 segundos. El propio modelo puede tardar un tiempo máximo de procesamiento de 60 segundos antes de responder a las /invocations. Si el modelo tiene un tiempo de procesamiento de entre 50 y 60 segundos, deberá establecer el tiempo de espera del conector del SDK en 70 segundos.

ejemplo funciones de invocación

En los siguientes ejemplos se muestra cómo el código del contenedor puede procesar las solicitudes de inferencia. Estos ejemplos gestionan las solicitudes que las aplicaciones cliente envían mediante la InvokeEndpoint acción.

FastAPI

FastAPI es un marco web para crear API con Python.

from fastapi import FastAPI, status, Request, Response . . . app = FastAPI() . . . @app.post('/invocations') async def invocations(request: Request): # model() is a hypothetical function that gets the inference output: model_resp = await model(Request) response = Response( content=model_resp, status_code=status.HTTP_200_OK, media_type="text/plain", ) return response . . .

En este ejemplo, la invocations función gestiona la solicitud de inferencia que se SageMaker envía al /invocations punto final.

Flask

Flask es un marcopara desarrollar aplicaciones web con Python.

import flask . . . app = flask.Flask(__name__) . . . @app.route('/invocations', methods=["POST"]) def invoke(request): # model() is a hypothetical function that gets the inference output: resp_body = model(request) return flask.Response(resp_body, mimetype='text/plain')

En este ejemplo, la invoke función gestiona la solicitud de inferencia que se SageMaker envía al /invocations punto final.

ejemplo funciones de invocación para solicitudes de streaming

En los siguientes ejemplos se muestra cómo el código del contenedor de inferencia puede procesar las solicitudes de streaming. Estos ejemplos gestionan las solicitudes que las aplicaciones cliente envían mediante la InvokeEndpointWithResponseStream acción.

Cuando un contenedor gestiona una solicitud de inferencia de streaming, devuelve la inferencia del modelo como una serie de partes de forma incremental a medida que el modelo las genera. Las aplicaciones cliente comienzan a recibir respuestas inmediatamente cuando están disponibles. No necesitan esperar a que el modelo genere la respuesta completa. Puede implementar la transmisión en streaming para que admita experiencias interactivas rápidas, como chatbots, asistentes virtuales y generadores de música.

FastAPI

FastAPI es un marco web para crear API con Python.

from starlette.responses import StreamingResponse from fastapi import FastAPI, status, Request . . . app = FastAPI() . . . @app.post('/invocations') async def invocations(request: Request): # Streams inference response using HTTP chunked encoding async def generate(): # model() is a hypothetical function that gets the inference output: yield await model(Request) yield "\n" response = StreamingResponse( content=generate(), status_code=status.HTTP_200_OK, media_type="text/plain", ) return response . . .

En este ejemplo, la invocations función gestiona la solicitud de inferencia que se SageMaker envía al /invocations punto final. Para transmitir la respuesta, el ejemplo utiliza la clase StreamingResponse del marco Starlette.

Flask

Flask es un marcopara desarrollar aplicaciones web con Python.

import flask . . . app = flask.Flask(__name__) . . . @app.route('/invocations', methods=["POST"]) def invocations(request): # Streams inference response using HTTP chunked encoding def generate(): # model() is a hypothetical function that gets the inference output: yield model(request) yield "\n" return flask.Response( flask.stream_with_context(generate()), mimetype='text/plain') . . .

En este ejemplo, la invocations función gestiona la solicitud de inferencia que se SageMaker envía al /invocations punto final. Para transmitir la respuesta, el ejemplo utiliza la función flask.stream_with_context del marco Flask.

Cómo debe responder su contenedor a las solicitudes de comprobación de estado (ping)

SageMaker lanza nuevos contenedores de inferencia en las siguientes situaciones:

  • Responder a las llamadas a la API CreateEndpoint, UpdateEndpoint y UpdateEndpointWeightsAndCapacities

  • Creación de parches de seguridad

  • Reemplazo de instancias con estado incorrecto

Poco después del inicio del contenedor, SageMaker comienza a enviar solicitudes GET periódicas al /ping punto final.

El requisito más sencillo en el contenedor es responder con un código de estado HTTP 200 y un cuerpo vacío. Esto indica SageMaker que el contenedor está listo para aceptar solicitudes de inferencia en el /invocations punto final.

Si el contenedor no comienza a superar las comprobaciones de estado y responde de forma constante durante 200 segundos durante los 8 minutos posteriores al inicio, se producirá un error en el lanzamiento de la nueva instancia. Esto provoca CreateEndpoint un error y deja el punto final en un estado fallido. La actualización solicitada por UpdateEndpoint no se ha completado, los parches de seguridad no se han aplicado y las instancias en mal estado no se sustituyen.

Puesto que la barrera mínima es que el contenedor devuelva un código 200 estático, un desarrollador del contenedor puede usar esta funcionalidad para realizar más comprobaciones. El tiempo de espera de la solicitud en los intentos de /ping es de 2 segundos.