Profilazione degli ambienti multisezione
Gli ambienti multisezione Cloud TPU sono composti da più sezioni di pod di TPU che comunicano sulla rete di data center (DCN). Puoi utilizzare lo strumento delle statistiche collettive DCN per visualizzare le informazioni sull'efficacia con cui il tuo ambiente multisezione utilizza la rete DCN. In particolare, lo strumento DCN Collective Stats consente di:
- Visualizzare e comprendere le prestazioni della rete tra sezioni in base ai dati raccolti
- Identificare i colli di bottiglia delle prestazioni
- Ottimizza le prestazioni del modello
Tutte le metriche nello strumento per le statistiche collettive DCN vengono generate in base alle TPU.
Terminologia
Lo strumento per le statistiche collettive DCN mostra le metriche che descrivono la comunicazione che avviene tra sezioni TPU in un ambiente multisezione. Quando il runtime TPU avvia la comunicazione tra sezioni, viene utilizzata una serie di operazioni:
send
- Interrompe l'host per avviare l'accesso diretto alla memoria (DMA) e fornisce all'host un buffer pieno per avviare il trasferimento dei dati.
send-done
- Segnala all'host che il trasferimento dei dati è stato completato.
recv
- Fornisce un buffer vuoto che l'host può riempire con i dati trasferiti.
recv-done
- Segnala all'host che i dati sono stati ricevuti.
Un collettivo viene avviato quando si verifica un'operazione send
e viene completato quando
si verifica l'operazione recv-done
corrispondente.
Ora Slack
Una misura del tempo per cui il collettivo è in grado di inviare e ricevere dati.
Non sono incluse le operazioni send
, send-done
, recv
o recv-done
.
Ad esempio, date la seguente cronologia:
In questo esempio, la durata di Slack viene calcolata come segue:
Tempo di attesa = t1 + t2 + t3
L'aumento del tempo di attesa riduce le possibilità di bloccare la TPU per un gruppo. Puoi aumentare il tempo di attesa scegliendo un metodo di sharding diverso.
Durata stallo
La durata media del tempo che il collettivo dedica alle operazioni di invio, invio, ricezione e ricezione. Tieni presente che non è incluso il tempo impiegato per trasmettere i dati. Ad esempio, date la seguente cronologia:
In questo esempio, la durata di stallo viene calcolata come segue:
Durata di stallo = tsend + tsend-done + trecv + trecv-done
Durata osservata
La quantità di tempo che intercorre tra le operazioni send
e recv-done
, inclusa l'ora di invio e ricezione dei dati. Ad esempio, date la seguente cronologia:
La durata osservata viene calcolata come segue:
Durata osservata = tsend + t1 + tsend-done + t2 + trecv + t3 + trecv-done
Occorrenze
Il numero di volte in cui un collettivo viene avviato e completato durante la durata di un profilo. Un collettivo viene avviato quando si verifica un'operazione send
e viene completato quando si verifica l'operazione recv-end
corrispondente. Per essere incluse in questa metrica, l'operazione send
e la relativa operazione recv-done
corrispondente devono avvenire entro una durata del profilo.
Stallo totale aggregato
Il periodo di tempo totale durante il quale un collettivo blocca una TPU durante la durata del profilo. Lo stallo totale dell'aggregazione è calcolato come segue:
Stallo totale aggregato = durata di stallo * occorrenze
Dimensione dati trasmessi
La quantità di dati trasmessi sulla rete per il collettivo durante la durata del profilo.
Larghezza di banda richiesta
La larghezza di banda necessaria per trasmettere i dati all'interno del slack fornito. Puoi utilizzare questa metrica per vedere il numero di collettivi che concorrono per la larghezza di banda di rete durante la durata del profilo. La larghezza di banda richiesta viene calcolata come segue:
Larghezza di banda richiesta = dimensione di trasmissione dei dati / tempo di attesa
Stato strumento
La seguente tabella mostra la versione del runtime TensorFlow o TPU richiesta per ogni metrica visualizzata nello strumento DCN Collective Stats.
Statistiche collettive DCN | Versione del runtime di TensorFlow della TPU supportata |
---|---|
Tempo Slack | TensorFlow 2.15.0, TensorBoard 2.15.1 e TensorBoard-plugin-profile 2.15.0 |
Durata stallo | TensorFlow 2.15.0, TensorBoard 2.15.1 e TensorBoard-plugin-profile 2.15.0 |
Durata osservata | TensorFlow 2.15.0, TensorBoard 2.15.1 e TensorBoard-plugin-profile 2.15.0 |
Occorrenze | TensorFlow 2.15.0, TensorBoard 2.15.1 e TensorBoard-plugin-profile 2.15.0 |
Stallo totale aggregato | tf-per notte, tb-notte, tbp-nightly |
Dimensione dati trasmessi | tf-per notte, tb-notte, tbp-nightly |
Larghezza di banda richiesta | tf-per notte, tb-notte, tbp-nightly |
Come analizzare lo strumento DCN Collective Stats
- Esegui il server TensorBoard e vai alla scheda Profile (Profilo).
- Ordina la tabella nello strumento per le statistiche collettive DCN in base a Stall totale aggregato in ordine decrescente.
- Identifica il nome collettivo DCN con il valore Stall totale aggregato più alto. Se la durata aggregata di questo gruppo è molto alta rispetto ad altri, ciò potrebbe indicare la presenza di un collo di bottiglia nel collettivo DCN.
- Moltiplica la larghezza di banda richiesta del collettivo DCN per il numero di core. Esistono 8 core per host TPU v4, quindi la larghezza di banda richiesta per un collettivo è 8 volte il valore visualizzato. Se la larghezza di banda richiesta è superiore alla larghezza di banda massima di rete della TPU, la rete potrebbe essere congestionata. Per utilizzare la larghezza di banda necessaria, prova a cambiare il meccanismo di sharding che utilizzi. Per ulteriori informazioni sui meccanismi di sharding, consulta la panoramica di Cloud TPU Multislice.
- Genera un dump HLO per determinare se sono presenti problemi del compilatore. È
meglio creare un fan-out delle operazioni
send
erecv-done
per un collettivo per consentire la pianificazione di più operazioni HLO sovrapposte. La sovrapposizione di più operazioni HLO riduce il tempo di stallo della TPU. - Controlla la durata delle operazioni
recv-done
nel visualizzatore di tracce per il collettivo DCN che ha raggiunto il numero massimo di blocchi totali aggregati. Se la durata del trasferimento è elevata, potrebbe esserci un collo di bottiglia della larghezza di banda perché le operazionirecv-done
di solito sono bloccate sulla rete per recuperare i dati. - Se la durata delle operazioni di
recv-done
non è troppo elevata rispetto al tempo di inattività, potrebbe essersi verificato un problema di hardware.