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

# Governance delle attività per l'implementazione del modello su HyperPod
<a name="sagemaker-hyperpod-model-deployment-task-gov"></a>

Questa sezione spiega come ottimizzare i cluster Amazon SageMaker HyperPod EKS condivisi per carichi di lavoro di inferenza in tempo reale. Imparerai a configurare le funzionalità di governance delle attività di Kueue, tra cui la gestione delle quote, la pianificazione delle priorità e le policy di condivisione delle risorse, per garantire che i carichi di lavoro di inferenza ottengano le risorse GPU di cui hanno bisogno durante i picchi di traffico, mantenendo al tempo stesso un’equa allocazione tra le attività di addestramento, valutazione e test dei tuoi team. Per informazioni più generali sulla governance delle attività, consulta [SageMaker HyperPod governance delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance.md).

## Come funziona la gestione dei carichi di lavoro di inferenza
<a name="sagemaker-hyperpod-model-deployment-task-gov-how"></a>

Per gestire efficacemente i picchi di traffico di inferenza in tempo reale nei cluster HyperPod EKS condivisi, implementa le seguenti strategie di governance delle attività utilizzando le funzionalità esistenti di Kueue.

**Configurazione della classe di priorità**

Definisci classi di priorità dedicate per i carichi di lavoro di inferenza con pesi elevati (ad esempio 100) per garantire che i pod di inferenza siano ammessi e pianificati prima di altri tipi di attività. Questa configurazione consente ai carichi di lavoro di inferenza di rendere prerilasciabili i processi con priorità più bassa durante il caricamento del cluster, il che è fondamentale per mantenere i requisiti di bassa latenza durante i picchi di traffico.

**Dimensionamento e allocazione delle quote**

Riserva al tuo team risorse GPU sufficienti in `ClusterQueue` per gestire i picchi di inferenza previsti. Durante i periodi con poco traffico di inferenza, le quote di risorse inutilizzate possono essere temporaneamente allocate alle attività di altri team. Quando la domanda di inferenza aumenta, le risorse prese in prestito possono essere recuperate per dare priorità ai pod di inferenza in sospeso. Per ulteriori informazioni, consulta [Cluster Queue](https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/).

**Strategie di condivisione delle risorse**

Scegli tra due approcci di condivisione delle quote in base alle tue esigenze:

1. **Controllo rigoroso delle risorse:** disabilita la funzionalità per prendere e dare in prestito le quote per garantire che la capacità GPU riservata sia sempre disponibile per i tuoi carichi di lavoro. Questo approccio richiede quote con dimensioni piuttosto ampie per gestire in modo indipendente i picchi di domanda e può comportare l’inattività dei nodi durante i periodi di traffico ridotto.

1. **Condivisione flessibile delle risorse: ** abilita il prestito delle quote per utilizzare le risorse inutilizzate di altri team quando necessario. I pod presi in prestito sono contrassegnati come prerilasciabili e possono essere eliminati se il team che li ha prestati reclama la capacità.

**Intra-Team Prevenzione **

Abilita la prelazione all’interno del team quando esegui carichi di lavoro misti (valutazione, addestramento e inferenza) nell’ambito della stessa quota. Ciò consente a Kueue di prerilasciare i processi a bassa priorità all’interno del team per ospitare pod di inferenza ad alta priorità, garantendo che l’inferenza in tempo reale possa essere eseguita senza dipendere dal prestito di quote esterne. Per ulteriori informazioni, consulta [Prelazione](https://kueue.sigs.k8s.io/docs/concepts/preemption/).

## Esempio di configurazione del carico di lavoro di inferenza
<a name="sagemaker-hyperpod-model-deployment-task-gov-example"></a>

L'esempio seguente mostra come Kueue gestisce le risorse GPU in un cluster Amazon condiviso. SageMaker HyperPod 

**Configurazione del cluster e impostazione delle policy**  
Il tuo cluster ha la configurazione seguente:
+ **Team A**: quota di 10 GPU P4
+ **Team B**: quota di 20 GPU P4
+ **Provisioning statico**: nessun dimensionamento automatico
+ **Capacità totale**: 30 GPU P4

Il pool di GPU condiviso utilizza questa policy di priorità:

1. **Real-time inferenza**: Priorità 100

1. **Addestramento**: priorità 75

1. **Valutazione**: priorità 50

Kueue applica le quote del team e le classi di priorità, con la prelazione e il prestito di quote abilitati.

**Stato iniziale: utilizzo normale del cluster**  
Durante il normale funzionamento:
+ Il Team A esegue processi di addestramento e valutazione su tutte e 10 le GPU P4
+ Il Team B esegue l’inferenza (10 P4) e la valutazione (10 P4) in tempo reale all’interno della sua quota di 20 GPU
+ Il cluster è completamente utilizzato e tutti i processi sono ammessi e in esecuzione

**Picco di inferenza: il Team B richiede GPU aggiuntive**  
Quando il Team B incontra un picco di traffico, i pod di inferenza aggiuntivi richiedono altre 5 GPU P4. Kueue rileva che i nuovi pod:
+ Sono all’interno del namespace del Team B
+ Hanno priorità 100 (inferenza in tempo reale)
+ Hanno l’ammissione in sospeso a causa di vincoli di quota

**Per la risposta, Kueue può scegliere tra due opzioni:**  
**Opzione 1: prestito di quote**. Se il Team A utilizza solo 6 dei suoi 10 P4, Kueue può ammettere i pod del Team B utilizzando i 4 P4 inattivi. Tuttavia, queste risorse prese in prestito sono prerilasciabili: se il Team A invia processi per raggiungere la sua quota massima, Kueue rilascia i pod di inferenza presi in prestito dal Team B.

**Opzione 2: Self-preemption (consigliata) ** - Il team B esegue lavori di valutazione a bassa priorità (priorità 50). Quando sono in attesa pod di inferenza ad alta priorità, Kueue interrompe i processi di valutazione inclusi nella quota del Team B e ammette i pod di inferenza. Questo approccio offre un’allocazione sicura delle risorse senza rischi esterni di espulsione.

Kueue segue un processo in tre fasi per l’allocazione delle risorse:

1. **Controllo delle quote**

   Domanda: il Team B ha una quota inutilizzata?
   + Sì → Ammetti i pod
   + No → Procedi alla Fase 2

1. **Self-preemption all'interno del Team B **

   Domanda: è possibile prerilasciare i processi del Team B con priorità più bassa?
   + Sì → Rendi prerilasciabili i processi di valutazione (priorità 50), libera 5 P4 e ammetti i pod di inferenza
   + No → Procedi alla Fase 3

   Questo approccio mantiene i carichi di lavoro entro la quota garantita del Team B, evitando rischi esterni di espulsione.

1. **Prestito da altri team**

   Domanda: c’è una quota inattiva che può essere presa in prestito da altri team?
   + Sì → Consenti l’utilizzo di una quota presa in prestito (contrassegnata come prerilasciabile)
   + No → Il pod rimane nello stato `NotAdmitted`

## Configurazione della governance delle attività per i carichi di lavoro di inferenza
<a name="sagemaker-hyperpod-model-deployment-task-gov-configure"></a>

Per integrare i tuoi carichi di lavoro di inferenza con Kueue, aggiungi etichette di governance delle attività al tuo o al tuo CRD. `InferenceEndpointConfig` `JumpStartModel` Queste etichette determinano chi LocalQueue riceve il carico di lavoro per la gestione delle quote e definiscono la priorità di pianificazione utilizzata nelle decisioni di prelazione. Le sezioni seguenti riguardano i prerequisiti, l'ambito delle risorse, la configurazione delle etichette e le fasi di verifica.

### Prerequisiti
<a name="sagemaker-hyperpod-model-deployment-task-gov-prereqs"></a>

Prima di configurare la governance delle attività per i carichi di lavoro di inferenza, assicurati che nel cluster siano presenti le seguenti risorse: HyperPod 
+ **Kueue ** è installato e in esecuzione sul tuo cluster
+ **ClusterQueue**Esiste A con una quota GPU assegnata al tuo team
+ A ** LocalQueue ** esiste nel namespace in cui intendi implementare il tuo endpoint di inferenza
+ Una o più ** PriorityClass ** risorse sono definite per i tipi di carico di lavoro (come inferenza, formazione, valutazione)

Per verificare che queste risorse siano disponibili, esegui i seguenti comandi:

```
# Verify Kueue is installed
kubectl get crd | grep kueue

# List available PriorityClasses
kubectl get priorityclass

# List ClusterQueues
kubectl get clusterqueue

# List LocalQueues in your namespace
kubectl get localqueue -n <your-namespace>
```

### Comprendere l'ambito delle risorse
<a name="sagemaker-hyperpod-model-deployment-task-gov-scoping"></a>

Le risorse per la governance delle attività hanno diversi ambiti che influiscono sulla configurazione delle etichette di distribuzione delle inferenze.

L'`kueue.x-k8s.io/queue-name`etichetta deve fare riferimento a un nome LocalQueue che esiste nello stesso namespace del tuo or. `InferenceEndpointConfig` `JumpStartModel` Se non LocalQueue viene trovata alcuna corrispondenza in quel namespace, il carico di lavoro non verrà ammesso da Kueue.

ClusterQueue ResourceFlavor, e PriorityClass sono classificati in cluster e accessibili da qualsiasi namespace.

Per verificare l'ambito delle risorse nel cluster:

```
kubectl api-resources | grep kueue
```

### Aggiungere etichette di governance delle attività
<a name="sagemaker-hyperpod-model-deployment-task-gov-labels"></a>

Per abilitare la governance delle attività per la distribuzione delle inferenze, aggiungi le seguenti etichette alla `metadata` sezione del tuo `InferenceEndpointConfig` o `JumpStartModel` del tuo CRD:

```
metadata:
  name: <your-deployment-name>
  namespace: <your-namespace>
  labels:
    kueue.x-k8s.io/queue-name: <your-localqueue-name>
    kueue.x-k8s.io/priority-class: <your-priority-class>
```

**Descrizioni delle etichette: **
+ `kueue.x-k8s.io/queue-name`— Indirizza il carico di lavoro a quello del tuo team LocalQueue per il monitoraggio delle quote. Deve corrispondere a un LocalQueue nome nello stesso namespace del carico di lavoro.
+ `kueue.x-k8s.io/priority-class`— Imposta la priorità di pianificazione per le decisioni di prelazione. Fa riferimento a un cluster classificato per nome PriorityClass .

### Verifica della configurazione della governance delle attività
<a name="sagemaker-hyperpod-model-deployment-task-gov-verify"></a>

Dopo aver applicato le tue `InferenceEndpointConfig` o `JumpStartModel` con le etichette di governance delle attività, verifica che Kueue abbia ammesso che il carico di lavoro e i pod siano stati pianificati correttamente.

**Per verificare che la governance delle attività funzioni**

1. Verifica lo stato di ammissione del carico di lavoro:

   ```
   kubectl get workloads -n <namespace>
   ```

   Un carico di lavoro ammesso correttamente viene visualizzato `True` nella colonna AMMISSIED ed elenca le risorse ClusterQueue riservate nella colonna RESERVED IN.

1. Verifica lo stato del pod:

   ```
   kubectl get pods -n <namespace>
   ```

   Dopo l'ammissione, i pod passano gradualmente attraverso le fasi di inizializzazione fino a raggiungere `Running` lo stato.

1. Controlla il consumo delle quote:

   ```
   kubectl get clusterqueue <clusterqueue-name> -o yaml
   ```

   Controlla la `status` sezione per confermare che il consumo di risorse viene monitorato.

1. Controlla i carichi di LocalQueue lavoro in sospeso:

   ```
   kubectl get localqueue -n <namespace>
   ```

   La colonna PENDING WORKLOADS mostra quanti carichi di lavoro sono in attesa di ammissione.

1. Visualizza gli eventi di ammissione a Kueue:

   ```
   kubectl describe workload <workload-name> -n <namespace>
   ```

   Consulta la sezione Eventi per le decisioni di ammissione e per eventuali errori.

Se i pod rimangono in `Pending` stato, stabilisci se il problema è a livello di ammissione Kueue (mostra il carico di lavoro`Admitted: False`) o a livello di scheduler Kubernetes (carico di lavoro ammesso ma pod non programmabile).