Profiler les environnements Multislice

Les environnements Cloud TPU Multislice sont composés de plusieurs tranches TPU qui communiquent sur le réseau de centre de données. Vous pouvez utiliser l'outil de statistiques Megascale dans XProf pour afficher des informations sur l'efficacité avec laquelle votre environnement multislices utilise le réseau DCN. Plus précisément, l'outil Statistiques Megascale vous permet de :

• Afficher et comprendre les performances réseau entre les 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 Megascale sont générées par TPU. Pour activer cet outil, suivez les mêmes étapes que pour capturer un profil dans votre framework et utilisez la bibliothèque XProfiler pour configurer une instance TensorBoard XProf afin d'afficher vos profils. Tant que votre charge de travail a été exécutée en tant que charge de travail multislices, TensorBoard affichera l'outil "Statistiques mégascale" pour toute charge de travail multislices.

Pour en savoir plus sur l'outil de statistiques Megascale dans XProf, consultez le guide Outil de statistiques Megascale.

Terminologie

L'outil de statistiques collectives DCN affiche des métriques qui décrivent la communication entre les tranches TPU dans un environnement multislices. Lorsque le runtime TPU lance la communication entre les 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, Direct Memory Access) 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 a lieu 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 a lieu 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 sommeil

Mesure du temps pendant lequel le collectif est en mesure d'envoyer et de recevoir des données. Cela n'inclut pas les opérations send, send-done, recv ni recv-done. Par exemple, prenons la chronologie suivante :

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

Temps de marge = 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 l'arrêt

Durée moyenne passée 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 les données. Par exemple, prenons la chronologie suivante :

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

Durée du blocage = 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. Par exemple, prenons la chronologie suivante :

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é pendant 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 l'opération recv-done correspondante doivent avoir lieu pendant la durée d'un profil pour être incluses dans cette métrique.

Temps d'arrêt total agrégé

Durée totale pendant laquelle un collectif bloque un TPU pendant la durée d'un profil. Le temps d'arrêt total de l'agrégation est calculé comme suit :

Temps d'arrêt total agrégé = durée de l'arrêt * nombre d'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 les données dans la marge de tolérance fournie. Vous pouvez utiliser cette métrique pour afficher le nombre de collectifs en concurrence pour la bande passante du 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 du runtime TPU requise pour chaque métrique affichée dans l'outil "Statistiques collectives DCN".

Statistiques globales du DCN	Version TensorFlow compatible de la version d'exécution TPU
Temps de marge	TensorFlow 2.15.0, TensorBoard 2.15.1 et tensorboard-plugin-profile 2.15.0
Durée de l'arrêt	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 agrégé	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 DCN

1. Exécutez le serveur TensorBoard et accédez à l'onglet Profil.

2. Dans l'outil de statistiques collectives DCN, triez le tableau par Total agrégé des temps d'arrêt dans l'ordre décroissant.

3. Identifiez le nom collectif DCN qui présente le nombre total de calages agrégés le plus élevé. Si la durée d'arrêt agrégée de ce collectif est nettement plus élevée que celle des autres, cela peut indiquer un goulot d'étranglement dans le collectif DCN.

4. Multipliez la bande passante requise du collectif DCN par le nombre de cœurs. Un hôte TPU v4 comporte huit cœurs. La bande passante requise pour un collectif est donc huit fois supérieure à 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 encombré. Pour réduire la bande passante requise, essayez de modifier le mécanisme de partitionnement que vous utilisez. Pour en savoir plus sur les mécanismes de partitionnement, consultez la Présentation de Cloud TPU Multislice.

5. Générez un dump HLO pour déterminer si des problèmes de compilation existent. Il est préférable de distribuer les opérations send et recv-done pour un collectif afin de permettre la planification de davantage d'opérations HLO qui se chevauchent. 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 le Trace Viewer pour le collectif DCN qui présente le temps d'arrêt total agrégé maximal. Si la durée du transfert est élevée, il peut y avoir un goulot d'étranglement de la bande passante, 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.