View a markdown version of this page

Scalabilità automatica della capacità di servizio - Amazon SageMaker AI
Scalabilità automatica delle repliche Ray ServeScalabilità automatica dei nodi con Karpenter gestitoUtilizzo di entrambe le direttive

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à.

Scalabilità automatica della capacità di servizio

La capacità di servizio è scalabile su due livelli. HyperPod Ray Serve ridimensiona le repliche all'interno del cluster in base al carico delle richieste e Karpenter gestito ridimensiona i nodi del cluster per contenere tali repliche. I due sistemi funzionano insieme: la scalabilità automatica delle repliche reagisce per prima, mentre la scalabilità automatica dei nodi dei nodi esistenti aumenta la capacità quando i nodi esistenti si esauriscono.

Scalabilità automatica delle repliche Ray Serve

Ray Serve regola il numero di repliche per una distribuzione in base al carico della richiesta. Imposta una configurazione di scalabilità automatica sull'implementazione anziché un numero fisso di repliche:

deployments:
  - name: Model
    autoscaling_config:
      min_replicas: 1
      max_replicas: 8
      target_ongoing_requests: 5

Affinché la scalabilità automatica delle repliche aggiunga e rimuova i worker pod, il Ray autoscaler deve essere attivato per il cluster. Impostato enableInTreeAutoscaling: true nelle RayCluster specifiche, o in base a: rayClusterConfig RayService

spec:
  enableInTreeAutoscaling: true

In caso contrario, la distribuzione autoscaling_config modifica il numero di repliche di destinazione, ma KubeRay non crea i worker pod necessari per soddisfarlo.

La scalabilità automatica delle repliche rimane entro la capacità attuale dei nodi del cluster. Quando Ray Serve necessita di più repliche di quante ne possano contenere i nodi, i pod rimangono in sospeso fino a quando non è disponibile un nodo.

Scalabilità automatica dei nodi con Karpenter gestito

Karpenter on gestito HyperPod aggiunge nodi quando i Ray pod sono in sospeso e li rimuove quando sono inattivi, quindi la capacità di servizio segue la domanda senza un pool di nodi fisso. Le istanze Spot sono supportate per la capacità dei nodi, il che riduce i costi per la gestione tollerante alle interruzioni. Per l'installazione e la configurazione, consulta. Scalabilità automatica su EKS SageMaker HyperPod

Utilizzo di entrambe le direttive

Imposta la scalabilità automatica della replica sulla distribuzione e la scalabilità automatica dei nodi sul cluster. I due livelli interagiscono in una catena che risponde all'aumento del carico di richieste:

  1. Ray Serve rileva un aumento del carico. L'autoscaler rileva che le richieste in corso superano il limite target_ongoing_requests e decide di aggiungere un'altra replica.

  2. KubeRay crea un nuovo worker pod. Ray Serve segnala di KubeRay scalare il gruppo di lavoratori e KubeRay crea un pod per la nuova replica.

  3. Il pod rimane in sospeso se non c'è capacità. Se i nodi esistenti non possono contenere il nuovo pod (GPU o memoria insufficienti), il pod entra in Pending stato.

  4. Managed Karpenter esegue il provisioning di un nodo. HyperPod managed Karpenter rileva il pod in sospeso, seleziona un tipo di istanza appropriato e avvia un nuovo nodo.

  5. Il nodo si apre e il pod inizia a funzionare. Una volta che il nodo è pronto e si unisce al cluster, Kubernetes pianifica il pod in sospeso su di esso. La nuova replica carica il modello e inizia a soddisfare le richieste.

In caso di scalabilità ridotta, il processo si inverte: Ray Serve rimuove le repliche inattive, KubeRay elimina i worker pod e Karpenter gestito termina i nodi che non hanno pod in esecuzione dopo la finestra di consolidamento.