Fehlerbehebung - Amazon SageMaker KI

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.

Fehlerbehebung

Im Folgenden FAQs können Sie Probleme mit Ihren Amazon SageMaker Asynchronous Inference-Endpunkten beheben.

Sie können die folgenden Methoden verwenden, um die Anzahl der Instances hinter Ihrem Endpunkt zu ermitteln:

  • Sie können die SageMaker KI verwenden DescribeEndpointAPI, um die Anzahl der Instanzen hinter dem Endpunkt zu einem bestimmten Zeitpunkt zu beschreiben.

  • Sie können die Anzahl der Instances abrufen, indem Sie sich Ihre CloudWatch Amazon-Metriken ansehen. Sehen Sie sich die metrics for your endpoint instances an, z. B. CPUUtilization oder, MemoryUtilization und überprüfen Sie die Statistik zur Anzahl der Stichproben für einen Zeitraum von 1 Minute. Die Anzahl sollte der Anzahl der aktiven Instances entsprechen. Der folgende Screenshot zeigt die in der CloudWatch Konsole grafisch dargestellte CPUUtilization Metrik, wobei die Statistik auf eingestellt istSample count, der Zeitraum auf 1 minute eingestellt ist und die resultierende Anzahl 5 ist.

CloudWatch Die Konsole zeigt das Diagramm der Anzahl der aktiven Instances für einen Endpunkt.

In den folgenden Tabellen sind die gängigen einstellbaren Umgebungsvariablen für SageMaker KI-Container nach Framework-Typ aufgeführt.

TensorFlow

Umgebungsvariable Beschreibung

SAGEMAKER_TFS_INSTANCE_COUNT

Bei TensorFlow basierten Modellen ist die tensorflow_model_server Binärdatei die operative Komponente, die dafür verantwortlich ist, ein Modell in den Speicher zu laden, Eingaben anhand eines Modelldiagramms auszuführen und Ausgaben abzuleiten. In der Regel wird eine einzelne Instance dieser Binärdatei gestartet, um Modelle auf einem Endpunkt bereitzustellen. Diese Binärdatei hat intern mehrere Threads und erzeugt mehrere Threads, um auf eine Inferenzanforderung zu antworten. In bestimmten Fällen kann es hilfreich sein, diesen Parameter zu erhöhen, wenn Sie feststellen, dass der CPU ordnungsgemäß ausgelastet ist (über 30% genutzt), der Speicher jedoch nicht ausgelastet ist (weniger als 10% Auslastung). Eine Erhöhung der Anzahl der tensorflow_model_servers zur Verfügung stehenden Server erhöht in der Regel den Durchsatz eines Endpunkts.

SAGEMAKER_TFS_FRACTIONAL_GPU_MEM_MARGIN

Dieser Parameter bestimmt den Anteil des verfügbaren GPU Speichers für die Initialisierung von CUDA DNN /cu und anderen Bibliotheken. GPU 0.2bedeutet, dass 20% des verfügbaren GPU Speichers für die Initialisierung von CUDA /cu DNN und anderen GPU Bibliotheken reserviert sind und 80% des verfügbaren GPU Speichers gleichmäßig auf die TF-Prozesse verteilt werden. GPUSpeicher ist vorab zugewiesen, sofern die allow_growth Option nicht aktiviert ist.

SAGEMAKER_TFS_INTER_OP_PARALLELISM

Dies ist auf die inter_op_parallelism_threads Variable zurückzuführen. Diese Variable bestimmt die Anzahl der Threads, die von unabhängigen, nicht blockierenden Vorgängen verwendet werden. 0 bedeutet, dass das System eine passende Zahl auswählt.

SAGEMAKER_TFS_INTRA_OP_PARALLELISM

Dies ist auf die intra_op_parallelism_threads Variable zurückzuführen. Dies bestimmt die Anzahl der Threads, die für bestimmte Operationen wie Matrixmultiplikation und Reduktionen zur Beschleunigung verwendet werden können. Ein Wert von 0 bedeutet, dass das System eine geeignete Zahl auswählt.

SAGEMAKER_GUNICORN_WORKERS

Dies bestimmt die Anzahl der Auftragnehmer-Prozesse, die Gunicorn zur Bearbeitung von Anfragen starten soll. Dieser Wert wird in Kombination mit anderen Parametern verwendet, um einen Satz abzuleiten, der den Inferenzdurchsatz maximiert. Darüber hinaus SAGEMAKER_GUNICORN_WORKER_CLASS bestimmt der, welche Art von Arbeitskräften hervorgebracht wurden, typischerweise async oder gevent.

SAGEMAKER_GUNICORN_WORKER_CLASS

Dies bestimmt die Anzahl der Auftragnehmer-Prozesse, die Gunicorn zur Bearbeitung von Anfragen starten soll. Dieser Wert wird in Kombination mit anderen Parametern verwendet, um einen Satz abzuleiten, der den Inferenzdurchsatz maximiert. Darüber hinaus SAGEMAKER_GUNICORN_WORKER_CLASS bestimmt der, welche Art von Arbeitskräften hervorgebracht wurden, typischerweise async oder gevent.

OMP_NUM_THREADS

Python verwendet intern OpenMP für die Implementierung von Multithreading innerhalb von Prozessen. In der Regel werden Threads erzeugt, die der Anzahl der CPU Kerne entsprechen. Wenn ein bestimmter Prozess jedoch zusätzlich zu Simultaneous Multi Threading (SMT) implementiert wird, wie z. B. bei Intel HypeThreading, kann es sein, dass er einen bestimmten Kern überlastet, indem er doppelt so viele Threads erzeugt wie die Anzahl der tatsächlichen Kerne. CPU In bestimmten Fällen kann eine Python-Binärdatei bis zu viermal so viele Threads wie verfügbare Prozessorkerne erzeugen. Eine ideale Einstellung für diesen Parameter, wenn Sie die Anzahl der verfügbaren Kerne mithilfe von Worker-Threads überlastet haben, ist daher1, oder die Hälfte der Anzahl der CPU Kerne auf einem bei eingeschaltetem System. CPU SMT

TF_DISABLE_MKL

TF_DISABLE_POOL_ALLOCATOR

In einigen Fällen MKL kann das Ausschalten die Inferenz beschleunigen, wenn TF_DISABLE_MKL und auf eingestellt TF_DISABLE_POOL_ALLOCATOR sind. 1

PyTorch

Umgebungsvariable Beschreibung

SAGEMAKER_TS_MAX_BATCH_DELAY

Dies ist die maximale Batchverzögerungszeit, auf TorchServe deren Empfang gewartet wird.

SAGEMAKER_TS_BATCH_SIZE

Wenn TorchServe es nicht die in batch_size vor Ablauf des Timers angegebene Anzahl von Anfragen empfängt, sendet es die empfangenen Anfragen an den Model-Handler.

SAGEMAKER_TS_MIN_WORKERS

Die Mindestanzahl von Arbeitskräften, auf TorchServe die herunterskaliert werden darf.

SAGEMAKER_TS_MAX_WORKERS

Die maximale Anzahl von Mitarbeitern, auf die TorchServe eine Skalierung erfolgen darf.

SAGEMAKER_TS_RESPONSE_TIMEOUT

Die Zeitverzögerung, nach deren Ablauf die Inferenz abläuft, wenn keine Antwort erfolgt.

SAGEMAKER_TS_MAX_REQUEST_SIZE

Die maximale Nutzlastgröße für TorchServe.

SAGEMAKER_TS_MAX_RESPONSE_SIZE

Die maximale Antwortgröße für TorchServe.

Server mit mehreren Modellen (MMS)

Umgebungsvariable Beschreibung

job_queue_size

Dieser Parameter ist nützlich, wenn Sie ein Szenario haben, in dem der Typ der Nutzlast für die Inferenzanforderung sehr groß ist und aufgrund der größeren Nutzlast möglicherweise ein höherer Heap-Speicherverbrauch für den Heap-Speicher besteht, JVM in dem diese Warteschlange verwaltet wird. Im Idealfall sollten Sie die Heap-Speicheranforderungen JVM niedriger halten und Python-Workern ermöglichen, mehr Speicher für die eigentliche Modellbereitstellung zuzuweisen. JVMdient nur dazu, die HTTP Anfragen zu empfangen, sie in die Warteschlange zu stellen und sie zur Inferenz an die Python-basierten Worker weiterzuleiten. Wenn Sie den erhöhenjob_queue_size, erhöhen Sie möglicherweise den Heap-Speicherverbrauch des JVM und nehmen dem Host letztendlich Speicher weg, der von Python-Workern hätte verwendet werden können. Lassen Sie daher auch bei der Optimierung dieses Parameters Vorsicht walten.

default_workers_per_model

Dieser Parameter ist für die Backend-Modellbereitstellung vorgesehen und kann für die Optimierung nützlich sein, da dies die kritische Komponente der gesamten Modellbereitstellung ist, auf deren Grundlage die Python-Prozesse Threads für jedes Modell erzeugen. Wenn diese Komponente langsamer (oder nicht richtig abgestimmt) ist, ist das Frontend-Tuning möglicherweise nicht effektiv.

Sie können denselben Container für asynchrone Inferenz verwenden wie für Real-Time Inference oder Batch Transform. Sie sollten sicherstellen, dass die Timeouts und die Payload-Größenbeschränkungen für Ihren Container so eingestellt sind, dass größere Payloads und längere Timeouts verarbeitet werden können.

Beachten Sie die folgenden Grenzwerte für asynchrone Inferenz:

  • Größenbeschränkung für die Nutzlast: 1 GB

  • Timeout-Limit: Eine Anfrage kann bis zu 60 Minuten dauern.

  • Warteschlangenmeldung TimeToLive (TTL): 6 Stunden

  • Anzahl der Nachrichten, die in Amazon gespeichert werden könnenSQS: Unbegrenzt. Es gibt jedoch ein Kontingent von 120.000 für die Anzahl der laufenden Nachrichten für eine Standardwarteschlange und 20.000 für eine FIFO Warteschlange.

Im Allgemeinen können Sie mit Asynchronous Inference die Skalierung auf der Grundlage von Aufrufen oder Instances vornehmen. Bei Aufrufmetriken empfiehlt es sich, sich Ihre ApproximateBacklogSize anzusehen. Dabei handelt es sich um eine Metrik, die die Anzahl der Elemente in Ihrer Warteschlange definiert, die noch verarbeitet wurden. Sie können diese Metrik oder Ihre InvocationsPerInstance Metrik verwenden, um zu verstehen, bei welchem Wert TPS Sie möglicherweise eingeschränkt werden. Überprüfen Sie auf Instance-Ebene Ihren Instance-Typ und dessen CPU GPU /Auslastung, um zu definieren, wann eine Skalierung erforderlich ist. Wenn eine einzelne Instance eine Kapazität von über 60-70% aufweist, ist dies oft ein gutes Zeichen dafür, dass Sie Ihre Hardware ausgelastet haben.

Es wird nicht empfohlen, mehrere Skalierungsrichtlinien zu verwenden, da diese zu Konflikten führen und zu Verwirrung auf Hardwareebene führen können, was zu Verzögerungen bei der Skalierung führen kann.

Prüfen Sie, ob Ihr Container Ping verarbeiten und Anfragen gleichzeitig aufrufen kann. SageMaker KI-Aufrufanforderungen dauern ungefähr 3 Minuten. In dieser Zeit schlagen in der Regel mehrere Ping-Anfragen fehl, da das Timeout dazu führt, dass die SageMaker KI Ihren Container als erkennt. Unhealthy

Ja. MaxConcurrentInvocationsPerInstance ist eine Funktion von asynchronen Endpunkten. Dies hängt nicht von der Implementierung des benutzerdefinierten Containers ab. MaxConcurrentInvocationsPerInstance steuert die Geschwindigkeit, mit der Aufrufanforderungen an den Kundencontainer gesendet werden. Wenn dieser Wert auf 1 festgelegt ist, wird immer nur eine Anfrage an den Container gesendet, unabhängig davon, wie viele Auftragnehmer sich im Kundencontainer befinden.

Der Fehler bedeutet, dass der Kundencontainer einen Fehler zurückgegeben hat. SageMaker KI kontrolliert das Verhalten von Kundencontainern nicht. SageMaker KI gibt einfach die Antwort von zurück ModelContainer und versucht es nicht erneut. Wenn Sie möchten, können Sie den Aufruf so konfigurieren, dass er es bei einem Fehler erneut versucht. Wir empfehlen Ihnen, die Container-Protokollierung zu aktivieren und Ihre Container-Logs zu überprüfen, um die Ursache für den 500-Fehler in Ihrem Modell zu finden. Überprüfen Sie auch die entsprechenden CPUUtilization und MemoryUtilization Metriken zum Zeitpunkt des Fehlers. Sie können den S3 auch für FailurePath die Modellantwort in Amazon SNS als Teil der asynchronen Fehlerbenachrichtigungen zur Untersuchung von Fehlern konfigurieren.

Sie können die Metrik InvocationsProcesssed, überprüfen, die mit der Anzahl der Aufrufe übereinstimmen sollte, die Sie erwarten, dass sie in einer Minute verarbeitet werden, basierend auf einer einzigen Parallelität.

Die bewährte Methode besteht darinSNS, Amazon, einen Benachrichtigungsdienst für messaging-orientierte Anwendungen, so zu aktivieren, dass mehrere Abonnenten „Push“ -Benachrichtigungen über zeitkritische Nachrichten aus verschiedenen Transportprotokollen, einschließlich HTTP Amazon SQS und E-Mail, anfordern und empfangen. Asynchronous Inference veröffentlicht Benachrichtigungen, wenn Sie einen Endpunkt mit einem SNS Amazon-Thema erstellen CreateEndpointConfig und dieses angeben.

SNSUm Amazon zur Überprüfung der Prognoseergebnisse von Ihrem asynchronen Endpunkt zu verwenden, müssen Sie zunächst ein Thema erstellen, das Thema abonnieren, Ihr Abonnement für das Thema bestätigen und den Amazon-Ressourcennamen (ARN) dieses Themas notieren. Ausführliche Informationen zum Erstellen, Abonnieren und Finden des SNS Themas Amazon ARN of an Amazon finden Sie unter Amazon Configuring Amazon SNS im Amazon SNS Developer Guide. Weitere Informationen zur Verwendung von Amazon SNS mit Asynchronous Inference finden Sie unter Prognoseergebnisse überprüfen.

Ja. Asynchrone Inferenz bietet einen Mechanismus zum Herunterskalieren auf null Instances, wenn keine Anfragen vorliegen. Wenn Ihr Endpunkt in diesen Zeiträumen auf null Instances herunterskaliert wurde, wird Ihr Endpunkt erst wieder hochskaliert, wenn die Anzahl der Anfragen in der Warteschlange das in Ihrer Skalierungsrichtlinie angegebene Ziel überschreitet. Dies kann zu langen Wartezeiten für Anfragen in der Warteschlange führen. Wenn Sie in solchen Fällen für neue Anfragen, die unter dem angegebenen Warteschlangenziel liegen, von Null auf Instances hochskalieren möchten, können Sie eine zusätzliche Skalierungsrichtlinie namens HasBacklogWithoutCapacity verwenden. Weitere Informationen zur Definition dieser Skalierungsrichtlinie finden Sie unter Autoscale an asynchronous endpoint.

Eine vollständige Liste der von Asynchronous Inference pro Region unterstützten Instances finden Sie unter KI-Preise. SageMaker Prüfen Sie, ob die erforderliche Instance in Ihrer Region verfügbar ist, bevor Sie fortfahren.