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:
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:
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:
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
- Esegui il server TensorBoard e vai alla scheda Profilo.
- Ordina la tabella nello strumento di statistiche collettive DCN in base a Aggregated Total Stall in ordine decrescente.
- 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.
- 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.
- Genera un dump HLO per determinare se ci sono problemi di compilatore. È meglio suddividere le operazioni
send
erecv-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. - 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 operazionirecv-done
solitamente vengono bloccate sulla rete per recuperare i dati. - Se la durata delle operazioni
recv-done
non è troppo elevata rispetto al tempo di attesa, potrebbe indicare un problema hardware.