Profilazione di ambienti Multislice

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

• Visualizzare e comprendere il rendimento della rete tra le sezioni in base ai dati raccolti
• Identificare i colli di bottiglia delle prestazioni
• Ottimizzare il rendimento del modello

Tutte le metriche nello strumento di statistiche Megascale vengono generate in base alla TPU. Per attivare questo strumento, segui gli stessi passaggi per acquisire il profilo nel tuo framework e utilizza la libreria XProfiler per configurare un'istanza TensorBoard XProf per visualizzare i tuoi profili. Se il carico di lavoro è stato eseguito come carico di lavoro multislice, TensorBoard mostrerà lo strumento "Statistiche su larga scala" per qualsiasi carico di lavoro multislice.

Per maggiori dettagli sullo strumento per le statistiche Megascale in XProf, consulta la guida Strumento per le statistiche Megascale.

Terminologia

Lo strumento per le statistiche collettive DCN mostra le metriche che descrivono la comunicazione che si verifica tra gli slice TPU all'interno di un ambiente Multislice. Quando il runtime 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 che l'host può riempire con i dati trasferiti.
• recv-done: segnala all'host che i dati sono stati ricevuti.

Nota: l'invio effettivo dei dati avviene dopo il completamento dell'operazione send. L'operazione send-done viene eseguita dopo l'invio dei dati. Allo stesso modo, i dati vengono ricevuti dopo il completamento dell'operazione recv. L'operazione recv-done si verifica dopo la ricezione dei dati.

Un collettivo viene avviato quando si verifica un'operazione send e viene completato quando si verifica l'operazione recv-done corrispondente.

Slack Time

Una misura del tempo in cui 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 cronologia:

Il tempo di tolleranza viene calcolato in questo esempio come segue:

Tempo di riserva = t₁ + t₂ + t₃

L'aumento del tempo di inattività riduce le possibilità di bloccare la TPU per un collettivo. Puoi aumentare il tempo di tolleranza scegliendo un altro metodo di sharding.

Durata stallo

La durata media del tempo che il collettivo trascorre nelle operazioni di invio, invio completato, ricezione e ricezione completata. Tieni presente che non è incluso il tempo dedicato alla trasmissione dei dati. Ad esempio, data la seguente cronologia:

La durata dello stallo viene calcolata in questo esempio come segue:

Durata dello stallo = t_send + t_send-done + t_recv + t_recv-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 cronologia:

La durata osservata viene calcolata come segue:

Durata osservata = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-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 la relativa operazione recv-done corrispondente devono verificarsi entro la durata di un profilo per essere incluse in questa metrica.

Stallo totale aggregato

Il tempo totale in cui un collettivo blocca una TPU durante la durata di un profilo. Il blocco totale dell'aggregazione viene calcolato come segue:

Stallo totale aggregato = durata dello stallo * 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 fornito. Puoi utilizzare questa metrica per visualizzare il numero di collettivi che competono 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 inattività

Stato dello strumento

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

Statistiche collettive DCN	Versioni di TensorFlow supportate del runtime TPU
Tempo di inattività	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-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 delle 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ù alto. Se la durata di stallo aggregata di questo collettivo è significativamente elevata rispetto ad altri, ciò potrebbe indicare che esiste un collo di bottiglia nel collettivo DCN.

4. Moltiplica la larghezza di banda richiesta del collettivo DCN per il numero di core. Ci sono 8 core per host TPU v4, quindi la larghezza di banda richiesta per una collettiva è 8 volte il valore visualizzato. Se la larghezza di banda richiesta è maggiore della larghezza di banda di rete massima della TPU, la rete potrebbe essere congestionata. Per ridurre la larghezza di banda richiesta, prova a modificare 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 ci sono problemi con il compilatore. È preferibile distribuire le operazioni send e recv-done per una collettiva 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 in Trace Viewer per il collettivo DCN con il blocco totale aggregato massimo. Se la durata del trasferimento è elevata, potrebbe esserci un collo di bottiglia della larghezza di banda perché le operazioni recv-done vengono solitamente bloccate sulla rete per ottenere i dati.

7. Se la durata delle operazioni recv-done non è troppo elevata rispetto al tempo di riserva, potrebbe trattarsi di un problema hardware.