Profilage des environnements Multislice

Les environnements Multislice Cloud TPU sont composés de plusieurs tranches de pod TPU qui communiquent sur le réseau de centre de données (DCN). Vous pouvez utiliser l'outil de statistiques collectives du réseau DCN pour afficher des informations sur l'efficacité avec laquelle votre environnement multicouche utilise le réseau DCN. Plus précisément, l'outil DCN Collective Stats vous permet de:

• Afficher et analyser les performances du réseau inter-tranches en fonction des données collectées
• Identifier les goulots d'étranglement
• Optimiser les performances de votre modèle

Toutes les métriques de l'outil de statistiques collectives du DCN sont générées par TPU.

Terminologie

L'outil de statistiques collectives du DCN affiche des métriques qui décrivent la communication qui s'effectue entre les tranches TPU dans un environnement Multislice. Lorsque l'environnement d'exécution TPU lance la communication inter-tranches, une série d'opérations est utilisée:

send

interrompt l'hôte pour démarrer l'accès direct à la mémoire (DMA) et fournit un tampon rempli à l'hôte pour démarrer le transfert de données.

send-done

Signale à l'hôte que le transfert de données est terminé.

recv

Fournit un tampon vide que l'hôte peut remplir avec les données transférées.

recv-done

Signale à l'hôte que les données ont été reçues.

Remarque :L'envoi effectif des données a lieu une fois l'opération send terminée. L'opération send-done se produit après l'envoi des données. De même, les données sont reçues une fois l'opération recv terminée. L'opération recv-done se produit après la réception des données.

Un collectif est lancé lorsqu'une opération send se produit et se termine lorsqu'une opération recv-done correspondante se produit.

Temps de pause

Mesure du temps pendant lequel le collectif peut envoyer et recevoir des données. Cela n'inclut pas les opérations send, send-done, recv ou recv-done. Prenons l'exemple suivant:

Dans cet exemple, le temps de latence est calculé comme suit:

Temps de latence = t₁ + t₂ + t₃

Augmenter le temps de latence réduit les risques de blocage du TPU pour un collectif. Vous pouvez augmenter le temps de latence en choisissant une autre méthode de partitionnement.

Durée de la mise en veille

Durée moyenne du temps passé par le collectif dans les opérations d'envoi, d'envoi terminé, de réception et de réception terminée. Notez que cela n'inclut pas le temps passé à transmettre des données. Prenons l'exemple suivant:

Dans cet exemple, la durée de l'arrêt est calculée comme suit:

Durée d'arrêt = t_send + t_send-done + t_recv + t_recv-done

Durée observée

Durée entre les opérations send et recv-done, y compris le temps d'envoi et de réception des données. Prenons l'exemple suivant:

La durée observée est calculée comme suit:

Durée observée = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-done

Occurrences

Nombre de fois qu'un collectif est lancé et terminé au cours de la durée d'un profil. Un collectif est lancé lorsqu'une opération send se produit et se termine lorsqu'une opération recv-end correspondante se produit. L'opération send et son opération recv-done correspondante doivent se produire pendant la durée d'un profil pour être incluses dans cette métrique.

Temps d'arrêt total cumulé

Durée totale pendant laquelle une opération collective bloque un TPU pendant la durée d'un profil. Le blocage total de l'agrégation est calculé comme suit:

Arrêt total agrégé = durée de l'arrêt * occurrences

Taille des données transmises

Quantité de données transmises sur le réseau pour le collectif pendant la durée du profil.

Bande passante requise

Bande passante requise pour transmettre des données dans la marge de manœuvre fournie. Vous pouvez utiliser cette métrique pour voir le nombre de collectifs qui se disputent la bande passante réseau pendant la durée du profil. La bande passante requise est calculée comme suit:

Bande passante requise = taille des données transmises / temps de latence

État de l'outil

Le tableau suivant indique la version de TensorFlow ou de l'environnement d'exécution TPU requise pour chaque métrique affichée dans l'outil Collective Stats de DCN.

Statistiques collectives du CDN	Version de TensorFlow compatible avec la version d'exécution TPU
Temps de pause	TensorFlow 2.15.0, tensorboard 2.15.1 et tensorboard-plugin-profile 2.15.0
Durée de la mise en veille	TensorFlow 2.15.0, tensorboard 2.15.1 et tensorboard-plugin-profile 2.15.0
Durée observée	TensorFlow 2.15.0, tensorboard 2.15.1 et tensorboard-plugin-profile 2.15.0
Occurrences	TensorFlow 2.15.0, tensorboard 2.15.1 et tensorboard-plugin-profile 2.15.0
Temps d'arrêt total cumulé	tf-nightly, tb-nightly, tbp-nightly
Taille des données transmises	tf-nightly, tb-nightly, tbp-nightly
Bande passante requise	tf-nightly, tb-nightly, tbp-nightly

Analyser l'outil de statistiques collectives du DCN

1. Exécutez le serveur TensorBoard et accédez à l'onglet Profile (Profil).
2. Triez le tableau dans l'outil de statistiques collectives du DCN par Total Stall cumulé dans l'ordre décroissant.
3. Identifiez le nom collectif de DCN qui affiche le nombre total d'arrêts cumulés le plus élevé. Si la durée d'arrêt cumulée de cette collective est considérablement élevée par rapport aux autres, cela peut indiquer qu'il existe un goulot d'étranglement dans la collective DCN.
4. Multipliez la bande passante requise du collectif DCN par le nombre de cœurs. Il y a huit cœurs par hôte TPU v4. La bande passante requise pour une collective est donc huit fois la valeur affichée. Si la bande passante requise est supérieure à la bande passante réseau maximale du TPU, cela peut signifier que le réseau est saturé. Pour réduire la bande passante requise, essayez de modifier le mécanisme de fractionnement que vous utilisez. Pour en savoir plus sur les mécanismes de fractionnement, consultez la présentation de la multislice Cloud TPU.
5. Générez un vidage HLO pour déterminer si des problèmes de compilation existent. Il est préférable de développer les opérations send et recv-done pour un collectif afin de permettre la planification d'opérations HLO plus chevauchantes. Le chevauchement d'un plus grand nombre d'opérations HLO réduit le temps d'arrêt du TPU.
6. Vérifiez la durée des opérations recv-done dans l'outil de visualisation des traces pour le collectif DCN présentant le blocage total cumulé maximal. Si la durée du transfert est élevée, un goulot d'étranglement de la bande passante peut se produire, car les opérations recv-done sont généralement bloquées sur le réseau pour obtenir les données.
7. Si la durée des opérations recv-done n'est pas trop élevée par rapport au temps de latence, cela peut indiquer un problème matériel.