Questa pagina descrive come eseguire job di addestramento distribuito su Vertex AI.
Requisiti di codice
Utilizza un framework ML che supporta 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, specifica 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 del cluster di addestramento viene assegnato un singolo ruolo o un'unica attività nell'addestramento distribuito. Ad esempio:
Replica principale: viene designata esattamente una replica come replica principale. Questa attività gestisce le altre e segnala lo stato del compito nel suo complesso.
Worker: una o più repliche possono essere designate come worker. Queste repliche svolgono la propria parte di lavoro come indicato nella configurazione del job.
Server dei parametri: se supportati dal tuo framework ML, una o più repliche possono essere designate come server dei parametri. Queste repliche memorizzano i parametri del modello e coordinano lo stato del modello condiviso tra i worker.
Valutatori: 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 si aspetta che tu non utilizzi più di un valutatore.
Configurare 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[]),
designando un WorkerPoolSpec per ogni tipo di attività:
Posizione in workerPoolSpecs[] |
Attività eseguita nel cluster |
|---|---|
Primo (workerPoolSpecs[0]) |
Principale, principale, pianificatore o "master" |
Secondo (workerPoolSpecs[1]) |
Secondario, repliche, worker |
Terza (workerPoolSpecs[2]) |
Server dei parametri, server di riduzione |
Quarto (workerPoolSpecs[3]) |
Valutatori |
Devi specificare una replica principale, 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 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 altri pool di worker
A seconda del framework ML, puoi specificare pool di worker 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 degli valutatori.
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 ignorare nell'elenco workerPoolSpecs[] per specificare quelli che vuoi utilizzare. Ad esempio:
Se vuoi specificare un job con una sola replica principale 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
{}
]
...
}
Riduci il tempo di addestramento con Reduction Server
Quando addestri un modello di ML di grandi dimensioni utilizzando più nodi, la comunicazione delle derive tra i nodi può contribuire a una latenza significativa. Reduction Server è un algoritmo all-reduce che può aumentare il throughput e ridurre la latenza per l'addestramento distribuito. Vertex AI rende disponibile Reduction Server in un'immagine del contenitore Docker che puoi utilizzare per uno dei tuoi pool di worker durante l'addestramento distribuito.
Per scoprire come funziona Reduction Server, consulta Addestramento GPU distribuito più rapido con Reduction Server su Vertex AI.
Prerequisiti
Puoi utilizzare Reduction Server 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 che utilizzano la riduzione all'insieme di NCCL. Potresti anche utilizzare altri framework ML che utilizzano NCCL.
I container in esecuzione sul nodo principale (
workerPoolSpecs[0]) e sui worker (workerPoolSpecs[1]) supportano il server di riduzione. Nello specifico, ogni contenitore è uno dei seguenti:Un contenitore di addestramento TensorFlow predefinito, versione 2.3 o successiva.
Un contenitore predefinito per l'addestramento di PyTorch, versione 1.4 o successiva.
Un container personalizzato con NCCL 2.7 o versioni successive e il pacchetto
google-reduction-serverinstallato. Puoi installare questo pacchetto su un'immagine container personalizzata aggiungendo la seguente riga al tuo 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 con Reduction Server
Per utilizzare Reduction Server, segui questa procedura quando crei una risorsa di addestramento personalizzata:
Specifica uno dei seguenti URI nel
containerSpec.imageUricampo del terzo pool di worker (workerPoolSpecs[2]):us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latesteurope-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latestasia-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
La scelta della regione più vicina a quella in cui esegui l'addestramento personalizzato potrebbe ridurre la latenza.
Quando selezioni il tipo di macchina e il numero di nodi per il terzo pool di worker, assicurati che la larghezza di banda di rete totale del terzo pool di worker corrisponda o superi quella del primo e del secondo pool di worker.
Per informazioni sulla larghezza di banda massima disponibile di ogni nodo nel secondo pool di worker, consulta Larghezza di banda della rete e GPU.
Non utilizzi 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)" in Famiglia di macchine general purpose.
Ad esempio, se configuri il primo e il secondo pool di worker in modo che utilizzino 5
n1-highmem-96nodi, ciascuno con 8 GPUNVIDIA_TESLA_V100, ogni nodo ha una larghezza di banda massima disponibile di 100 Gbps, per una larghezza di banda totale di 500 Gbps. Per eguagliare questa larghezza di banda nel terzo pool di worker, potresti utilizzare 16 nodin1-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-16per i nodi del server di riduzione, in quanto offre una larghezza di banda relativamente elevata per le sue risorse.
Il seguente comando fornisce un esempio di come creare una risorsa CustomJob
che utilizza Reduction Server:
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 con Reduction Server
Tipo di macchina e conteggio
Nell'addestramento del server di riduzione, ogni worker deve connettersi a tutti gli host dei riduttore. 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 del riduttore.
Una buona scelta per gli host dei riduttori è una VM N1/N2 per uso generico con almeno 16 vCPU che offre una larghezza di banda in uscita di 32 Gbps, 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 da 50 a 100 Gbps, il che le rende una
buona scelta per i nodi VM di riduzione.
La larghezza di banda in uscita totale di worker e riduttori deve essere la stessa. Ad esempio, se utilizzi 8 VM a2-megagpu-16g come worker, devi utilizzare almeno 25 VM a2-megagpu-16g come riduttori.n1-highcpu-16
`(8 worker VMs * 100 Gbps) / 32 Gbps egress = 25 reducer VMs`.
Raggruppare piccoli messaggi
Reduction Server funziona al meglio se i messaggi da aggregare sono sufficientemente grandi. La maggior parte dei framework ML fornisce già tecniche con terminologia diversa per il raggruppamento di piccoli tensori di gradiente prima di eseguire l'operazione all-reduce.
Horovod
Horovod supporta la fusione di tensori per raggruppare piccoli tensori per l'operazione all-reduce. I tensori vengono inseriti in un buffer di fusione fino a quando il buffer non è completamente pieno ed viene eseguita l'operazione di riduzione totale 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 è di 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 "bucketing del gradiente". Imposta il parametro bucket_cap_mb
nel costruttore DistributedDataParallel per controllare le dimensioni dei bucket batch.
La dimensione predefinita è 25 MB.
BEST PRACTICE: il valore consigliato per 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 del cluster complessivo. Come TF_CONFIG di TensorFlow, CLUSTER_SPEC descrive ogni replica del cluster, incluso l'indice e il ruolo (replica principale, worker, server di parametri o valutatore).
Quando esegui l'addestramento distribuito con TensorFlow, TF_CONFIG viene analizzato per compilare tf.train.ClusterSpec.
Analogamente, quando esegui l'addestramento distribuito con altri framework ML, devi analizzare CLUSTER_SPEC per compilare eventuali variabili o impostazioni di ambiente richieste dal framework.
Il formato di CLUSTER_SPEC
La variabile di ambiente CLUSTER_SPEC è una stringa JSON con il seguente formato:
| Chiave | Descrizione | |
|---|---|---|
"cluster"
|
La descrizione del cluster per il contenitore personalizzato. Come per
La descrizione del cluster contiene un elenco di nomi di repliche per ogni pool di worker specificato. |
|
"workerpool0"
|
Tutti i job di addestramento distribuito hanno una replica principale nel primo pool di worker. | |
"workerpool1"
|
Questo pool di worker contiene repliche di worker, se le hai specificate durante la creazione del job. | |
"workerpool2"
|
Questo pool di worker contiene server dei parametri, se li hai specificati durante la creazione del job. | |
"workerpool3"
|
Questo pool di worker contiene valutatori, se li hai specificati durante la creazione del job. | |
"environment"
|
La stringa cloud.
|
|
"task"
|
Descrive l'attività del nodo specifico su cui viene eseguito il codice. Puoi utilizzare queste informazioni per scrivere codice per worker specifici in un compito distribuito. Questa voce è un dizionario con le seguenti chiavi: | |
"type"
|
Il tipo di pool di worker in cui è in esecuzione questa attività. Ad esempio,
"workerpool0" si riferisce alla replica principale.
|
|
"index"
|
L'indice a partire da zero dell'attività. Ad esempio, se il tuo job di addestramento include due worker, questo valore è impostato su |
|
"trial"
|
L'identificatore della prova di ottimizzazione degli iperparametri attualmente in esecuzione. Quando configuri l'ottimizzazione degli iperparametri per il tuo job, imposti un numero di prove da eseguire per l'addestramento. Questo valore ti consente di distinguere nel codice tra le prove in esecuzione. L'identificatore è un valore di stringa contenente il numero della prova, a partire da 1. | |
job |
Il |
|
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 rispetto a quanto richiesto da TensorFlow.
L'addestramento distribuito con TensorFlow funziona allo stesso modo se utilizzi i container personalizzati o un container predefinito.
La variabile di ambiente TF_CONFIG è una stringa JSON con il seguente formato:
TF_CONFIG campi |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
cluster |
La descrizione del cluster TensorFlow. Un dizionario che mappa uno o più nomi di attività ( Si tratta di un primo argomento valido per il
costruttore
|
||||||||||
task |
La descrizione dell'attività della VM in cui è impostata questa variabile di ambiente. Per un determinato job di addestramento, questo dizionario è diverso su ogni VM. Puoi utilizzare queste informazioni per personalizzare il codice eseguito su ogni VM in un job di addestramento distribuito. Puoi anche utilizzarlo per modificare il comportamento del codice di addestramento per prove diverse di un job di ottimizzazione degli iperparametri. Questo dizionario include le seguenti coppie chiave-valore:
|
||||||||||
job |
Il |
||||||||||
environment |
La stringa |
||||||||||
Esempio di TF_CONFIG
Il seguente codice di esempio stampa la variabile di ambienteTF_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 di runtime 2.1 o successive e che utilizza un worker master, due worker e un server di parametri, questo codice genera il seguente log per uno dei worker durante la prima prova 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 utilizzare TF_CONFIG
TF_CONFIG è impostato solo per i job di addestramento distribuito.
È probabile che non sia necessario interagire con la variabile di ambiente TF_CONFIG direttamente nel codice di addestramento. Accedi alla variabile di ambiente TF_CONFIG solo se le strategie di distribuzione di TensorFlow e il flusso di lavoro di ottimizzazione degli iperparametri standard 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 server di parametri per il tuo job, con ParameterServerStrategy.
Tuttavia, tieni presente che al momento 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 è necessario accedere direttamente alla variabile di ambiente TF_CONFIG nel codice di addestramento, perché è gestita da TensorFlow.
Analizza direttamente la variabile di ambiente TF_CONFIG 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 diversi argomenti al codice di addestramento per ogni prova. Il codice di addestramento non deve necessariamente essere a conoscenza della 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.