Profilerstellung für Umgebungen mit mehreren Segmenten

Cloud TPU-Multislice-Umgebungen bestehen aus mehreren TPU-Pod-Slices, die über das Rechenzentrumsnetzwerk (DCN) kommunizieren. Mit dem kollektiven DCN-Statistiktool können Sie Informationen darüber abrufen, wie effektiv Ihre Multislice-Umgebung das DCN-Netzwerk nutzt. Das DCN Collective Stats bietet folgende Möglichkeiten:

• Sehen Sie sich die Netzwerkleistung auf der Grundlage erfasster Daten an und analysieren Sie sie.
• Leistungsengpässe identifizieren
• Modellleistung optimieren

Alle Messwerte im DCN-Tool für kollektive Statistiken werden pro TPU generiert.

Terminologie

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

send

Unterbricht den Host, um den direkten Arbeitsspeicherzugriff (DMA) zu starten, und stellt dem Host einen gefüllten Zwischenspeicher bereit, um die Datenübertragung zu starten.

send-done

Signalisiert dem Host, dass die Datenübertragung abgeschlossen ist.

recv

Stellt einen leeren Zwischenspeicher bereit, den der Host mit den übertragenen Daten füllt.

recv-done

Signalisiert dem Host, dass die Daten empfangen wurden.

Hinweis: Das tatsächliche Senden der Daten erfolgt, nachdem der send-Vorgang abgeschlossen ist. Der send-done-Vorgang wird ausgeführt, nachdem die Daten gesendet wurden. Ebenso werden Daten empfangen, nachdem der recv-Vorgang abgeschlossen ist. Der recv-done-Vorgang wird nach dem Empfang der Daten ausgeführt.

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

Slack-Zeit

Ein Maß für die Zeit, die das Kollektiv in der Lage ist, Daten zu senden und zu empfangen. send-, send-done-, recv- oder recv-done-Vorgänge sind davon nicht betroffen. Nehmen wir als Beispiel den folgenden Zeitplan:

Die Slack-Zeit wird in diesem Beispiel so berechnet:

Slack-Zeit = t₁ + t₂ + t₃

Wenn Sie die Pufferzeit erhöhen, sinkt die Wahrscheinlichkeit, dass die TPU für ein Kollektiv anhält. Sie können die Slack-Zeit verlängern, indem Sie eine andere Fragmentierungsmethode auswählen.

Wartezeit

Die durchschnittliche Zeit, die das Kollektiv für Sende-, Sende-, Empfangs- und Empfangsvorgänge aufwendet. Hinweis: Dies beinhaltet nicht die Zeit, die für die Übertragung von Daten aufgewendet wird. Nehmen wir als Beispiel den folgenden Zeitplan:

Die Stalldauer wird in diesem Beispiel wie folgt berechnet:

Dauer der Unterbrechung = t_send + t_send-done + t_recv + t_recv-done

Beobachtete Dauer

Die Zeitspanne zwischen den send- und recv-done-Vorgängen, einschließlich der Zeit, in der Daten gesendet und empfangen werden. Nehmen wir als Beispiel den folgenden Zeitplan:

Die beobachtete Dauer wird wie folgt berechnet:

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

Häufigkeit

Die Häufigkeit, mit der ein Kollektiv während einer Profildauer initiiert und abgeschlossen wird. Ein Kollektiv wird initiiert, wenn ein send-Vorgang ausgeführt wird, und wird abgeschlossen, wenn der entsprechende recv-end-Vorgang ausgeführt wird. Der send-Vorgang und der zugehörige recv-done-Vorgang müssen innerhalb einer Profildauer ausgeführt werden, um in diesen Messwert aufgenommen zu werden.

Zusammengefasste Pausen insgesamt

Die Gesamtzeit, die ein Kollektiv eine TPU während einer Profildauer anhält. Die Gesamtverzögerung der Aggregation wird so berechnet:

Aggregierte Gesamtverzögerung = Dauer der Verzögerung × Vorkommen

Übertragene Datenmenge

Die Menge an Daten, die während der Profildauer für das Kollektiv über das Netzwerk übertragen wird.

Erforderliche Bandbreite

Die Bandbreite, die zum Übertragen von Daten innerhalb des vorgesehenen Slack-TV benötigt wird. Mit diesem Messwert können Sie die Anzahl der Kollektive sehen, die während der Profildauer um die Netzwerkbandbreite konkurrieren. Die erforderliche Bandbreite wird so berechnet:

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

Tool status

Die folgende Tabelle zeigt die Version der TensorFlow- oder TPU-Laufzeitversion, die für jeden im DCN Collective Stats-Tool angezeigten Messwert erforderlich ist.

DCN-Kollektivstatistiken	Unterstütztes TensorFlow der TPU-Laufzeitversion
Slack-Zeit	TensorFlow 2.15.0, tensorboard 2.15.1 und tensorboard-plugin-profile 2.15.0
Wartezeit	TensorFlow 2.15.0, tensorboard 2.15.1 und tensorboard-plugin-profile 2.15.0
Beobachtete Dauer	TensorFlow 2.15.0, tensorboard 2.15.1 und tensorboard-plugin-profile 2.15.0
Häufigkeit	TensorFlow 2.15.0, tensorboard 2.15.1 und tensorboard-plugin-profile 2.15.0
Zusammengefasste Pausen insgesamt	tf-nightly, tb-nightly, tbp-nightly
Übertragene Datenmenge	tf-nightly, tb-nightly, tbp-nightly
Erforderliche Bandbreite	tf-nightly, tb-nightly, tbp-nightly

So analysieren Sie das DCN Collective Stats-Tool

1. Führen Sie den TensorBoard-Server aus und rufen Sie den Tab Profil auf.
2. Sortieren Sie die Tabelle im DCN-Tool für kollektive Statistiken in absteigender Reihenfolge nach Aggregated Total Stall (Aggregierter Gesamtstand).
3. Ermitteln Sie den Namen der DCN-Sammlung mit dem höchsten Wert für Zusammengefasste Gesamtstall. Wenn die aggregierte Dauer des Stillstands dieses Kollektivs im Vergleich zu anderen deutlich hoch ist, könnte dies auf einen Engpass im DCN-Kollektiv hinweisen.
4. Multiplizieren Sie die erforderliche Bandbreite des DCN-Kollektivs mit der Anzahl der Kerne. Es gibt 8 Kerne pro v4-TPU-Host. Die erforderliche Bandbreite für eine Gruppe ist also das 8-Fache des angezeigten Werts. Wenn die erforderliche Bandbreite größer als die maximale Netzwerkbandbreite ist, kann dies bedeuten, dass das Netzwerk überlastet ist. Sie können die erforderliche Bandbreite reduzieren, indem Sie den verwendeten Fragmentierungsmechanismus ändern. Weitere Informationen zu Fragmentierungsmechanismen 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 eine Gruppe auszufächern, um die Planung von mehr überlappenden HLO-Vorgängen zu ermöglichen. Durch die Überschneidung von mehr HLO-Vorgängen wird die TPU-Stallzeit reduziert.
6. Prüfen Sie die Dauer von recv-done-Vorgängen in Trace Viewer für das DCN-Kollektiv, das die maximale aggregierte Gesamtverzögerung hat. Bei einer langen Übertragungsdauer kann es zu einem Bandbreitenengpass kommen, da recv-done-Vorgänge in der Regel im Netzwerk blockiert sind, um Daten abzurufen.
7. Wenn die Dauer von recv-done-Vorgängen im Vergleich zur Slack-Zeit nicht zu lang ist, kann dies auf ein Hardwareproblem hindeuten.