View a markdown version of this page

Konfigurieren Sie Anforderungslimits für die Bereitstellung Ihres HyperPod Inferenzmodells - Amazon SageMaker KI
VoraussetzungenKonfigurieren Sie die Anforderungslimits in Ihrer YAML-BereitstellungErläuterung der FelderWie funktioniert die AnforderungsbegrenzungBeispiele

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.

Konfigurieren Sie Anforderungslimits für die Bereitstellung Ihres HyperPod Inferenzmodells

Sie können das Anforderungslimit für Ihre SageMaker HyperPod Amazon-Inferenzmodellbereitstellungen konfigurieren, um die Anzahl der gleichzeitigen Anfragen zu kontrollieren, die jeder Pod akzeptiert. Wenn das Limit erreicht ist, erhalten überzählige Anfragen eine konfigurierbare HTTP-Fehlerantwort, die ein Fail-Fast-Verhalten ermöglicht und es dem Load Balancer ermöglicht, den Datenverkehr an andere Pods umzuleiten.

Die Anforderungsbegrenzung wird durch den Nginx-Sidecar-Proxy erzwungen, der zusammen mit Ihrem Modellcontainer ausgeführt wird. Dazu müssen Metriken in Ihrer Bereitstellung aktiviert sein.

Voraussetzungen

Stellen Sie vor der Konfiguration von Anforderungslimits sicher, dass:

  • Metriken sind in Ihrer Bereitstellung aktiviert (metrics.enabled: true). Der Nginx-Sidecar-Proxy, der Anforderungslimits durchsetzt, wird nur erstellt, wenn Metriken aktiviert sind.

Konfigurieren Sie die Anforderungslimits in Ihrer YAML-Bereitstellung

Fügen Sie den requestLimits Abschnitt unter worker in Ihrer InferenceEndpointConfig YAML hinzu. Das folgende Beispiel begrenzt jeden Pod auf 10 gleichzeitige Anfragen mit einer Warteschlange von 5 und gibt HTTP 503 zurück, wenn die Grenzwerte überschritten werden.

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-model
  namespace: ns-team-a
spec:
  modelName: my-model-name
  instanceType: ml.g5.8xlarge
  invocationEndpoint: invocations
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: my-model-bucket
      region: us-east-2
      modelLocation: models/my-model
  worker:
    image: my-model-image:latest
    modelInvocationPort:
      containerPort: 8080
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: "1"
      requests:
        cpu: "4"
        memory: "32Gi"
        nvidia.com/gpu: "1"
    requestLimits:
      maxConcurrentRequests: 10
      maxQueueSize: 5
      overflowStatusCode: 503
  metrics:
    enabled: true
  tlsConfig:
    tlsCertificateOutputS3Uri: "s3://my-tls-bucket/certs"

Erläuterung der Felder

maxConcurrentRequests (Optional, Ganzzahl)

Maximale Anzahl gleichzeitiger Anfragen, die der Nginx-Sidecar-Proxy pro Pod akzeptiert. Wenn das Limit erreicht ist, werden neue Anfragen entweder in die Warteschlange gestellt (sofern maxQueueSize konfiguriert) oder sofort mit dem Überlauf-Statuscode abgelehnt. Minimum: 1. Wenn es nicht oder auf 0 gesetzt ist, wird kein Parallelitätslimit durchgesetzt.

maxQueueSize (Optional, Ganzzahl)

Maximale Anzahl von Anfragen, die in die Warteschlange gestellt werden, wenn das Limit für gleichzeitige Anfragen erreicht ist. Anfragen in der Warteschlange warten, bis eine Anfrage während des Fluges abgeschlossen ist. Wenn die Warteschlange voll ist, erhalten neue Anfragen die Antwort mit dem Überlaufstatuscode. Minimum: 0. Wenn dieser Wert nicht oder auf 0 gesetzt ist, wird keine Warteschlange angewendet. Anfragen werden sofort abgelehnt, wenn das Limit für gleichzeitige Anfragen erreicht ist.

overflowStatusCode (Optional, Ganzzahl)

Der HTTP-Statuscode wird zurückgegeben, wenn die Anforderungslimits überschritten werden. Muss zwischen 400 und 599 liegen. Standard: 429 (Zu viele Anfragen). Typische Werte:

  • 429— Zu viele Anfragen (Standard). Standard-HTTP-Status zur Ratenbegrenzung.

  • 503— Dienst nicht verfügbar. Nützlich, wenn Sie möchten, dass der Load Balancer es auf einem anderen Pod erneut versucht.

Wie funktioniert die Anforderungsbegrenzung

Wenn eine Inferenzanforderung beim Nginx-Sidecar-Proxy eintrifft:

  1. Wenn die Anzahl der aktiven Anfragen darunter liegtmaxConcurrentRequests, wird die Anfrage an den Modellcontainer weitergeleitet.

  2. Wenn das Limit erreicht maxQueueSize ist und größer als 0 ist, wird die Anfrage in die Warteschlange gestellt und wartet (bis zu 60 Sekunden), bis ein aktiver Slot verfügbar wird.

  3. Wenn die Warteschlange voll ist (oder keine Warteschlange konfiguriert ist), wird die Anfrage sofort mit der konfigurierten overflowStatusCode und einer JSON-Fehlerantwort abgelehnt:

    {
  "error": "Too many concurrent requests",
  "max_concurrent": 10,
  "max_queue_size": 5,
  "current": 10
}

Beispiele

Strikte Parallelitätsbeschränkung ohne Warteschlangen

So lehnen Sie überzählige Anfragen sofort ab, ohne sich in die Warteschlange zu stellen:

requestLimits:
  maxConcurrentRequests: 5
  overflowStatusCode: 429

Begrenzung der Parallelität mit Warteschlangen

Um eine kleine Warteschlange vor der Ablehnung zuzulassen:

requestLimits:
  maxConcurrentRequests: 10
  maxQueueSize: 5
  overflowStatusCode: 503

In dieser Konfiguration werden bis zu 10 Anfragen gleichzeitig verarbeitet. Wenn die 11. bis 15. Anfragen eintreffen, werden sie in die Warteschlange gestellt und warten auf einen aktiven Slot. Bei der 16. Anfrage und den darauffolgenden Anfragen wird HTTP 503 empfangen.