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
Die folgenden häufig gestellten Fragen können Ihnen helfen, Probleme mit Ihren Amazon SageMaker Asynchronous Inference-Endpoints zu beheben.
## F: Ich habe Autoscaling aktiviert. Wie kann ich die Anzahl der Instances hinter dem Endpunkt zu einem bestimmten Zeitpunkt ermitteln?
Sie können die folgenden Methoden verwenden, um die Anzahl der Instances hinter Ihrem Endpunkt zu ermitteln:
+ Sie können die [DescribeEndpoint-API](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html) von SageMaker AI verwenden, um die Anzahl der Instances hinter dem Endpunkt zu einem bestimmten Zeitpunkt zu beschreiben.
+ Sie können die Anzahl der Instances abrufen, indem Sie sich Ihre Amazon CloudWatch-Metriken ansehen. Sehen Sie sich die [metrics for your endpoint instances](https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-jobs) 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 `Sample count` eingestellt ist, der **Zeitraum** auf `1 minute` eingestellt ist und die resultierende Anzahl 5 ist.
## F: Was sind die allgemeinen einstellbaren Umgebungsvariablen für SageMaker-AI-Container?
In den folgenden Tabellen sind die allgemeinen einstellbaren Umgebungsvariablen für SageMaker-AI-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 gegen einen Modellgraphen 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 die CPU angemessen ausgelastet ist (über 30% ausgelastet), 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/cuDNN und anderen GPU-Bibliotheken. `0.2` bedeutet, dass 20% des verfügbaren GPU-Speichers für die Initialisierung von Cuda/cuDNN und anderen GPU-Bibliotheken reserviert sind und 80% des verfügbaren GPU-Speichers gleichmäßig auf die TF-Prozesse verteilt sind. Der GPU-Speicher 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. Intels HyperThreading, kann es sein, dass ein bestimmter Prozess einen bestimmten Kern überlastet, indem er doppelt so viele Threads erzeugt wie die Anzahl der tatsächlichen CPU-Kerne. In bestimmten Fällen kann eine Python-Binärdatei bis zu viermal so viele Threads wie verfügbare Prozessorkerne erzeugen. Daher ist eine ideale Einstellung für diesen Parameter, wenn Sie die verfügbaren Kerne mit Auftragnehmer-Threads überbelegt haben, `1` oder die Hälfte der Anzahl der CPU-Kerne auf einer CPU mit aktiviertem SMT. |
| `TF_DISABLE_MKL`
`TF_DISABLE_POOL_ALLOCATOR` | In einigen Fällen kann das Ausschalten von MKL die Inferenz beschleunigen, wenn `TF_DISABLE_MKL` und `TF_DISABLE_POOL_ALLOCATOR` auf `1` eingestellt sind. |
**PyTorch**
| Umgebungsvariable | Beschreibung |
| --- | --- |
| `SAGEMAKER_TS_MAX_BATCH_DELAY` | Dies ist die maximale Batch-Verzögerungszeit, auf deren Empfang TorchServe wartet. |
| `SAGEMAKER_TS_BATCH_SIZE` | Wenn TorchServe vor Ablauf des Timers nicht die in `batch_size` angegebene Anzahl von Anfragen empfängt, sendet es die empfangenen Anfragen an den Model-Handler. |
| `SAGEMAKER_TS_MIN_WORKERS` | Die Mindestanzahl von Workern, auf die TorchServe herunterskalieren darf. |
| `SAGEMAKER_TS_MAX_WORKERS` | Die maximale Anzahl von Workern, auf die TorchServe skaliert werden 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. |
**Multi Model Server (MMS)**
| Umgebungsvariable | Beschreibung |
| --- | --- |
| `job_queue_size` | Dieser Parameter ist nützlich, wenn Sie ein Szenario haben, in dem der Typ der Nutzlast der Inferenzanforderung groß ist und aufgrund der größeren Nutzlast möglicherweise ein höherer Heap-Speicherverbrauch der JVM, in der diese Warteschlange verwaltet wird, auftreten kann. Im Idealfall sollten Sie die Heap-Speicheranforderungen von JVM niedriger halten und Python-Workern ermöglichen, mehr Speicher für die eigentliche Modellbereitstellung zuzuweisen. JVM dient 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 `job_queue_size` erhöhen, erhöhen Sie möglicherweise den Heap-Speicherverbrauch der 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. |
## F: Wie stelle ich sicher, dass mein Container asynchrone Inferenz unterstützt?
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.
## F: Was sind die spezifischen Grenzwerte für asynchrone Inferenz, und können sie angepasst werden?
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.
+ Warteschlangennachricht TimeToLive (TTL): 6 Stunden
+ Anzahl der Nachrichten, die in Amazon SQS gespeichert werden können: 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.
## F: Welche Metriken eignen sich am besten für die automatische Skalierung bei asynchroner Inferenz? Kann ich mehrere Skalierungsrichtlinien haben?
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 TPS Sie möglicherweise gedrosselt 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.
## F: Warum beendet mein asynchroner Endpunkt eine Instance `Unhealthy` und die Aktualisierungsanforderungen von Autoscaling schlagen fehl?
Prüfen Sie, ob Ihr Container in der Lage ist, Ping- und Aufruf-Anfragen gleichzeitig zu verarbeiten. SageMaker-AI-Aufrufanfragen dauern ungefähr 3 Minuten. In dieser Zeit schlagen in der Regel mehrere Ping-Anfragen fehl, da das Timeout dazu führt, dass SageMaker AI Ihren Container als `Unhealthy` erkennt.
## F: Kann `MaxConcurrentInvocationsPerInstance` mit den Ningx/Gunicorn/Flask-Einstellungen für meinen BYOC-Modellcontainer arbeiten?
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.
## F: Wie kann ich Modellserverfehler (500) auf meinem asynchronen Endpunkt debuggen?
Der Fehler bedeutet, dass der Kundencontainer einen Fehler zurückgegeben hat. SageMaker AI kontrolliert nicht das Verhalten von Kundencontainern. SageMaker AI gibt einfach die Antwort von `ModelContainer` zurück 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 auch den [S3FailurePath](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AsyncInferenceOutputConfig.html#sagemaker-Type-AsyncInferenceOutputConfig-S3FailurePath) zur Modellantwort in Amazon SNS als Teil der asynchronen Fehlerbenachrichtigungen konfigurieren, um Fehler zu untersuchen.
## F: Wie kann ich wissen, ob `MaxConcurrentInvocationsPerInstance=1` wirksam wird? Gibt es irgendwelche Kennzahlen, die ich überprüfen kann?
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.
## F: Wie kann ich den Erfolg und Misserfolg meiner Aufrufanfragen verfolgen? Was sind die besten Methoden?
Die bewährte Methode besteht darin, Amazon SNS zu aktivieren, einen Benachrichtigungsdienst für messaging-orientierte Anwendungen, bei dem mehrere Abonnenten „Push“ -Benachrichtigungen über zeitkritische Nachrichten über verschiedene Transportprotokolle wie HTTP, Amazon SQS und E-Mail anfordern und empfangen. Asynchronous Inference sendet Benachrichtigungen, wenn Sie einen Endpunkt mit `CreateEndpointConfig` und einen Amazon SNS-Thema angeben.
Um Amazon SNS 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 Auffinden des Amazon-ARN eines Amazon SNS-Themas finden Sie unter [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html) im *Amazon SNS SNS-Entwicklerhandbuch*. Weitere Informationen zur Verwendung von Amazon SNS mit asynchroner Inferenz finden Sie unter [Überprüfen der Prognoseergebnisse](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-check-predictions.html).
## F: Kann ich eine Skalierungsrichtlinie definieren, die bei Erhalt einer neuen Anfrage von Null auf Instances hochskaliert?
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](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-autoscale.html#async-inference-autoscale-scale-up).
## F: Ich erhalte die Fehlermeldung, dass der Instance-Typ für asynchrone Inferenz nicht unterstützt wird. Welche Instance-Typen unterstützt Asynchronous Inference?
Eine vollständige Liste der von Asynchronous Inference pro Region unterstützten Instances finden Sie unter [SageMaker-Preise.](https://aws.amazon.com/sagemaker/pricing/) Prüfen Sie, ob die erforderliche Instance in Ihrer Region verfügbar ist, bevor Sie fortfahren.