Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Modellserver für die Modellbereitstellung mit Amazon SageMaker AI Sie können beliebte Modellserver wie TorchServe DJL Serving und Triton Inference Server verwenden, um Ihre Modelle auf KI bereitzustellen. SageMaker In den folgenden Themen wird erläutert, wie. **Topics** + [Stellen Sie Modelle bereit mit TorchServe](deploy-models-frameworks-torchserve.md) + [Stellen Sie Modelle mit DJL Serving bereit](deploy-models-frameworks-djl-serving.md) + [Modellbereitstellung mit Triton Inference Server](deploy-models-frameworks-triton.md) # Stellen Sie Modelle bereit mit TorchServe TorchServe ist der empfohlene Modellserver für PyTorch, der im AWS PyTorch Deep Learning Container (DLC) vorinstalliert ist. Dieses leistungsstarke Tool bietet Kunden eine konsistente und benutzerfreundliche Erfahrung und bietet eine hohe Leistung bei der Bereitstellung mehrerer PyTorch Modelle in verschiedenen AWS Instanzen, einschließlich CPU, GPU, Neuron und Graviton, unabhängig von der Modellgröße oder Verteilung. TorchServe unterstützt eine Vielzahl fortschrittlicher Funktionen, darunter dynamisches Batching, Microbatching, A/B Modelltests, Streaming, Torch XLA, TensorRT, ONNX und IPEX. Darüber hinaus integriert es die Lösung für große Modelle, PiPPy, nahtlos und ermöglicht PyTorch so die effiziente Handhabung großer Modelle. Darüber hinaus TorchServe erweitert es die Unterstützung auf beliebte Open-Source-Bibliotheken wie Accelerate DeepSpeed, Fast Transformers und mehr und erweitert so seine Funktionen noch weiter. Mit TorchServe können AWS Benutzer ihre PyTorch Modelle vertrauensvoll einsetzen und bereitstellen und dabei die Vorteile der Vielseitigkeit und optimierten Leistung für verschiedene Hardwarekonfigurationen und Modelltypen nutzen. Ausführlichere Informationen finden Sie in der [PyTorchDokumentation](https://pytorch.org/serve/) und [TorchServeauf GitHub](https://github.com/pytorch/serve). In der folgenden Tabelle sind die AWS PyTorch DLCs unterstützten von aufgeführt TorchServe. | Instance-Typ | SageMaker AI PyTorch DLC-Link | | --- | --- | | CPU und GPU | [SageMaker KI-Container PyTorch ](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-containers-sm-support-only) | | Neuron | [PyTorch Behälter für Neuronen](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#neuron-containers) | | Graviton | [SageMaker PyTorch KI-Graviton-Behälter](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-graviton-containers-sm-support-only) | In den folgenden Abschnitten wird die Einrichtung zum Erstellen und Testen PyTorch DLCs auf Amazon SageMaker AI beschrieben. ## Erste Schritte Stellen Sie vor Beginn sicher, dass die folgenden Voraussetzungen erfüllt sind: 1. Stellen Sie sicher, dass Sie Zugriff auf ein AWS Konto haben. Richten Sie Ihre Umgebung so ein, dass sie entweder über einen AWS IAM-Benutzer oder eine IAM-Rolle auf Ihr Konto zugreifen AWS CLI können. Wir empfehlen die Verwendung einer IAM-Rolle. Zu Testzwecken in Ihrem persönlichen Konto können Sie der IAM-Rolle die folgenden Richtlinien für verwaltete Berechtigungen hinzufügen: + [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. Konfigurieren Sie Ihre Abhängigkeiten lokal wie im folgenden Beispiel gezeigt: ``` 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. Rufen Sie das PyTorch DLC-Image ab, wie im folgenden Beispiel gezeigt. SageMaker PyTorch AI-DLC-Images sind in allen AWS Regionen verfügbar. Weitere Informationen finden Sie in der [Liste der DLC-Container-Images](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. Einen lokalen Workspace erstellen. ``` mkdir -p workspace/ ``` ## Hinzufügen eines Pakets In den folgenden Abschnitten wird beschrieben, wie Sie Ihrem PyTorch DLC-Image Pakete hinzufügen und vorinstallieren. **BYOC-Anwendungsfälle** In den folgenden Schritten wird beschrieben, wie Sie Ihrem PyTorch DLC-Image ein Paket hinzufügen. Weitere Informationen zum Anpassen Ihres Containers finden Sie unter [Benutzerdefinierte Images für AWS Deep Learning Containers erstellen](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). 1. Angenommen, Sie möchten dem PyTorch DLC-Docker-Image ein Paket hinzufügen. Erstellen Sie ein Dockerfile unter dem `docker` Verzeichnis, wie im folgenden Beispiel gezeigt: ``` 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. Erstellen und veröffentlichen Sie das benutzerdefinierte Docker-Image mithilfe des folgenden Skripts [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 Anwendungsfälle für KI-Vorinstallationen** Das folgende Beispiel zeigt Ihnen, wie Sie ein Paket in Ihrem PyTorch DLC-Container vorinstallieren. Sie müssen lokal im Verzeichnis `workspace/code` eine `requirements.txt` Datei erstellen. ``` mkdir -p workspace/code cat workspace/code/requirements.txt transformers==4.28.1 ``` ## Modellartefakte erstellen TorchServe Im folgenden Beispiel verwenden wir das vortrainierte [ MNIST-Modell](https://github.com/pytorch/serve/tree/master/examples/image_classifier/mnist). Wir erstellen ein Verzeichnis`workspace/mnist`, implementieren [mnist\$1handler.py](https://github.com/pytorch/serve/blob/master/examples/image_classifier/mnist/mnist_handler.py), indem wir den [TorchServe benutzerdefinierten Serviceanweisungen](https://github.com/pytorch/serve/blob/master/docs/custom_service.md#custom-service) folgen, und [konfigurieren die Modellparameter](https://github.com/pytorch/serve/tree/master/model-archiver#config-file) (wie Batchgröße und Worker) in [model-config.yaml](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/lama/model-config.yaml). Anschließend verwenden wir das TorchServe Tool, `torch-model-archiver` um die Modellartefakte zu erstellen und auf Amazon S3 hochzuladen. 1. Konfigurieren Sie die Modellparameter in `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. Erstellen Sie die Modellartefakte mithilfe von [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 ``` Wenn Sie ein Paket vorinstallieren möchten, müssen Sie das `code` Verzeichnis in die Datei `tar.gz` aufnehmen. ``` 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. Laden Sie `mnist.tar.gz` auf Amazon S3 hoch. ``` # 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 ``` ## Verwenden von Endpunkten mit einem einzigen Modell für die Bereitstellung mit TorchServe Das folgende Beispiel zeigt Ihnen, wie Sie einen [Echtzeit-Inferenzendpunkt für ein einzelnes Modell](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints-deployment.html) erstellen, das Modell auf dem Endpunkt bereitstellen und den Endpunkt mithilfe des [Amazon SageMaker Python SDK](https://sagemaker.readthedocs.io/en/stable/) testen. ``` 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) ``` ## Verwendung von Endpunkten mit mehreren Modellen für die Bereitstellung TorchServe [Multi-Modell-Endpunkte](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html) sind eine skalierbare und kostengünstige Lösung für das Hosting einer großen Anzahl von Modellen hinter einem Endpunkt. Sie verbessern die Nutzung der Endgeräte, indem sie dieselbe Ressourcenflotte gemeinsam nutzen und Container zum Hosten all Ihrer Modelle bereitstellen. Sie reduzieren auch den Bereitstellungsaufwand, da SageMaker KI das dynamische Laden und Entladen von Modellen sowie die Skalierung von Ressourcen auf der Grundlage von Verkehrsmustern verwaltet. Endgeräte mit mehreren Modellen eignen sich besonders für Deep-Learning- und generative KI-Modelle, die eine beschleunigte Rechenleistung erfordern. Durch den Einsatz TorchServe von SageMaker KI-Endpunkten mit mehreren Modellen können Sie Ihre Entwicklung beschleunigen, indem Sie einen Serving-Stack verwenden, mit dem Sie vertraut sind, und gleichzeitig die gemeinsame Nutzung von Ressourcen und das vereinfachte Modellmanagement nutzen, die SageMaker KI-Endgeräte mit mehreren Modellen bieten. Das folgende Beispiel zeigt Ihnen, wie Sie einen Endpunkt mit mehreren Modellen erstellen, das Modell auf dem Endpunkt bereitstellen und den Endpunkt mithilfe des [Amazon SageMaker Python SDK](https://sagemaker.readthedocs.io/en/stable/) testen. Weitere Details finden Sie in diesem [Notebook-Beispiel](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") ``` ## Kennzahlen TorchServe unterstützt sowohl Metriken auf System- als auch auf Modellebene. Sie können Metriken entweder im Protokollformatmodus oder im Prometheus-Modus über die Umgebungsvariable `TS_METRICS_MODE` aktivieren. Sie können die TorchServe zentrale Metrik-Konfigurationsdatei verwenden`metrics.yaml`, um die Arten von Metriken anzugeben, die verfolgt werden sollen, z. B. Anzahl der Anfragen, Latenz, Speichernutzung, GPU-Auslastung und mehr. Mithilfe dieser Datei können Sie Einblicke in die Leistung und den Zustand der bereitgestellten Modelle gewinnen und das TorchServe Serververhalten effektiv in Echtzeit überwachen. Ausführlichere Informationen finden Sie in der [Dokumentation zu den TorchServe Metriken](https://github.com/pytorch/serve/blob/master/docs/metrics.md#torchserve-metrics). Sie können über den CloudWatch Amazon-Protokollfilter auf TorchServe Metrikprotokolle zugreifen, die dem StatsD-Format ähneln. Im Folgenden finden Sie ein Beispiel für ein TorchServe Metrikprotokoll: ``` CPUUtilization.Percent:0.0|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 DiskAvailable.Gigabytes:318.0416717529297|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 ``` # Stellen Sie Modelle mit DJL Serving bereit DJL Serving ist eine leistungsstarke, universelle, eigenständige Serverlösung. Sie verwendet ein Deep-Learning-Modell, mehrere Modelle oder Workflows und stellt sie über einen HTTP-Endpunkt zur Verfügung. Sie können einen der DJL Serving [Deep Learning Containers (DLCs)](https://docs.aws.amazon.com/deep-learning-containers/latest/devguide/what-is-dlc.html) verwenden, um Ihre Modelle bereitzustellen. AWS Informationen zu den unterstützten Modelltypen und Frameworks finden Sie im [DJL Serving GitHub Repository](https://github.com/deepjavalibrary/djl-serving). DJL Serving bietet viele Funktionen, die Ihnen helfen, Ihre Modelle mit hoher Leistung einzusetzen: + Benutzerfreundlichkeit – DJL Serving kann die meisten Modelle ohne Änderungen bedienen. Sie bringen Ihre Modellartefakte mit und DJL Serving kann sie hosten. + Unterstützung mehrerer Geräte und Beschleuniger — DJL Serving unterstützt die Bereitstellung von Modellen auf CPUs GPUs, und AWS Inferentia. + Leistung – DJL Serving führt Multithread-Inferenzen in einer einzigen Java Virtual Machine (JVM) aus, um den Durchsatz zu erhöhen. + Dynamisches Batching – DJL Serving unterstützt dynamisches Batching, um den Durchsatz zu erhöhen. + Automatische Skalierung – DJL Serving skaliert die Worker je nach Auslastung automatisch nach oben oder unten. + Unterstützung mehrerer Engines — DJL Serving kann gleichzeitig Modelle hosten, die verschiedene Frameworks verwenden (z. B. und). PyTorch TensorFlow + Ensemble- und Workflow-Modelle — DJL Serving unterstützt die Implementierung komplexer Workflows, die aus mehreren Modellen bestehen, und kann Teile des Workflows auf CPUs und andere Teile darauf ausführen. GPUs Modelle innerhalb eines Workflows können verschiedene Frameworks nutzen. In den folgenden Abschnitten wird beschrieben, wie Sie mit DJL Serving auf SageMaker KI einen Endpunkt einrichten. ## Erste Schritte Stellen Sie vor Beginn sicher, dass die folgenden Voraussetzungen erfüllt sind: 1. Stellen Sie sicher, dass Sie Zugriff auf ein AWS Konto haben. Richten Sie Ihre Umgebung so ein, dass sie entweder über einen AWS IAM-Benutzer oder eine IAM-Rolle auf Ihr Konto zugreifen AWS CLI können. Wir empfehlen die Verwendung einer IAM-Rolle. Zu Testzwecken in Ihrem persönlichen Konto können Sie der IAM-Rolle die folgenden Richtlinien für verwaltete Berechtigungen hinzufügen: + [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. Stellen Sie sicher, dass Sie den [Docker-Client](https://docs.docker.com/get-docker/) auf Ihrem System eingerichtet haben. 1. Melden Sie sich bei Amazon Elastic Container Registry an und legen Sie die folgenden Umgebungsvariablen fest: ``` 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. Rufen Sie das Docker-Image ab. ``` docker pull 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118 ``` Alle verfügbaren DJL Serving-Container-Images finden Sie in den [großen Modell-Inferenzcontainern](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#large-model-inference-containers) und den [DJL Serving CPU-Inferenzcontainern](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#djl-cpu-full-inference-containers). Wenn Sie ein Bild aus den Tabellen in den obigen Links auswählen, ersetzen Sie die AWS Region in der Beispiel-URL-Spalte durch die Region, in der Sie sich befinden. Sie DLCs sind in den Regionen verfügbar, die in der Tabelle oben auf der Seite [Verfügbare Deep Learning Containers Learning-Container-Images](https://github.com/aws/deep-learning-containers/blob/master/available_images.md) aufgeführt sind. ## Passen Sie Ihren Container an Sie können den DLC-Basisimages Pakete hinzufügen, um Ihren Container anzupassen. Angenommen, Sie möchten dem `763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118` Docker-Image ein Paket hinzufügen. Sie müssen eine Docker-Datei mit dem gewünschten Image als Basis-Image erstellen, die erforderlichen Pakete hinzufügen und das Image an Amazon ECR übertragen. Um ein Paket hinzuzufügen, führen Sie die folgenden Schritte aus: 1. Geben Sie Anweisungen zum Ausführen der gewünschten Bibliotheken oder Pakete in der Docker-Datei des Basis-Images an. ``` 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. Erstellen Sie das Docker-Image aus der Docker-Datei. Geben Sie Ihr Amazon ECR-Repository, den Namen des Basis-Images und ein Tag für das Image an. Wenn Sie kein Amazon ECR-Repository haben, finden Sie unter [ Verwenden von Amazon ECR mit dem AWS CLI](https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html) im *Amazon ECR-Benutzerhandbuch* Anweisungen zur Erstellung eines solchen. ``` docker build -f Dockerfile -t /: ``` 1. Pushen Sie die Docker-Manifestliste in Ihr Amazon ECR-Repository. ``` docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/: ``` Sie sollten jetzt über ein benutzerdefiniertes Container-Image verfügen, das Sie für die Modellbereitstellung verwenden können. Weitere Beispiele für die Anpassung Ihres Containers finden Sie unter [Benutzerdefinierte Images für AWS Deep Learning Containers erstellen](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). ## Vorbereiten Ihrer Modellartefakte Bevor Sie Ihr Modell auf SageMaker KI bereitstellen, müssen Sie Ihre Modellartefakte in einer `.tar.gz` Datei verpacken. DJL Serving akzeptiert die folgenden Artefakte in Ihrem Archiv: + Modell-Checkpoint: Dateien, in denen Ihre Modellgewichte gespeichert sind. + `serving.properties`: Eine Konfigurationsdatei, die Sie für jedes Modell hinzufügen können. Platzieren Sie `serving.properties` im selben Verzeichnis wie Ihre Modelldatei. + `model.py`: Der Code für den Inferenz-Handler. Dies gilt nur, wenn der Python-Modus verwendet wird. Wenn Sie `model.py` nicht angeben, verwendet djl-Serving einen der Standard-Handler. Im Folgenden wird ein Beispiel für eine `model.tar.gz` Struktur dargestellt: ``` - 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 unterstützt Java-Engines, die auf DJL- oder Python-Engines basieren. Nicht alle der oben genannten Artefakte sind erforderlich. Die erforderlichen Artefakte variieren je nach ausgewähltem Modus. Im Python-Modus müssen Sie beispielsweise nur `option.model_id` in der `serving.properties` Datei angeben. Sie müssen den Modell-Checkpoint innerhalb von LMI-Containern nicht angeben. Im Java-Modus müssen Sie den Modell-Checkpoint verpacken. Weitere Informationen zur Konfiguration von `serving.properties` und zum Betrieb verschiedener Engines finden Sie unter [Betriebsmodi für DJL Serving](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md). ## Verwenden Sie Endpunkte mit einem einzigen Modell für die Bereitstellung mit DJL Serving Nachdem Sie Ihre Modellartefakte vorbereitet haben, können Sie Ihr Modell auf einem SageMaker KI-Endpunkt bereitstellen. In diesem Abschnitt wird beschrieben, wie Sie mit DJL Serving ein einzelnes Modell auf einem Endpunkt bereitstellen. Wenn Sie mehrere Modelle bereitstellen, überspringen Sie diesen Abschnitt und gehen Sie zu [Verwenden Sie Endpunkte mit mehreren Modellen für die Bereitstellung mit DJL Serving](#deploy-models-frameworks-djl-mme). Das folgende Beispiel zeigt Ihnen eine Methode zum Erstellen eines Modellobjekts mit dem Amazon SageMaker Python SDK. Sie müssen die folgenden Felder angeben: + `image_uri`: Sie können entweder eines der DJL Serving-Basisimages abrufen, wie in diesem Beispiel gezeigt, oder Sie können ein benutzerdefiniertes Docker-Image aus Ihrem Amazon ECR-Repository angeben, wenn Sie die Anweisungen unter [Passen Sie Ihren Container an](#deploy-models-frameworks-djl-byoc) befolgt haben. + `model_s3_url`: Dies sollte ein Amazon-S3-URI sein, der auf Ihre `.tar.gz`Datei verweist. + `model_name`: Geben Sie einen Namen für das Modellobjekt an. ``` 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 ``` ## Verwenden Sie Endpunkte mit mehreren Modellen für die Bereitstellung mit DJL Serving Wenn Sie mehrere Modelle auf einem Endpunkt bereitstellen möchten, bietet SageMaker KI Endpunkte mit mehreren Modellen, die eine skalierbare und kostengünstige Lösung für die Bereitstellung einer großen Anzahl von Modellen darstellen. DJL Serving unterstützt auch das gleichzeitige Laden mehrerer Modelle und das gleichzeitige Ausführen von Inferenzen für jedes der Modelle. DJL Serving Container halten sich an die SageMaker AI-Verträge für Endgeräte mit mehreren Modellen und können zur Bereitstellung von Endpunkten mit mehreren Modellen verwendet werden. Jedes einzelne Modellartefakt muss auf die gleiche Weise verpackt werden, wie im vorherigen Abschnitt [Vorbereiten Ihrer Modellartefakte](#deploy-models-frameworks-djl-artifacts)beschrieben. Sie können modellspezifische Konfigurationen in der `serving.properties` Datei und modellspezifischen Code für den Inferenz-Handler in `model.py` festlegen. Für einen Multimodell-Endpunkt müssen die Modelle wie folgt angeordnet werden: ``` root_dir |-- model_1.tar.gz |-- model_2.tar.gz |-- model_3.tar.gz . . . ``` Das Amazon SageMaker Python SDK verwendet das [MultiDataModel](https://sagemaker.readthedocs.io/en/stable/api/inference/multi_data_model.html)Objekt, um einen Endpunkt mit mehreren Modellen zu instanziieren. Die Amazon-S3-URI für das Stammverzeichnis sollte als `model_data_prefix`-Argument an den `MultiDataModel`-Konstruktor übergeben werden. DJL Serving bietet auch mehrere Konfigurationsparameter zur Verwaltung der Speicheranforderungen des Modells, wie z. B. `required_memory_mb` und `reserved_memory_mb`, die für jedes Modell in der Datei [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties) konfiguriert werden können. Diese Parameter sind nützlich, um Fehler aufgrund unzureichenden Speichers besser behandeln zu können. Alle konfigurierbaren Parameter finden Sie unter [OutofMemory Handling](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/out_of_memory_management.md) in djl-Serving. Mit der Auto-Scaling-Funktion von DJL Serving kann auf einfache Weise sichergestellt werden, dass die Modelle für den eingehenden Verkehr angemessen skaliert werden. Standardmäßig bestimmt DJL Serving die maximale Anzahl von Workern für ein Modell, die auf der Grundlage der verfügbaren Hardware (wie CPU-Kerne oder GPU-Geräte) unterstützt werden kann. Sie können für jedes Modell Unter- und Obergrenzen festlegen, um sicherzustellen, dass immer ein Mindestdatenvolumen bereitgestellt werden kann und dass ein einzelnes Modell nicht alle verfügbaren Ressourcen verbraucht. Sie können die folgenden Eigenschaften in der Datei [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties) festlegen: + `gpu.minWorkers`: Mindestanzahl von Arbeitern für. GPUs + `gpu.maxWorkers`: Maximale Anzahl von Arbeitnehmern für GPUs. + `cpu.minWorkers`: Mindestanzahl von Arbeitnehmern für CPUs. + `cpu.maxWorkers`: Maximale Anzahl von Arbeitnehmern für CPUs. [Ein end-to-end Beispiel für die Bereitstellung eines Multi-Modell-Endpunkts auf SageMaker KI mithilfe eines DJL Serving-Containers finden Sie im Beispiel-Notizbuch Multi-Model-Inference-Demo.ipynb.](https://github.com/deepjavalibrary/djl-demo/blob/master/aws/sagemaker/Multi-Model-Inference-Demo.ipynb) # Modellbereitstellung mit Triton Inference Server [Triton Inference Server](https://github.com/triton-inference-server/server) ist eine Open-Source-Inferenz-Server-Software, die die KI-Inferenz optimiert. Mit Triton können Sie jedes Modell bereitstellen, das mit mehreren Frameworks für Deep Learning und maschinelles Lernen erstellt wurde, darunter TensorRT,,, ONX TensorFlow PyTorch, OpenVINO, Python, RAPIDS FIL und mehr. Die SageMaker KI-Triton-Container helfen Ihnen bei der Bereitstellung von Triton Inference Server auf der KI-Hosting-Plattform, um trainierte Modelle in der SageMaker Produktion bereitzustellen. Es unterstützt die verschiedenen Modi, in denen SageMaker KI arbeitet. Eine Liste der verfügbaren Triton Inference Server-Container, die auf SageMaker KI verfügbar sind, finden Sie unter [NVIDIA Triton Inference Containers (nur SM-Unterstützung)](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#nvidia-triton-inference-containers-sm-support-only). [Für end-to-end Notebook-Beispiele empfehlen wir, einen Blick in das Repository zu werfen. amazon-sagemaker-examples ](https://github.com/aws/amazon-sagemaker-examples/tree/main/sagemaker-triton) ## Hosting-Modi Die folgenden SageMaker KI-Hosting-Modi werden von Triton-Containern unterstützt: + Endpunkte für ein einzelnes Modell + Dies ist der Standardbetriebsmodus von SageMaker AI. In diesem Modus kann der Triton-Container ein einzelnes Modell oder ein einzelnes Ensemble-Modell laden. + Der Name des Modells muss als Eigenschaft der Containerumgebung übergeben werden, die Teil des `CreateModel` SageMaker AI-API-Aufrufs ist. Die Umgebungsvariable, die zur Übergabe des Modellnamens verwendet wird, ist `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Endpunkte eines einzelnen Modells mit Ensemble + Triton Inference Server unterstützt ein *Ensemble*, bei dem es sich um eine Pipeline oder einen DAG (gerichteter azyklischer Graph) von Modellen handelt. Während ein Ensemble technisch gesehen aus mehreren Modellen besteht, kann SageMaker KI im standardmäßigen Einzelmodell-Endpunktmodus das *eigentliche Ensemble* (das Metamodell, das die Pipeline darstellt) als das zu ladende Hauptmodell behandeln und anschließend die zugehörigen Modelle laden. + Zum Laden des Modells muss der Modellname des eigentlichen Ensembles verwendet werden. Es muss als Eigenschaft der Container-Umgebung übergeben werden, die Teil des `CreateModel` SageMaker API-Aufrufs ist. Die Umgebungsvariable, die zur Übergabe des Modellnamens verwendet wird, ist `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Multimodell-Endpunkte + In diesem Modus kann SageMaker KI mehrere Modelle auf einem einzigen Endpunkt bedienen. Sie können diesen Modus verwenden, indem Sie die Umgebungsvariable `‘MultiModel’: true` als Eigenschaft der Container-Umgebung angeben, die Teil des `CreateModel` SageMaker API-Aufrufs ist. + Standardmäßig wird beim Start der Instance kein Modell geladen. Um eine Inferenzanforderung für ein bestimmtes Modell auszuführen, geben Sie die `*.tar.gz` Datei des entsprechenden Modells als Argument für die `TargetModel` Eigenschaft des `InvokeEndpoint` SageMaker API-Aufrufs an. + Endpunkte mit mehreren Modellen und Ensemble + In diesem Modus funktioniert SageMaker KI wie für Endpunkte mit mehreren Modellen beschrieben. Der SageMaker AI Triton-Container kann jedoch mehrere Ensemble-Modelle laden, was bedeutet, dass mehrere Modell-Pipelines auf derselben Instanz ausgeführt werden können. SageMaker AI behandelt jedes Ensemble als ein Modell, und das eigentliche Ensemble jedes Modells kann aufgerufen werden, indem das entsprechende `*.tar.gz` Archiv als angegeben wird. `TargetModel` + Für eine bessere Speicherverwaltung während des dynamischen Speichers `LOAD` und `UNLOAD` empfehlen wir, die Ensemblegröße klein zu halten. ## Inferenz-Payload-Typen Triton unterstützt zwei Methoden zum Senden einer Inferenz-Payload über das Netzwerk – `json` und `binary+json` (oder binär codiertes JSON). Die JSON-Nutzlast umfasst in beiden Fällen den Datentyp, die Form und den eigentlichen Tensor für die Inferenzanforderung. Der Anforderungstensor muss ein binärer Tensor sein. Bei dem `binary+json` Format müssen Sie die Länge der Anforderungsmetadaten im Header angeben, damit Triton die binäre Nutzlast korrekt analysieren kann. Im SageMaker AI Triton-Container erfolgt dies mithilfe eines benutzerdefinierten `Content-Type` Headers:. `application/vnd.sagemaker-triton.binary+json;json-header-size={}` Dies unterscheidet sich von der Verwendung des `Inference-Header-Content-Length` Headers auf einem eigenständigen Triton Inference Server, da benutzerdefinierte Header in KI nicht zulässig sind. SageMaker ## Verwenden Sie config.pbtxt, um die Modellkonfiguration festzulegen Bei Triton Inference Servern auf SageMaker KI muss jedes Modell eine `config.pbtxt` Datei enthalten, die mindestens die folgenden Konfigurationen für das Modell spezifiziert: + `name`: Für Modelle, die außerhalb von SageMaker KI laufen, ist dies zwar optional, wir empfehlen jedoch, dass Sie immer einen Namen für die Modelle angeben, die in Triton on AI ausgeführt werden sollen. SageMaker + [`platform` und/oder `backend`](https://github.com/triton-inference-server/backend/blob/main/README.md#backends): Die Einrichtung eines Backends ist wichtig, um den Typ des Modells zu spezifizieren. Einige Backends haben eine weitere Klassifizierung, wie `tensorflow_savedmodel` oder ` tensorflow_graphdef` zum Beispiel. Solche Optionen können zusätzlich zum Schlüssel `backend` als Teil des `platform` Schlüssels angegeben werden. Die gängigsten Backends sind `tensorrt`, `onnxruntime`, `tensorflow`, `pytorch`, `python`, `dali`, `fil`, und `openvino`. + `input`: Geben Sie drei Attribute für die Eingabe an: `name`, `data_type` und `dims` (die Form). + `output`: Geben Sie drei Attribute für die Ausgabe an: `name`, `data_type` und `dims` (die Form). + `max_batch_size`: Stellen Sie die Chargengröße auf einen Wert größer oder gleich 1 ein, der die maximale Chargengröße angibt, die Triton für das Modell verwenden sollte. [Weitere Informationen zur Konfiguration finden `config.pbtxt` Sie im Triton-Repository. GitHub ](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md) Triton bietet verschiedene Konfigurationen zur Optimierung des Modellverhaltens. Einige der gängigsten und wichtigsten Konfigurationsoptionen sind: + [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): Instance-Gruppen helfen bei der Angabe der Nummer und des Standorts für ein bestimmtes Modell. Sie haben die Attribute `count``kind`, und `gpus` (werden verwendet, wenn `kind` `KIND_GPU` ist). Das `count` Attribut entspricht der Anzahl der Worker. Für die reguläre Bereitstellung von Models hat jeder Worker seine eigene Kopie des Modells. In ähnlicher Weise `count` gibt der in Triton die Anzahl der Modellkopien pro Gerät an. Wenn der `instance_group` Typ beispielsweise `KIND_CPU` ist, hat die CPU die `count` Anzahl der Modellkopien. **Anmerkung** Auf einer GPU-Instance gilt die `instance_group` Konfiguration pro GPU-Gerät. Beispielsweise wird die `count` Anzahl der Modellkopien auf jedem GPU-Gerät platziert, sofern Sie nicht explizit angeben, welche GPU-Geräte das Modell laden sollen. + [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) und [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): Dynamisches Batching wird für statuslose Modelle verwendet, und Sequenz-Batching wird für statusbehaftete Modelle verwendet (bei denen Sie jedes Mal eine Anfrage an dieselbe Modell-Instance weiterleiten möchten). Batching-Scheduler ermöglichen eine modellspezifische Warteschlange, wodurch der Durchsatz je nach Batching-Konfiguration erhöht werden kann. + [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): Ein Ensemble-Modell stellt eine *Pipeline* aus einem oder mehreren Modellen und die Verbindung von Eingabe- und Ausgangstensoren zwischen diesen Modellen dar. Es kann konfiguriert werden, indem `platform` als `ensemble` angegeben wird. Die Ensemble-Konfiguration ist nur eine Darstellung der Modellpipeline. Bei SageMaker KI werden alle Modelle eines Ensembles als vom Ensemble-Modell abhängige Modelle behandelt und bei SageMaker KI-Metriken als ein einziges Modell gezählt, wie z. `LoadedModelCount` ## Veröffentlichung von Triton-Standardmetriken auf Amazon CloudWatch Der NVIDIA Triton Inference Container stellt Metriken an Port 8002 (konfigurierbar) für die verschiedenen Modelle zur Verfügung GPUs , die im Triton Inference Server verwendet werden. [Vollständige Informationen zu den verfügbaren Standardmetriken finden Sie auf der GitHub Seite mit den Triton Inference Server-Metriken.](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/metrics.md) Diese Metriken liegen im Prometheus-Format vor und können mit einer Prometheus-Scraper-Konfiguration gescrapt werden. Ab Version v23.07 unterstützt der SageMaker AI Triton-Container die Veröffentlichung dieser Metriken auf Amazon, CloudWatch indem er einige Umgebungsvariablen angibt. Um die Prometheus-Metriken zu ermitteln, nutzt der SageMaker KI-Triton-Container den Amazon-Agenten. CloudWatch Die erforderlichen Umgebungsvariablen, die Sie für die Erfassung von Metriken angeben müssen, lauten wie folgt: | Umgebungsvariable | Description | Beispielwert | | --- | --- | --- | | `SAGEMAKER_TRITON_ALLOW_METRICS` | Geben Sie diese Option an, damit Triton Metriken auf seinem Prometheus-Endpunkt veröffentlichen kann. | „true“ | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | Geben Sie diese Option an, um die Vorabprüfungen zu starten, die für die Veröffentlichung von Metriken auf Amazon CloudWatch erforderlich sind. | „true“ | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Geben Sie diese Option an, um auf die Protokollgruppe zu verweisen, in die die Metriken geschrieben werden. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesTest" | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Geben Sie diese Option an, um auf den Metrik-Namespace zu verweisen, in dem Sie die Metriken sehen und grafisch darstellen möchten. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesPublicTest" | | `SAGEMAKER_TRITON_METRICS_PORT` | Geben Sie dies als 8002 oder einen anderen Port an. Wenn SageMaker AI den angegebenen Port nicht blockiert hat, wird er verwendet. Andernfalls wird automatisch ein anderer nicht blockierter Port ausgewählt. | „8002" | Beachten Sie bei der Veröffentlichung von Metriken mit Triton auf SageMaker KI die folgenden Einschränkungen: + Sie können zwar benutzerdefinierte Metriken über die C-API und das Python-Backend (ab Version 23.05) generieren, diese werden jedoch derzeit nicht für die Veröffentlichung auf Amazon unterstützt. CloudWatch + Im Modus SageMaker AI Multi-Model Endpoints (MME) läuft Triton in einer Umgebung, in der Modell-Namespacing aktiviert sein muss, da jedes Modell (außer Ensemble-Modellen) so behandelt wird, als ob es sich in seinem eigenen Modell-Repository befände. Derzeit führt dies zu einer Einschränkung für Metriken. Wenn Modell-Namespacing aktiviert ist, unterscheidet Triton die Metriken nicht zwischen zwei Modellen mit demselben Namen, die zu unterschiedlichen Ensembles gehören. Um das Problem zu umgehen, stellen Sie sicher, dass jedes bereitgestellte Modell einen eindeutigen Namen hat. Dies macht es auch einfacher, Ihre Metriken darin nachzuschlagen. CloudWatch ## Umgebungsvariablen In der folgenden Tabelle sind die unterstützten Umgebungsvariablen für Triton on SageMaker AI aufgeführt. | Umgebungsvariable | Description | Typ | Mögliche Werte | | --- | --- | --- | --- | | `SAGEMAKER_MULTI_MODEL` | Ermöglicht Triton den Betrieb im SageMaker KI-Modus für Endgeräte mit mehreren Modellen. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME` | Geben Sie das Modell an, das im SageMaker AI-Einzelmodellmodus (Standard) geladen werden soll. Geben Sie für den Ensemble-Modus den Namen des eigentlichen Ensembles an. | Zeichenfolge | **wie in config.pbtxt angegeben | | `SAGEMAKER_TRITON_PING_MODE` | `'ready'`ist der Standardmodus im Einzelmodellmodus von SageMaker AI und der Standardmodus im `'live'` Mehrmodell-Endpunktmodus von SageMaker AI. | Zeichenfolge | `ready`, `live` | | `SAGEMAKER_TRITON_DISABLE_MODEL_NAMESPACING` | Im SageMaker KI-Triton-Container ist dieser Wert standardmäßig auf `true` eingestellt. | Boolesch | `true`, `false` | | `SAGEMAKER_BIND_TO_PORT` | Bei Verwendung von SageMaker AI ist der Standardport 8080. In Szenarien mit mehreren Containern können Sie eine Anpassung an einen anderen Port vornehmen. | Zeichenfolge | ** | | `SAGEMAKER_SAFE_PORT_RANGE` | Dies wird von der SageMaker AI-Plattform festgelegt, wenn der Multi-Container-Modus verwendet wird. | Zeichenfolge | **–** | | `SAGEMAKER_TRITON_ALLOW_GRPC` | SageMaker KI unterstützt GRPC derzeit zwar nicht, aber wenn Sie Triton vor einem benutzerdefinierten Reverse-Proxy verwenden, können Sie GRPC aktivieren. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_GRPC_PORT` | Der Standardport für GRPC ist 8001, aber Sie können ihn ändern. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_THREAD_COUNT` | Sie können die Anzahl der Standard-HTTP-Request-Handler-Threads festlegen. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_LOG_VERBOSE` | `true`standardmäßig auf SageMaker KI, aber Sie können diese Option selektiv ausschalten. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_LOG_INFO` | `false`standardmäßig auf SageMaker KI. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_LOG_WARNING` | `false`standardmäßig auf SageMaker KI. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_LOG_ERROR` | `false`standardmäßig auf SageMaker KI. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_SHM_DEFAULT_BYTE_SIZE` | Geben Sie die Shm-Größe für das Python-Backend in Byte an. Der Standardwert ist 16 MB, kann aber erhöht werden. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_SHM_GROWTH_BYTE_SIZE` | Geben Sie die Shm-Wachstumsgröße für das Python-Backend in Byte an. Der Standardwert ist 1 MB, kann aber erhöht werden, um größere Inkremente zu ermöglichen. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_TENSORFLOW_VERSION` | Der Standardwert ist `2`. Triton unterstützt Tensorflow 2 ab Triton v23.04 nicht mehr. Sie können diese Variable für frühere Versionen konfigurieren. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_MODEL_LOAD_GPU_LIMIT` | Schränken Sie den maximalen Prozentsatz des GPU-Speichers ein, der für das Laden des Modells verwendet wird, sodass der Rest für die Inferenzanforderungen verwendet werden kann. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_ALLOW_METRICS` | `false`standardmäßig auf SageMaker KI. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_METRICS_PORT` | Der Standard-Port ist 8002. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | `false`standardmäßig auf SageMaker KI. Setzen Sie diese Variable auf, `true` um die Übertragung von Triton-Standardmetriken an Amazon CloudWatch zu ermöglichen. Wenn diese Option aktiviert ist, sind Sie für die CloudWatch Kosten verantwortlich, die entstehen, wenn Kennzahlen auf Ihrem Konto veröffentlicht werden. | Boolesch | `true`, `false` | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Erforderlich, wenn Sie die Veröffentlichung von Kennzahlen auf aktiviert haben CloudWatch. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Erforderlich, wenn Sie die Veröffentlichung von Metriken für aktiviert haben CloudWatch. | Zeichenfolge | ** | | `SAGEMAKER_TRITON_ADDITIONAL_ARGS` | Hängt beim Starten des Triton-Servers alle zusätzlichen Argumente an. | Zeichenfolge | ** |