Multislice-Umgebungen profilerstellen

Cloud TPU-Multislice-Umgebungen bestehen aus mehreren TPU-Pod-Slices, die über das Data Center Network (DCN) kommunizieren. Mit dem DCN Collective Stats-Tool können Sie Informationen dazu abrufen, wie effektiv Ihre Multi-Slice-Umgebung das DCN-Netzwerk nutzt. Mit dem DCN Collective Stats-Tool kannst du Folgendes tun:

• Netzwerkleistung zwischen Slices auf Grundlage der erfassten Daten aufrufen und analysieren
• Leistungsengpässe identifizieren
• Leistung des Modells 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 Slices 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 zum Starten der Datenübertragung zur Verfügung.

send-done

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

recv

Bietet einen leeren Puffer, den der Host mit den übertragenen Daten füllen kann.

recv-done

Signalisiert dem Host, dass die Daten empfangen wurden.

Hinweis: Das tatsächliche Senden der Daten erfolgt nach Abschluss des send-Vorgangs. Der send-done-Vorgang erfolgt nach dem Senden der Daten. Ebenso werden Daten erst nach Abschluss des recv-Vorgangs empfangen. Der recv-done-Vorgang wird nach dem Empfang der Daten ausgeführt.

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

Slack Time

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

In diesem Beispiel wird die Pufferzeit so berechnet:

Lukrative Zeit = t₁ + t₂ + t₃

Wenn Sie die Wartezeit verlängern, verringern Sie die Wahrscheinlichkeit, dass die TPU für ein Kollektiv angehalten wird. Sie können die Ruhezeit verlängern, indem Sie eine andere Sharding-Methode auswählen.

Dauer des Stillstands

Die durchschnittliche Dauer, die das Kollektiv für die Vorgänge „Senden“, „Senden abgeschlossen“, „Empfangen“ und „Empfang abgeschlossen“ benötigt. Hinweis: Die Zeit für die Datenübertragung ist nicht enthalten. Angenommen, Sie haben folgende Zeitachse:

Die Dauer des Stillstands wird in diesem Beispiel so berechnet:

Stalldauer = t_send + t_send-done + t_recv + t_recv-done

Beobachtete Dauer

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

Die beobachtete Dauer wird so 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 der Dauer eines Profils gestartet und abgeschlossen wird. Ein Kollektiv wird gestartet, wenn ein send-Vorgang auftritt, und abgeschlossen, wenn der entsprechende recv-end-Vorgang auftritt. Der send-Vorgang und der zugehörige recv-done-Vorgang müssen innerhalb einer Profildauer stattfinden, um in diesen Messwert aufgenommen zu werden.

Aggregierte Gesamtauslastung

Die Gesamtzeit, während der ein Cluster eine TPU während der Profildauer blockiert. Die Gesamtsperrung bei der Aggregation wird so berechnet:

Gesamte Aussetzer (aggregiert) = Aussetzerdauer × Vorkommen

Größe der übertragenen Daten

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

Erforderliche Bandbreite

Die Bandbreite, die für die Datenübertragung innerhalb des bereitgestellten Spielraums erforderlich ist. Mit diesem Messwert kannst du 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 ÷ Leerlaufzeit

Tool-Status

In der folgenden Tabelle ist die Version der TensorFlow- oder TPU-Laufzeitumgebung aufgeführt, die für jeden Messwert im DCN Collective Stats-Tool erforderlich ist.

DCN-Statistiken für mehrere Channels	Unterstützte TensorFlow-Version der TPU-Laufzeitversion
Leerlaufzeit	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 Gesamtauslastung	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

DCN Collective Stats Tool analysieren

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 zusammengefasste Statistiken absteigend nach Aggregated Total Stall.
3. Ermitteln Sie den DCN-Kollektivnamen mit dem höchsten Wert für Aggregated Total Stall. Wenn die aggregierte Zeitspanne der Aussetzer dieses Kollektivs im Vergleich zu anderen deutlich höher ist, kann dies auf ein 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 ein Kollektiv ist also 8 mal so hoch wie der angezeigte Wert. Wenn die erforderliche Bandbreite größer als die maximale Netzwerkbandbreite der TPU ist, kann das bedeuten, dass das Netzwerk überlastet ist. Sie können versuchen, den verwendeten Sharding-Mechanismus zu ändern, um die erforderliche Bandbreite zu senken. Weitere Informationen zu Sharding-Mechanismen finden Sie unter Cloud TPU Multislice – Übersicht.
5. Erstellen Sie einen HLO-Dump, um festzustellen, ob es Compilerprobleme gibt. Es ist besser, send- und recv-done-Vorgänge für ein Kollektiv zu verzweigen, um die Planung von mehr sich überschneidenden HLO-Vorgängen zu ermöglichen. Wenn Sie mehr HLO-Vorgänge überschneiden, wird die TPU-Stallzeit verkürzt.
6. Prüfen Sie in der Trace Viewer die Dauer der recv-done-Vorgänge für das DCN-Kollektiv mit der maximalen aggregierten Gesamtsperrung. Wenn die Übertragung lange dauert, kann es zu einem Bandbreitenengpass kommen, 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 zur Leerlaufzeit nicht zu hoch ist, kann dies auf ein Hardwareproblem hinweisen.