Configura i limiti di richiesta per l'implementazione del tuo modello di inferenza HyperPod - Amazon SageMaker AI

View a markdown version of this page

Configura i limiti di richiesta per l'implementazione del tuo modello di inferenza HyperPod - Amazon SageMaker AI
PrerequisitiConfigura i limiti di richiesta nel tuo YAML di distribuzioneSpiegazione dei campiCome funziona la limitazione delle richiesteEsempi

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configura i limiti di richiesta per l'implementazione del tuo modello di inferenza HyperPod

Puoi configurare la limitazione delle richieste sulle distribuzioni del tuo modello di SageMaker HyperPod inferenza Amazon per controllare il numero di richieste simultanee accettate da ogni pod. Quando viene raggiunto il limite, le richieste in eccesso ricevono una risposta di errore HTTP configurabile, che consente un comportamento fail-fast e consente al load balancer di reindirizzare il traffico verso altri pod.

La limitazione delle richieste viene applicata dal proxy sidecar nginx che viene eseguito insieme al container del modello. Ciò richiede che le metriche siano abilitate sulla distribuzione.

Prerequisiti

Prima di configurare i limiti delle richieste, verifica che:

  • Le metriche sono abilitate nella tua distribuzione (). metrics.enabled: true Il proxy sidecar nginx che impone i limiti di richiesta viene creato solo quando le metriche sono abilitate.

Configura i limiti di richiesta nel tuo YAML di distribuzione

Aggiungi la requestLimits sezione sotto worker nel tuo YAML. InferenceEndpointConfig L'esempio seguente limita ogni pod a 10 richieste simultanee con una coda di 5, restituendo HTTP 503 quando vengono superati i limiti.

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"

Spiegazione dei campi

maxConcurrentRequests (Facoltativo, Numero intero)

Numero massimo di richieste simultanee accettate dal proxy sidecar nginx per pod. Quando viene raggiunto il limite, le nuove richieste vengono messe in coda (se configurate) o immediatamente rifiutate con maxQueueSize il codice di stato dell'overflow. Minimo: 1. Se non è impostato o è impostato su 0, non viene applicato alcun limite di concorrenza.

maxQueueSize (Facoltativo, Numero intero)

Numero massimo di richieste da mettere in coda quando viene raggiunto il limite di richieste simultanee. Le richieste in coda attendono il completamento di una richiesta in volo. Quando la coda è piena, le nuove richieste ricevono la risposta con il codice di stato dell'overflow. Minimo: 0 Se non è impostata o è impostata su 0, non viene applicata alcuna coda: le richieste vengono rifiutate immediatamente quando viene raggiunto il limite di richieste simultanee.

overflowStatusCode (Facoltativo, Numero intero)

Codice di stato HTTP restituito quando vengono superati i limiti di richiesta. Deve essere compreso tra 400 e 599. Predefinito: 429 (Troppe richieste). Valori comuni:

  • 429— Troppe richieste (impostazione predefinita). Stato HTTP standard per la limitazione della velocità.

  • 503— Servizio non disponibile. Utile quando si desidera che il load balancer riprovi su un pod diverso.

Come funziona la limitazione delle richieste

Quando una richiesta di inferenza arriva al proxy sidecar nginx:

  1. Se il numero di richieste attive è inferioremaxConcurrentRequests, la richiesta viene inoltrata al contenitore del modello.

  2. Se il limite viene raggiunto ed maxQueueSize è maggiore di 0, la richiesta viene messa in coda e attende (fino a 60 secondi) che uno slot attivo diventi disponibile.

  3. Se la coda è piena (o non è configurata alcuna coda), la richiesta viene immediatamente rifiutata con la configurazione e una risposta di errore JSON: overflowStatusCode

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

Esempi

Limite di concorrenza rigoroso senza code

Per rifiutare immediatamente le richieste in eccesso senza fare la coda:

requestLimits:
  maxConcurrentRequests: 5
  overflowStatusCode: 429

Limite di concorrenza con l'accodamento

Per consentire una piccola coda prima del rifiuto:

requestLimits:
  maxConcurrentRequests: 10
  maxQueueSize: 5
  overflowStatusCode: 503

In questa configurazione, vengono elaborate fino a 10 richieste contemporaneamente. Quando arrivano dall'undicesima alla quindicesima richiesta, vengono messe in coda e attendono uno slot attivo. La sedicesima richiesta e le successive ricevono il protocollo HTTP 503.