Risorse di computing

Se ti interessano i cluster di addestramento di Gemini Enterprise Agent Platform, contatta il tuo rappresentante di vendita per l'accesso.

I cluster di addestramento di Gemini Enterprise Agent Platform supportano una varietà di tipi di macchine per adattarsi a diversi carichi di lavoro. Puoi scegliere tra le seguenti opzioni quando configuri i pool di nodi del cluster:

  • a4-highgpu-8g
  • a4x-highgpu-4g
  • a3-ultragpu-8g
  • a3-megagpu-8g
  • Famiglia di CPU n2

Tipo di macchina A4X

I cluster di addestramento di Gemini Enterprise Agent Platform supportano il tipo di macchina A4X ottimizzato per l'acceleratore (a4x-highgpu-4g), una piattaforma exascale basata sull'architettura NVIDIA GB200 NVL72 a livello di rack.

Confronto architettonico

La seguente tabella illustra le differenze hardware fondamentali tra la famiglia A4X e altre famiglie ottimizzate per l'acceleratore.

Funzionalità A4X (a4x-highgpu-4g) A3 / A4H
Architettura della CPU ARM X86
Conteggio GPU 4 GPU per nodo 8 GPU per nodo
Tipo di prenotazione Modalità Tutta la capacità Modalità gestita
Criterio di posizionamento Rigoroso (compatto) Flessibile

Linee guida specifiche per A4X

  • Il numero di VM del pool di nodi A4X deve essere un multiplo di 18 (ad esempio 18, 36, 54). Questo è necessario perché la capacità A4X viene provisioning in blocchi fissi e non condivisibili di 18 nodi chiamati domini NVLink. Questi domini sono vincolati da una rigida policy di posizionamento compatto e tutti i blocchi allocati parzialmente non possono essere utilizzati da altri cluster.
  • A causa dell'architettura basata su ARM dei nodi A4X, devi apportare due modifiche chiave ai tuoi workload di addestramento:
    • Utilizza immagini compatibili con ARM: tutti i job di addestramento devono utilizzare un'immagine container creata per l'architettura ARM.
    • Adattamento per 4 GPU: la logica di addestramento distribuito deve essere aggiornata per riconoscere e utilizzare correttamente le 4 GPU disponibili su ogni nodo A4X.
  • Procedura di segnalazione di host difettosi e tempi di inattività Quando segnali un host come difettoso, tieni presente la seguente procedura di ripristino:
    • Nessuna capacità di standby: il sistema non utilizza un pool di riserva di standby per una sostituzione immediata dei nodi.
    • Recupero basato sulla riparazione: il nodo rimane non disponibile finché l'host fisico sottostante non viene riparato.
    • Tempi di inattività prolungati: questa procedura di riparazione richiede in genere da 3 a 14 giorni.

Provisioning della capacità

La scelta del modello di provisioning giusto è fondamentale per bilanciare costi, velocità e disponibilità delle risorse. Vedi le seguenti opzioni di provisioning:

  • RESERVATION: alloca nodi da una prenotazione Compute Engine specifica che hai creato in anticipo. Questo modello garantisce la capacità ed è la scelta consigliata per le risorse ad alta richiesta.

  • FLEX_START: utilizza Dynamic Workload Scheduler per mettere in coda il job. Il job inizia automaticamente non appena le risorse di calcolo richieste diventano disponibili, offrendo un orario di inizio flessibile senza richiedere una prenotazione.

  • SPOT: esegue il provisioning del pool di nodi utilizzando le VM spot. Si tratta dell'opzione più economica, ma deve essere utilizzata solo per i carichi di lavoro a tolleranza di errore e in grado di gestire le interruzioni, poiché le VM potrebbero essere prerilasciate in qualsiasi momento.

  • ON_DEMAND: questa è l'opzione predefinita per i node pool solo CPU ed è più adatta ai tipi di macchine non scarsi. Fornisce istanze VM standard con prezzi prevedibili e con pagamento a consumo.

Segui queste indicazioni per effettuare la selezione:

  • Per le risorse GPU ad alta richiesta (come A3 e A4): il modello RESERVATION è fortemente consigliato. Ti garantisce l'accesso dedicato alla capacità di cui hai bisogno per i job di addestramento critici.

  • Per i workload bursty o flessibili: valuta FLEX_START o SPOT. FLEX_START mette in coda il job finché non sono disponibili risorse, mentre SPOT offre un notevole risparmio sui costi per i job a tolleranza di errore che possono gestire la preemption.

  • Per i tipi di macchine abbondanti: il modello ON_DEMAND è la scelta preferita. Utilizzalo per i tipi di macchine non scarsi e per i quali la disponibilità immediata non è un problema.

Utilizzo di una prenotazione condivisa (facoltativo)

Se vuoi utilizzare una prenotazione condivisa anziché una prenotazione locale, devi eseguire altri passaggi prima di poter creare un cluster.

Prima di utilizzare una prenotazione condivisa con i cluster di addestramento di Gemini Enterprise Agent Platform, assicurati che la prenotazione condivisa funzioni creando manualmente una VM che la utilizzi. Se la creazione della VM funziona, vai al passaggio successivo. Nella configurazione di creazione del cluster, utilizza il nome della prenotazione nel seguente formato: projects/RESERVATION_HOST_PROJECT_ID/zones/RESERVATION_ZONE/reservations/RESERVATION_NAME.

Passaggi successivi

Dopo aver selezionato le opzioni di calcolo e provisioning per il cluster di addestramento, puoi creare il cluster ed eseguire un workload.