Creazione di profili di ambienti Multislice

Attenzione: questa pagina si applica all'API Cloud TPU, che non è più in fase di sviluppo attivo. L'API Cloud TPU riceverà solo correzioni di bug e aggiornamenti di sicurezza. Ti consigliamo di utilizzare Google Kubernetes Engine per Multislice. Per saperne di più, consulta la sezione Eseguire il deployment di TPU Multislice in GKE.

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

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

Tutte le metriche nello strumento Statistiche Megascale vengono generate per ogni TPU. Per abilitare 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 profili. Se il carico di lavoro è stato eseguito come carico di lavoro Multislice, TensorBoard visualizzerà lo strumento "Statistiche Megascale" per qualsiasi carico di lavoro Multislice.

Per maggiori dettagli sullo strumento Statistiche Megascale in XProf, consulta la guida Strumento Statistiche Megascale.

Terminologia

Lo strumento 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 gli slice, vengono utilizzate 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 si verifica 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.

Una collettiva viene avviata quando si verifica un'operazione send e viene completata quando si verifica l'operazione recv-done corrispondente.

Tempo di slack

Misura del tempo in cui la collettiva è in grado di inviare e ricevere dati. Non include le operazioni send, send-done, recv o recv-done. Ad esempio, dato il seguente cronologia:

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

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

L'aumento del tempo di slack riduce le probabilità di bloccare la TPU per una collettiva. Puoi aumentare il tempo di slack scegliendo un metodo di sharding diverso.

Durata di blocco

La durata media del tempo che la collettiva trascorre nelle operazioni di invio, invio completato, ricezione e ricezione completata. Tieni presente che non include il tempo trascorso per la trasmissione dei dati. Ad esempio, dato il seguente cronologia:

In questo esempio, la durata di blocco viene calcolata come segue:

Durata di blocco = t_send + t_send-done + t_recv + t_recv-done

Durata osservata

Il tempo trascorso tra le operazioni send e recv-done, incluso il tempo di invio e ricezione dei dati. Ad esempio, dato il 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 una collettiva viene avviata e completata durante la durata di un profilo. Una collettiva viene avviata quando si verifica un'operazione send e viene completata 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

Il tempo totale in cui una collettiva blocca una TPU durante la durata di un profilo. Il blocco totale aggregato viene calcolato come segue:

Blocco totale aggregato = durata di blocco * occorrenze

Dimensione dei dati trasmessi

La quantità di dati trasmessi sulla rete per la collettiva durante la durata del profilo.

Larghezza di banda richiesta

La larghezza di banda necessaria per trasmettere i dati all'interno dello slack fornito. Puoi utilizzare questa metrica per visualizzare il numero di collettive in competizione per la larghezza di banda della rete durante la durata del profilo. La larghezza di banda richiesta viene calcolata come segue:

Larghezza di banda richiesta = dimensione dei dati trasmessi / tempo di slack

Stato dello strumento

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

Statistiche collettive DCN	Versione di TensorFlow o del runtime TPU supportata
Tempo di slack	TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Durata di blocco	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 Statistiche collettive DCN in base a Blocco totale aggregato in ordine decrescente.

3. Identifica il nome della collettiva DCN con il Blocco totale aggregato più alto. Se la durata di blocco aggregata di questa collettiva è significativamente elevata rispetto alle altre, potrebbe indicare un collo di bottiglia nella collettiva DCN.

4. Moltiplica la larghezza di banda richiesta della collettiva DCN per il numero di core. Sono disponibili 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, potrebbe significare che la rete è congestionata. Per ridurre la larghezza di banda richiesta, prova a modificare il meccanismo di sharding che utilizzi. Per saperne di più sui meccanismi di sharding, consulta la panoramica di Cloud TPU Multislice.

5. Genera un dump HLO per determinare se sono presenti problemi del 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 blocco della TPU.

6. Controlla la durata delle operazioni recv-done in Trace Viewer per la collettiva 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 in genere bloccate sulla rete per ottenere i dati.

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