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. # Servidores de modelos para la implementación de modelos con Amazon SageMaker AI Puede utilizar servidores de modelos populares TorchServe, como DJL Serving y Triton Inference Server, para implementar sus modelos en IA. SageMaker En los siguientes temas se explica cómo hacerlo. **Topics** + [Implemente modelos con TorchServe](deploy-models-frameworks-torchserve.md) + [Implementar modelos con DJL Serving](deploy-models-frameworks-djl-serving.md) + [Implementación de modelos con Triton Inference Server](deploy-models-frameworks-triton.md) # Implemente modelos con TorchServe TorchServe es el modelo de servidor recomendado PyTorch, ya que viene preinstalado en el contenedor de aprendizaje AWS PyTorch profundo (DLC). Esta poderosa herramienta ofrece a los clientes una experiencia uniforme y fácil de usar, y ofrece un alto rendimiento al implementar varios PyTorch modelos en varias AWS instancias, incluidas la CPU, la GPU, Neuron y Graviton, independientemente del tamaño o la distribución del modelo. TorchServe admite una amplia gama de funciones avanzadas, como el procesamiento dinámico por lotes, el microprocesamiento, las A/B pruebas de modelos, la transmisión, el torch XLA, TensorRT, ONNX e IPEX. Además, integra a la perfección la solución para modelos grandes, Pi, lo PyTorch que permite un manejo eficiente de modelos grandes. PPy Además, TorchServe amplía su soporte a bibliotecas populares de código abierto DeepSpeed, como Accelerate y Fast Transformers, entre otras, lo que amplía aún más sus capacidades. Con TorchServe ella, AWS los usuarios pueden implementar y utilizar sus PyTorch modelos con confianza, aprovechando su versatilidad y rendimiento optimizado en diversas configuraciones de hardware y tipos de modelos. [Para obtener información más detallada, puede consultar la [PyTorchdocumentación](https://pytorch.org/serve/) y demásTorchServe. GitHub](https://github.com/pytorch/serve) En la siguiente tabla se enumeran las AWS PyTorch DLCs compatibles con TorchServe. | Tipo de instancia | SageMaker Enlace PyTorch DLC de AI | | --- | --- | | CPU y GPU | [SageMaker Contenedores de IA PyTorch ](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-containers-sm-support-only) | | Neuron | [PyTorch Contenedores Neuron](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#neuron-containers) | | Graviton | [SageMaker Contenedores AI PyTorch Graviton](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-graviton-containers-sm-support-only) | En las siguientes secciones se describe la configuración para compilar y probar PyTorch DLCs en Amazon SageMaker AI. ## Introducción Antes de comenzar, compruebe que cumple los siguientes requisitos previos: 1. Asegúrese de tener acceso a una AWS cuenta. Configure su entorno para que AWS CLI pueda acceder a su cuenta a través de un usuario de AWS IAM o un rol de IAM. Recomendamos utilizar un rol de IAM. Para realizar pruebas en su cuenta personal, puede asociar las siguientes políticas de permisos gestionados al rol de IAM: + [AmazonEC2ContainerRegistryFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess) + [AmazonEC2FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) + [AWS ServiceRoleForAmazonEKSNodegroup](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSServiceRoleForAmazonEKSNodegroup) + [AmazonSageMakerFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSageMakerFullAccess) + [Amazon S3 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) 1. Configure sus dependencias de forma local, como se muestra en el siguiente ejemplo. ``` from datetime import datetime import os import json import logging import time # External Dependencies: import boto3 from botocore.exceptions import ClientError import sagemaker sess = boto3.Session() sm = sess.client("sagemaker") region = sess.region_name account = boto3.client("sts").get_caller_identity().get("Account") smsess = sagemaker.Session(boto_session=sess) role = sagemaker.get_execution_role() # Configuration: bucket_name = smsess.default_bucket() prefix = "torchserve" output_path = f"s3://{bucket_name}/{prefix}/models" print(f"account={account}, region={region}, role={role}") ``` 1. Recupera la imagen del PyTorch DLC, como se muestra en el siguiente ejemplo. SageMaker Las imágenes del PyTorch DLC de IA están disponibles en todas las AWS regiones. Para obtener más información, consulte la [lista de imágenes de contenedores de DLC](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-containers-sm-support-only). ``` baseimage = sagemaker.image_uris.retrieve( framework="pytorch", region="", py_version="py310", image_scope="inference", version="2.0.1", instance_type="ml.g4dn.16xlarge", ) ``` 1. Crear un espacio de trabajo local. ``` mkdir -p workspace/ ``` ## Añadir un paquete En las siguientes secciones se describe cómo añadir y preinstalar paquetes a una imagen de PyTorch DLC. **Casos de uso de BYOC** En los pasos siguientes se describe cómo añadir un paquete a la imagen de PyTorch DLC. Para obtener más información sobre la personalización del contenedor, consulte [Creación de imágenes personalizadas de AWS Deep Learning Containers](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). 1. Supongamos que quieres añadir un paquete a la imagen del docker del PyTorch DLC. Cree un Dockerfile en el directorio de `docker`, como se muestra en el siguiente ejemplo: ``` mkdir -p workspace/docker cat workspace/docker/Dockerfile ARG BASE_IMAGE FROM $BASE_IMAGE #Install any additional libraries RUN pip install transformers==4.28.1 ``` 1. Cree y publique la imagen de Docker personalizada mediante el siguiente script: [build\$1and\$1push.sh](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/docker/build_and_push.sh). ``` # Download script build_and_push.sh to workspace/docker ls workspace/docker build_and_push.sh Dockerfile # Build and publish your docker image reponame = "torchserve" versiontag = "demo-0.1" ./build_and_push.sh {reponame} {versiontag} {baseimage} {region} {account} ``` **SageMaker Casos de uso de preinstalación de IA** En el siguiente ejemplo, se muestra cómo preinstalar un paquete en el contenedor de contenido PyTorch descargable. Debe crear un archivo `requirements.txt` localmente en el directorio `workspace/code`. ``` mkdir -p workspace/code cat workspace/code/requirements.txt transformers==4.28.1 ``` ## Crea artefactos modelo TorchServe En el siguiente ejemplo, utilizamos el modelo MNIST [ previamente entrenado](https://github.com/pytorch/serve/tree/master/examples/image_classifier/mnist). Creamos un directorio`workspace/mnist`, implementamos [mnist\$1handler.py](https://github.com/pytorch/serve/blob/master/examples/image_classifier/mnist/mnist_handler.py) siguiendo las [instrucciones de servicio TorchServe personalizadas](https://github.com/pytorch/serve/blob/master/docs/custom_service.md#custom-service) y [configuramos los parámetros del modelo (como el](https://github.com/pytorch/serve/tree/master/model-archiver#config-file) tamaño del lote y los trabajadores) en [model-config.yaml](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/lama/model-config.yaml). A continuación, utilizamos la TorchServe herramienta `torch-model-archiver` para crear los artefactos del modelo y subirlos a Amazon S3. 1. Configure los parámetros del modelo en `model-config.yaml`. ``` ls -al workspace/mnist-dev mnist.py mnist_handler.py mnist_cnn.pt model-config.yaml # config the model cat workspace/mnist-dev/model-config.yaml minWorkers: 1 maxWorkers: 1 batchSize: 4 maxBatchDelay: 200 responseTimeout: 300 ``` 1. Cree los artefactos del modelo utilizando [torch-model-archiver ](https://github.com/pytorch/serve/tree/master/model-archiver#torch-model-archiver-for-torchserve). ``` torch-model-archiver --model-name mnist --version 1.0 --model-file workspace/mnist-dev/mnist.py --serialized-file workspace/mnist-dev/mnist_cnn.pt --handler workspace/mnist-dev/mnist_handler.py --config-file workspace/mnist-dev/model-config.yaml --archive-format tgz ``` Si desea preinstalar un paquete, debe incluir el directorio `code` en el archivo `tar.gz`. ``` cd workspace torch-model-archiver --model-name mnist --version 1.0 --model-file mnist-dev/mnist.py --serialized-file mnist-dev/mnist_cnn.pt --handler mnist-dev/mnist_handler.py --config-file mnist-dev/model-config.yaml --archive-format no-archive cd mnist mv ../code . tar cvzf mnist.tar.gz . ``` 1. Suba `mnist.tar.gz` a Amazon S3. ``` # upload mnist.tar.gz to S3 output_path = f"s3://{bucket_name}/{prefix}/models" aws s3 cp mnist.tar.gz {output_path}/mnist.tar.gz ``` ## Uso de puntos finales de un solo modelo para realizar la implementación TorchServe El siguiente ejemplo muestra cómo crear un [punto final de inferencia en tiempo real de un solo modelo](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints-deployment.html), implementar el modelo en el punto final y probar el punto final mediante el [SDK de Amazon SageMaker Python](https://sagemaker.readthedocs.io/en/stable/). ``` from sagemaker.model import Model from sagemaker.predictor import Predictor # create the single model endpoint and deploy it on SageMaker AI model = Model(model_data = f'{output_path}/mnist.tar.gz', image_uri = baseimage, role = role, predictor_cls = Predictor, name = "mnist", sagemaker_session = smsess) endpoint_name = 'torchserve-endpoint-' + time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime()) predictor = model.deploy(instance_type='ml.g4dn.xlarge', initial_instance_count=1, endpoint_name = endpoint_name, serializer=JSONSerializer(), deserializer=JSONDeserializer()) # test the endpoint import random import numpy as np dummy_data = {"inputs": np.random.rand(16, 1, 28, 28).tolist()} res = predictor.predict(dummy_data) ``` ## Uso de puntos de enlace multimodelo con los que realizar la implementación TorchServe Los [puntos de conexión multimodelo](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html) son una solución escalable y rentable para alojar una gran cantidad de modelos detrás de un punto de conexión. Mejoran la utilización de los puntos de conexión al compartir la misma flota de recursos y servir contenedores para alojar todos sus modelos. También reducen la sobrecarga de despliegue, ya que la SageMaker IA gestiona de forma dinámica los modelos de carga y descarga, además de escalar los recursos en función de los patrones de tráfico. Los puntos de conexión multimodelo son especialmente útiles para el aprendizaje profundo y los modelos de IA generativa que requieren una potencia de cálculo acelerada. Al utilizarlos TorchServe en terminales multimodelo de SageMaker IA, puede acelerar su desarrollo utilizando una pila de servidores con la que esté familiarizado y, al mismo tiempo, aprovechar el intercambio de recursos y la gestión simplificada de modelos que ofrecen los puntos finales multimodelo de SageMaker IA. El siguiente ejemplo muestra cómo crear un punto final multimodelo, implementar el modelo en el punto final y probar el punto final mediante el [SDK de Amazon SageMaker Python](https://sagemaker.readthedocs.io/en/stable/). Puede encontrar más detalles en este [ejemplo de cuaderno](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/torchserve_multi_model_endpoint.ipynb). ``` from sagemaker.multidatamodel import MultiDataModel from sagemaker.model import Model from sagemaker.predictor import Predictor # create the single model endpoint and deploy it on SageMaker AI model = Model(model_data = f'{output_path}/mnist.tar.gz', image_uri = baseimage, role = role, sagemaker_session = smsess) endpoint_name = 'torchserve-endpoint-' + time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime()) mme = MultiDataModel( name = endpoint_name, model_data_prefix = output_path, model = model, sagemaker_session = smsess) mme.deploy( initial_instance_count = 1, instance_type = "ml.g4dn.xlarge", serializer=sagemaker.serializers.JSONSerializer(), deserializer=sagemaker.deserializers.JSONDeserializer()) # list models list(mme.list_models()) # create mnist v2 model artifacts cp mnist.tar.gz mnistv2.tar.gz # add mnistv2 mme.add_model(mnistv2.tar.gz) # list models list(mme.list_models()) predictor = Predictor(endpoint_name=mme.endpoint_name, sagemaker_session=smsess) # test the endpoint import random import numpy as np dummy_data = {"inputs": np.random.rand(16, 1, 28, 28).tolist()} res = predictor.predict(date=dummy_data, target_model="mnist.tar.gz") ``` ## Métricas TorchServe admite métricas tanto a nivel de sistema como a nivel de modelo. Puede habilitar las métricas en el modo de formato de registro o en el modo Prometheus a través de la variable de entorno `TS_METRICS_MODE`. Puede usar el archivo de configuración de métricas TorchServe central `metrics.yaml` para especificar los tipos de métricas que se van a rastrear, como el recuento de solicitudes, la latencia, el uso de la memoria, el uso de la GPU, etc. Al consultar este archivo, puede obtener información sobre el rendimiento y el estado de los modelos implementados y supervisar de forma eficaz el comportamiento del TorchServe servidor en tiempo real. Para obtener información más detallada, consulte la [documentación sobre TorchServe métricas](https://github.com/pytorch/serve/blob/master/docs/metrics.md#torchserve-metrics). Puedes acceder a los registros de TorchServe métricas similares al formato StatsD a través del filtro de CloudWatch registros de Amazon. El siguiente es un ejemplo de registro de TorchServe métricas: ``` CPUUtilization.Percent:0.0|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 DiskAvailable.Gigabytes:318.0416717529297|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 ``` # Implementar modelos con DJL Serving DJL Serving es una solución de servidor de modelos independiente y universal de alto rendimiento. Toma un modelo de aprendizaje profundo, varios modelos o flujos de trabajo y los hace disponibles a través de un punto de conexión HTTP. Puede utilizar uno de los DJL Serving [Deep Learning Containers (DLCs)](https://docs.aws.amazon.com/deep-learning-containers/latest/devguide/what-is-dlc.html) para servir sus modelos. AWS Para obtener más información sobre los tipos de modelos y marcos compatibles, consulte el repositorio de [DJL Serving GitHub.](https://github.com/deepjavalibrary/djl-serving) DJL Serving ofrece muchas funciones que le ayudan a implementar sus modelos con un alto rendimiento: + Facilidad de uso: DJL Serving puede funcionar con la mayoría de los modelos sin ninguna modificación. Usted trae los artefactos de sus modelos y DJL Serving puede alojarlos. + Compatibilidad con varios dispositivos y aceleradores: DJL Serving admite la implementación de modelos en CPUs GPUs, e Inferentia. AWS + Rendimiento: DJL Serving ejecuta inferencias multiproceso en una sola máquina virtual Java (JVM) para aumentar el rendimiento. + Procesamiento dinámico por lotes: DJL Serving admite el procesamiento por lotes dinámico para aumentar el rendimiento. + Escalado automático: DJL Serving amplía o reduce automáticamente el número de trabajadores en función de la carga de tráfico. + Soporte multimotor: DJL Serving puede alojar modelos simultáneamente utilizando diferentes marcos (por ejemplo, y). PyTorch TensorFlow + Modelos de conjunto y flujo de trabajo: DJL Serving permite implementar flujos de trabajo complejos compuestos por varios modelos y puede ejecutar partes del flujo de trabajo CPUs y otras partes. GPUs Los modelos de un flujo de trabajo pueden sacar provecho de diferentes marcos. En las siguientes secciones se describe cómo configurar un terminal con DJL Serving on SageMaker AI. ## Introducción Antes de comenzar, compruebe que cumple los siguientes requisitos previos: 1. Asegúrese de tener acceso a una AWS cuenta. Configure su entorno para que AWS CLI pueda acceder a su cuenta a través de un usuario de AWS IAM o un rol de IAM. Recomendamos utilizar un rol de IAM. Para realizar pruebas en su cuenta personal, puede asociar las siguientes políticas de permisos gestionados al rol de IAM: + [AmazonEC2ContainerRegistryFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess) + [AmazonEC2FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) + [AmazonSageMakerFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSageMakerFullAccess) + [Amazon S3 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) 1. Asegúrese de tener el cliente [Docker](https://docs.docker.com/get-docker/) configurado en su sistema. 1. Inicie sesión en Amazon Elastic Container Registry y configure las siguientes variables de entorno: ``` export ACCOUNT_ID= export REGION= aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com ``` 1. Extraiga la imagen de Docker. ``` docker pull 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118 ``` Para ver todas las imágenes de los contenedores de DJL Serving disponibles, consulte los [contenedores de inferencia de modelos grandes](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#large-model-inference-containers) y los [contenedores de inferencia de CPU de DJL Serving](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#djl-cpu-full-inference-containers). Al elegir una imagen de las tablas de los enlaces anteriores, sustituya la AWS región de la columna URL de ejemplo por la región en la que se encuentra. DLCs Están disponibles en las regiones que figuran en la tabla situada en la parte superior de la página de [imágenes de Available Deep Learning Containers](https://github.com/aws/deep-learning-containers/blob/master/available_images.md). ## Personalice su contenedor Puede añadir paquetes a las imágenes base del DLC para personalizar su contenedor. Supongamos que quiere añadir un paquete a la imagen de Docker `763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118`. Debe crear un dockerfile con la imagen que desee como imagen base, añadir los paquetes necesarios y enviar la imagen a Amazon ECR. Para crear un paquete, siga los pasos que se describen a continuación: 1. Especifique las instrucciones para ejecutar las bibliotecas o paquetes que quiera en el dockerfile de la imagen base. ``` FROM 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118 ## add custom packages/libraries RUN git clone https://github.com/awslabs/amazon-sagemaker-examples ``` 1. Cree la imagen de Docker desde el Dockerfile. Especifique su repositorio de Amazon ECR, el nombre de la imagen base y una etiqueta para la imagen. Si no dispone de ningún repositorio de Amazon ECR, consulte [Uso de Amazon ECR con el AWS CLI](https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html) en la *Guía del usuario de Amazon ECR* para obtener instrucciones sobre cómo crear uno. ``` docker build -f Dockerfile -t /: ``` 1. Envíe la imagen de Docker a su repositorio de Amazon ECR. ``` docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/: ``` Ahora debería disponer de una imagen de contenedor personalizada que pueda utilizar para servir modelos. Para ver más ejemplos de cómo personalizar su contenedor, consulte [Creación de imágenes personalizadas de AWS Deep Learning Containers](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). ## Preparación de los artefactos de su modelo Antes de implementar el modelo en la SageMaker IA, debe empaquetar los artefactos del modelo en un `.tar.gz` archivo. DJL Serving acepta los siguientes artefactos en su archivo: + Punto de control de modelos: archivos que almacenan los pesos del modelo. + `serving.properties`: un archivo de configuración que puede añadir para cada modelo. Coloque `serving.properties` en el mismo directorio que el archivo del modelo. + `model.py`: el código del controlador de inferencias. Esto solo es aplicable cuando se utiliza el modo Python. Si no especifica `model.py`, djl-serving utiliza uno de los controladores predeterminados. A continuación se muestra un ejemplo de la estructura de `model.tar.gz`. ``` - model_root_dir # root directory - serving.properties - model.py # your custom handler file for Python, if you choose not to use the default handlers provided by DJL Serving - model binary files # used for Java mode, or if you don't want to use option.model_id and option.s3_url for Python mode ``` DJL Serving es compatible con motores Java impulsados por motores DJL o Python. No se requieren todos los artefactos anteriores; los artefactos necesarios varían según el modo que elija. Por ejemplo, en el modo Python, solo necesita especificar `option.model_id` en el archivo `serving.properties`; no necesita especificar el punto de control del modelo dentro de los contenedores de LMI. En el modo Java, debe empaquetar el punto de control del modelo. Para obtener más información sobre cómo configurar `serving.properties` y operar con diferentes motores, consulte [Modos de funcionamiento de DJL Serving](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md). ## Utilice terminales de un solo modelo para realizar la implementación con DJL Serving Tras preparar los artefactos del modelo, puede implementarlo en un punto final de SageMaker IA. En esta sección se describe cómo implementar un único modelo en un punto de conexión con DJL Serving. Si va a implementar varios modelos, omita esta sección y vaya a [Utilice puntos de conexión multimodelo para realizar la implementación con DJL Serving](#deploy-models-frameworks-djl-mme). El siguiente ejemplo muestra un método para crear un objeto modelo mediante el SDK de Amazon SageMaker Python. Deberá especificar los siguientes campos: + `image_uri`: puede recuperar una de las imágenes base de DJL Serving, como se muestra en este ejemplo, o puede especificar una imagen de Docker personalizada de su repositorio de Amazon ECR, si ha seguido las instrucciones que se indican en [Personalice su contenedor](#deploy-models-frameworks-djl-byoc). + `model_s3_url`: debe ser un URI de Amazon S3 que apunte a su archivo`.tar.gz`. + `model_name`: especifique un nombre para el objeto de modelo. ``` import boto3 import sagemaker from sagemaker.model import Model from sagemaker import image_uris, get_execution_role aws_region = "aws-region" sagemaker_session = sagemaker.Session(boto_session=boto3.Session(region_name=aws_region)) role = get_execution_role() def create_model(model_name, model_s3_url): # Get the DJL DeepSpeed image uri image_uri = image_uris.retrieve( framework="djl-deepspeed", region=sagemaker_session.boto_session.region_name, version="0.20.0" ) model = Model( image_uri=image_uri, model_data=model_s3_url, role=role, name=model_name, sagemaker_session=sagemaker_session, ) return model ``` ## Utilice puntos de conexión multimodelo para realizar la implementación con DJL Serving Si desea implementar varios modelos en un punto final, la SageMaker IA ofrece puntos finales multimodelo, que son una solución escalable y rentable para implementar un gran número de modelos. DJL Serving también permite cargar varios modelos simultáneamente y ejecutar inferencias en cada uno de los modelos de forma simultánea. Los contenedores DJL Serving cumplen con los contratos de puntos finales multimodelo de SageMaker IA y se pueden utilizar para implementar puntos finales multimodelo. Cada artefacto modelo individual debe empaquetarse de la misma manera que se describe en la anterior sección [Preparación de los artefactos de su modelo](#deploy-models-frameworks-djl-artifacts). Puede establecer configuraciones específicas del modelo en el archivo `serving.properties` y el código del controlador de inferencias específico del modelo en `model.py`. Para un punto de conexión multimodelo, los modelos deben organizarse de la siguiente manera: ``` root_dir |-- model_1.tar.gz |-- model_2.tar.gz |-- model_3.tar.gz . . . ``` El SDK de Amazon SageMaker Python usa el [MultiDataModel](https://sagemaker.readthedocs.io/en/stable/api/inference/multi_data_model.html)objeto para crear una instancia de un punto final multimodelo. El URI de Amazon S3 para el directorio raíz debe pasarse como argumento `model_data_prefix` al constructor `MultiDataModel`. DJL Serving también proporciona varios parámetros de configuración para gestionar los requisitos de memoria del modelo, como `required_memory_mb` y `reserved_memory_mb`, que pueden configurarse para cada modelo del archivo [serving.properties.](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties) Estos parámetros son útiles para gestionar los errores de falta de memoria de forma más eficaz. Para ver todos los parámetros configurables, consulte [OutofMemory handling](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/out_of_memory_management.md) in djl-serving. La característica de escalado automático de DJL Serving ayuda a garantizar que los modelos se escalen adecuadamente para el tráfico entrante. De forma predeterminada, DJL Serving determina el número máximo de trabajadores que puede soportar un modelo en función del hardware disponible (por ejemplo, núcleos de CPU o dispositivos de GPU). Puede establecer límites inferiores y superiores para cada modelo para garantizar que siempre se pueda atender un nivel de tráfico mínimo y que un solo modelo no consuma todos los recursos disponibles. Puede establecer las siguientes propiedades en el archivo [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties): + `gpu.minWorkers`: Número mínimo de trabajadores para. GPUs + `gpu.maxWorkers`: Número máximo de trabajadores para GPUs. + `cpu.minWorkers`: Número mínimo de trabajadores para CPUs. + `cpu.maxWorkers`: Número máximo de trabajadores para CPUs. [Para ver un end-to-end ejemplo de cómo implementar un terminal multimodelo en la SageMaker IA mediante un contenedor de DJL Serving, consulte el cuaderno de ejemplo Multi-model-Inference-Demo.ipynb.](https://github.com/deepjavalibrary/djl-demo/blob/master/aws/sagemaker/Multi-Model-Inference-Demo.ipynb) # Implementación de modelos con Triton Inference Server [Servidor de inferencia Triton](https://github.com/triton-inference-server/server) es un software de servidor de inferencias de código abierto que optimiza la inferencia de IA. Con Triton, puede implementar cualquier modelo creado con múltiples marcos de aprendizaje profundo y aprendizaje automático, incluidos TensorRT,, ONNX TensorFlow, OpenVINO PyTorch, Python, RAPIDS FIL y más. Los contenedores Triton de SageMaker IA le ayudan a implementar el servidor de inferencia Triton en la plataforma SageMaker AI Hosting para ofrecer modelos entrenados en producción. Es compatible con los diferentes modos en los que SageMaker opera la IA. Para ver una lista de los contenedores del servidor de inferencia Triton disponibles en SageMaker IA, consulte los contenedores de [inferencia Triton de NVIDIA (solo compatibles con SM)](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#nvidia-triton-inference-containers-sm-support-only). [Para ver ejemplos de end-to-end cuadernos, te recomendamos que consultes el repositorio. amazon-sagemaker-examples ](https://github.com/aws/amazon-sagemaker-examples/tree/main/sagemaker-triton) ## Modos de alojamiento Los contenedores Triton admiten los siguientes modos de alojamiento de SageMaker IA: + Puntos de conexión de modelo único + Este es el modo de funcionamiento predeterminado de la SageMaker IA. En este modo, el contenedor Triton puede cargar un solo modelo o un solo modelo de conjunto. + El nombre del modelo debe pasarse como una propiedad del entorno del contenedor, que forma parte de la llamada a la API de `CreateModel` SageMaker IA. La variable de entorno que se utiliza para pasar el nombre del modelo es `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Puntos de conexión de modelo único con conjunto + El servidor de inferencia Triton admite un *conjunto*, que es una canalización, o un DAG (gráfico acíclico dirigido) de modelos. Aunque técnicamente un conjunto se compone de varios modelos, en el modo de punto final predeterminado para un solo modelo, la SageMaker IA puede tratar el *conjunto propiamente dicho* (el metamodelo que representa la canalización) como el modelo principal a cargar y, posteriormente, cargar los modelos asociados. + Se debe utilizar el nombre del modelo del propio conjunto para cargar el modelo. Debe transferirse como una propiedad del entorno del contenedor, que forma parte de la llamada a la `CreateModel` SageMaker API. La variable de entorno que se utiliza para pasar el nombre del modelo es `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Puntos de conexión multimodelo + En este modo, la SageMaker IA puede ofrecer varios modelos en un único punto final. Para usar este modo, especifique la variable de entorno `‘MultiModel’: true` como una propiedad del entorno del contenedor, que forma parte de la llamada a la `CreateModel` SageMaker API. + De forma predeterminada, no se carga ningún modelo cuando se inicia la instancia. Para ejecutar una solicitud de inferencia en un modelo concreto, especifica el `*.tar.gz` archivo del modelo correspondiente como argumento de la `TargetModel` propiedad de la llamada a la `InvokeEndpoint` SageMaker API. + Puntos de conexión multimodelo con conjunto + En este modo, la SageMaker IA funciona como se describe para los puntos finales multimodelo. Sin embargo, el contenedor Triton de SageMaker AI puede cargar varios modelos de conjuntos, lo que significa que se pueden ejecutar múltiples canalizaciones de modelos en la misma instancia. SageMaker La IA trata cada conjunto como un modelo, y se puede invocar el conjunto propio de cada modelo especificando el `*.tar.gz` archivo correspondiente como. `TargetModel` + Para una mejor gestión de la memoria durante la memoria dinámica `LOAD` y `UNLOAD`, le recomendamos que mantenga el tamaño del conjunto pequeño. ## Tipos de carga de inferencia Triton admite dos métodos para enviar una carga útil de inferencia a través de la red `json` y `binary+json` (o json codificado en binario). En ambos casos, la carga útil de JSON incluye el tipo de datos, la forma y el tensor real de la solicitud de inferencia. El tensor de solicitud debe ser un tensor binario. Con el formato `binary+json`, debe especificar la longitud de los metadatos de la solicitud en el encabezado para que Triton pueda analizar correctamente la carga binaria. En el contenedor SageMaker AI Triton, esto se hace mediante un `Content-Type` encabezado personalizado:`application/vnd.sagemaker-triton.binary+json;json-header-size={}`. Esto es diferente a usar el `Inference-Header-Content-Length` encabezado en un servidor de inferencia Triton independiente porque los encabezados personalizados no están permitidos en AI. SageMaker ## Uso de config.pbtxt para establecer la configuración del modelo En el caso de los servidores de inferencia Triton SageMaker basados en IA, cada modelo debe incluir un `config.pbtxt` archivo que especifique, como mínimo, las siguientes configuraciones del modelo: + `name`: Si bien esto es opcional para los modelos que se ejecutan fuera de la SageMaker IA, le recomendamos que siempre proporcione un nombre para los modelos que se ejecutarán en Triton en la IA. SageMaker + [`platform` y/o `backend`](https://github.com/triton-inference-server/backend/blob/main/README.md#backends): configurar un backend es esencial para especificar el tipo de modelo. Algunos backends tienen una clasificación adicional, como `tensorflow_savedmodel` o ` tensorflow_graphdef`. Es posible especificar estas opciones como parte de la clave `platform` además de la clave `backend`. Los backends más comunes son `tensorrt`, `onnxruntime`, `tensorflow`, `pytorch`, `python`, `dali`, `fil` y `openvino`. + `input`: especifique tres atributos para la entrada: `name`, `data_type` y `dims` (la forma). + `output`: especifique tres atributos para la salida: `name`, `data_type` y `dims` (la forma). + `max_batch_size`: establezca el tamaño del lote en un valor mayor o igual a 1 que indique el tamaño máximo de lote que Triton debe utilizar con el modelo. [Para obtener más información sobre la configuración`config.pbtxt`, consulta el repositorio de GitHub Triton.](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md) Triton proporciona varias configuraciones para ajustar el comportamiento del modelo. Algunas de las opciones de configuración más comunes e importantes son: + [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#instance-groups](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#instance-groups): los grupos de instancias ayudan a especificar el número y la ubicación de un modelo determinado. Tienen los atributos `count`, `kind`, y `gpus` (usados cuando `kind` es `KIND_GPU`). El atributo `count` equivale a la cantidad de trabajadores. Para el servicio de modelos normal, cada trabajador tiene su propia copia de modelo. Del mismo modo, en Triton, el `count` especifica el número de copias del modelo por dispositivo. Por ejemplo, si el tipo `instance_group` es `KIND_CPU`, entonces la CPU tiene el número `count` de copias del modelo. **nota** En una instancia de GPU, la configuración `instance_group` se aplica a cada dispositivo de GPU. Por ejemplo, se coloca el número `count` de copias del modelo en cada dispositivo de GPU, a menos que especifique explícitamente qué dispositivos de GPU deben cargar el modelo. + [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#dynamic-batcher](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#dynamic-batcher) y [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#stateful-models](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#stateful-models): el procesamiento por lotes dinámico se usa para los modelos sin estado y el procesamiento por lotes secuencial se usa para los modelos con estado (en los que se desea enrutar una solicitud a la misma instancia del modelo cada vez). Los programadores de procesamiento por lotes permiten una cola por modelo, lo que ayuda a aumentar el rendimiento, en función de la configuración del procesamiento por lotes. + [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#ensemble-models](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#ensemble-models): un modelo de conjunto representa una *canalización* de uno o más modelos y la conexión de los tensores de entrada y salida entre esos modelos. Es posible configurarlo especificando `platform` como`ensemble`. La configuración del conjunto es solo una representación de la canalización del modelo. En el caso de la SageMaker IA, todos los modelos de un conjunto se consideran dependientes del modelo de conjunto y se cuentan como un modelo único para las métricas de la SageMaker IA, por ejemplo. `LoadedModelCount` ## Publicar las métricas predeterminadas de Triton en Amazon CloudWatch El contenedor de inferencias Triton de NVIDIA expone las métricas en el puerto 8002 (configurable) para los distintos modelos y GPUs que se utilizan en el servidor de inferencia Triton. [Para obtener todos los detalles de las métricas predeterminadas disponibles, consulte la GitHub página de las métricas del servidor de inferencia Triton.](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/metrics.md) Estas métricas están en formato Prometheus y pueden extraerse mediante una configuración de scraper de Prometheus. A partir de la versión 23.07 en adelante, el contenedor SageMaker AI Triton permite publicar estas métricas en Amazon CloudWatch especificando algunas variables de entorno. Para analizar las métricas de Prometheus, el contenedor Triton de IA aprovecha SageMaker el agente de Amazon. CloudWatch Las variables de entorno obligatorias que debe especificar para recopilar las métricas son las siguientes: | Variable de entorno | Description (Descripción) | Ejemplo de valor | | --- | --- | --- | | `SAGEMAKER_TRITON_ALLOW_METRICS` | Especifique esta opción para permitir que Triton publique métricas en su punto final de Prometheus. | "true" | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | Especifica esta opción para iniciar las comprobaciones previas necesarias para publicar las métricas en Amazon CloudWatch. | "true" | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Especifique esta opción para apuntar al grupo de registros en el que se escriben las métricas. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesTest" | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Especifique esta opción para apuntar al espacio de nombres de las métricas en el que quiera ver y trazar las métricas. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesPublicTest" | | `SAGEMAKER_TRITON_METRICS_PORT` | Especifique esto como 8002 o cualquier otro puerto. Si SageMaker AI no ha bloqueado el puerto especificado, se utiliza. De lo contrario, se elige automáticamente otro puerto no bloqueado. | "8002" | Al publicar métricas con Triton on SageMaker AI, tenga en cuenta las siguientes limitaciones: + Si bien puedes generar métricas personalizadas a través de la C-API y el backend de Python (a partir de la versión 23.05), actualmente no se admiten para su publicación en Amazon. CloudWatch + En el modo de puntos finales multimodelo (MME) de SageMaker IA, Triton se ejecuta en un entorno que requiere que se habilite el espacio de nombres de los modelos, ya que cada modelo (excepto los modelos de conjunto) se trata como si estuviera en su propio repositorio de modelos. En la actualidad, esto crea una limitación para las métricas. Cuando el espaciado de nombres de los modelos está activado, Triton no distingue las métricas entre dos modelos con el mismo nombre que pertenecen a conjuntos diferentes. Como solución alternativa, asegúrese de que cada modelo que se esté implementando tenga un nombre único. Esto también facilita la búsqueda de las métricas. CloudWatch ## Variables de entorno En la siguiente tabla se enumeran las variables de entorno compatibles con Triton on SageMaker AI. | Variable de entorno | Description (Descripción) | Tipo | Valores posibles | | --- | --- | --- | --- | | `SAGEMAKER_MULTI_MODEL` | Permite que Triton funcione en el modo de puntos finales multimodelo de SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME` | Especifique el modelo que se va a cargar en el modo de modelo único de SageMaker IA (predeterminado). Para el modo conjunto, especifique el nombre del propio conjunto. | Cadena | **como se especifica en config.pbtxt | | `SAGEMAKER_TRITON_PING_MODE` | `'ready'`es el modo predeterminado en el modo de modelo único de la SageMaker IA y `'live'` es el predeterminado en el modo de puntos finales multimodelo de la SageMaker IA. | Cadena | `ready`, `live` | | `SAGEMAKER_TRITON_DISABLE_MODEL_NAMESPACING` | En el contenedor SageMaker AI Triton, está configurado de forma predeterminada. `true` | Booleano | `true`, `false` | | `SAGEMAKER_BIND_TO_PORT` | En SageMaker AI, el puerto predeterminado es el 8080. Puede personalizarlo para un puerto diferente en escenarios con varios contenedores. | Cadena | ** | | `SAGEMAKER_SAFE_PORT_RANGE` | Esto lo establece la plataforma de SageMaker IA cuando se utiliza el modo de contenedores múltiples. | Cadena | **–** | | `SAGEMAKER_TRITON_ALLOW_GRPC` | Si bien la SageMaker IA no es compatible con el GRPC actualmente, si utilizas Triton frente a un proxy inverso personalizado, puedes optar por habilitar el GRPC. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_GRPC_PORT` | El puerto predeterminado del GRPC es el 8001, pero puede cambiarlo. | Cadena | ** | | `SAGEMAKER_TRITON_THREAD_COUNT` | Puede establecer el número de subprocesos predeterminados del controlador de solicitudes HTTP. | Cadena | ** | | `SAGEMAKER_TRITON_LOG_VERBOSE` | `true`de forma predeterminada en la SageMaker IA, pero puedes desactivar esta opción de forma selectiva. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_LOG_INFO` | `false`de forma predeterminada en la SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_LOG_WARNING` | `false`de forma predeterminada en SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_LOG_ERROR` | `false`de forma predeterminada en SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_SHM_DEFAULT_BYTE_SIZE` | Especifique el tamaño de shm para el backend de Python (en bytes). El valor predeterminado es 16 MB, pero se puede aumentar. | Cadena | ** | | `SAGEMAKER_TRITON_SHM_GROWTH_BYTE_SIZE` | Especifique el tamaño de crecimiento de shm para el backend de Python (en bytes). El valor predeterminado es 1 MB, pero se puede aumentar para permitir mayores incrementos. | Cadena | ** | | `SAGEMAKER_TRITON_TENSORFLOW_VERSION` | El valor predeterminado es `2`. Triton ya no es compatible con Tensorflow 2 desde la versión 23.04 de Triton. Puede configurar esta variable para versiones anteriores. | Cadena | ** | | `SAGEMAKER_TRITON_MODEL_LOAD_GPU_LIMIT` | Restrinja el porcentaje máximo de memoria de la GPU que se utiliza para cargar los modelos y permitir que el resto se utilice para las solicitudes de inferencia. | Cadena | ** | | `SAGEMAKER_TRITON_ALLOW_METRICS` | `false`de forma predeterminada en SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_METRICS_PORT` | El puerto predeterminado es 8002. | Cadena | ** | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | `false`de forma predeterminada en SageMaker IA. Defina esta variable para `true` permitir enviar las métricas predeterminadas de Triton a Amazon CloudWatch. Si esta opción está habilitada, serás responsable de CloudWatch los costes cuando se publiquen las métricas en tu cuenta. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Es obligatorio si has activado la publicación de métricas en CloudWatch. | Cadena | ** | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Obligatorio si has activado la publicación de métricas en CloudWatch. | Cadena | ** | | `SAGEMAKER_TRITON_ADDITIONAL_ARGS` | Añade cualquier argumento adicional al iniciar el servidor Triton. | Cadena | ** |