Profile für Multislice-Umgebungen erstellen

Cloud TPU-Multislice-Umgebungen bestehen aus mehreren TPU-Slices, die über das Rechnenzentrumsnetzwerk (Data Center Network, DCN) kommunizieren. Mit dem Tool Megascale Stats in XProf können Sie anzeigen lassen, wie effektiv Ihre Multislice-Umgebung das DCN-Netzwerk nutzt. Das Tool Megascale Stats bietet folgende Möglichkeiten:

• Anzeigen und Verstehen der Netzwerkleistung der einzelnen Slices auf der Grundlage der erfassten Daten
• Erkennen von Leistungsengpässen
• Optimieren der Leistung Ihres Modells

Alle Messwerte im Tool Megascale Stats werden pro TPU generiert. Sie aktivieren das Tool mit den gleichen Schritten wie beim Erfassen von Profilen in Ihrem Framework. Dann richten Sie mit der XProfiler-Bibliothek eine TensorBoard-XProf-Instanz ein, mit der Sie Ihre Profile ansehen können. TensorBoard zeigt das Tool Megascale Stats für alle Arbeitslasten an, die als Multislice-Arbeitslasten ausgeführt wurden.

Weitere Informationen zum Tool Megascale Stats in XProf finden Sie in der Anleitung zum Tool Megascale Stats.

Terminologie

Das Tool DCN Collective Stats zeigt Messwerte zur Kommunikation zwischen TPU-Slices in einer Multislice-Umgebung an. Wenn die TPU-Laufzeit die Kommunikation zwischen Slices initiiert, kommt es zu einer Reihe von Vorgängen:

• send: Unterbricht den Host und startet einen direkten Arbeitsspeicherzugriff (Direct Memory Access, DMA); stellt dem Host einen gefüllten Zwischenspeicher bereit und startet die Datenübertragung.
• send-done: Signalisiert dem Host, dass die Datenübertragung abgeschlossen ist.
• recv: Stellt dem Host einen leeren Zwischenspeicher bereit, den er mit den übertragenen Daten füllen kann.
• recv-done: Signalisiert dem Host, dass die Daten empfangen wurden.

Hinweis: Das eigentliche Senden der Daten wird nach Abschluss des Vorgangs send ausgeführt Nachdem die Daten gesendet wurden, wird der Vorgang send-done ausgeführt. Analog dazu wird der Empfang der Daten erst nach Abschluss des Vorgangs recv ausgeführt. Nachdem die Daten empfangen wurden, wird der Vorgang recv-done ausgeführt.

Eine Sammlung wird gestartet, wenn ein send-Vorgang ausgeführt wird, und beendet, wenn der entsprechende recv-done-Vorgang ausgeführt wird.

Zeitpuffer

Eine Zeiteinheit, in der die Sammlung Daten senden und empfangen kann. Dies umfasst nicht die Vorgänge send, send-done, recv oder recv-done. Beispiel für eine Zeitachse:

Der Zeitpuffer wird in diesem Beispiel folgendermaßen berechnet:

Zeitpuffer = t₁ + t₂ + t₃

Ein längerer Zeitpuffer verringert die Wahrscheinlichkeit, dass die TPU für eine Sammlung blockiert wird. Sie können den Zeitpuffer verlängern, indem Sie eine andere Fragmentierungsmethode auswählen.

Verzögerungsdauer

Die durchschnittliche Dauer, die die Sammlung für die Vorgänge „send“, „send-done“, „recv“ und „recv-done“ benötigt. Beachten Sie, dass die Zeit für die Datenübertragung hier nicht berücksichtigt ist. Beispiel für eine Zeitachse:

Die Dauer der Verzögerung wird in diesem Beispiel so berechnet:

Verzögerungsdauer = 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. Beispiel für eine Zeitachse:

Die beobachtete Dauer wird folgendermaßen berechnet:

Beobachtete Dauer = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-done

Häufigkeit

Die Häufigkeit, mit der eine Sammlung während einer Profildauer gestartet und beendet wird. Eine Sammlung wird gestartet, wenn ein send-Vorgang erfolgt, und beendet, wenn der entsprechende recv-end-Vorgang erfolgt. Der send-Vorgang und der entsprechende recv-done-Vorgang müssen innerhalb einer Profildauer erfolgen, damit sie für diesen Messwert berücksichtigt werden.

Aggregierte Gesamtverzögerung

Die Zeit innerhalb einer Profildauer, die eine TPU insgesamt durch eine Sammlung blockiert wird. Die aggregierte Gesamtverzögerung wird folgendermaßen berechnet:

Aggregierte Gesamtverzögerung = Verzögerungsdauer × Vorkommen

Übertragene Datenmenge

Die Datenmenge, die innerhalb der Profildauer für die Sammlung über das Netzwerk übertragen wurde.

Erforderliche Bandbreite

Die erforderliche Bandbreite für die Übertragung von Daten innerhalb des bereitgestellten Zeitpuffers. Anhand dieses Messwerts sehen Sie, wie viele Sammlungen während der Profildauer um Netzwerkbandbreite konkurrieren. Die erforderliche Bandbreite wird folgendermaßen berechnet:

Erforderliche Bandbreite = übertragene Datenmenge / Zeitpuffer

Toolstatus

In der folgenden Tabelle sind die Versionen von TensorFlow oder TPU-Laufzeit aufgeführt, die von den einzelnen vom Tool DCN Collective Stats ausgegebenen Messwerte unterstützt werden.

DCN Collective Stats	Unterstützte TensorFlow-Version der TPU-Laufzeit
Zeitpuffer	TensorFlow 2.15.0, TensorBoard 2.15.1 und TensorBoard-Plugin-Profil 2.15.0
Verzögerungsdauer	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 Gesamtverzögerung	tf-nightly, tb-nightly, tbp-nightly
Übertragene Datenmenge	tf-nightly, tb-nightly, tbp-nightly
Erforderliche Bandbreite	tf-nightly, tb-nightly, tbp-nightly

Analyse mit dem Tool DCN Collective Stats

1. Starten Sie den TensorBoard-Server und wechseln Sie zum Tab Profil.

2. Sortieren Sie die Tabelle im Tool DCN Collective Stats in absteigender Reihenfolge nach Aggregierte Gesamtverzögerung.

3. Bestimmen Sie den DCN-Sammlungsnamen mit der höchsten aggregierten Gesamtverzögerung. Wenn die aggregierte Verzögerungsdauer in dieser Gruppe im Vergleich zu anderen deutlich länger ist, kann dies auf einen Engpass in der DCN-Sammlung hinweisen.

4. Multiplizieren Sie die erforderliche Bandbreite der DCN-Sammlung mit der Anzahl der Kerne. Jeder v4-TPU-Host hat 8 Kerne. Die erforderliche Bandbreite für eine Sammlung 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 Fragmentierungsmechanismus ändern. Weitere Informationen zu Fragmentierungsmechanismen finden Sie unter Cloud TPU Multislice.

5. Generieren Sie einen HLO-Dump, um festzustellen, ob Compilerprobleme vorliegen. Es ist besser, send- und recv-done-Vorgänge für eine Sammlung zu verteilen, um mehr sich überschneidende HLO-Vorgänge planen zu können. Durch die Überschneidung von mehreren HLO-Vorgängen reduziert sich die TPU-Verzögerungszeit.

6. Überprüfen Sie im Trace Viewer die Dauer der recv-done-Vorgänge für die DCN-Sammlung mit der längsten aggregierten Gesamtverzögerungszeit. Wenn die Übertragungsdauer lang ist, könnte ein Bandbreitenengpass vorliegen, da recv-done-Vorgänge normalerweise im Netzwerk blockiert werden, um die Daten abzurufen.

7. Wenn die Dauer der recv-done-Vorgänge im Vergleich zum Zeitpuffer nicht zu lang ist, könnte ein Hardwareproblem vorliegen.