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

Questa pagina descrive l'avvio flessibile in Google Kubernetes Engine (GKE). L'avvio flessibile, basato su Dynamic Workload Scheduler, fornisce una tecnica flessibile ed economica per utilizzare risorse di calcolo specializzate, come GPU o TPU, quando devi eseguire workload AI/ML.

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

Le informazioni riportate in questa pagina possono aiutarti a:

  • Comprendere il funzionamento dell'avvio flessibile in GKE.
  • Decidere se l'avvio flessibile è adatto al tuo workload.
  • Decidere quale configurazione di avvio flessibile è adatta al tuo workload.
  • Gestire le interruzioni quando utilizzi le VM con avvio flessibile.
  • Comprendere le limitazioni delle VM con avvio flessibile in GKE.

Questa pagina è destinata agli amministratori e agli operatori della piattaforma e agli ingegneri di machine learning (ML) che vogliono ottimizzare l'infrastruttura di accelerazione 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 workload richiedono risorse TPU che vengono eseguite nei node pool di sezioni TPU a host singolo.
  • I tuoi workload richiedono altro hardware specializzato, come la serie di macchine H4D ottimizzata per HPC.
  • Hai una capacità GPU o TPU riservata limitata o inesistente 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 punta.

Prezzi dell'avvio flessibile

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

  • Sconto (fino al 53%) per vCPU, GPU e TPU.
  • Pagamento a consumo.

Requisiti

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

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

  • Per eseguire le TPU, consulta i requisiti della versione di GKE in Pianificare le TPU in GKE. L'avvio flessibile supporta le seguenti versioni e zone:

    • Ironwood (TPU7x) in us-central1-c.
    • TPU Trillium (v6e) in asia-northeast1-b, us-east5-a e us-east5-b.
    • 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à di calcolo richiesta (ad esempio GPU o TPU) nei tuoi workload. Inoltre, con i cluster standard, configuri l'avvio flessibile su node pool specifici. GKE esegue automaticamente il provisioning delle VM con avvio flessibile completando la seguente procedura quando la capacità diventa disponibile:

  1. Il workload richiede una capacità non immediatamente disponibile. Questa richiesta può essere effettuata direttamente dalla specifica del workload o tramite strumenti di orchestrazione come le classi di computing personalizzate o Kueue.
  2. GKE identifica che l'avvio flessibile è abilitato sul nodo e che il workload può attendere per un periodo di tempo indeterminato.
  3. Il gestore della scalabilità automatica dei cluster accetta la richiesta e calcola il numero di nodi necessari, trattandoli come una singola unità.
  4. Il gestore della scalabilità automatica dei 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. Se non specifichi un valore per il parametro maxRunDurationSeconds, il valore predefinito è di sette giorni.
  5. Al termine del tempo di esecuzione definito nel parametro maxRunDurationSeconds termina, i nodi e i pod vengono prerilasciati.
  6. Se i pod terminano prima e i nodi non vengono più utilizzati, il gestore della scalabilità automatica dei 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 dei ritardi durante l'avvio. I tentativi di ripetizione dei pod condividono questa durata, il che significa che dopo il tentativo di ripetizione è disponibile meno tempo per i pod. 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 l'impostazione del 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 con avvio flessibile in questo documento, ma applica anche le seguenti condizioni:

    • Il pianificatore attende finché tutte le risorse richieste non sono disponibili in una singola zona.
    • Tutti i pod del workload possono essere eseguiti insieme sui nodi di cui è stato eseguito il provisioning di recente.
    • 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:

Avvio flessibile Avvio flessibile con provisioning in coda
Disponibilità Anteprima

Disponibilità generale (GA)

Nota: l'avvio flessibile supporta i flag flex-start e enable-queued-provisioning in anteprima.
Acceleratori supportati
Dimensioni del workload consigliate Da piccole a medie, il che significa che il workload può essere eseguito su un singolo nodo. Ad esempio, questa configurazione è ideale se esegui piccoli job di addestramento, inferenza offline o job batch. Da medie a grandi, il che significa che il workload può essere eseguito su più nodi. Il workload richiede più risorse e non può iniziare l'esecuzione finché non viene eseguito il provisioning e la preparazione di tutti i nodi contemporaneamente. Ad esempio, questa configurazione è ideale se esegui workload di addestramento di machine learning distribuiti.
Tipo di provisioning GKE esegue il provisioning di un nodo alla volta quando le risorse sono disponibili. Per le TPU, GKE crea un nodo alla volta nei node pool di sezioni TPU a host singolo e la sezione completa alla volta nei node pool di sezioni TPU multi-host. GKE alloca tutte le risorse richieste contemporaneamente.
Complessità della configurazione Meno complessa. Questa configurazione è simile alle VM on demand e spot. Più complessa. Ti consigliamo vivamente di utilizzare uno strumento di gestione delle quote, come Kueue.
Supporto delle classi di computing personalizzate Sì No
Riciclo dei nodi Sì No
Prezzo SKU di avvio flessibile SKU di avvio flessibile
Quota
Strategia di upgrade dei nodi Upgrade di breve durata Upgrade di breve durata
gcloud container node pool create flag --flex-start
  • --flex-start
  • --enable-queued-provisioning
Inizia GPU: TPU: Eseguire un workload su larga scala con l'avvio flessibile con provisioning in coda

Ottimizzare la configurazione dell'avvio flessibile

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

Gestire le interruzioni nei workload che utilizzano Dynamic Workload Scheduler

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

Tutti i nodi che utilizzano VM Flex-start, 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 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 dei workload per i nodi che utilizzano upgrade di breve durata

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

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

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 le interruzioni dei 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 upgrade di breve durata.

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

Considerazioni per la migrazione del cluster agli upgrade di breve durata

GKE aggiorna i nodi esistenti utilizzando il provisioning in coda per utilizzare upgrade di breve durata quando il cluster viene sottoposto all'upgrade alla versione 1.32.2-gke.1652000 o successive. GKE non aggiorna altre impostazioni, ad esempio l'abilitazione 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 node pool utilizzano upgrade di breve durata:

Riciclo dei nodi nell'avvio flessibile

Per garantire una transizione fluida dei nodi ed evitare tempi di inattività per i job in esecuzione, l'avvio flessibile 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 computing personalizzato e includere il campo nodeRecycling nella specifica flexStart con il leadTimeSeconds parametro.

Il parametro leadTimeSeconds consente di bilanciare la disponibilità delle risorse e l'efficienza dei costi. Questo parametro specifica con quanti secondi di anticipo (in secondi) prima che un nodo raggiunga la fine della sua durata di sette giorni deve iniziare il processo di provisioning di un nuovo nodo per sostituirlo. Un tempo di risposta più lungo aumenta la probabilità che il nuovo nodo sia pronto prima della rimozione del vecchio, ma potrebbe comportare costi aggiuntivi.

Il processo di riciclo dei nodi prevede i seguenti passaggi:

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

    • creationTimestamp più maxRunDurationSeconds
    • leadTimeSeconds

    Il flag creationTimeStamp include l'ora in cui è stato creato il nodo. Il campo maxRunDurationSeconds può essere specificato nella classe di computing personalizzata e il valore predefinito è di sette giorni.

  2. Creazione del nodo: inizia il processo di creazione del nuovo nodo, passando per le fasi di accodamento e provisioning. La durata della fase di accodamento può variare dinamicamente a seconda della zona e della capacità specifica dell'acceleratore.

  3. Isolamento del nodo che sta per raggiungere la fine della sua durata di sette giorni: dopo che il nuovo nodo è in esecuzione, il vecchio nodo viene isolato. Questa azione impedisce la pianificazione di nuovi pod su di esso. I pod esistenti in quel nodo continuano a essere eseguiti.

  4. Deprovisioning del nodo: dopo un periodo di tempo adeguato, viene eseguito il deprovisioning del nodo che sta per raggiungere la fine della sua durata di sette giorni, il che contribuisce a garantire la migrazione dei workload in esecuzione al nuovo nodo.

Il seguente esempio di configurazione della classe di computing 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 il tutorial Gestire gli LLM su GKE con una strategia di provisioning delle GPU con ottimizzazione dei costi e alta disponibilità.

Limitazioni

  • L'anti-affinità tra pod non è supportata. Il gestore della scalabilità automatica dei cluster non considera le regole di anti-affinità tra pod durante il provisioning dei nodi, il che potrebbe portare a workload non pianificabili. Questa situazione potrebbe verificarsi quando è stato eseguito il provisioning dei nodi per due o più oggetti Dynamic Workload Scheduler nello stesso pool di nodi.
  • 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 la ANY policy di località per la scalabilità automatica dei 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 Google 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é viene eseguito il provisioning dei nodi contemporaneamente. Per saperne di più, consulta Gestire le interruzioni nei workload che utilizzano Dynamic Workload Scheduler.
  • Potresti visualizzare altre VM di breve durata elencate nella Google Cloud console. Questo comportamento è previsto perché Compute Engine potrebbe creare e poi rimuovere immediatamente 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 temporanei. Devi utilizzare volumi permanenti per l'archiviazione. Per selezionare il tipo di archiviazione migliore che utilizza i volumi permanenti, consulta la panoramica dell'archiviazione per i cluster GKE.
  • Se il workload utilizza il riciclo dei nodi e viene eseguito il deployment da un job, configura il job con la modalità di completamento impostata su Indexed.
  • Un singolo oggetto ProvisioningRequest supporta una sola voce nell'elenco podSets. Le richieste con più voci podSet non vanno a buon fine.

Passaggi successivi