Leistungsprofil von PyTorch XLA

Übersicht

In dieser Anleitung wird beschrieben, wie Sie Cloud TPU-Leistungstools und die automatische Analyse von Messwerten mit PyTorch verwenden können. Mit diesen Tools können Sie Fehler beheben und die Leistung der Trainingsarbeitslasten optimieren.

Konzepte

Wenn Sie PyTorch / XLA noch nicht kennen, finden Sie in den Dokumenten zur API_TOOL und zur Fehlerbehebung von PyTorch. Informationen zu Cloud TPU finden Sie im Dokument "Konzepte".

TPU-Knoten + PyTorch/XLA-Profil

Erforderliche Cloud TPU-bezogene Ressourcen erstellen und initialisieren

  1. Erstellen Sie Variablen für Ihre Projekt-ID, Ihren Cloud Storage-Bucket und die Zone, die für Ihre TPU-Ressourcen verwendet werden soll.

    export PROJECT_ID=PROJECT_ID
    export BUCKET_NAME=BUCKET_NAME
    export ZONE=ZONE
    
    gcloud --project=$PROJECT_ID compute project-info add-metadata \
    --metadata BUCKET_NAME=$BUCKET_NAME
    
  2. Compute Engine-VM-Instanz erstellen Hier werden alle Python-Skripts und -Modelle gespeichert.

    gcloud compute instances create profiler-tutorial-vm \
      --project=${PROJECT_ID} \
      --zone=${ZONE} \
      --machine-type=n1-standard-16 \
      --image-project=ml-images \
      --image-family=torch-xla \
      --boot-disk-size=300GB \
      --scopes=https://www.googleapis.com/auth/cloud-platform
    
  3. Erstellen Sie eine TPU-Ressource.

    gcloud compute tpus create profiler-tutorial-tpu \
     --project=${PROJECT_ID} \
     --zone=${ZONE} \
     --network=default \
     --version=pytorch-1.8 \
     --accelerator-type=v3-8
    
  4. Cloud Storage-Bucket erstellen

    Installieren Sie zuerst die gsutil-Befehlszeile, wenn sie noch nicht installiert ist: Installationsanleitung.

  5. Erstellen Sie mit dem Befehl gsutil mb einen Cloud Storage-Bucket, in dem alle Profilerstellungsartefakte gespeichert sind. Ersetzen Sie die Variablen für Region und Bucket-Name durch die Werte, die Sie für das Training verwenden möchten.

    gsutil mb -p ${PROJECT_ID} -c standard -l REGION gs://${BUCKET_NAME}
    

    wobei

    • REGION ist die Region, in der Sie die Cloud TPU erstellt haben, z. B. europe-west4.
  6. Erstellen Sie ein Dienstkonto für das Cloud TPU-Projekt.

    gcloud beta services identity create --service tpu.googleapis.com --project $PROJECT_ID
    

    Der Befehl gibt ein Cloud TPU-Dienstkonto im folgenden Format zurück:

    service-PROJECT_NUMBER@cloud-tpu.iam.gserviceaccount.com
    

    Beispiel: service-140064964940@cloud-tpu.iam.gserviceaccount.com

  7. Exportieren Sie das Dienstkonto und gewähren Sie Dienstkonto-Berechtigungen für den Storage-Bucket. Ersetzen Sie account-number durch den PROJECT_NUMBER, der in der Ausgabe des Dienstkontos zurückgegeben wird.

    export SERVICE_ACCOUNT=service-ACCOUNT_NUMBER@cloud-tpu.iam.gserviceaccount.com
    gsutil acl ch -u $SERVICE_ACCOUNT:READER gs://${BUCKET_NAME}
    gsutil acl ch -u $SERVICE_ACCOUNT:WRITER gs://${BUCKET_NAME}
    

TensorBoard einrichten

  1. ssh zu Ihrem VM-Weiterleitungsport 9001 auf der VM zu Port 9001 auf Ihrem lokalen Computer. Über diesen Port wird die TensorBoard-UI in Ihrem lokalen Browser geöffnet.

      gcloud compute ssh profiler-tutorial-vm \
       --project ${PROJECT_ID} \
       --zone ${ZONE} \
       --ssh-flag="-4 -L 9001:localhost:9001"
    
  2. Erstellen Sie eine Conda-Umgebung für die TensorBoard-Installation:

    conda create -y -n tensorboard python=3.6
    conda activate tensorboard
    pip install tf-nightly==2.5.0.dev20210211 tb-nightly==2.5.0a20210211 tbp-nightly==2.5.0a20210211
    
  3. Testen Sie die Installation. Führen Sie dazu den TensorBoard-Server auf Ihrer Compute Engine-VM aus und versuchen Sie dann, unter http://localhost:9001/#profile eine Verbindung zum Server herzustellen. Ihr lokaler Computer:

     # Get bucket name
     BUCKET_NAME=$(curl "http://metadata.google.internal/computeMetadata/v1/project/attributes/BUCKET_NAME" -H "Metadata-Flavor: Google")
    
     tensorboard --logdir gs://${BUCKET_NAME} --port 9001
    

Wenn Sie http://localhost:9001/#profile auf Ihrem lokalen Computer aufrufen, sollte Folgendes angezeigt werden:

Bild

Wenn Sie http://localhost:9001 aufrufen, können Sie auch auf die obige Profilseite zugreifen, indem Sie im Drop-down-Menü oben rechts neben der Schaltfläche UPLOAD die Option PROFILE auswählen. :

Bild

Profil für das Modell erstellen

Starten Sie ein neues Terminalfenster und ssh noch einmal auf der GCE-VM, damit der TensorBoard-Server aktiv bleibt (diese Zeit ohne Verwendung von -L) Option für die Portweiterleitung).

  1. Exportieren Sie im neuen Terminalfenster Ihre Projekt-ID, die Storage-Bucket-Umgebung und die Zonenvariablen noch einmal, da diese in einer neuen Shell gespeichert sind.

    export PROJECT_ID=PROJECT_ID
    export ZONE=ZONE
    
  2. ssh in die VM:

      gcloud compute ssh profiler-tutorial-vm \
       --project ${PROJECT_ID} \
       --zone ${ZONE}
    
    conda activate torch-xla-1.8
    PROJECT_ID=$(curl "http://metadata.google.internal/computeMetadata/v1/project/project-id" -H "Metadata-Flavor: Google")
    export TPU_IP_ADDRESS=$(gcloud compute tpus describe profiler-tutorial-tpu --zone=${ZONE} --project=${PROJECT_ID} \
    --format="value(ipAddress)")
    echo TPU_IP_ADDRESS=${TPU_IP_ADDRESS}
    export XRT_TPU_CONFIG="tpu_worker;0;$TPU_IP_ADDRESS:8470"
    
  3. Überprüfen Sie, ob Integrationstests in Ihrer Umgebung durchgängig funktionieren:

    python /usr/share/torch-xla-1.8/pytorch/xla/test/test_profiler.py # takes <1 min
    >
  4. Bearbeiten Sie vor dem Training die folgenden Zeilen in /usr/share/torch-xla-1.8/pytorch/xla/test/test_profile_mp_mnist.py:

    Ändern:

    accuracy = train_mnist(flags, dynamic_graph=True, fetch_often=True)
    
    An:
    accuracy = train_mnist(flags, dynamic_graph=False, fetch_often=False)
    

    Die beiden obigen Argumente in train_mnist führen zu künstlichen Ursachen für dynamische Grafiken und Tensoren, die später im Abschnitt "Automatische Messwertanalyse" untersucht werden. Da Sie nun lediglich die Profilerstellung für die TPU durchführen, wird im folgenden Beispiel die nominale Leistung ausgeführt.

  5. Starten Sie einen Trainingslauf, der für die Profilerstellung für Server verwendet wird:

    PT_XLA_DEBUG=1 XLA_HLO_DEBUG=1 python /usr/share/torch-xla-1.8/pytorch/xla/test/test_profile_mp_mnist.py --num_epochs 1000 --fake_data
    

TPU-Profiling (Server)

Rufen Sie nach der Ausführung des Trainings http://localhost:9001/#profile auf und erfassen Sie ein Profil anhand der folgenden Anweisungen:

Bild

Die folgende Seite wird automatisch neu geladen:

Bild

Unterstützte Tools werden im Drop-down-Menü Tools im linken Bereich angezeigt:

  • Übersichtsseite (dies schließt nicht die Anzeige des Input Pipeline Analyzers ein, was sich grundlegend zwischen TensorFlow/TPU und PyTorch / XLA TPU unterscheidet).
  • Memory Viewer
  • Op Profile
  • Pod Viewer
  • Tensorflow-Statistiken (Statistiken auf Framework-Ebene; Statistiken zu PyTorch)
  • Trace Viewer (erfordert den Chrome-Browser)

Übersichtsseite

Diese Seite bietet eine Übersicht über ein erfasstes Profil. Dieses Beispiel zeigt eine sehr hohe Leerlaufzeit, da ein kleines Modell im MNIST-Dataset trainiert wird.

Memory Viewer

Zeigt den Gerätespeicher (HBM) an, der pro Tensor und der HLO PyTorch-Vorgang verwendet wird. Der Arbeitsspeicherbetrachter erfasst eine Ansicht des Speichers pro HLO-Modul. Daher werden einige Module wie die Diagrammdatenzuordnung des Geräts (Eingabe- und Label-Batch gesendet) gesendet. Wählen Sie links im Drop-down-Menü Hosts das Modul aus, um die Arbeitsspeichernutzung eines bestimmten HLO-Moduls anzuzeigen:

Bild

Nach der Anzeige des ausgewählten HLO-Moduls erhalten Sie eine ganzheitliche Ansicht des HBM-Zeitfensters für die Modulausführung. Die Reihenfolge ist nach der Zuweisungsgröße, der Programmausführungsgröße und der Padding-Größe angeordnet.

Bild

Jede Pufferzuordnung kann dann weiter untersucht werden, wenn Sie den Mauszeiger darauf bewegen. So ermitteln Sie beispielsweise, welche Zuweisung den HBM zur Verfügung stellt:

Bild

Im obigen Beispiel entspricht (1) den vom Nutzercode hinzugefügten torch_xla.debug.profiler.Trace-Annotationen. Bei der Prüfung des test_profile_mp_mnist.py-Codes wird dieser dieser Zeile entsprechen:

   class MNIST(nn.Module):
   ...
     def forward(self, x):
       with xp.Trace('conv1'):
         x = F.relu(F.max_pool2d(self.conv1(x), 2))
         x = self.bn1(x)
   ...
   

Aus dem Namespace test_mnist-Vorgang können Sie auch angeben, dass dieses HLO-Modul der Evaluierung entspricht, da es den Kontextmanager xp.trace('test_mnist') hat.

XLA Op Profile

Op Profile ist ein Cloud TPU-Tool zur Anzeige von Leistungsstatistiken von XLA-Vorgängen, die während der Zeit der Profilerstellung ausgeführt wurden. Op Profile zeigt folgendes:

  • Wie gut Ihre Anwendung die Cloud TPU verwendet als Prozentsatz der Zeit, die für Vorgänge nach Kategorie und TPU-FLOPS-Auslastung aufgewendet wird.
  • Vorgänge, die am zeitaufwendigsten waren. Diese Vorgänge sind potenzielle Ziele für die Optimierung.
  • Details zu einzelnen Vorgängen, einschließlich Form, Auffüllung und Ausdrücken, die den Vorgang verwenden.

Sie können Op Profile verwenden, um gute Ziele für die Optimierung zu finden. Wenn Ihr Modell beispielsweise nur 5% des FLOPS-Höchstwertes der TPU erreicht, können Sie mit dem Tool ermitteln, welche XLA-Vorgänge die längste Ausführungszeit benötigen und wie viele TPU-FLOPS sie verbrauchen.

Bild

Beschreibung der einzelnen Elemente:

  1. Übersicht. Zeigt die Cloud TPU-Auslastung an und macht Optimierungsvorschläge.
  2. "Control Panel" (Steuerfeld). Enthält Steuerelemente, mit denen Sie die Anzahl der in der Tabelle angezeigten Vorgänge, die angezeigten Reihenfolgen und die Sortierreihenfolge festlegen können.
  3. Vorgangstabelle. Eine Tabelle mit den wichtigsten TensorFlow-Vorgangskategorien, die den XLA-Vorgängen zugeordnet sind. Diese Vorgänge sind nach Prozentsatz der Cloud TPU-Nutzung sortiert.
  4. Karten mit Vorgangsdetails. Zeigen Details zum Vorgang an, wenn Sie den Mauszeiger über einen Vorgang in der Tabelle bewegen. Dazu gehören die FLOPS-Auslastung, der Ausdruck, in dem der Vorgang verwendet wird, und das Vorgangslayout (Passform).

Pod Viewer

Eine vollständige Beschreibung des Pod-Viewer-Tools finden Sie unter TPU-Tools.

Framework-Statistiken (Tensorflow/PyTorch-Statistiken)

Framework-Statistiken bieten eine detaillierte Aufschlüsselung der Statistiken von PyTorch und XRT, die auf TPU-Geräten und TPU-Hosts ausgeführt werden.

Trace Viewer

Trace Viewer ist ein Cloud TPU-Tool zur Leistungsanalyse. Der Trace Viewer verwendet den Chrome Trace Event Profiling Viewer, daher muss der Chrome-Browser verwendet werden.

Trace Viewer enthält eine Zeitachse mit folgenden Informationen:

  • Dauer der Vorgänge, die von Ihrem TensorFlow-Modell ausgeführt wurden.
  • Teil des Systems (TPU oder Hostcomputer), in dem ein Vorgang ausgeführt wurde. Bei PyTorch / XLA funktioniert der Hostcomputer vor allem an der Kompilierung und Zwischenspeicherzuordnung/Deallocation, während die TPU das eigentliche Modelltraining übernimmt.
  • Trace Viewer ermöglicht es Ihnen, Leistungsprobleme in Ihrem Modell zu identifizieren und Maßnahmen zu deren Lösung zu ergreifen. Eine Aufschlüsselung lässt dann erkennen, welche PyTorch-/XLA-Vorgänge die längste Ausführungszeit haben.

Sie können Traces direkt hinzufügen, um zu messen, wie lange bestimmte Teile Ihres Modells ausgeführt werden. Dazu fügen Sie xp.Trace(NAME)-Annotationen hinzu. Der folgende Trace zeigt beispielsweise:

Bild

  1. Wird von expliziten Nutzerannotationen im Modellcode von "test_profile_mp_mnist.py" generiert.
  2. PyTorch-Vorgänge werden ausgeführt (Vorverarbeitung).
  3. Automatisch generierter Name des PyLO-Moduls von PyTorch / XLA.
  4. XLA-Vorgänge, die auf dem Gerät ausgeführt werden (nicht genutzt)

Weitere Informationen finden Sie in der allgemeinen TPU-Dokumentation für den Trace Viewer. Sie ignorieren Abschnitte um die Eingabepipeline und andere TensorFlow-spezifische Teile, da sie in den in diesem Dokument.

PyTorch-/XLA-Client-Profiling

Ähnlich wie bei der Profilerstellung der TPU-Seite während der laufenden Modellausführung profilieren Sie jetzt die PyTorch-/XLA-Clientseite für das Training. Das auf der Clientseite verwendete Hauptmonitoringtool ist der Trace Viewer.

Sie müssen den Profiling-Server in Ihrem Trainingsskript starten. Ein Beispiel finden Sie hier. Sie können in TensorBoard eine Trace abfragen, um einen Trace zu erfassen.

Bild

Wenn Sie Traces von mehreren Prozessen erfassen, kann jeder Prozess Profilerstellungsserver auf verschiedenen Ports starten. Beispiel: Sie fügenxm.get_ordinal() eine Basis-Portnummer an und geben Sie dann eine Liste derlocalhost:port Verbunden durch ",". Mit TensorBoard können Sie Traces aus mehreren Prozessen gleichzeitig nicht aufrufen. Daher sehen Sie unterschiedliche Moderator/in Drop-down-Menüs für jeden Prozess aus.

Das folgende Diagramm zeigt ein Beispiel-Trace:

Bild

Ähnlich wie Sie verschiedene Namespace-Traces für TPU-Traces hinzufügen können, können Sie dieselbe API verwenden, um sie den clientseitigen Traces (xp.Trace(NAME)) hinzuzufügen. Da dieses Modell klein ist und mit kleinen MNIST-Images verwendet wird, sind die Schrittzeiten kurz und nicht unbedingt einheitlich. Als Übung können Sie versuchen, die Traces hinzuzufügen und einen Profiler-Server ähnlich dem in unserem Beispiel zu test_train_mp_imagenet.py --fake_data zu starten, um Traces von ResNet50 abzurufen.

Die Traces enthalten zusätzliche Metadaten, die untersucht werden können. In den Trace-Dateien für TransferToServer und TransferFromServer wird genau die Anzahl der gesendeten und empfangenen Tensoren und deren Gesamtgröße angezeigt:

Bild

Bei XLA-Graph-Kompilierungen ist der Grafik-Hashwert hilfreich, der bei der Diagnose von Problemen hilfreich sein kann:

Bild

Zusätzlich zur Profilerstellung über die TensorBoard-UI bieten wir auch eine API für das programmatische Erstellen von TPUs und dem Client aus PyTorch / XLA: xp.trace() an.

Analyse automatischer Messwerte

In diesem Abschnitt erfahren Sie, wie Sie mit dem Debugging-Modus Leistungsprobleme erkennen. Beispiele:

  • Dynamische Grafiken / Kontinuierliche Kompilierungen
  • Sehr langsame Kompilierung
  • Sehr langsame Grafikausführung
  • Häufige XLA-CPU-Übertragungen
  • Wiederholter HBM-Host für RAM-Wechsel
  • Wiederholte HBM-Defragmentierung
  • aten:: Vorgänge mit Untergrenze

Setzen Sie vor Beginn des Trainings die folgenden Zeilen in /usr/share/torch-xla-1.8/pytorch/xla/test/test_profile_mp_mnist.py zurück:

Ändern:

   accuracy = train_mnist(flags, dynamic_graph=False, fetch_often=False)
   
An:
   accuracy = train_mnist(flags, dynamic_graph=True, fetch_often=True)
   

Diese Änderungen führen zu künstlichen Kompilierungen und Tensor-Abrufen. dynamic_graph=True ändert die Batchgröße für jeden Schritt künstlich. Dabei werden XLA-Grafiken verkleinert, um sie bei jedem Schritt zu unterscheiden und neu zu kompilieren. fetch_often=True fügt bei jedem Schritt loss.item()-Aufrufe ein, um bei jedem Schritt Tensorwerte über das Gerät abzurufen und die Leistung zu beeinträchtigen.

Beispiel für ein Trainingsskript ausführen:

   PT_XLA_DEBUG=1 python /usr/share/torch-xla-1.8/pytorch/xla/test/test_profile_mp_mnist.py --fake_data --num_cores=1
   

Beim Debugging wird empfohlen, mit --num_cores=1 auszuführen, da der Fehlerbehebungsprozess vereinfacht wird. Hier sehen Sie einige Beispiele für die Ausgabe:

Epoch 1 train begin 01:18:05
| Training Device=xla:1/0 Step=0 Loss=0.00000 Rate=1905.00 GlobalRate=1904.72 Time=01:18:05
pt-xla-profiler: TransferFromServerTime too frequent: 3 counts during 3 steps
pt-xla-profiler: TransferFromServerTime too frequent: 4 counts during 4 steps
pt-xla-profiler: TransferFromServerTime too frequent: 5 counts during 5 steps
pt-xla-profiler: TransferFromServerTime too frequent: 6 counts during 6 steps
pt-xla-profiler: TransferFromServerTime too frequent: 7 counts during 7 steps
pt-xla-profiler: TransferFromServerTime too frequent: 8 counts during 8 steps
pt-xla-profiler: TransferFromServerTime too frequent: 9 counts during 9 steps
pt-xla-profiler: TransferFromServerTime too frequent: 10 counts during 10 steps
pt-xla-profiler: CompileTime too frequent: 21 counts during 11 steps
pt-xla-profiler: TransferFromServerTime too frequent: 11 counts during 11 steps
pt-xla-profiler: CompileTime too frequent: 23 counts during 12 steps

Zeilen mit dem Präfix pt-xla-profiler entsprechen der Analyse der automatischen Messwerte. In diesem Beispiel wurde TransferFromServerTime zu oft pro Schritt gesehen. Dies liegt an der Trainingsschleife, die den Wert von loss.item() in jedem Schritt ermittelt. Es kann auch die Warnung CompileTime zu häufig auftreten, wenn Ihr Modell aufgrund dynamischer Formen im Diagramm wiederholt neu kompiliert werden muss. Das folgende Code-Snippet verursacht dieses Problem: test_profile_mp_mnist.py

    for step, (data, target) in enumerate(loader):
      if dynamic_graph:
        # The batch dimension is different every step.
        index = max(-step, -flags.batch_size + 1)  # non-empty
        data, target = data[:-index, :, :, :], target[:-index]
      ...
      if fetch_often:
        # Fetch tensor value from XLA:TPU to CPU every step.
        loss_i = loss.item()

Sie können dann Strg + C aus dem Trainingsskript entfernen, und am Ende sollten Sie eine Zusammenfassung der verworfenen Vorgänge sehen. aten::_local_scalar_dense ist eine spezielle Funktion, die dem Abrufen von XLA-Tensoren zurück zum CPU-Kontext entspricht.

In diesem Bericht sehen Sie, dass es zwei Stellen gibt, an denen die Funktion aten::_local_scalar_dense aufgerufen wird. Beide entsprechen dem Quellcode von loss.item():

  • test/test_profile_mp_mnist.py:158
  • test/test_profile_mp_mnist.py:61
pt-xla-profiler: ================================================================================
pt-xla-profiler: Unlowered Op usage summary (more of these ops, lower performance)
pt-xla-profiler: Note: _local_scalar_dense typically indicates CPU context access
pt-xla-profiler: --------------------------------------------------------------------------------
pt-xla-profiler: FRAME (count=27):
pt-xla-profiler: Unlowered Op: "_local_scalar_dense"
pt-xla-profiler: Python Frames:
pt-xla-profiler:   train_loop_fn (test/test_profile_mp_mnist.py:158)
pt-xla-profiler:   train_mnist (test/test_profile_mp_mnist.py:184)
pt-xla-profiler:   _mp_fn (test/test_profile_mp_mnist.py:206)
pt-xla-profiler:   _start_fn (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/distributed/xla_multiprocessing.py:323)
pt-xla-profiler:   spawn (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/distributed/xla_multiprocessing.py:386)
pt-xla-profiler:    (test/test_profile_mp_mnist.py:216)
pt-xla-profiler:
pt-xla-profiler:
pt-xla-profiler: FRAME (count=2):
pt-xla-profiler: Unlowered Op: "_local_scalar_dense"
pt-xla-profiler: Python Frames:
pt-xla-profiler:   _train_update (test/test_profile_mp_mnist.py:61)
pt-xla-profiler:    (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/core/xla_model.py:700)
pt-xla-profiler:   _run_step_closures (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/core/xla_model.py:709)
pt-xla-profiler:   mark_step (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/core/xla_model.py:723)
pt-xla-profiler:   __exit__ (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/debug/profiler.py:153)
pt-xla-profiler:   train_loop_fn (test/test_profile_mp_mnist.py:162)
pt-xla-profiler:   train_mnist (test/test_profile_mp_mnist.py:184)
pt-xla-profiler:   _mp_fn (test/test_profile_mp_mnist.py:206)
pt-xla-profiler:   _start_fn (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/distributed/xla_multiprocessing.py:323)
pt-xla-profiler:   spawn (/home/jysohn/git/jysohn23/pytorch/xla/torch_xla/distributed/xla_multiprocessing.py:386)
pt-xla-profiler:    (test/test_profile_mp_mnist.py:216)
pt-xla-profiler:
pt-xla-profiler:
pt-xla-profiler: ================================================================================

Führen Sie nun die Analyse von automatischen Messwerten im folgenden Skript aus, das einen nicht fallenden Vorgang enthält (ab unserer Version 1.8) mit _ctc_loss:

PT_XLA_DEBUG=1 python <<EOF
import torch
import torch_xla.core.xla_model as xm

dev = xm.xla_device()
t = torch.randn(50, 16, 20).log_softmax(2).to(dev)
target = torch.randint(low=1, high=20, size=(16, 30), dtype=torch.long).to(dev)
input_lengths = torch.full(size=(16,), fill_value=50, dtype=torch.long).to(dev)
target_lengths = torch.randint(low=10, high=30, size=(16,), dtype=torch.long).to(dev)

for _ in range(10):
  loss = torch.nn.CTCLoss()(t, target, input_lengths, target_lengths)
  xm.mark_step()
EOF

Wenn Sie das obige Skript mit PT_XLA_DEBUG=1 ausführen, sollte die Ausgabe in etwa so aussehen:

…
pt-xla-profiler: TransferFromServerTime too frequent: 30 counts during 10 steps
pt-xla-profiler: Op(s) not lowered: aten::_ctc_loss,  Please open a GitHub issue with the above op lowering requests.
pt-xla-profiler: ================================================================================
pt-xla-profiler: Unlowered Op usage summary (more of these ops, lower performance)
pt-xla-profiler: Note: _local_scalar_dense typically indicates CPU context access
pt-xla-profiler: --------------------------------------------------------------------------------
pt-xla-profiler: FRAME (count=10):
pt-xla-profiler: Unlowered Op: "_ctc_loss"
pt-xla-profiler: Python Frames:
pt-xla-profiler:   ctc_loss (/anaconda3/envs/torch-xla-1.8/lib/python3.6/site-packages/torch/nn/functional.py:2305)
pt-xla-profiler:   forward (/anaconda3/envs/torch-xla-1.8/lib/python3.6/site-packages/torch/nn/modules/loss.py:1593)
pt-xla-profiler:   _call_impl (/anaconda3/envs/torch-xla-1.8/lib/python3.6/site-packages/torch/nn/modules/module.py:889)
pt-xla-profiler:    (:11)
pt-xla-profiler:
pt-xla-profiler:
pt-xla-profiler: ================================================================================

Der analytische Messwertanalytiker zeigt, dass die elfte Zeile von STDIN zu dieser verschlechterlichen Funktion führt (die Zeile mit torch.nn.CTCLoss()). Derzeit ist die ctc_loss-Operation nicht gesunken. . Daher ist der Bericht oben enthalten. Sie können auch einige Warnungen für TransferFromServerTime sehen, da die Tensoren zu Beginn der XLA:TPU zuerst ausgeführt werden. Da der Vorgang aber nicht abgesenkt ist, müssen Sie zuerst die XLA-Tensoren wieder zurück zu CPU, führen Sie die Funktion aten:: auf der CPU aus und übertragen Sie sie zurück.

Wenn Sie die pt-xla-profiler-Ausgabe stattdessen in eine Datei schreiben möchten, legen Sie PT_XLA_DEBUG=1 und PT_XLA_DEBUG_FILE=$PATH_TO_FILE fest.

Clean-up

Beenden Sie die VM und löschen Sie dann die TPU-, VM- und Cloud Storage-Bucket mit den folgenden Befehlen:

(vm)$ exit
gcloud compute instances delete profiler-tutorial-vm \
  --zone=${ZONE} \
  --project=${PROJECT_ID}
gcloud compute tpus delete profiler-tutorial-tpu \
  --zone=${ZONE} \
  --project=${PROJECT_ID} \
  --async
gsutil rm -fr gs://${BUCKET_NAME}

TPU-VM + PyTorch/XLA-Profil

In diesem Abschnitt können Sie ein Profil der PyTorch/XLA mithilfe der TPU-VM-Architektur erstellen.

Umgebungsvariablen exportieren

  1. Erstellen Sie Variablen für Ihre Projekt-ID und die Zone für Ihre TPU-Ressourcen.

    export PROJECT_ID=PROJECT_ID
    export ZONE=ZONE
    

Cloud TPU erstellen

In den TPU-VM-Nutzerhandbuch Erstellen Sie nach der Einrichtung eine v3-8-TPU-VM, die im Lieferumfang dertorch , torch_xla , torchvision undtensorboard vorinstalliert.

  1. Erstellen Sie eine TPU-Ressource.

    gcloud alpha compute tpus tpu-vm create profiler-tutorial-tpu-vm \
     --project=${PROJECT_ID} \
     --zone=${ZONE} \
     --version=v2-alpha \
     --accelerator-type=v3-8
    

TensorBoard-Serverstart

  1. Stellen Sie eine SSH-Verbindung zur VM her, installieren Sie tensorboard-plugin-profile und starten Sie einen Tensorboard-Server.

      gcloud alpha compute tpus tpu-vm ssh profiler-tutorial-tpu-vm \
       --project ${PROJECT_ID} \
       --zone ${ZONE} \
       --ssh-flag="-4 -L 9001:localhost:9001"
    
      pip3 install tf-nightly==2.6.0.dev20210511 tb-nightly==2.6.0a20210512 tbp-nightly==2.5.0a20210511
    
      tensorboard --logdir ./tensorboard --port 9001
    

Wenn Sie die TensorBoard-Ausgabe unter http://localhost:9001 auf Ihrem lokalen Computer aufrufen, sollte Folgendes angezeigt werden:

Bild

Wenn Sie die TensorBoard-Ausgabe unter http://localhost:9001 aufrufen, können Sie auch auf die obige Profilseite zugreifen, indem Sie im Drop-down-Menü oben rechts neben der Schaltfläche UPLOAD die Option PROFILE auswählen:

Bild

Profil für das Modell erstellen

Exportieren Sie in einem neuen Terminalfenster in Ihrer Entwicklungsumgebung die gleichen Umgebungsvariablen wie oben und ssh auf Ihre TPU-VM:

  1. Exportieren Sie im neuen Terminalfenster Ihre Projekt-ID und die Variablenvariablen noch einmal, da diese in einer neuen Shell gespeichert sind.

    export PROJECT_ID=PROJECT_ID
    export ZONE=ZONE
    
  2. ssh in die VM:

      gcloud alpha compute tpus tpu-vm ssh profiler-tutorial-tpu-vm \
       --project ${PROJECT_ID} \
       --zone ${ZONE}
    
  3. Klonen Sie das PyTorch/XLA-Repository und führen Sie den e2e-Test aus:

      git clone -b r1.8 https://github.com/pytorch/xla
      export XRT_TPU_CONFIG="localservice;0;localhost:51011"
      python3 xla/test/test_profiler.py  # takes <1 min
    >
  4. Bearbeiten Sie vor Beginn des Trainings die folgenden Zeilen in xla/test/test_profile_mp_mnist.py:

    Ändern:

        accuracy = train_mnist(flags, dynamic_graph=True, fetch_often=True)
    
    An:
        accuracy = train_mnist(flags, dynamic_graph=False, fetch_often=False)
    

    Die beiden obigen Argumente in train_mnist führen zu künstlichen Ursachen für dynamische Grafiken und Tensoren, die später im Abschnitt "Automatische Messwertanalyse" untersucht werden. Da Sie nun lediglich die Profilerstellung für die TPU durchführen, wird im folgenden Beispiel die nominale Leistung ausgeführt.

  5. Starten Sie einen Trainingslauf:

     XLA_HLO_DEBUG=1 python3 xla/test/test_profile_mp_mnist.py --num_epochs 1000 --fake_data
    

TPU und Clientprofiling

Sobald das Training ausgeführt wird, rufen Sie die TensorBoard-Ausgabe unter http://localhost:9001 auf und erfassen ein Profil mithilfe der folgenden Anweisungen:

Bild

Die folgende Seite sollte neu geladen werden:

Bild

Derzeit ist in der TPU-VM-Einrichtung nur das Trace Viewer-Tool ausgewählt. Wählen Sie daher im Drop-down-Menü Tools trace_viewer aus und prüfen Sie die Traces. In der TPU-VM-Einrichtung werden die Traces auf der Client- und der TPU-Gerät in einer Vollansicht angezeigt:

Bild

Clean-up

  1. Beenden Sie die VM und löschen Sie dann die TPU-, VM- und Cloud Storage-Bucket mit den folgenden Befehlen:

    (vm)$ exit
    

Löschen Sie die von Ihnen erstellte TPU-VM:

  1. Löschen Sie Ihre Cloud TPU- und Compute Engine-Ressourcen.

    $ gcloud alpha compute tpus tpu-vm delete profiler-tutorial-tpu-vm \
      --project ${PROJECT_ID} --zone=${ZONE}
    
  2. Prüfen Sie mit dem folgenden Befehl, ob die Ressourcen gelöscht wurden: Der Löschvorgang kann einige Minuten dauern. Eine Antwort wie die folgende gibt an, dass Ihre Instanzen erfolgreich gelöscht wurden.

    $ gcloud alpha compute tpus tpu-vm list --project ${PROJECT_ID} --zone=${ZONE}
    
    Listed 0 items.