Multislice-Umgebungen profilieren

Cloud TPU-Multislice-Umgebungen bestehen aus mehreren TPU-Slices, die über das Data Center Network (DCN) kommunizieren. Mit dem Tool „Megascale stats“ in XProf können Sie Informationen dazu aufrufen, wie effektiv in Ihrer Multislice-Umgebung das DCN-Netzwerk genutzt wird. Mit dem Tool „Megascale Stats“ können Sie:

• Netzwerkleistung zwischen Slices auf Grundlage der erhobenen Daten ansehen und nachvollziehen
• Leistungsengpässe identifizieren
• Leistung Ihres Modells optimieren

Alle Messwerte im Megascale-Statistiktool werden auf TPU-Basis generiert. Um dieses Tool zu aktivieren, folgen Sie den gleichen Schritten wie beim Erstellen eines Profils in Ihrem Framework und verwenden Sie die XProfiler-Bibliothek, um eine TensorBoard XProf-Instanz zum Ansehen Ihrer Profile einzurichten. Solange Ihre Arbeitslast als Multislice-Arbeitslast ausgeführt wurde, wird in TensorBoard das Tool „Megascale stats“ für jede Multislice-Arbeitslast angezeigt.

Weitere Informationen zum Megascale Stats Tool in XProf finden Sie im Leitfaden zum Megascale Stats Tool.

Terminologie

Das DCN-Tool für kollektive Statistiken zeigt Messwerte an, die die Kommunikation zwischen TPU-Slices in einer Multislice-Umgebung beschreiben. Wenn die TPU-Laufzeit die Kommunikation zwischen Segmenten initiiert, werden eine Reihe von Vorgängen verwendet:

• send: Unterbricht den Host, um den direkten Speicherzugriff (Direct Memory Access, DMA) zu starten, und stellt dem Host einen gefüllten Puffer zur Verfügung, um die Datenübertragung zu starten.
• send-done: Signalisiert dem Host, dass die Datenübertragung abgeschlossen ist.
• recv: Stellt einen leeren Puffer bereit, in den der Host die übertragenen Daten einfügen kann.
• recv-done: Signalisiert dem Host, dass die Daten empfangen wurden.

Hinweis :Das tatsächliche Senden von Daten erfolgt nach Abschluss des Vorgangs send. Der Vorgang send-done erfolgt, nachdem die Daten gesendet wurden. Ebenso werden Daten empfangen, nachdem der recv-Vorgang abgeschlossen ist. Der Vorgang recv-done findet nach dem Empfang der Daten statt.

Ein Kollektiv wird initiiert, wenn ein send-Vorgang erfolgt, und abgeschlossen, wenn der entsprechende recv-done-Vorgang erfolgt.

Slack Time

Ein Maß für die Zeit, in der das Kollektiv Daten senden und empfangen kann. Die Vorgänge send, send-done, recv oder recv-done sind nicht enthalten. Angenommen, Sie haben die folgende Zeitachse:

Die Pufferzeit wird in diesem Beispiel so berechnet:

Pufferzeit = t₁ + t₂ + t₃

Wenn Sie die Pufferzeit erhöhen, sinkt die Wahrscheinlichkeit, dass die TPU für ein Collective angehalten wird. Sie können die Pufferzeit verlängern, indem Sie eine andere Sharding-Methode auswählen.

Dauer des Stillstands

Die durchschnittliche Zeit, die für die kollektiven Sende-, Sendeabschluss-, Empfangs- und Empfangsabschlussvorgänge aufgewendet wird. Die Zeit für die Datenübertragung ist nicht enthalten. Angenommen, Sie haben die folgende Zeitachse:

Die Dauer des Stalls wird in diesem Beispiel so berechnet:

Stall duration = t_send + t_send-done + t_recv + t_recv-done

Beobachtete Dauer

Die Zeit zwischen den Vorgängen send und recv-done, einschließlich der Zeit für das Senden und Empfangen von Daten. Angenommen, Sie haben die folgende Zeitachse:

Die beobachtete Dauer wird so berechnet:

Beobachteter Zeitraum = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-done

Häufigkeit

Die Anzahl der Kollektive, die während der Laufzeit eines Profils initiiert und abgeschlossen werden. Ein Kollektiv wird initiiert, wenn ein send-Vorgang erfolgt, und abgeschlossen, wenn der entsprechende recv-end-Vorgang erfolgt. Der send-Vorgang und der entsprechende recv-done-Vorgang müssen innerhalb der Profildauer erfolgen, damit sie in diesen Messwert einbezogen werden.

Aggregierte Gesamtzahl der Pufferungen

Die Gesamtzeit, die eine Gruppe eine TPU während der Profildauer blockiert. Die Gesamtzahl der Unterbrechungen bei der Aggregation wird so berechnet:

Aggregierter Gesamtabbruch = Dauer des Abbruchs × Anzahl der Vorkommen

Größe der übertragenen Daten

Die Datenmenge, die für das Kollektiv während des Profilzeitraums über das Netzwerk übertragen wurde.

Erforderliche Bandbreite

Die Bandbreite, die zum Übertragen von Daten innerhalb des angegebenen Spielraums erforderlich ist. Mit diesem Messwert können Sie die Anzahl der Kollektive sehen, die während des Profilzeitraums um die Netzwerkbandbreite konkurrieren. Die erforderliche Bandbreite wird so berechnet:

Erforderliche Bandbreite = Größe der übertragenen Daten / Pufferzeit

Tool-Status

In der folgenden Tabelle sehen Sie die Version von TensorFlow oder der TPU-Laufzeit, die für die einzelnen Messwerte im Tool „DCN Collective Stats“ erforderlich ist.

DCN-Sammelstatistiken	Unterstützte TensorFlow-Version der TPU-Laufzeitversion
Pufferzeit	TensorFlow 2.15.0, TensorBoard 2.15.1 und TensorBoard-Plugin-Profil 2.15.0
Dauer des Stillstands	TensorFlow 2.15.0, TensorBoard 2.15.1 und TensorBoard-Plugin-Profil 2.15.0
Beobachtete Dauer	TensorFlow 2.15.0, TensorBoard 2.15.1 und TensorBoard-Plugin-Profil 2.15.0
Häufigkeit	TensorFlow 2.15.0, TensorBoard 2.15.1 und TensorBoard-Plugin-Profil 2.15.0
Aggregierte Gesamtzahl der Pufferungen	tf-nightly, tb-nightly, tbp-nightly
Größe der übertragenen Daten	tf-nightly, tb-nightly, tbp-nightly
Erforderliche Bandbreite	tf-nightly, tb-nightly, tbp-nightly

Tool zum Analysieren von kollektiven Statistiken für DCN

1. Führen Sie den TensorBoard-Server aus und rufen Sie den Tab Profil auf.

2. Sortieren Sie die Tabelle im Tool für kollektive DCN-Statistiken absteigend nach Aggregated Total Stall.

3. Ermitteln Sie den DCN-Sammelnamen mit dem höchsten Aggregated Total Stall (Aggregierter Gesamtabbruch). Wenn die aggregierte Dauer von Stalls in dieser Gruppe im Vergleich zu anderen deutlich hoch ist, kann dies auf einen Engpass in der DCN-Gruppe hinweisen.

4. Multiplizieren Sie die erforderliche Bandbreite des DCN-Kollektivs mit der Anzahl der Kerne. Jeder v4-TPU-Host hat 8 Kerne. Die erforderliche Bandbreite für ein Collective ist also das Achtfache des angezeigten Werts. Wenn die erforderliche Bandbreite größer als die maximale Netzwerkbandbreite der TPU ist, ist das Netzwerk möglicherweise überlastet. Um die erforderliche Bandbreite zu verringern, können Sie den verwendeten Sharding-Mechanismus ändern. Weitere Informationen zu Sharding-Mechanismen finden Sie unter Cloud TPU Multislice-Übersicht.

5. Generieren Sie einen HLO-Dump, um festzustellen, ob Compilerprobleme vorliegen. Es ist besser, send- und recv-done-Vorgänge für ein Kollektiv aufzuteilen, um die Planung von mehr sich überschneidenden HLO-Vorgängen zu ermöglichen. Durch das Überlappen von mehr HLO-Vorgängen wird die TPU-Wartezeit reduziert.

6. Prüfen Sie im Trace Viewer die Dauer von recv-done-Vorgängen für das DCN-Kollektiv mit der maximalen aggregierten Gesamtdauer des Stillstands. Wenn die Übertragung lange dauert, kann es zu einem Bandbreitenengpass kommen, da recv-done-Vorgänge in der Regel im Netzwerk blockiert werden, um die Daten abzurufen.

7. Wenn die Dauer von recv-done-Vorgängen im Vergleich zur Pufferzeit nicht zu hoch ist, könnte dies auf ein Hardwareproblem hindeuten.