Informazioni sul provisioning di GPU e TPU con la modalità di provisioning con avvio flessibile

Questa pagina descrive la modalità di provisioning flex-start in Google Kubernetes Engine (GKE). L'avvio flessibile, basato su Dynamic Workload Scheduler, fornisce una tecnica flessibile ed economica per ottenere GPU e TPU quando devi eseguire carichi di lavoro AI/ML.

L'avvio flessibile consente di eseguire il provisioning dinamico di GPU e TPU in base alle esigenze, per un massimo di sette giorni, senza essere vincolati a un orario di inizio specifico e senza la gestione di prenotazioni a lungo termine. Pertanto, l'avvio flessibile è ideale per workload di dimensioni piccole e medie con requisiti di domanda fluttuanti o di breve durata. Ad esempio, il pre-addestramento di modelli di piccole dimensioni, l'ottimizzazione dei modelli o i modelli di pubblicazione scalabili.

Le informazioni in questa pagina possono aiutarti a:

• Scopri come funziona l'avvio flessibile in GKE.
• Decidi se l'avvio flessibile è adatto al tuo workload.
• Decidi quale configurazione di avvio flessibile è adatta al tuo workload.
• Gestire le interruzioni quando utilizzi l'avvio flessibile.
• Comprendi le limitazioni dell'avvio flessibile in GKE.

Questa pagina è destinata agli amministratori e operatori della piattaforma e agli ingegneri di machine learning (ML) che vogliono ottimizzare l'infrastruttura degli acceleratori per i loro workload.

Quando utilizzare l'avvio flessibile

Ti consigliamo di utilizzare l'avvio flessibile se i tuoi workload soddisfano tutte le seguenti condizioni:

• I tuoi workload richiedono risorse GPU.
• I tuoi carichi di lavoro richiedono risorse TPU eseguite in node pool di slice TPU single-host.
• Hai una capacità di GPU o TPU riservata limitata o nulla e hai bisogno di un accesso più affidabile a questi acceleratori.
• Il tuo workload è flessibile in termini di tempo e il tuo caso d'uso può permettersi di attendere per ottenere tutta la capacità richiesta, ad esempio quando GKE alloca le risorse GPU al di fuori delle ore di maggiore attività.

Prezzi per l'avvio flessibile

L'avvio flessibile è consigliato se il tuo carico di lavoro richiede risorse di cui viene eseguito il provisioning in modo dinamico in base alle necessità, per un massimo di sette giorni con prenotazioni a breve termine, senza una gestione complessa delle quote e con un accesso conveniente. L'avvio flessibile è basato su Dynamic Workload Scheduler e viene fatturato utilizzando i prezzi di Dynamic Workload Scheduler:

• Scontati (fino al 53%) per vCPU, GPU e TPU.
• Paghi in base al consumo.

Requisiti

Per utilizzare l'avvio flessibile in GKE, il cluster deve soddisfare i seguenti requisiti:

• Per eseguire le GPU, utilizza GKE 1.32.2-gke.1652000 o versioni successive.

• Per eseguire le TPU, utilizza GKE 1.33.0-gke.1712000 o versioni successive. L'avvio flessibile supporta le seguenti versioni e zone:

  • TPU Trillium (v6e) in asia-northeast1-b e us-east5-a.
  • TPU v5e in us-west4-a.
  • TPU v5p in us-east5-a.

  TPU v3 e v4 non sono supportate.

Come funziona la modalità di provisioning con avvio flessibile

Con l'avvio flessibile, specifichi la capacità GPU o TPU richiesta nei tuoi carichi di lavoro. Inoltre, con i cluster Standard, puoi configurare l'avvio flessibile su pool di nodi specifici. GKE esegue automaticamente il provisioning delle VM completando il seguente processo quando la capacità diventa disponibile:

1. Il workload richiede una capacità non immediatamente disponibile. Questa richiesta può essere effettuata direttamente dalla specifica del carico di lavoro o tramite strumenti di pianificazione come le classi di calcolo personalizzate o Kueue.
2. GKE identifica che il nodo ha l'avvio flessibile attivato e che il workload può attendere per un periodo di tempo indeterminato.
3. Il gestore della scalabilità automatica dei cluster accetta la tua richiesta e calcola il numero di nodi necessari, trattandoli come un'unica unità.
4. Il gestore della scalabilità automatica del cluster esegue il provisioning dei nodi necessari quando sono disponibili. Questi nodi vengono eseguiti per un massimo di sette giorni o per una durata inferiore se specifichi un valore nel parametro maxRunDurationSeconds. Questo parametro è disponibile con GKE versione 1.28.5-gke.1355000 o successive. Se non specifichi un valore per il parametro maxRunDurationSeconds, il valore predefinito è sette giorni.
5. Al termine del tempo di esecuzione definito nel parametro maxRunDurationSeconds, i nodi e i pod vengono prelati.
6. Se i pod terminano prima e i nodi non vengono più utilizzati, il gestore della scalabilità automatica del cluster li rimuove in base al profilo di scalabilità automatica.

GKE conteggia la durata di ogni richiesta di avvio flessibile a livello di nodo. Il tempo disponibile per l'esecuzione dei pod potrebbe essere leggermente inferiore a causa di ritardi durante l'avvio. I tentativi di Pod condividono questa durata, il che significa che è disponibile meno tempo per i pod dopo il tentativo. GKE conteggia la durata di ogni richiesta di avvio flessibile separatamente.

Configurazioni di avvio flessibile

GKE supporta le seguenti configurazioni di avvio flessibile:

• Avvio flessibile, in cui GKE alloca le risorse nodo per nodo. Questa configurazione richiede solo di impostare il flag --flex-start durante la creazione del nodo.

• Avvio flessibile con provisioning in coda, in cui GKE alloca tutte le risorse richieste contemporaneamente. Per utilizzare questa configurazione, devi aggiungere i flag --flex-start e enable-queued-provisioning quando crei il pool di nodi. GKE segue la procedura descritta in Come funziona la modalità di provisioning flessibile in questo documento, ma applica anche le seguenti condizioni:

  • Lo scheduler attende che tutte le risorse richieste siano disponibili in una singola zona.
  • Tutti i pod del workload possono essere eseguiti insieme sui nodi appena sottoposti a provisioning.
  • I nodi di cui è stato eseguito il provisioning non vengono riutilizzati tra le esecuzioni dei workload.

La seguente tabella confronta le configurazioni di avvio flessibile:

Ottimizzare la configurazione dell'avvio flessibile

Per creare un'infrastruttura AI/ML solida e ottimizzata per i costi, puoi combinare le configurazioni di avvio flessibile con le funzionalità GKE disponibili. Ti consigliamo di utilizzare le classi di calcolo per definire un elenco prioritario di configurazioni dei nodi in base ai requisiti del tuo workload. GKE selezionerà la configurazione più adatta in base alla disponibilità e alla priorità che hai definito.

Gestire le interruzioni nei carichi di lavoro che utilizzano Dynamic Workload Scheduler

I carichi di lavoro che richiedono la disponibilità di tutti i nodi o della maggior parte dei nodi in un pool di nodi sono sensibili alle espulsioni. Inoltre, i nodi di cui viene eseguito il provisioning utilizzando le richieste di Dynamic Workload Scheduler non supportano la riparazione automatica. La riparazione automatica rimuove tutti i carichi di lavoro da un nodo, impedendone l'esecuzione.

Tutti i nodi che utilizzano l'avvio flessibile, il provisioning in coda o entrambi utilizzano upgrade di breve durata quando il control plane del cluster esegue la versione minima per l'avvio flessibile, 1.32.2-gke.1652000 o versioni successive.

Gli upgrade di breve durata aggiornano un pool di nodi Standard o un gruppo di nodi in un cluster Autopilot senza interrompere i nodi in esecuzione. I nuovi nodi vengono creati con la nuova configurazione, sostituendo gradualmente i nodi esistenti con la vecchia configurazione nel tempo. Le versioni precedenti di GKE, che non supportano l'avvio flessibile o gli upgrade di breve durata, richiedono best practice diverse.

Best practice per ridurre al minimo le interruzioni del workload per i nodi che utilizzano upgrade di breve durata

I nodi con avvio flessibile e i nodi che utilizzano il provisioning in coda vengono configurati automaticamente per utilizzare gli upgrade di breve durata quando il cluster esegue la versione 1.32.2-gke.1652000 o successive.

Per ridurre al minimo le interruzioni dei carichi di lavoro in esecuzione sui nodi che utilizzano upgrade di breve durata, esegui le seguenti attività:

• Configura periodi di manutenzione ed esclusioni per impostare quando GKE deve e non deve eseguire operazioni di aggiornamento, come gli upgrade dei nodi, garantendo al contempo che GKE abbia ancora il tempo per eseguire la manutenzione automatica.
• Disattiva la riparazione automatica del nodo.

Per i nodi sui cluster che eseguono versioni precedenti alla 1.32.2-gke.1652000 e che quindi non utilizzano upgrade di breve durata, consulta le indicazioni specifiche per questi nodi.

Best practice per ridurre al minimo l'interruzione del workload per i nodi di provisioning in coda senza upgrade di breve durata

I nodi che utilizzano il provisioning in coda su un cluster che esegue una versione di GKE precedente alla 1.32.2-gke.1652000 non utilizzano upgrade di breve durata. I cluster di cui è stato eseguito l'upgrade alla versione 1.32.2-gke.1652000 o successive con nodi di provisioning in coda esistenti vengono aggiornati automaticamente per utilizzare gli upgrade di breve durata.

Per i nodi che eseguono queste versioni precedenti, consulta le seguenti indicazioni:

• A seconda della registrazione al canale di rilascio del cluster, utilizza le seguenti best practice per impedire che gli upgrade automatici dei nodi interrompano i tuoi carichi di lavoro:
  • Se il cluster è registrato in un canale di rilascio, utilizza finestre ed esclusioni di manutenzione per impedire a GKE di eseguire automaticamente l'upgrade dei nodi mentre il workload è in esecuzione.
  • Se il cluster non è registrato in un canale di rilascio, disattiva gli aggiornamenti automatici dei nodi. Tuttavia, consigliamo di utilizzare i canali di rilascio, in cui è possibile utilizzare esclusioni dalla manutenzione con ambiti più granulari.
• Disattiva la riparazione automatica del nodo.
• Utilizza periodi di manutenzione ed esclusioni per ridurre al minimo le interruzioni dei workload in esecuzione, garantendo al contempo che GKE abbia comunque il tempo di eseguire la manutenzione automatica. Assicurati di pianificare questo periodo di tempo quando non sono in esecuzione workload.
• Per assicurarti che il tuo pool di nodi rimanga aggiornato, esegui l'upgrade manuale del pool di nodi quando non sono attive richieste di Dynamic Workload Scheduler e il pool di nodi è vuoto.

Considerazioni per la migrazione del cluster agli upgrade di breve durata

GKE aggiorna i nodi esistenti utilizzando il provisioning in coda per utilizzare gli upgrade di breve durata quando il cluster viene aggiornato alla versione 1.32.2-gke.1652000 o successive. GKE non aggiorna altre impostazioni, ad esempio l'attivazione degli upgrade automatici dei nodi se li hai disabilitati per un pool di nodi specifico.

Ti consigliamo di prendere in considerazione l'implementazione delle seguenti best practice ora che i tuoi pool di nodi utilizzano upgrade di breve durata:

• Se hai disabilitato gli upgrade automatici dei nodi utilizzando il flag --no-enable-autoupgrade, questa migrazione non riattiva gli upgrade automatici dei nodi per il pool di nodi. Ti consigliamo di abilitare gli upgrade automatici dei nodi, perché gli upgrade di breve durata non interrompono i nodi esistenti e i carichi di lavoro in esecuzione. Per ulteriori informazioni, consulta la sezione Upgrade di breve durata.
• Ti consigliamo inoltre di registrare il cluster se non è già registrato a un canale di rilascio, in modo da poter utilizzare ambiti di esclusione della manutenzione più granulari.

Riciclo dei nodi nell'avvio flessibile

Per garantire una transizione fluida dei nodi ed evitare tempi di inattività per i job in esecuzione, flex-start supporta il riciclo dei nodi. Quando un nodo raggiunge la fine della sua durata, GKE lo sostituisce automaticamente con uno nuovo per preservare i workload in esecuzione.

Per utilizzare il riciclo dei nodi, devi creare un profilo di classe di calcolo personalizzata e includere il campo nodeRecycling nella specifica flexStart con il parametro leadTimeSeconds.

Il parametro leadTimeSeconds ti consente di bilanciare la disponibilità delle risorse e l'efficienza dei costi. Questo parametro specifica con quanti secondi di anticipo rispetto alla fine della durata di sette giorni di un nodo deve iniziare il processo di provisioning di un nuovo nodo per sostituirlo. Un lead time più lungo aumenta la probabilità che il nuovo nodo sia pronto prima che venga rimosso quello precedente, ma potrebbe comportare costi aggiuntivi.

Il processo di riciclo dei nodi è costituito dai seguenti passaggi:

1. Fase di riciclo:GKE verifica che un nodo con provisioning flessibile abbia il campo nodeRecycling con il parametro leadTimeSeconds impostato. In questo caso, GKE avvia la fase di riciclo dei nodi quando la data corrente è maggiore o uguale alla differenza tra i valori dei seguenti campi:

   • creationTimestamp + maxRunDurationSeconds
   • leadTimeSeconds

   Il flag creationTimeStamp include l'ora in cui è stato creato il nodo. Il campo maxRunDurationSeconds può essere specificato nella classe di calcolo personalizzata ed è impostato su sette giorni per impostazione predefinita.

2. Creazione del nodo:inizia il processo di creazione del nuovo nodo, che procede attraverso le fasi di accodamento e provisioning. La durata della fase di accodamento può variare in modo dinamico a seconda della zona e della capacità specifica dell'acceleratore.

3. Contrassegna come non pianificabile il nodo che sta per raggiungere la fine della durata di sette giorni:dopo l'esecuzione del nuovo nodo, il vecchio nodo viene contrassegnato come non pianificabile. Questa azione impedisce la pianificazione di nuovi pod. I pod esistenti in quel nodo continuano a essere eseguiti.

4. Decommissioning del nodo:il nodo che sta per raggiungere la fine della sua durata di sette giorni viene alla fine sottoposto a deprovisioning dopo un periodo di tempo adeguato, il che contribuisce a garantire che i carichi di lavoro in esecuzione siano stati migrati al nuovo nodo.

Il seguente esempio di configurazione di una classe di calcolo include i campi leadTimeSeconds e maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Per ulteriori informazioni su come utilizzare il riciclo dei nodi, prova l'esercitazione Servire LLM su GKE con una strategia di provisioning delle GPU a costi ottimizzati e ad alta disponibilità.

Limitazioni

• L'anti-affinità tra pod non è supportata. Il gestore della scalabilità automatica dei cluster non prende in considerazione le regole di anti-affinità tra pod durante il provisioning dei nodi, il che potrebbe portare a carichi di lavoro non pianificabili. Questa situazione può verificarsi quando i nodi per due o più oggetti Dynamic Workload Scheduler sono stati sottoposti a provisioning nello stessopool di nodil.
• Sono supportati solo i nodi GPU.
• Le prenotazioni non sono supportate con Dynamic Workload Scheduler. Devi specificare il flag --reservation-affinity=none quando crei il pool di nodi. Dynamic Workload Scheduler richiede e supporta solo i ANY criteri di località per la scalabilità automatica del cluster.
• Una singola richiesta di Dynamic Workload Scheduler può creare fino a 1000 macchine virtuali (VM), ovvero il numero massimo di nodi per zona per un singolo pool di nodi.
• GKE utilizza la quota ACTIVE_RESIZE_REQUESTS di Compute Engine per controllare il numero di richieste di Dynamic Workload Scheduler in attesa in una coda. Per impostazione predefinita, questa quota ha un limite di 100 richieste per Trusted Cloud progetto. Se tenti di creare una richiesta di Dynamic Workload Scheduler superiore a questa quota, la nuova richiesta non va a buon fine.
• I node pool che utilizzano Dynamic Workload Scheduler sono sensibili alle interruzioni perché i nodi vengono sottoposti a provisioning insieme. Per saperne di più, consulta Gestire le interruzioni nei carichi di lavoro che utilizzano Dynamic Workload Scheduler.
• Potresti visualizzare altre VM di breve durata elencate nella console Trusted Cloud . Questo comportamento è intenzionale perché Compute Engine potrebbe creare e poi rimuovere rapidamente le VM finché non è disponibile la capacità di eseguire il provisioning di tutte le macchine richieste.
• Le VM spot non sono supportate.
• Dynamic Workload Scheduler non supporta i volumi effimeri. Devi utilizzare volumi permanenti per l'archiviazione. Per selezionare il tipo di archiviazione migliore che utilizza volumi permanenti, consulta la Panoramica dell'archiviazione per i cluster GKE.
• Se il carico di lavoro utilizza il riciclo dei nodi e viene eseguito il deployment da un job, configura il job con la modalità di completamento impostata su Indexed.

Passaggi successivi

• Seleziona un tipo di GPU
• Esegui il deployment delle GPU con Dynamic Workload Scheduler.