View a markdown version of this page

Configurer les limites de demandes pour le déploiement de votre modèle HyperPod d'inférence - Amazon SageMaker AI
Conditions préalablesConfigurez les limites de demandes dans votre fichier YAML de déploiementExplication des champsComment fonctionne la limitation des demandesExemples

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configurer les limites de demandes pour le déploiement de votre modèle HyperPod d'inférence

Vous pouvez configurer la limitation des demandes sur vos déploiements de modèles d' SageMaker HyperPod inférence Amazon afin de contrôler le nombre de demandes simultanées acceptées par chaque pod. Lorsque la limite est atteinte, les demandes excédentaires reçoivent une réponse d'erreur HTTP configurable, ce qui permet un comportement rapide et permet à l'équilibreur de charge de rediriger le trafic vers d'autres pods.

La limitation des requêtes est appliquée par le proxy nginx sidecar qui s'exécute parallèlement à votre conteneur de modèles. Cela nécessite que les métriques soient activées sur votre déploiement.

Conditions préalables

Avant de configurer les limites de demandes, vérifiez que :

  • Les métriques sont activées sur votre déploiement (metrics.enabled: true). Le proxy nginx sidecar qui applique les limites de requêtes n'est créé que lorsque les métriques sont activées.

Configurez les limites de demandes dans votre fichier YAML de déploiement

Ajoutez la requestLimits section ci-dessous worker dans votre InferenceEndpointConfig YAML. L'exemple suivant limite chaque pod à 10 requêtes simultanées avec une file d'attente de 5, renvoyant HTTP 503 lorsque les limites sont dépassées.

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"

Explication des champs

maxConcurrentRequests (facultatif, entier)

Nombre maximum de requêtes simultanées que le proxy nginx sidecar accepte par pod. Lorsque la limite est atteinte, les nouvelles demandes sont soit mises en file d'attente (si elle maxQueueSize est configurée), soit immédiatement rejetées avec le code d'état de dépassement. Minimum : 1. Si ce paramètre n'est pas défini ou s'il est défini sur 0, aucune limite de simultanéité n'est appliquée.

maxQueueSize (facultatif, entier)

Nombre maximum de demandes à mettre en file d'attente lorsque la limite de demandes simultanées est atteinte. Les demandes en file d'attente attendent qu'une demande en vol soit terminée. Lorsque la file d'attente est pleine, les nouvelles demandes reçoivent la réponse du code d'état de débordement. Minimum : 0. S'il n'est pas défini ou défini sur 0, aucune mise en file d'attente n'est appliquée : les demandes sont rejetées immédiatement lorsque la limite de demandes simultanées est atteinte.

overflowStatusCode (facultatif, entier)

Code d'état HTTP renvoyé lorsque les limites de requêtes sont dépassées. Il doit être compris entre 400 et 599. Par défaut : 429 (trop de demandes). Valeurs communes :

  • 429— Trop de demandes (par défaut). État HTTP standard pour la limitation du débit.

  • 503— Service non disponible. Utile lorsque vous souhaitez que l'équilibreur de charge réessaie sur un autre pod.

Comment fonctionne la limitation des demandes

Lorsqu'une demande d'inférence arrive au proxy nginx sidecar :

  1. Si le nombre de demandes actives est inférieurmaxConcurrentRequests, la demande est transmise au conteneur modèle.

  2. Si la limite est atteinte et maxQueueSize est supérieure à 0, la demande est mise en file d'attente et attend (jusqu'à 60 secondes) qu'un créneau actif soit disponible.

  3. Si la file d'attente est pleine (ou si aucune file d'attente n'est configurée), la demande est immédiatement rejetée avec la configuration overflowStatusCode et une réponse d'erreur JSON :

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

Exemples

Limite de simultanéité stricte sans mise en file d'attente

Pour rejeter immédiatement les demandes excédentaires sans les mettre en file d'attente :

requestLimits:
  maxConcurrentRequests: 5
  overflowStatusCode: 429

Limite de simultanéité avec mise en file d'attente

Pour autoriser une petite file d'attente avant de rejeter :

requestLimits:
  maxConcurrentRequests: 10
  maxQueueSize: 5
  overflowStatusCode: 503

Dans cette configuration, jusqu'à 10 demandes sont traitées simultanément. Lorsque les 11e à 15e demandes arrivent, elles sont mises en file d'attente et attendent un créneau actif. La 16e demande et les suivantes reçoivent le protocole HTTP 503.