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:

Chip di pod v5e

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:

Chip di pod v5e

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:

Chip di pod v5e

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

  1. Esegui il server TensorBoard e vai alla scheda Profile (Profilo).
  2. Ordina la tabella nello strumento per le statistiche collettive DCN in base a Stall totale aggregato in ordine decrescente.
  3. 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.
  4. 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.
  5. Genera un dump HLO per determinare se sono presenti problemi del compilatore. È meglio creare un fan-out delle operazioni send e recv-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.
  6. 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 operazioni recv-done di solito sono bloccate sulla rete per recuperare i dati.
  7. Se la durata delle operazioni di recv-done non è troppo elevata rispetto al tempo di inattività, potrebbe essersi verificato un problema di hardware.