View a markdown version of this page

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

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 Implementierung Ihres HyperPod Inferenzmodells

Sie können die Anforderungsbegrenzung für Ihre Bereitstellungen im SageMaker HyperPod Amazon-Inferenzmodell 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, wodurch ein Fail-Fast-Verhalten ermöglicht wird und der Load Balancer den Datenverkehr an andere Pods umleiten kann.

Die Anforderungsbeschränkung wird durch den Nginx-Sidecar-Proxy durchgesetzt, 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 Anforderungslimits in Ihrer YAML-Bereitstellung

Fügen Sie den requestLimits Abschnitt worker unten zu Ihrer InferenceEndpointConfig YAML hinzu. Das folgende Beispiel beschränkt jeden Pod auf 10 gleichzeitige Anfragen mit einer Warteschlange von 5, wobei HTTP 503 zurückgegeben wird, 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 Overflow-Statuscode abgelehnt. Minimum: 1. Wenn nicht festgelegt oder auf 0 gesetzt, 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 laufende Anfrage abgeschlossen ist. Wenn die Warteschlange voll ist, erhalten neue Anfragen die Antwort mit dem Überlauf-Statuscode. Minimum: 0. Wenn dieser Wert nicht gesetzt oder auf 0 gesetzt ist, wird kein Queuing angewendet. Anfragen werden sofort abgewiesen, wenn das Limit für gleichzeitige Anfragen erreicht ist.

overflowStatusCode (Optional, Ganzzahl)

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

  • 429— Zu viele Anfragen (Standard). Standard-HTTP-Status für die Ratenbegrenzung.

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

Wie funktioniert die Begrenzung von Anfragen

Wenn eine Inferenzanforderung beim Nginx-Sidecar-Proxy eintrifft:

  1. Wenn die Anzahl der aktiven Anfragen niedriger istmaxConcurrentRequests, 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 zurückgewiesen:

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

Beispiele

Strikte Begrenzung der Parallelität ohne Warteschlangen

So lehnen Sie überschüssige Anfragen sofort ab, ohne sich in die Warteschlange zu stellen:

requestLimits:
  maxConcurrentRequests: 5
  overflowStatusCode: 429

Begrenzung der Parallelität bei Warteschlangen

Um vor dem Ablehnen eine kleine Warteschlange zuzulassen:

requestLimits:
  maxConcurrentRequests: 10
  maxQueueSize: 5
  overflowStatusCode: 503

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