Profiler les environnements multitranches

Les environnements Cloud TPU multitranches sont composés de plusieurs tranches TPU qui communiquent sur le réseau du centre de données (DCN). Vous pouvez utiliser l'outil de statistiques Megascale dans XProf pour afficher des informations sur l'efficacité avec laquelle votre environnement multitranches utilise le réseau DCN. Plus précisément, l'outil de statistiques Megascale vous permet d'effectuer les opérations suivantes :

  • Afficher et comprendre les performances des communications 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. Si vous souhaitez activer cet outil, suivez les mêmes étapes pour capturer les profils dans votre infrastructure et utilisez la bibliothèque XProfiler pour configurer une instance TensorBoard XProf afin de visualiser les profils. Dès lors que votre charge de travail a été exécutée en tant que charge de travail multitranches, TensorBoard affiche l'outil "Statistiques megascale" pour toute charge de travail multitranches.

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 au sein d'un environnement multitranches. Lorsque l'environnement d'exécution 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 : indique à 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.

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

Temps de relâchement

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 :

Puce de pod v5e

Dans cet exemple, le temps de relâchement est calculé comme suit :

Temps de relâchement = t1 + t2 + t3

Le fait d'augmenter le temps de relâchement réduit les risques de blocage du TPU pour un collectif. Vous pouvez augmenter le temps de relâchement en choisissant une autre méthode de segmentation.

Durée de blocage

Durée moyenne passée par le collectif dans les opérations "envoi", "envoi terminé", "réception" et "réception terminée". Notez que cela n'inclut pas le temps passé à transmettre les données. Par exemple, prenons la chronologie suivante :

Puce de pod v5e

Dans cet exemple, la durée de blocage est calculée comme suit :

Durée de blocage = tsend + tsend-done + trecv + trecv-done

Durée observée

Durée entre les opérations send et recv-done, temps d'envoi et de réception des données compris. Par exemple, prenons la chronologie suivante :

Puce de pod v5e

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

Durée observée = tsend + t1 + tsend-done + t2 + trecv + t3 + trecv-done

Occurrences

Nombre de fois qu'un collectif est lancé et terminé pendant la durée d'un profilage. Un collectif est lancé lorsqu'une opération send se produit et se termine lorsque l'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 profilage pour être incluses dans cette métrique.

Temps de blocage total agrégé

Durée totale pendant laquelle un collectif bloque un TPU au cours d'un profilage. Le temps de blocage total agrégé est calculé comme suit :

Temps de blocage total agrégé = durée de blocage * 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 profilage.

Bande passante requise

Bande passante requise pour transmettre les données dans le temps de relâchement fourni. 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 profilage. La bande passante requise est calculée comme suit :

Bande passante requise = taille des données transmises / temps de relâchement

État de l'outil

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

Statistiques collectives DCN Version TensorFlow compatible avec l'environnement d'exécution TPU
Temps de relâchement TensorFlow 2.15.0, TensorBoard 2.15.1 et tensorboard-plugin-profile 2.15.0
Durée de blocage 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

Outil d'analyse des 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 temps de blocage total agrégé dans l'ordre décroissant.

  3. Identifiez le nom du collectif DCN qui présente le temps de blocage total agrégé le plus élevé. Si le temps de blocage total agrégé de ce collectif est nettement plus élevé que celui des autres, cela peut indiquer qu'il existe un goulot d'étranglement dans le collectif DCN.

  4. Multipliez la bande passante requise pour le 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 segmentation que vous utilisez. Pour en savoir plus sur les mécanismes de segmentation, consultez la présentation des Cloud TPU multitranches.

  5. Générez un dump HLO pour déterminer si des problèmes de compilation existent. Il est préférable de procéder à une distribution ramifiée des opérations send et recv-done pour un collectif afin de permettre la planification d'un plus grand nombre d'opérations HLO qui se chevauchent. Le chevauchement d'un plus grand nombre d'opérations HLO réduit le temps de blocage du TPU.

  6. Vérifiez la durée des opérations recv-done dans le lecteur de traces pour le collectif DCN qui présente le temps de blocage total agrégé maximal. Si la durée du transfert est importante, un goulot d'étranglement de la bande passante peut apparaître, car les opérations recv-done sont généralement bloquées sur le réseau pour l'obtention des données.

  7. Si la durée des opérations recv-done n'est pas trop élevée par rapport au temps de relâchement, cela peut indiquer un problème matériel.