Best Practices für Lasttests von Amazon SageMaker-Echtzeit-Inferenzendpunkten

Amazon Sage Maker ist ein vollständig verwalteter Dienst für maschinelles Lernen (ML). Mit SageMaker können Data Scientists und Entwickler schnell und einfach ML-Modelle erstellen und trainieren und diese dann direkt in einer produktionsbereiten gehosteten Umgebung bereitstellen. Es bietet eine integrierte Jupyter-Authoring-Notebook-Instance für den einfachen Zugriff auf Ihre Datenquellen zur Untersuchung und Analyse, sodass Sie keine Server verwalten müssen. Es bietet auch gemeinsame ML-Algorithmen die für die effiziente Ausführung extrem großer Datenmengen in einer verteilten Umgebung optimiert sind.

Die SageMaker-Echtzeit-Inferenz ist ideal für Workloads, die interaktive Echtzeitanforderungen mit geringer Latenz haben. Mit der Echtzeit-Inferenz von SageMaker können Sie REST-Endpunkte bereitstellen, die von einem bestimmten Instance-Typ mit einer bestimmten Menge an Rechenleistung und Arbeitsspeicher unterstützt werden. Die Bereitstellung eines SageMaker-Echtzeitendpunkts ist für viele Kunden nur der erste Schritt auf dem Weg zur Produktion. Wir möchten in der Lage sein, die Leistung des Endpunkts zu maximieren, um ein Ziel für Transaktionen pro Sekunde (TPS) zu erreichen und gleichzeitig Latenzanforderungen einzuhalten. Ein großer Teil der Leistungsoptimierung für Inferenz besteht darin, sicherzustellen, dass Sie den richtigen Instance-Typ auswählen und zählen, um einen Endpunkt zu unterstützen.

Dieser Beitrag beschreibt die Best Practices für Lasttests eines SageMaker-Endpunkts, um die richtige Konfiguration für die Anzahl der Instanzen und die Größe zu finden. Dies kann uns helfen, die Mindestanforderungen an bereitgestellte Instanzen zu verstehen, um unsere Latenz- und TPS-Anforderungen zu erfüllen. Von dort aus tauchen wir ein, wie Sie die Metriken und die Leistung der Nutzung des SageMaker-Endpunkts verfolgen und verstehen können Amazon CloudWatch Metriken.

Wir vergleichen zunächst die Leistung unseres Modells auf einer einzelnen Instanz, um das TPS zu identifizieren, das es gemäß unseren akzeptablen Latenzanforderungen verarbeiten kann. Dann extrapolieren wir die Ergebnisse, um über die Anzahl der Instanzen zu entscheiden, die wir benötigen, um unseren Produktionsdatenverkehr zu bewältigen. Schließlich simulieren wir Datenverkehr auf Produktionsebene und richten Belastungstests für einen Echtzeit-SageMaker-Endpunkt ein, um zu bestätigen, dass unser Endpunkt die Last auf Produktionsebene bewältigen kann. Der gesamte Codesatz für das Beispiel ist im Folgenden verfügbar GitHub-Repository.

Lösungsübersicht

Für diesen Posten setzen wir einen vortrainierten ein Umarmendes Gesicht DistilBERT-Modell von dem Face Hub umarmen. Dieses Modell kann eine Reihe von Aufgaben ausführen, aber wir senden eine Nutzlast speziell für die Stimmungsanalyse und Textklassifizierung. Mit dieser Beispielnutzlast streben wir 1000 TPS an.

Stellen Sie einen Echtzeit-Endpunkt bereit

In diesem Beitrag wird davon ausgegangen, dass Sie mit der Bereitstellung eines Modells vertraut sind. Beziehen auf Erstellen Sie Ihren Endpunkt und stellen Sie Ihr Modell bereit die Interna hinter dem Hosten eines Endpunkts zu verstehen. Im Moment können wir schnell auf dieses Modell im Hugging Face Hub verweisen und einen Echtzeit-Endpunkt mit dem folgenden Code-Snippet bereitstellen:

# Hub Model configuration. https://huggingface.co/models
hub = { 'HF_MODEL_ID':'distilbert-base-uncased', 'HF_TASK':'text-classification'
} # create Hugging Face Model Class
huggingface_model = HuggingFaceModel(
transformers_version='4.17.0',
pytorch_version='1.10.2',
py_version='py38',
env=hub,
role=role,
) # deploy model to SageMaker Inference
predictor = huggingface_model.deploy(
initial_instance_count=1, # number of instances
instance_type='ml.m5.12xlarge' # ec2 instance type
)

Lassen Sie uns unseren Endpunkt schnell mit der Beispielnutzlast testen, die wir für Lasttests verwenden möchten:

import boto3
import json
client = boto3.client('sagemaker-runtime')
content_type = "application/json"
request_body = {'inputs': "I am super happy right now."}
data = json.loads(json.dumps(request_body))
payload = json.dumps(data)
response = client.invoke_endpoint(
EndpointName=predictor.endpoint_name,
ContentType=content_type,
Body=payload)
result = response['Body'].read()
result

Beachten Sie, dass wir den Endpunkt mit einer einzigen unterstützen Amazon Elastic Compute-Cloud (Amazon EC2)-Instance vom Typ ml.m5.12xlarge, die 48 vCPU und 192 GiB Arbeitsspeicher enthält. Die Anzahl der vCPUs ist ein guter Hinweis auf die Parallelität, die die Instanz verarbeiten kann. Im Allgemeinen wird empfohlen, verschiedene Instanztypen zu testen, um sicherzustellen, dass wir eine Instanz haben, deren Ressourcen ordnungsgemäß genutzt werden. Eine vollständige Liste der SageMaker-Instanzen und ihrer entsprechenden Rechenleistung für Echtzeit-Inferenz finden Sie unter Amazon SageMaker Preise.

Zu verfolgende Metriken

Bevor wir mit Lasttests beginnen können, ist es wichtig zu verstehen, welche Metriken nachverfolgt werden müssen, um den Leistungsabfall Ihres SageMaker-Endpunkts zu verstehen. CloudWatch ist das primäre Protokollierungstool, das SageMaker verwendet, um Ihnen dabei zu helfen, die verschiedenen Metriken zu verstehen, die die Leistung Ihres Endpunkts beschreiben. Sie können CloudWatch-Protokolle verwenden, um Ihre Endpunktaufrufe zu debuggen; Alle Protokollierungs- und Druckanweisungen, die Sie in Ihrem Inferenzcode haben, werden hier erfasst. Weitere Informationen finden Sie unter So funktioniert Amazon CloudWatch.

Es gibt zwei verschiedene Arten von Metriken, die CloudWatch für SageMaker abdeckt: Metriken auf Instanzebene und Aufrufmetriken.

Metriken auf Instanzebene

Der erste zu berücksichtigende Parametersatz sind die Metriken auf Instanzebene: CPUUtilization und MemoryUtilization (für GPU-basierte Instanzen, GPUUtilization). Für CPUUtilization, sehen Sie in CloudWatch möglicherweise zunächst Prozentsätze über 100 %. Es ist wichtig zu erkennen, für CPUUtilization, wird die Summe aller CPU-Kerne angezeigt. Wenn die Instanz hinter Ihrem Endpunkt beispielsweise 4 vCPUs enthält, bedeutet dies, dass der Nutzungsbereich bis zu 400 % beträgt. MemoryUtilizationhingegen liegt im Bereich von 0–100 %.

Konkret können Sie CPUUtilization um ein tieferes Verständnis dafür zu bekommen, ob Sie über ausreichende oder sogar überschüssige Hardware verfügen. Wenn Sie eine nicht ausgelastete Instanz haben (weniger als 30 %), könnten Sie Ihren Instanztyp möglicherweise herunterskalieren. Umgekehrt wäre es bei einer Auslastung von etwa 80–90 % vorteilhaft, eine Instanz mit mehr Rechenleistung/Arbeitsspeicher auszuwählen. Aus unseren Tests schlagen wir eine Auslastung Ihrer Hardware von etwa 60–70 % vor.

Aufrufmetriken

Wie der Name schon sagt, können wir mithilfe von Aufrufmetriken die End-to-End-Latenz aller Aufrufe an Ihren Endpunkt verfolgen. Sie können die Aufrufmetriken verwenden, um die Fehleranzahl und die Art von Fehlern (5xx, 4xx usw.) zu erfassen, die möglicherweise auf Ihrem Endpunkt auftreten. Noch wichtiger ist, dass Sie die Latenzaufschlüsselung Ihrer Endpunktanrufe nachvollziehen können. Vieles davon lässt sich damit einfangen ModelLatency und OverheadLatency Metriken, wie im folgenden Diagramm dargestellt.

Das ModelLatency Die Metrik erfasst die Zeit, die die Inferenz innerhalb des Modellcontainers hinter einem SageMaker-Endpunkt benötigt. Beachten Sie, dass der Modellcontainer auch benutzerdefinierten Rückschlusscode oder Skripts enthält, die Sie für Rückschlüsse übergeben haben. Diese Einheit wird als Aufrufmetrik in Mikrosekunden erfasst, und im Allgemeinen können Sie ein Perzentil über CloudWatch (p99, p90 usw.) grafisch darstellen, um zu sehen, ob Sie Ihre Ziellatenz erreichen. Beachten Sie, dass sich mehrere Faktoren auf die Modell- und Containerlatenz auswirken können, z. B. die folgenden:

• Benutzerdefiniertes Inferenzskript – Unabhängig davon, ob Sie Ihren eigenen Container implementiert oder einen SageMaker-basierten Container mit benutzerdefinierten Inferenzhandlern verwendet haben, empfiehlt es sich, Ihr Skript zu profilieren, um alle Vorgänge abzufangen, die speziell viel Zeit zu Ihrer Latenz hinzufügen.
• Kommunikationsprotokoll – Erwägen Sie REST- vs. gRPC-Verbindungen zum Modellserver innerhalb des Modellcontainers.
• Modell-Framework-Optimierungen – Dies ist Framework-spezifisch, zum Beispiel mit TensorFlow, gibt es eine Reihe von Umgebungsvariablen, die Sie optimieren können und die spezifisch für TF Serving sind. Stellen Sie sicher, dass Sie überprüfen, welchen Container Sie verwenden und ob es Framework-spezifische Optimierungen gibt, die Sie innerhalb des Skripts oder als Umgebungsvariablen zum Einfügen in den Container hinzufügen können.

OverheadLatency wird ab dem Zeitpunkt gemessen, an dem SageMaker die Anfrage erhält, bis es eine Antwort an den Client zurücksendet, abzüglich der Modelllatenz. Dieser Teil liegt weitgehend außerhalb Ihrer Kontrolle und fällt unter die Zeit, die von SageMaker-Overheads in Anspruch genommen wird.

Die End-to-End-Latenz als Ganzes hängt von einer Vielzahl von Faktoren ab und ist nicht unbedingt die Summe von ModelLatency erfahren OverheadLatency. Zum Beispiel, wenn Ihr Kunde das macht InvokeEndpoint API-Aufruf über das Internet, aus Sicht des Clients wäre die End-to-End-Latenz Internet + ModelLatency + OverheadLatency. Daher wird empfohlen, sich beim Lasttest Ihres Endpunkts zum genauen Benchmarking des Endpunkts selbst auf die Endpunktmetriken zu konzentrieren (ModelLatency, OverheadLatency und InvocationsPerInstance) zum genauen Benchmarking des SageMaker-Endpunkts. Alle Probleme im Zusammenhang mit End-to-End-Latenz können dann separat isoliert werden.

Einige Fragen zur End-to-End-Latenz:

• Wo ist der Client, der Ihren Endpunkt aufruft?
• Gibt es Zwischenschichten zwischen Ihrem Client und der SageMaker-Laufzeitumgebung?

Automatische Skalierung

Wir behandeln die automatische Skalierung in diesem Beitrag nicht speziell, aber es ist eine wichtige Überlegung, um die richtige Anzahl von Instanzen basierend auf der Arbeitslast bereitzustellen. Abhängig von Ihren Verkehrsmustern können Sie eine anhängen Auto Scaling-Richtlinie zu Ihrem SageMaker-Endpunkt. Es gibt verschiedene Skalierungsmöglichkeiten, wie z TargetTrackingScaling, SimpleScaling und StepScaling. Dadurch kann Ihr Endpunkt basierend auf Ihrem Datenverkehrsmuster automatisch ein- und ausskaliert werden.

Eine gängige Option ist die Zielverfolgung, bei der Sie eine CloudWatch-Metrik oder eine benutzerdefinierte Metrik angeben können, die Sie definiert haben, und basierend darauf skalieren. Eine häufige Anwendung der automatischen Skalierung ist das Tracking InvocationsPerInstance metrisch. Nachdem Sie einen Engpass bei einem bestimmten TPS identifiziert haben, können Sie dies oft als Metrik verwenden, um auf eine größere Anzahl von Instanzen zu skalieren, um Spitzenlasten des Datenverkehrs bewältigen zu können. Eine tiefere Aufschlüsselung der automatischen Skalierung von SageMaker-Endpunkten finden Sie unter Konfigurieren von Autoscaling-Inferenzendpunkten in Amazon SageMaker.

Lastprüfung

Obwohl wir Locust verwenden, um anzuzeigen, wie wir Tests in großem Maßstab laden können, wenn Sie versuchen, die Instanz hinter Ihrem Endpunkt richtig zu dimensionieren, SageMaker-Inferenz-Empfehler ist eine effizientere Option. Mit Lasttest-Tools von Drittanbietern müssen Sie Endpunkte manuell über verschiedene Instanzen hinweg bereitstellen. Mit Inference Recommender können Sie einfach ein Array der Instance-Typen übergeben, für die Sie den Test laden möchten, und SageMaker wird gestartet Jobs & Karriere für jeden dieser Fälle.

Heuschrecke

Für dieses Beispiel verwenden wir Heuschrecke, ein Open-Source-Lasttesttool, das Sie mit Python implementieren können. Locust ist vielen anderen Open-Source-Lasttest-Tools ähnlich, hat aber einige spezifische Vorteile:

• Einfache Einrichtung – Wie wir in diesem Beitrag demonstrieren, übergeben wir ein einfaches Python-Skript, das leicht für Ihren spezifischen Endpunkt und Ihre Nutzlast umgestaltet werden kann.
• Verteilt und skalierbar – Locust ist ereignisbasiert und nutzt gevent unter der Haube. Dies ist sehr nützlich, um hochgradig gleichzeitige Workloads zu testen und Tausende von gleichzeitigen Benutzern zu simulieren. Sie können mit einem einzigen Prozess, auf dem Locust läuft, eine hohe TPS erreichen, aber es hat auch eine verteilte Lasterzeugung Funktion, mit der Sie auf mehrere Prozesse und Client-Computer skalieren können, wie wir in diesem Beitrag untersuchen werden.
• Locust-Metriken und Benutzeroberfläche – Locust erfasst auch die End-to-End-Latenz als Metrik. Dies kann dazu beitragen, Ihre CloudWatch-Metriken zu ergänzen, um ein vollständiges Bild Ihrer Tests zu zeichnen. Dies wird alles in der Locust-Benutzeroberfläche erfasst, wo Sie gleichzeitige Benutzer, Arbeiter und mehr verfolgen können.

Um Locust besser zu verstehen, schauen Sie sich ihre an Dokumentation.

Amazon EC2-Setup

Sie können Locust in jeder für Sie kompatiblen Umgebung einrichten. Für diesen Beitrag richten wir eine EC2-Instanz ein und installieren dort Locust, um unsere Tests durchzuführen. Wir verwenden eine c5.18xlarge EC2-Instanz. Die clientseitige Rechenleistung ist ebenfalls zu berücksichtigen. Wenn Ihnen auf der Clientseite die Rechenleistung ausgeht, wird dies häufig nicht erfasst und fälschlicherweise als SageMaker-Endpunktfehler angesehen. Es ist wichtig, Ihren Client an einem Ort mit ausreichender Rechenleistung zu platzieren, der die Last bewältigen kann, mit der Sie testen. Für unsere EC2-Instance verwenden wir ein Ubuntu Deep Learning AMI, aber Sie können jedes AMI verwenden, solange Sie Locust auf dem Computer ordnungsgemäß einrichten können. Um zu verstehen, wie Sie Ihre EC2-Instance starten und sich mit ihr verbinden, lesen Sie das Tutorial Beginnen Sie mit Amazon EC2 Linux-Instances.

Die Locust-Benutzeroberfläche ist über Port 8089 zugänglich. Wir können dies öffnen, indem wir unsere eingehenden Sicherheitsgruppenregeln für die EC2-Instanz anpassen. Wir öffnen auch Port 22, damit wir per SSH in die EC2-Instanz gelangen können. Erwägen Sie, die Quelle auf die spezifische IP-Adresse zu beschränken, von der aus Sie auf die EC2-Instance zugreifen.

Nachdem Sie mit Ihrer EC2-Instance verbunden sind, richten wir eine virtuelle Python-Umgebung ein und installieren die Open-Source-Locust-API über die CLI:

virtualenv venv #venv is the virtual environment name, you can change as you desire
source venv/bin/activate #activate virtual environment
pip install locust

Wir sind jetzt bereit, mit Locust für Lasttests unseres Endpunkts zusammenzuarbeiten.

Heuschreckentest

Alle Locust-Belastungstests werden basierend auf a Locust-Datei die Sie bereitstellen. Diese Locust-Datei definiert eine Aufgabe für den Lasttest; Hier definieren wir unser Boto3 invoke_endpoint API-Aufruf. Siehe folgenden Code:

config = Config(
retries = { 'max_attempts': 0, 'mode': 'standard'
}
) self.sagemaker_client = boto3.client('sagemaker-runtime',config=config)
self.endpoint_name = host.split('/')[-1]
self.region = region
self.content_type = content_type
self.payload = payload

Passen Sie im vorangehenden Code die Aufrufparameter für den Aufrufendpunkt so an, dass sie zu Ihrem spezifischen Modellaufruf passen. Wir benutzen das InvokeEndpoint API, die den folgenden Codeabschnitt in der Locust-Datei verwendet; Dies ist unser Belastungstestlaufpunkt. Die Locust-Datei, die wir verwenden, ist locust_script.py.

def send(self): request_meta = { "request_type": "InvokeEndpoint", "name": "SageMaker", "start_time": time.time(), "response_length": 0, "response": None, "context": {}, "exception": None,
}
start_perf_counter = time.perf_counter() try:
response = self.sagemaker_client.invoke_endpoint(
EndpointName=self.endpoint_name,
Body=self.payload,
ContentType=self.content_type
)
response_body = response["Body"].read()

Nachdem wir unser Locust-Skript fertig haben, möchten wir verteilte Locust-Tests ausführen, um unsere einzelne Instanz einem Stresstest zu unterziehen und herauszufinden, wie viel Datenverkehr unsere Instanz verarbeiten kann.

Der verteilte Locust-Modus ist etwas nuancierter als ein Einzelprozess-Locust-Test. Im verteilten Modus haben wir einen primären und mehrere Worker. Der primäre Worker weist die Worker an, wie die gleichzeitigen Benutzer, die eine Anfrage senden, generiert und gesteuert werden. In unserer verteilt.sh script sehen wir standardmäßig, dass 240 Benutzer auf die 60 Worker verteilt werden. Notiere dass der --headless -Flag in der Locust-CLI entfernt die UI-Funktion von Locust.

#replace with your endpoint name in format https://<<endpoint-name>>
export ENDPOINT_NAME=https://$1 export REGION=us-east-1
export CONTENT_TYPE=application/json
export PAYLOAD='{"inputs": "I am super happy right now."}'
export USERS=240
export WORKERS=60
export RUN_TIME=1m
export LOCUST_UI=false # Use Locust UI .
.
. locust -f $SCRIPT -H $ENDPOINT_NAME --master --expect-workers $WORKERS -u $USERS -t $RUN_TIME --csv results &
.
.
. for (( c=1; c<=$WORKERS; c++ ))
do
locust -f $SCRIPT -H $ENDPOINT_NAME --worker --master-host=localhost &
done

./distributed.sh huggingface-pytorch-inference-2022-10-04-02-46-44-677 #to execute Distributed Locust test

Wir führen den verteilten Test zuerst auf einer einzelnen Instanz aus, die den Endpunkt unterstützt. Die Idee dabei ist, dass wir eine einzelne Instanz vollständig maximieren möchten, um die Anzahl der Instanzen zu verstehen, die wir benötigen, um unser Ziel-TPS zu erreichen und gleichzeitig unsere Latenzanforderungen einzuhalten. Beachten Sie, dass Sie die ändern müssen, wenn Sie auf die Benutzeroberfläche zugreifen möchten Locust_UI Umgebungsvariable auf True und nehmen Sie die öffentliche IP Ihrer EC2-Instance und ordnen Sie Port 8089 der URL zu.

Der folgende Screenshot zeigt unsere CloudWatch-Metriken.

Schließlich bemerken wir, dass wir, obwohl wir anfänglich einen TPS von 200 erreichen, 5xx-Fehler in unseren clientseitigen EC2-Protokollen bemerken, wie im folgenden Screenshot gezeigt.

Wir können dies auch überprüfen, indem wir uns speziell unsere Metriken auf Instanzebene ansehen CPUUtilization.

Hier bemerken wir CPUUtilization bei fast 4,800 %. Unsere ml.m5.12x.large-Instanz hat 48 vCPUs (48 * 100 = 4800~). Dies sättigt die gesamte Instanz, was auch unsere 5xx-Fehler erklärt. Wir sehen auch eine Zunahme ModelLatency.

Es scheint, als ob unsere einzelne Instanz gestürzt wird und nicht über die Rechenleistung verfügt, um eine Last über die von uns beobachteten 200 TPS hinaus auszuhalten. Unser Ziel-TPS ist 1000, also versuchen wir, unsere Instanzanzahl auf 5 zu erhöhen. Dies muss in einer Produktionsumgebung möglicherweise sogar noch mehr sein, da wir ab einem bestimmten Punkt Fehler bei 200 TPS beobachtet haben.

Wir sehen sowohl in den Protokollen der Locust-Benutzeroberfläche als auch in CloudWatch, dass wir einen TPS von fast 1000 haben, wobei fünf Instanzen den Endpunkt unterstützen.

Wenn Sie selbst bei diesem Hardware-Setup Fehler feststellen, stellen Sie sicher, dass Sie dies überwachen CPUUtilization um das Gesamtbild hinter Ihrem Endpoint-Hosting zu verstehen. Es ist wichtig, Ihre Hardwareauslastung zu verstehen, um zu sehen, ob Sie hoch- oder sogar herunterskalieren müssen. Manchmal führen Probleme auf Containerebene zu 5xx-Fehlern, aber wenn CPUUtilization niedrig ist, weist dies darauf hin, dass es nicht Ihre Hardware ist, sondern etwas auf Container- oder Modellebene, das zu diesen Problemen führen könnte (z. B. keine richtige Umgebungsvariable für die Anzahl der Worker festgelegt). Wenn Sie andererseits bemerken, dass Ihre Instanz vollständig ausgelastet ist, ist dies ein Zeichen dafür, dass Sie entweder die aktuelle Instanzflotte erhöhen oder eine größere Instanz mit einer kleineren Flotte ausprobieren müssen.

Obwohl wir die Anzahl der Instanzen auf 5 erhöht haben, um 100 TPS zu verarbeiten, können wir sehen, dass die ModelLatency Metrik ist immer noch hoch. Dies liegt daran, dass die Instanzen gesättigt sind. Im Allgemeinen empfehlen wir, die Ressourcen der Instanz zu 60–70 % auszulasten.

Aufräumen

Stellen Sie nach dem Auslastungstest sicher, dass Sie alle Ressourcen bereinigen, die Sie nicht über die SageMaker-Konsole oder über die verwenden delete_endpoint Boto3-API-Aufruf. Stellen Sie außerdem sicher, dass Sie Ihre EC2-Instanz oder die Client-Konfiguration, die Sie haben, stoppen, damit auch dort keine weiteren Gebühren anfallen.

Zusammenfassung

In diesem Beitrag haben wir beschrieben, wie Sie Ihren SageMaker-Echtzeit-Endpunkt einem Lasttest unterziehen können. Wir haben auch besprochen, welche Metriken Sie beim Lasttest Ihres Endpunkts auswerten sollten, um Ihren Leistungsabfall zu verstehen. Schauen Sie unbedingt vorbei SageMaker-Inferenz-Empfehler um die richtige Größe von Instanzen und weitere Techniken zur Leistungsoptimierung besser zu verstehen.

Über die Autoren

Markus Karp ist ML-Architekt im SageMaker-Serviceteam. Er konzentriert sich darauf, Kunden dabei zu helfen, ML-Workloads in großem Umfang zu entwerfen, bereitzustellen und zu verwalten. In seiner Freizeit reist er gerne und entdeckt neue Orte.

Widder Vegiraju ist ML-Architekt im SageMaker-Serviceteam. Er konzentriert sich darauf, Kunden bei der Erstellung und Optimierung ihrer KI/ML-Lösungen auf Amazon SageMaker zu unterstützen. In seiner Freizeit liebt er es zu reisen und zu schreiben.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/best-practices-for-load-testing-amazon-sagemaker-real-time-inference-endpoints/