Contribuisci a migliorare questa pagina
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à.
Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.
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à.
Gestisci l'elaborazione per i AI/ML carichi di lavoro con EKS Auto Mode e Karpenter
Suggerimento
Registrati
Questa sezione spiega come gestire l'elaborazione accelerata (AWS Trainium, GPU NVIDIA) per i carichi di lavoro di addestramento e inferenza AI utilizzando Amazon EKS Auto Mode o Karpenter autogestito.
EKS Auto Mode e Karpenter supportano due modalità di provisioning: provisioning dinamico e provisioning statico. Con il provisioning dinamico, EKS Auto Mode e Karpenter forniscono e scalano le istanze di calcolo accelerate man mano che i carichi di lavoro sono programmati sul cluster. Con il provisioning statico, EKS Auto Mode e Karpenter forniscono e gestiscono un numero fisso di nodi. È possibile utilizzare il provisioning dinamico e statico nello stesso cluster per mantenere un pool di capacità di base costante e al contempo scalare in base alle richieste del carico di lavoro.
EKS Auto Mode e Karpenter supportano tutte e quattro le opzioni di acquisto della capacità (SpotOn-Demand, Capacity Blocks e ODCR) e forniscono sempre prima la capacità riservata, seguita da Spot o. On-Demand
EKS Auto Mode contro Karpenter
Entrambi gli approcci condividono l' NodePool API, ma differiscono per proprietà operativa, API delle risorse, supporto del sistema operativo, gestione delle interruzioni Spot e flessibilità di configurazione.
| Funzionalità | Modalità automatica di EKS | Self-managed Karpenter |
|---|---|---|
|
Ideale per |
Team che preferiscono un'infrastruttura gestita con un sovraccarico operativo minimo |
Team che preferiscono il pieno controllo sul ciclo di vita dei nodi, sulle AMI, sull'ottimizzazione del sistema operativo e sull'applicazione delle patch. |
|
Modello operativo |
AWS effettua il provisioning e gestisce il controller Karpenter, GPU/Trainium i driver, i plug-in dei dispositivi, l'applicazione delle patch al sistema operativo e la gestione delle interruzioni Spot. |
Tu installi e gestisci il controller Karpenter nel tuo cluster e possiedi i GPU/Trainium driver, i plug-in dei dispositivi, il ciclo di vita delle AMI, l'applicazione delle patch e la gestione delle interruzioni Spot. |
|
Opzioni di calcolo |
On-Demand, Spot, ODCR, Capacity Blocks per ML |
On-Demand, Spot, ODCR, Capacity Blocks per ML |
|
API di risorse |
|
|
|
Sistema operativo Node |
Solo Bottlerocket. Dipendenze NVIDIA GPU, AWS Trainium ed EFA incluse. |
AL2023, Bottlerocket, Windows o la tua AMI. |
|
Durata del nodo |
Durata massima del nodo di 21 giorni per l'applicazione delle patch di sicurezza. I carichi di lavoro devono tollerare la rotazione dei nodi. |
Sei tu a definire il ciclo di vita del nodo e i budget relativi alle interruzioni NodePool |
|
Gestione delle interruzioni puntuali |
Nativo. Non è richiesta alcuna coda SQS o Node Termination Handler. |
È responsabilità dell'utente configurare e abilitare. |
|
Estrazione rapida dei contenitori |
Il pull parallelo SOCI è incluso in tutte le istanze della famiglia G, P e Trn |
È tua responsabilità configurare e abilitare. |
|
Gruppi di collocamento EC2 |
Cluster, partizione, diffusione |
Cluster, partizione, diffusione |
|
Configurazione dell'interfaccia di rete |
Non supportata |
Configurazione per interfaccia per tipo |
|
Riparazione dei nodi |
Abilitato per impostazione predefinita, include l'agente di monitoraggio dei nodi EKS |
Abilitato opzionalmente, agente di monitoraggio dei nodi EKS autogestito |
|
Prezzi |
Tariffa di gestione EKS Auto Mode in aggiunta al costo |
Fonte aperta. Paghi per le istanze EC2 sottostanti. |
Etichette comuni AI/ML e note
EKS Auto Mode e Karpenter espongono le etichette delle istanze che è possibile utilizzare in NodePool requirements and Pod nodeSelector o nodeAffinity per indirizzare carichi di lavoro senza codificare i tipi di istanze. Il prefisso dell'etichetta è diverso tra i due: EKS Auto Mode utilizza mentre Karpenter autogestito utilizza. eks.amazonaws.com/ karpenter.k8s.aws/
Le tabelle seguenti mostrano le etichette pertinenti che possono essere utilizzate in. NodePools EKS Auto Mode e Karpenter applicano anche le etichette elencate nella documentazione di Karpenter
Etichette di pianificazione per la capacità riservata
Quando EKS Auto Mode o Karpenter avvia un nodo in una prenotazione, aggiunge le seguenti etichette. Utilizzale innodeSelector, nell'affinità dei nodi o nei NodePool requisiti per indirizzare i carichi di lavoro.
-
karpenter.sh/capacity-type:reserved, oon-demand.spotIndica la capacità di backup del nodo. -
karpenter.k8s.aws/capacity-reservation-id: l'ID di prenotazione specifico in cui è stato avviato il nodo. -
karpenter.k8s.aws/capacity-reservation-type:defaultper ODCR,capacity-blockper Capacity Blocks.
Gli esempi seguenti mostrano modelli di pianificazione comuni:
Aggiungi un Pod a una prenotazione specifica (nessuna riserva):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
Scegli come target solo i nodi ODCR (qualsiasi ODCR, non i Capacity Blocks):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
Scegli come target qualsiasi capacità riservata (ODCR o Capacity Block):
spec: nodeSelector: karpenter.sh/capacity-type: reserved
Preferisci riservato ma ricorri a Spot o On-Demand se non disponibile:
spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]
Comportamento di scadenza della prenotazione
Gli ODCR e i Capacity Blocks si comportano diversamente al termine della prenotazione. Assicurati che la tua strategia di pianificazione e checkpoint corrisponda al tipo di prenotazione che supporta il tuo carico di lavoro.
ODCR
Un'istanza lanciata in un ODCR non è presente in tale ODCR a tempo indeterminato. L'ODCR può scadere, essere annullato oppure l'istanza può essere rimossa manualmente dall'ODCR. Se si verifica una di queste situazioni e EKS Auto Mode/Karpenter rileva che l'istanza non appartiene più a un ODCR, aggiorna l'etichetta del nodo da a. karpenter.sh/capacity-type reserved on-demand L'istanza continua a funzionare con On-Demand capacità standard e i Pod esistenti continuano a funzionare senza interruzioni.
Nota
Qualsiasi Pod programmato con un strict non nodeSelector: karpenter.sh/capacity-type: reserved verrà programmato sul nodo se è stato rietichettato. Affinché i carichi di lavoro sopravvivano alla scadenza o alla cancellazione dell'ODCR, utilizza lo preferredDuringSchedulingIgnoredDuringExecution schema mostrato sopra anziché un. nodeSelector
Blocchi di capacità
A differenza degli ODCR, i Capacity Blocks hanno sempre un'ora di fine ed EC2 termina le istanze Capacity Block 30 minuti prima dell'ora di fine (60 minuti per i tipi di istanza). UltraServer Pianifica i lavori di formazione e inferenza per completare o salvare lo stato prima della chiusura della finestra di prenotazione. I pod che utilizzano un codice rigoroso nodeSelector per un determinato capacity-reservation-id periodo vengono attivati una Pending volta scaduto il blocco e non verranno riprogrammati altrove. Combina il checkpoint con il modello di affinità flessibile riportato sopra se hai bisogno che i carichi di lavoro passino ad altre capacità durante la scadenza del Capacity Block.
-
Puoi utilizzare le istanze riservate fino a 30 minuti prima dell'ora di fine del Capacity Block per la maggior parte dei tipi di istanze o 60 minuti prima dell'ora di fine per i tipi di istanze. UltraServer
-
EKS Auto Mode e Karpenter iniziano a svuotare preventivamente i nodi in un Capacity Block 10 minuti prima dell'inizio della chiusura di EC2, in modo che i carichi di lavoro abbiano il tempo di effettuare il checkpoint e spegnersi correttamente.
Capacità statica NodePools
EKS Auto Mode e Karpenter supportano la capacità statica NodePools, che mantiene un numero fisso di nodi indipendentemente dalla richiesta del carico di lavoro. I pool statici eliminano i ritardi dovuti all'avvio a freddo per l'inferenza sensibile alla latenza e consentono di riservare un ingombro minimo dell'infrastruttura per il cluster.
La capacità statica viene configurata impostando il campo su. replicas NodePool
Considerazioni
-
Una volta
replicasimpostato su un NodePool, non è possibile rimuoverlo. Un singolo NodePool non può passare dal provisioning statico a quello dinamico della capacità. -
La capacità statica non NodePools viene presa in considerazione per il consolidamento. Impostato
limits.nodessoprareplicasper consentire il ridimensionamento temporaneo durante la deriva o la scadenza dell'AMI. -
Per una distribuzione prevedibile delle zone di disponibilità (AZ), crea una capacità statica NodePool per AZ anziché estenderla su più zone in un unico pool.
Blocchi di capacità per ML
I Capacity Blocks for ML consentono di prenotare istanze P-family e Trainium per una finestra futura definita. Sono prepagate, quindi EKS Auto Mode e Karpenter le considerano gratuite e danno loro la priorità rispetto a Spot. On-Demand I Capacity Blocks for ML possono avere una durata di prenotazione di 1-14 giorni o un multiplo di 7 giorni, fino a 182 giorni (6 mesi).
Per utilizzare Capacity Blocks for ML con EKS Auto Mode o Karpenter, capacityReservationSelectorTerms configuralo inserendo il tuo ID di prenotazione della capacità nel tuo. NodeClass Non è possibile utilizzare l'open booking matching con Capacity Blocks for ML. Un termine può specificare un ID, un set di tag o criteri di corrispondenza delle istanze in base ai quali effettuare una selezione. Quando specifica i tag, selezionerà tutte le prenotazioni di capacità accessibili dall'account con i tag corrispondenti. Questo può essere ulteriormente limitato specificando l'ID di un account proprietario.
Per altri esempi, consulta la documentazione di Karpenter
On-Demand Prenotazioni di capacità (ODCR)
Gli ODCR garantiscono la capacità in una zona di disponibilità (AZ) specifica senza un impegno a lungo termine. Ti verranno addebitate le On-Demand tariffe standard indipendentemente dal fatto che la capacità venga utilizzata o meno. Gli ODCR supportano tutte le famiglie di GPU NVIDIA, incluse le G-family istanze non supportate da Capacity Blocks for ML. Gli ODCR sono prepagati, quindi EKS Auto Mode e Karpenter li modellano come gratuiti e danno loro la priorità rispetto a Spot e Spot. On-Demand
Gli ODCR si comportano in modo diverso rispetto a Capacity Blocks for ML al termine della prenotazione. Quando un ODCR scade o viene annullato, l'istanza continua a funzionare come standard. On-Demand Per informazioni dettagliate, vedi Comportamento di scadenza della prenotazione.
Per utilizzare gli ODCR con EKS Auto Mode o Karpenter, capacityReservationSelectorTerms configurali inserendo i termini di prenotazione della capacità nel tuo. NodeClass Un termine può specificare un ID, un set di tag o criteri di corrispondenza a istanze in base ai quali effettuare la selezione. Quando specifica i tag, selezionerà tutte le prenotazioni di capacità accessibili dall'account con i tag corrispondenti. Quando specifica i criteri di corrispondenza delle istanze, seleziona le prenotazioni in base al loro comportamento di corrispondenza: open (corrisponde a tutte le istanze compatibili) o targetizzata (corrisponde solo alle istanze con target esplicito). Questo può essere ulteriormente limitato specificando l'ID dell'account proprietario.
Per altri esempi, consulta la documentazione di Karpenter
On-Demand
On-Demand è il tipo di capacità predefinito e può essere utilizzato con il provisioning statico o dinamico in EKS Auto Mode e Karpenter. Puoi richiedere On-Demand istanze in modo esplicito impostando il tuo. karpenter.sh/capacity-type: on-demand NodePool EKS Auto Mode e Karpenter selezionano l'istanza con il prezzo più basso che soddisfa le richieste di risorse del Pod. Utilizzala On-Demand per lo sviluppo, la prototipazione, la scalabilità inferenziale imprevedibile e qualsiasi carico di lavoro che richieda una disponibilità immediata senza rischi di interruzione.
Spot
Spot offre risparmi fino al 90% rispetto all'utilizzo di capacità EC2 di riserva. On-Demand AWS può recuperare le istanze Spot con un avviso di interruzione di 2 minuti. Massimizza la disponibilità elencando più famiglie di istanze su. NodePool Associa i carichi di lavoro Spot a un checkpoint PodDisruptionBudget e a uno storage durevole (Amazon S3 o Amazon EFS) a intervalli regolari in modo che i Pod possano salvare lo stato durante la finestra di drenaggio.
Spot è la soluzione ideale per carichi di lavoro di formazione e inferenza riutilizzabili e tolleranti ai guasti, in cui le interruzioni occasionali sono accettabili in cambio di significativi risparmi sui costi.
I candidati più comuni includono:
-
Ottimizzazione e scansione degli iperparametri: molte prove brevi e parallele che possono essere riprovate se interrotte.
-
Formazione distribuita con checkpointing: processi di lunga durata che salvano periodicamente lo stato su S3 o FSx e possono riprendere dall'ultimo checkpoint dopo la perdita del nodo.
-
Inferenza in batch e offline: processi di assegnazione di punteggi su larga scala rispetto a set di dati in cui la latenza end-to-end viene misurata in ore, non in secondi.
-
Preelaborazione dei dati e pipeline di ingegneria delle funzionalità: trasformazioni parallele su set di dati di grandi dimensioni.
-
Valutazione e benchmarking dei modelli: lavori ripetibili che producono risultati idempotenti.
-
Sviluppo, prototipazione e notebook: sperimentazione interattiva in cui gli utenti possono tollerare riavvii occasionali.
Evita Spot per inferenze in tempo reale sensibili alla latenza, endpoint di SLA-bound produzione e carichi di lavoro che non prevedono checkpoint o non tollerano riavvii.
Puoi richiedere in modo esplicito istanze Spot impostando il tuo. karpenter.sh/capacity-type: spot NodePool