Addestramento distribuito

Questa pagina descrive come eseguire job di addestramento distribuito su Vertex AI.

Requisiti di codice

Utilizza un framework ML che supporti l'addestramento distribuito. Nel codice di addestramento, puoi utilizzare le variabili di ambiente CLUSTER_SPEC o TF_CONFIG per fare riferimento a parti specifiche del cluster di addestramento.

Struttura del cluster di addestramento

Se esegui un job di addestramento distribuito con Vertex AI, devi specificare più macchine (nodi) in un cluster di addestramento. Il servizio di addestramento alloca le risorse per i tipi di macchine specificati. Il job in esecuzione su un determinato nodo è chiamato replica. Un gruppo di repliche con la stessa configurazione è chiamato pool di worker.

A ogni replica nel cluster di addestramento viene assegnato un singolo ruolo o attività nell'addestramento distribuito. Ad esempio:

• Replica principale: esattamente una replica è designata come replica principale. Questa attività gestisce le altre e segnala lo stato del job nel suo complesso.

• Worker: una o più repliche possono essere designate come worker. Queste repliche svolgono la loro parte di lavoro come specificato nella configurazione del job.

• Server dei parametri: se supportato dal framework ML, una o più repliche possono essere designate come server dei parametri. Queste repliche archiviano i parametri del modello e coordinano lo stato del modello condiviso tra i worker.

• Valutatore/i: se supportato dal tuo framework ML, una o più repliche possono essere designate come valutatori. Queste repliche possono essere utilizzate per valutare il modello. Se utilizzi TensorFlow, tieni presente che in genere non è previsto l'utilizzo di più di un valutatore.

Configura un job di addestramento distribuito

Puoi configurare qualsiasi job di addestramento personalizzato come job di addestramento distribuito definendo più pool di worker. Puoi anche eseguire l'addestramento distribuito all'interno di una pipeline di addestramento o di un job di ottimizzazione degli iperparametri.

Per configurare un job di addestramento distribuito, definisci l'elenco dei pool di worker (workerPoolSpecs[]), assegnando un WorkerPoolSpec per ogni tipo di attività:

Devi specificare una replica primaria, che coordina il lavoro svolto da tutte le altre repliche. Utilizza la prima specifica del pool di worker solo per la replica principale e imposta il relativo replicaCount su 1:

{
  "workerPoolSpecs": [
     // `WorkerPoolSpec` for worker pool 0, primary replica, required
     {
       "machineSpec": {...},
       "replicaCount": 1,
       "diskSpec": {...},
       ...
     },
     // `WorkerPoolSpec` for worker pool 1, optional
     {},
     // `WorkerPoolSpec` for worker pool 2, optional
     {},
     // `WorkerPoolSpec` for worker pool 3, optional
     {}
   ]
   ...
}

Specifica worker pool aggiuntivi

A seconda del framework ML, puoi specificare worker pool aggiuntivi per altri scopi. Ad esempio, se utilizzi TensorFlow, puoi specificare i pool di worker per configurare le repliche dei worker, le repliche del server dei parametri e le repliche dell'evaluatore.

L'ordine dei pool di worker specificati nell'elenco workerPoolSpecs[] determina il tipo di pool di worker. Imposta valori vuoti per i pool di worker che non vuoi utilizzare, in modo da poterli saltare nell'elenco workerPoolSpecs[] per specificare i pool di worker che vuoi utilizzare. Ad esempio:

Se vuoi specificare un job che ha solo una replica primaria e un pool di worker del server di parametri, devi impostare un valore vuoto per il pool di worker 1:

{
  "workerPoolSpecs": [
     // `WorkerPoolSpec` for worker pool 0, required
     {
       "machineSpec": {...},
       "replicaCount": 1,
       "diskSpec": {...},
       ...
     },
     // `WorkerPoolSpec` for worker pool 1, optional
     {},
     // `WorkerPoolSpec` for worker pool 2, optional
     {
       "machineSpec": {...},
       "replicaCount": 1,
       "diskSpec": {...},
       ...
     },
     // `WorkerPoolSpec` for worker pool 3, optional
     {}
   ]
   ...
}

Ridurre il tempo di addestramento con il server di riduzione

Quando addestri un modello di ML di grandi dimensioni utilizzando più nodi, la comunicazione dei gradienti tra i nodi può contribuire a una latenza significativa. Reduction Server è un algoritmo di riduzione che può aumentare il throughput e ridurre la latenza per l'addestramento distribuito. Vertex AI rende disponibile Reduction Server in un'immagine container Docker che puoi utilizzare per uno dei tuoi pool di worker durante l'addestramento distribuito.

Per scoprire di più sul funzionamento di Reduction Server, consulta Addestramento GPU distribuito più rapido con Reduction Server su Vertex AI.

Prerequisiti

Puoi utilizzare il server di riduzione se soddisfi i seguenti requisiti:

• Stai eseguendo l'addestramento distribuito con i worker GPU.

• Il codice di addestramento utilizza TensorFlow o PyTorch ed è configurato per l'addestramento parallelo dei dati su più host con GPU utilizzando NCCL all-reduce. Potresti anche essere in grado di utilizzare altri framework di ML che utilizzano NCCL.

• I container in esecuzione sul nodo primario (workerPoolSpecs[0]) e sui worker (workerPoolSpecs[1]) supportano il server di riduzione. Nello specifico, ogni contenitore è uno dei seguenti:

  • Un container di addestramento TensorFlow predefinito, versione 2.3 o successiva.

  • Un container predefinito per l'addestramento PyTorch, versione 1.4 o successiva.

  • Un container personalizzato con NCCL 2.7 o versioni successive e il pacchetto google-reduction-server installato. Puoi installare questo pacchetto su un'immagine container personalizzata aggiungendo la seguente riga al Dockerfile:

    RUN echo "deb https://packages.cloud.google.com/apt google-fast-socket main" | tee /etc/apt/sources.list.d/google-fast-socket.list && \
        curl -s -L https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - && \
        apt update && apt install -y google-reduction-server
    

Addestramento utilizzando il server di riduzione

Per utilizzare il server di riduzione, procedi nel seguente modo quando crei una risorsa di addestramento personalizzata:

1. Specifica uno dei seguenti URI nel campo containerSpec.imageUri del terzo pool di worker (workerPoolSpecs[2]):

   • us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
   • europe-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
   • asia-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest

   La scelta della regione multipla più vicina a quella in cui esegui l'addestramento personalizzato potrebbe ridurre la latenza.

2. Quando selezioni il tipo di macchina e il numero di nodi per il terzo worker pool, assicurati che la larghezza di banda di rete totale del terzo worker pool corrisponda o superi la larghezza di banda di rete totale del primo e del secondo worker pool.

   Per scoprire la larghezza di banda massima disponibile di ogni nodo nel secondo pool di worker, consulta Larghezza di banda di rete e GPU.

   Non utilizzi le GPU per i nodi del server di riduzione. Per informazioni sulla larghezza di banda massima disponibile di ogni nodo nel terzo pool di worker, consulta le colonne "Larghezza di banda in uscita massima (Gbps)" nella famiglia di macchine per uso generico.

   Ad esempio, se configuri il primo e il secondo pool di worker in modo che utilizzino 5 nodi n1-highmem-96, ciascuno con 8 GPU NVIDIA_TESLA_V100, ogni nodo ha una larghezza di banda massima disponibile di 100 Gbps, per una larghezza di banda totale di 500 Gbps. Per corrispondere a questa larghezza di banda nel terzo pool di worker, potresti utilizzare 16 nodi n1-highcpu-16, ciascuno con una larghezza di banda massima di 32 Gbps, per una larghezza di banda totale di 512 Gbps.

   Ti consigliamo di utilizzare il tipo di macchina n1-highcpu-16 per i nodi del server di riduzione, perché questo tipo di macchina offre una larghezza di banda relativamente elevata per le sue risorse.

Il comando seguente fornisce un esempio di come creare una risorsa CustomJob che utilizza il server di riduzione:

gcloud ai custom-jobs create \
  --region=LOCATION \
  --display-name=JOB_NAME \
  --worker-pool-spec=machine-type=n1-highmem-96,replica-count=1,accelerator-type=NVIDIA_TESLA_V100,accelerator-count=8,container-image-uri=CUSTOM_CONTAINER_IMAGE_URI \
  --worker-pool-spec=machine-type=n1-highmem-96,replica-count=4,accelerator-type=NVIDIA_TESLA_V100,accelerator-count=8,container-image-uri=CUSTOM_CONTAINER_IMAGE_URI \
  --worker-pool-spec=machine-type=n1-highcpu-16,replica-count=16,container-image-uri=us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest

Per maggiori informazioni, consulta la guida alla creazione di un CustomJob.

Best practice per l'addestramento utilizzando Reduction Server

Tipo di macchina e conteggio

Nell'addestramento del server di riduzione, ogni worker deve connettersi a tutti gli host di riduzione. Per ridurre al minimo il numero di connessioni sull'host worker, utilizza un tipo di macchina con la larghezza di banda di rete più elevata per l'host reducer.

Una buona scelta per gli host di riduzione è una VM N1/N2 per uso generico con almeno 16 vCPU che fornisca 32 Gbps di larghezza di banda in uscita, come n1-highcpu-16 e n2-highcpu-16. La larghezza di banda delle VM di livello 1 per le VM N1/N2 aumenta la larghezza di banda in uscita massima compresa tra 50 Gbps e 100 Gbps, il che le rende una buona scelta per i nodi VM di riduzione.

La larghezza di banda di uscita totale di worker e reducer deve essere la stessa. Ad esempio, se utilizzi 8 VM a2-megagpu-16g come worker, devi utilizzare almeno 25 VM n1-highcpu-16 come reducer.

`(8 worker VMs * 100 Gbps) / 32 Gbps egress = 25 reducer VMs`.

Raggruppa i messaggi di piccole dimensioni

Il server di riduzione funziona meglio se i messaggi da aggregare sono sufficientemente grandi. La maggior parte dei framework ML fornisce già tecniche con terminologia diversa per raggruppare piccoli tensori di gradienti prima di eseguire la riduzione totale.

Horovod

Horovod supporta Tensor Fusion per raggruppare piccoli tensori per la riduzione collettiva. I tensori vengono riempiti in un buffer di fusione finché il buffer non è completamente pieno e viene eseguita l'operazione all-reduce sul buffer. Puoi regolare le dimensioni del buffer di fusione impostando la variabile di ambiente HOROVOD_FUSION_THRESHOLD.

Il valore consigliato per la variabile di ambiente HOROVOD_FUSION_THRESHOLD è almeno 128 MB. In questo caso, imposta la variabile di ambiente HOROVOD_FUSION_THRESHOLD su 134217728 (128 * 1024 * 1024).

PyTorch

DistributedDataParallel di PyTorch supporta i messaggi batch come "raggruppamento dei gradienti". Imposta il parametro bucket_cap_mb nel costruttore DistributedDataParallel per controllare la dimensione dei bucket batch. La dimensione predefinita è 25 MB.

BEST PRACTICE: il valore consigliato di bucket_cap_mb è 64 (64 MB).

Variabili di ambiente per il cluster

Vertex AI compila una variabile di ambiente, CLUSTER_SPEC, su ogni replica per descrivere la configurazione complessiva del cluster. Come TF_CONFIG di TensorFlow, CLUSTER_SPEC descrive ogni replica nel cluster, incluso il relativo indice e ruolo (replica principale, worker, server dei parametri o valutatore).

Quando esegui l'addestramento distribuito con TensorFlow, TF_CONFIG viene analizzato per creare tf.train.ClusterSpec. Allo stesso modo, quando esegui l'addestramento distribuito con altri framework ML, devi analizzare CLUSTER_SPEC per popolare le variabili di ambiente o le impostazioni richieste dal framework.

Il formato di CLUSTER_SPEC

La variabile di ambiente CLUSTER_SPEC è una stringa JSON con il seguente formato:

Esempio di CLUSTER_SPEC

Ecco un valore di esempio:

{
   "cluster":{
      "workerpool0":[
         "cmle-training-workerpool0-ab-0:2222"
      ],
      "workerpool1":[
         "cmle-training-workerpool1-ab-0:2222",
         "cmle-training-workerpool1-ab-1:2222"
      ],
      "workerpool2":[
         "cmle-training-workerpool2-ab-0:2222",
         "cmle-training-workerpool2-ab-1:2222"
      ],
      "workerpool3":[
         "cmle-training-workerpool3-ab-0:2222",
         "cmle-training-workerpool3-ab-1:2222",
         "cmle-training-workerpool3-ab-2:2222"
      ]
   },
   "environment":"cloud",
   "task":{
      "type":"workerpool0",
      "index":0,
      "trial":"TRIAL_ID"
   },
   "job": {
      ...
   }
}

Il formato di TF_CONFIG

Oltre a CLUSTER_SPEC, Vertex AI imposta la variabile di ambiente TF_CONFIG su ogni replica di tutti i job di addestramento distribuito. Vertex AI non imposta TF_CONFIG per i job di addestramento con una sola replica.

CLUSTER_SPEC e TF_CONFIG condividono alcuni valori, ma hanno formati diversi. Entrambe le variabili di ambiente includono campi aggiuntivi oltre a quelli richiesti da TensorFlow.

L'addestramento distribuito con TensorFlow funziona allo stesso modo quando utilizzi container personalizzati e quando utilizzi un container predefinito.

La variabile di ambiente TF_CONFIG è una stringa JSON nel seguente formato:

Esempio di TF_CONFIG

Il seguente codice di esempio stampa la variabile di ambiente TF_CONFIG nei log di addestramento:

import json
import os

tf_config_str = os.environ.get('TF_CONFIG')
tf_config_dict  = json.loads(tf_config_str)

# Convert back to string just for pretty printing
print(json.dumps(tf_config_dict, indent=2))

In un job di ottimizzazione degli iperparametri eseguito nella versione runtime 2.1 o successive e che utilizza un worker master, due worker e un server dei parametri, questo codice produce il seguente log per uno dei worker durante il primo tentativo di ottimizzazione degli iperparametri. L'output di esempio nasconde il campo job per brevità e sostituisce alcuni ID con valori generici.

{
  "cluster": {
    "chief": [
      "training-workerpool0-[ID_STRING_1]-0:2222"
    ],
    "ps": [
      "training-workerpool2-[ID_STRING_1]-0:2222"
    ],
    "worker": [
      "training-workerpool1-[ID_STRING_1]-0:2222",
      "training-workerpool1-[ID_STRING_1]-1:2222"
    ]
  },
  "environment": "cloud",
  "job": {
    ...
  },
  "task": {
    "cloud": "[ID_STRING_2]",
    "index": 0,
    "trial": "1",
    "type": "worker"
  }
}

Quando utilizzarli TF_CONFIG

TF_CONFIG è impostato solo per i job di addestramento distribuito.

Probabilmente non devi interagire direttamente con la variabile di ambiente TF_CONFIG nel codice di addestramento. Accedi solo alla variabile di ambiente TF_CONFIG se le strategie di distribuzione di TensorFlow e il flusso di lavoro standard di ottimizzazione degli iperparametri di Vertex AI, entrambi descritti nelle sezioni successive, non funzionano per il tuo job.

Addestramento distribuito

Vertex AI imposta la variabile di ambiente TF_CONFIG per estendere le specifiche richieste da TensorFlow per l'addestramento distribuito.

Per eseguire l'addestramento distribuito con TensorFlow, utilizza l'tf.distribute.Strategy API. In particolare, ti consigliamo di utilizzare l'API Keras insieme a MultiWorkerMirroredStrategy o, se specifichi i parameter server per il tuo job, a ParameterServerStrategy. Tuttavia, tieni presente che TensorFlow fornisce solo il supporto sperimentale per queste strategie.

Queste strategie di distribuzione utilizzano la variabile di ambiente TF_CONFIG per assegnare ruoli a ogni VM nel job di addestramento e per facilitare la comunicazione tra le VM. Non devi accedere direttamente alla variabile di ambiente TF_CONFIG nel codice di addestramento, perché TensorFlow la gestisce per te.

Analizza la variabile di ambiente TF_CONFIG direttamente solo se vuoi personalizzare il comportamento delle diverse VM che eseguono il job di addestramento.

Ottimizzazione degli iperparametri

Quando esegui un job di ottimizzazione degli iperparametri, Vertex AI fornisce argomenti diversi al codice di addestramento per ogni prova. Il codice di addestramento non deve necessariamente sapere quale prova è attualmente in esecuzione. Inoltre, puoi monitorare l'avanzamento dei job di ottimizzazione degli iperparametri nella console Google Cloud .

Se necessario, il codice può leggere il numero di prova corrente dal campo trial del campo task della variabile di ambiente TF_CONFIG.

Passaggi successivi

• Crea una pipeline di addestramento.