View a markdown version of this page

Configurez 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 le YAML de votre 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.

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

Vous pouvez configurer la limitation des demandes dans le cadre de 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 demandes est appliquée par le proxy nginx sidecar qui s'exécute parallèlement à votre modèle de conteneur. Cela nécessite que les métriques soient activées lors de 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 demandes n'est créé que lorsque les métriques sont activées.

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

Ajoutez la requestLimits section ci-dessous worker dans votre fichier InferenceEndpointConfig YAML. L'exemple suivant limite chaque pod à 10 requêtes simultanées avec une file d'attente de 5, renvoyant le protocole 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 demandes simultanées acceptées par le proxy nginx sidecar par pod. Lorsque la limite est atteinte, les nouvelles demandes sont soit mises en file d'attente (si maxQueueSize elles sont configurées), soit immédiatement rejetées avec le code d'état du dépassement. Minimum : 1. S'il n'est pas défini ou défini sur 0, aucune limite de simultanéité n'est appliquée.

maxQueueSize (facultatif, entier)

Nombre maximal 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 cours de vol soit terminée. Lorsque la file d'attente est pleine, les nouvelles demandes reçoivent la réponse du code d'état du 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 demandes sont dépassées. 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 qu'elle 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 réponse configurée 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 faire la queue :

requestLimits:
  maxConcurrentRequests: 5
  overflowStatusCode: 429

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

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

requestLimits:
  maxConcurrentRequests: 10
  maxQueueSize: 5
  overflowStatusCode: 503

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