Profilazione di ambienti multislice

Gli ambienti Cloud TPU Multislice sono composti da più sezioni di pod di TPU che si connettono tramite la rete del data center (DCN). Puoi utilizzare lo strumento Statistiche collettive DCN per visualizzare informazioni sull'efficacia con cui il tuo ambiente Multislice utilizza la rete DCN. Nello specifico, lo strumento Statistiche collettive DCN consente di:

  • Visualizzare e comprendere il rendimento della rete inter-slice in base ai dati raccolti
  • Individuare i colli di bottiglia delle prestazioni
  • Ottimizza le prestazioni del modello

Tutte le metriche nello strumento di statistiche collettive del DCN vengono generate in base alla TPU.

Terminologia

Lo strumento Statistiche collettive DCN mostra le metriche che descrivono la comunicazione tra i slice TPU in un ambiente Multislice. Quando il runtime della TPU avvia la comunicazione tra slice, viene utilizzata una serie di operazioni:

send
Interrompe l'host per avviare l'accesso diretto alla memoria (DMA) e fornisce un buffer compilato all'host per avviare il trasferimento dei dati.
send-done
Segnala all'host che il trasferimento dei dati è stato completato.
recv
Fornisce un buffer vuoto da riempire con i dati trasferiti dall'host.
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.

Tempo di attesa

Una misura del tempo durante il quale il collettivo è in grado di inviare e ricevere dati. Non sono incluse le operazioni send, send-done, recv o recv-done. Ad esempio, data la seguente sequenza temporale:

Chip del pod v5e

In questo esempio, il tempo di attesa viene calcolato come segue:

Tempo di tempo morto = t1 + t2 + t3

L'aumento del tempo di attesa riduce le probabilità di bloccare la TPU per un collettivo. Puoi aumentare il tempo di attesa scegliendo un altro metodo di suddivisione.

Durata dell'arresto

La durata media del tempo impiegato dal collettivo per le operazioni send, send-done, recv e recv-done. Tieni presente che questo non include il tempo impiegato per trasmettere i dati. Ad esempio, data la seguente sequenza temporale:

Chip del pod v5e

In questo esempio, la durata dell'arresto anomalo viene calcolata come segue:

Tempo di blocco = tsend + tsend-done + trecv + trecv-done

Durata osservata

Il tempo che intercorre tra le operazioni send e recv-done, incluso il tempo di invio e ricezione dei dati. Ad esempio, data la seguente sequenza temporale:

Chip del 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. L'operazione send e l'operazione recv-done corrispondente devono verificarsi entro la durata di un profilo per essere incluse in questa metrica.

Blocco totale aggregato

La quantità totale di tempo in cui un collettivo blocca una TPU durante la durata di un profilo. L'arresto totale dell'aggregazione viene calcolato come segue:

Tempo di blocco totale aggregato = durata blocco * occorrenze

Dimensione dei 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 entro il margine di tempo fornito. Puoi utilizzare questa metrica per visualizzare il numero di collettivi in competizione 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 = dimensioni dei dati trasmessi / tempo di attesa

Stato dello strumento

La tabella seguente mostra la versione di TensorFlow o del runtime TPU obbligatoria per ogni metrica visualizzata nello strumento Statistiche collettive DCN.

Statistiche collettive DCN Versione del runtime TPU di TensorFlow supportata
Tempo di inattività TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Durata dell'arresto 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
Blocco totale aggregato tf-nightly, tb-nightly, tbp-nightly
Dimensione dei dati trasmessi tf-nightly, tb-nightly, tbp-nightly
Larghezza di banda richiesta tf-nightly, tb-nightly, tbp-nightly

Come analizzare lo strumento Statistiche collettive DCN

  1. Esegui il server TensorBoard e vai alla scheda Profilo.
  2. Ordina la tabella nello strumento di statistiche collettive DCN in base a Aggregated Total Stall in ordine decrescente.
  3. Identifica il nome collettivo del DCN con il valore Aggregated Total Stall più elevato. Se la durata complessiva dell'arresto anomalo di questo collettivo è notevolmente elevata rispetto ad altri, potrebbe indicare 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 è pari a 8 volte il valore visualizzato. Se la larghezza di banda richiesta è superiore alla larghezza di banda massima della rete della TPU, la rete potrebbe essere congestionata. Per ridurre la larghezza di banda richiesta, prova a modificare il meccanismo di sharding utilizzato. Per saperne di più sui meccanismi di suddivisione, consulta la panoramica di Cloud TPU Multislice.
  5. Genera un dump HLO per determinare se ci sono problemi di compilatore. È meglio suddividere le operazioni send e recv-done per un collettivo per consentire la pianificazione di più operazioni HLO sovrapposte. L'accavallamento di più operazioni HLO riduce il tempo di blocco della TPU.
  6. Controlla la durata delle operazioni recv-done in Trace Viewer per il collettivo DCN con la massima interruzione totale aggregata. Se la durata del trasferimento è elevata, potrebbe verificarsi un collo di bottiglia della larghezza di banda perché le operazioni recv-done solitamente vengono bloccate sulla rete per recuperare i dati.
  7. Se la durata delle operazioni recv-done non è troppo elevata rispetto al tempo di attesa, potrebbe indicare un problema hardware.