PyTorch XLA-Leistungsprofilerstellung

Übersicht

In diesem Leitfaden erfahren Sie, wie Sie Cloud TPU-Leistungstools und das Feature zur automatischen Messwertanalyse mit PyTorch verwenden. Mit diesen Tools können Sie die Leistung von Trainingsarbeitslasten debuggen und optimieren.

Weitere Informationen zur Cloud TPU-Leistung mit PyTorch finden Sie in den folgenden Blogposts:

Wenn Sie neu bei PyTorch/XLA sind, lesen Sie die Dokumente API_GUIDE und Fehlerbehebung für PyTorch. Informationen zu Cloud TPU finden Sie im Konzeptdokument.

TPU-Knoten + PyTorch/XLA-Profilerstellung

Erstellen Sie die erforderlichen Cloud TPU-bezogenen Ressourcen und initialisieren Sie sie.

  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. Erstellen Sie eine Compute Engine-VM-Instanz. Hier werden alle Ihre 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. Eine TPU-Ressource erstellen

    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, falls noch nicht geschehen: Installationsanleitung.

  5. Verwenden Sie den Befehl gsutil mb, um einen Cloud Storage-Bucket zu erstellen, in dem alle Profilerstellungsartefakte gespeichert werden. Ersetzen Sie die Variablen für die Region und den Bucket-Namen durch die Werte, die Sie für Ihr Training verwenden werden.

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

    Dabei gilt:

    • 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-164006649440@cloud-tpu.iam.gserviceaccount.com

  7. Exportieren Sie das Dienstkonto und gewähren Sie Dienstkontoberechtigungen für den Storage-Bucket. Ersetzen Sie account-number durch die PROJECT_NUMBER, die in der Ausgabe der Dienstkontoerstellung zurückgegeben wurde.

    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. Stellen Sie eine ssh-Verbindung zu Ihrem VM-Weiterleitungsport 9001 auf Ihrer VM zu Port 9001 auf Ihrem lokalen Computer her. Ü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.6.0.dev20210511 tb-nightly==2.6.0a20210512 tbp-nightly==2.5.0a20210511
    
  3. Testen Sie Ihre Installation. Führen Sie dazu den TensorBoard-Server auf Ihrer Compute Engine-VM aus und versuchen Sie dann, eine Verbindung zum Server herzustellen. Rufen Sie dazu http://localhost:9001/#profile auf Ihrem lokalen Computer auf:

     # 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 auf Ihrem lokalen Computer http://localhost:9001/#profile aufrufen, sollte etwa Folgendes angezeigt werden:

Image

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

Image

Profil des Modells erstellen

Starten Sie von Ihrem lokalen Computer aus ein neues Terminalfenster und stellen Sie noch einmal eine ssh-Verbindung zur GCE-VM her, um den TensorBoard-Server offen zu halten (dieses Mal ohne -L Option verwenden für die Portweiterleitung).

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

    export PROJECT_ID=PROJECT_ID
    export ZONE=ZONE
    
  2. Stellen Sie eine ssh-Verbindung zur VM her:

      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. Prü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 Sie:

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

    Die beiden oben genannten Argumente in train_mnist lösen auf künstliche Art dynamische Diagramme und Tensor-Abrufe aus, die später im Abschnitt zur automatischer Messwerte-Analyse erkundet werden. Da Sie derzeit nur die TPU-Profilerstellung machen, wird das folgenden Beispiel mit Nominalleistung ausgeführt.

  5. Starten Sie einen Trainingsausführung, der für die Serverprofilerstellung 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-Profilerstellung (Server)

Sobald das Training ausgeführt wird, rufen Sie http://localhost:9001/#profile auf und erfassen Sie ein Profil anhand der folgenden Anleitung:

Image

Die folgende Seite wird automatisch neu geladen:

Image

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

  • Übersichtsseite (dies umfasst nicht die Anzeige des Input Pipeline Analyzer, der sich grundlegend zwischen TensorFlow/TPU und PyTorch / XLA TPU unterscheidet).
  • Memory Viewer
  • Op Profile
  • Pod Viewer
  • TensorFlow-Stats (Statistiken auf Framework-Ebene; PyTorch-Statistiken)
  • Trace Viewer (erfordert Chrome-Browser)

Übersichtsseite

Diese Seite bietet eine Übersicht über ein erfasstes Profil. Dieses Beispiel zeigt eine sehr hohe Leerlaufzeit, da es ein winziges Modell für das MNIST-Dataset trainiert.

Memory Viewer

Zeigt den Gerätespeicher (HBM) an, der pro Tensor und HLO-PyTorch-Vorgang verwendet wird. Der Memory Viewer erfasst eine Ansicht des Arbeitsspeichers pro HLO-Modul. Daher gibt es einige Module wie die Diagramme zur Gerätedatenzuweisung (Eingabe und gesendeter Labelbatch). Wählen Sie zum Anzeigen der Arbeitsspeichernutzung eines bestimmten HLO-Moduls das Modul aus dem Drop-down-Menü Hosts auf der linken Seite aus:

Image

Sobald Sie das ausgewählte HLO-Modul ansehen, erhalten Sie eine ganzheitliche Sicht auf die Zeitachse des HBM-Footprints für die Modulausführung. Diese wird nach Zuweisungsgröße, Größe der Programmausführung und Padding-Größe geordnet.

Image

Alle Zwischenspeicherzuordnungen können dann weiter geprüft werden, indem Sie den Mauszeiger darauf bewegen. So ermitteln Sie beispielsweise, welche Zuweisung den größten Teil des Geräte-HBM beansprucht:

Image

Im obigen Beispiel entspricht (1) den vom Nutzer code hinzugefügten torch_xla.debug.profiler.Trace-Annotationen. Untersuchen Sie den Code test_profile_mp_mnist.py, ob er dieser Zeile entspricht:

   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)
   ...
   

Außerdem können Sie aus dem op-Namespace test_mnist feststellen, dass dieses HLO-Modul dem eval-loop entspricht, da es den Kontextmanager xp.trace('test_mnist') hat.

XLA Op-Profil

Op Profile ist ein Cloud TPU-Tool zur Anzeige der Leistungsstatistiken von XLA-Vorgängen, die während der Dauer 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.

Image

Beschreibung von jedem:

  1. Übersichtsabschnitt. Zeigt die Cloud TPU-Auslastung an und stellt Optimierungsvorschläge bereit.
  2. Systemsteuerung. Enthält Steuerelemente, mit denen Sie Anzahl und Art der in der Tabelle angezeigten Vorgänge festlegen können und wie sie sortiert werden.
  3. Vorgangs-Tabelle Eine Tabelle mit den wichtigsten TensorFlow-Vorgangskategorien, jeweils den XLA-Vorgängen zugeordnet. Diese Vorgänge werden 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. Enthalten die FLOPS-Auslastung, den 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 PyTorch- und XRT-Vorgängestatistiken, 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 Profiling Viewer für Trace-Ereignisse, sodass der Chrome-Browser erforderlich ist.

Trace Viewer enthält eine Zeitachse mit folgenden Informationen:

  • Dauer für die 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 arbeitet der Hostcomputer in der Regel primär mit der Kompilierung und Zwischenspeicher zuordnen bzw. Entziehen der Zuordnung, 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.

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

Image

  1. Wird durch explizite Nutzerannotationen im Modellcode von test_profile_mp_mnist.py generiert.
  2. Ausgeführte PyTorch-Vorgänge (vor der Senkung).
  3. Automatisch generierter PyTorch- / XLA-HLO-Modulname
  4. XLA-Vorgänge, die auf dem Gerät ausgeführt werden (fusioniert).

Weitere Informationen finden Sie in der allgemeinen TPU-Dokumentation für den Trace Viewer. Ignorieren Sie jedoch Abschnitte zur Eingabepipeline und andere TensorFlow-spezifische Teile, da diese in der Kontext dieses Dokuments nicht relevant.

PyTorch- / XLA-Clientprofilerstellung

Ähnlich wie bei der Profilerstellung für die TPU-Seite, während die Modellausführung lief, erstellen Sie jetzt während des Trainings ein Profil für die PyTorch-/XLA-Clientseite. Das wichtigste Monitoringtool, das auf der Clientseite verwendet wird, ist der Trace Viewer.

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

Image

Zum Erfassen von Traces aus mehreren Prozessen kann jeder Prozess Profilerstellungs-Server an verschiedenen Ports starten (z. B. durch Hinzufügen von xm.get_ordinal() zu einer Basisportnummer) und dann eine Liste vonlocalhost:port angeben, verkettet durch ','. TensorBoard unterstützt nicht die gleichzeitige Anzeige von Traces aus mehreren Prozessen. Daher werden verschiedene Host Drop-down-Menüs für jeden Prozess angezeigt.

Das folgende Diagramm zeigt einen Beispiel-Trace:

Image

Ähnlich wie verschiedene Namespace-Traces für TPU-Traces hinzugefügt werden konnten, 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 Profilerstellungs-Server ähnlich dem in unserem Beispiel in test_train_mp_imagenet.py --fake_data zu starten, um Traces von ResNet50 zu erhalten.

Die Traces haben zusätzliche Metadaten, die geprüft werden können. Beispielsweise zeigen TransferToServer- und TransferFromServer-Traces die genaue Anzahl der gesendeten und empfangenen Tensoren und ihre Gesamtgröße an:

Image

Bei XLA-Diagrammkompilierungen sehen Sie den Diagramm-Hash, der bei der Diagnose von Problemen hilfreich sein kann:

Image

Anstatt über die TensorBoard-UI ein Profil zu erstellen, bieten wir auch eine API für die programmatische Profilerstellung sowohl der TPU als auch des Clients von PyTorch / XLA: xp.trace().

automatische Messwerte-Analyse

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

  • Dynamische Diagramme / kontinuierliche Kompilierung
  • Sehr langsame Diagrammkompilierung
  • Sehr langsame Diagrammausführung
  • Häufige XLA→CPU-Übertragungen
  • Wiederholtes Gerät-HBM zu Host-RAM-Austauschen
  • Wiederholte HBM-Defragmentierung
  • Nicht gesenkte aten::-Vorgänge

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

Ändern Sie:

   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 künstlich zu Kompilierungen und Tensor-Abrufen. dynamic_graph=True ändert die Batchgröße für jeden Schritt künstlich, sodass gesenkte XLA-Grafiken bei jedem Schritt und jeder Neukompilierung unterschiedlich sind. fetch_often=True fügt bei jedem Schritt loss.item()-Aufrufe ein, die bei jedem Schritt zum Abrufen von Tensorwerten vom Gerät führen, was die Leistung verlangsamt.

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
   

Die Best Practice besteht darin, zur Vereinfachung des Debugging-Prozesses mit --num_cores=1 auszuführen. Einige der Beispielausgaben sehen so aus:

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 Ausgabe der automatischen Messwertanalyse. In diesem Beispiel sehen Sie, dass TransferFromServerTime zu häufig gesehen wurde, nämlich einmal pro Schritt. Dies liegt daran, dass die Trainingsschleife bei jedem Schritt den Wert von loss.item() abruft. Außerdem wird möglicherweise die Warnung CompileTime zu häufig angezeigt, wenn Ihr Modell aufgrund der dynamischen Formen im Diagramm wiederholt neu kompiliert werden muss. Das folgende Code-Snippet verursacht diese Art von 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 aus dem Trainingsskript Strg^C drücken und sollten am Ende eine Zusammenfassung der nicht gesenkten Vorgänge sehen. Beachten Sie, dass aten::_local_scalar_dense eine spezielle Operation ist, die dem Abrufen von XLA-Tensoren zurück in den CPU-Kontext entspricht.

In diesem Bericht sehen Sie, dass es zwei Hauptorte gibt, an denen der Vorgang 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 jetzt die automatische Messwertanalyse im folgenden Skript aus, das einen nicht gesenkten Vorgang (wie in unserem Release 1.8) enthält: _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 automatische Analysator für Messwerte zeigt, dass die 11. Zeile von STDIN diese nicht abgesenkte Operation verursacht (d. h. die Linie mit torch.nn.CTCLoss()). Derzeit wurde die Operation ctc_loss nicht abgesenkt. Aus diesem Grund wird der obige Bericht angezeigt. Sie können auch einige Warnungen für TransferFromServerTime sehen, da sich die Tensoren vor der Ausführung initial in XLA:TPU befinden. Da jedoch der Vorgang nicht abgesenkt ist, müssen Sie zuerst die XLA-Tensoren zurück in CPU übertragen, Operation aten:: auf der CPU ausführen und sie zurückübertragen.

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

Bereinigen

Beenden Sie Ihre VM und löschen Sie dann die TPU, die VM und den Cloud Storage-Bucket, indem Sie folgende Befehle ausführen:

(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-Profilerstellung

Verwenden Sie diesen Abschnitt, um ein Profil für PyTorch/XLA mithilfe der TPU-VM-Architektur zu erstellen.

Umgebungsvariablen exportieren

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

    export PROJECT_ID=PROJECT_ID
    export ZONE=ZONE
    

Cloud TPU erstellen

Weitere Informationen finden Sie in den TPU VM-Nutzerhandbuch Erstellen Sie nach der Einrichtung eine v3-8-TPU-VM, die mit torch, torch_xla, torchvision und tensorboard vorinstalliert kommt.

  1. Eine TPU-Ressource erstellen

    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 das 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, sollten Sie in etwa Folgendes sehen:

Image

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

Image

Profil des Modells erstellen

Exportieren Sie in einem neuen Terminalfenster in Ihrer Entwicklungsumgebung dieselben Umgebungsvariablen wie oben und stellen Sie eine ssh zu Ihrer TPU-VM her:

  1. Exportieren Sie im neuen Terminalfenster Ihre Projekt-ID und Zonenvariablen noch einmal, da dies in einer neuen Shell ist.

    export PROJECT_ID=PROJECT_ID
    export ZONE=ZONE
    
  2. Stellen Sie eine ssh-Verbindung zur VM her:

      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 unseren 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 dem Start des Trainings die folgenden Zeilen in xla/test/test_profile_mp_mnist.py:

    Ändern Sie:

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

    Die beiden oben genannten Argumente in train_mnist lösen auf künstliche Art dynamische Diagramme und Tensor-Abrufe aus, die später im Abschnitt zur automatischer Messwerte-Analyse erkundet werden. Da Sie derzeit nur die TPU-Profilerstellung machen, wird das folgenden Beispiel mit Nominalleistung 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 + Clientprofilerstellung

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

Image

Anschließend sollte die folgende Seite neu geladen werden:

Image

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 sehen Sie in einer vollständigen Ansicht Traces sowohl aufseiten des "Clients" als auch aufseiten des TPU-Geräts:

Image

Bereinigen

  1. Beenden Sie Ihre VM und löschen Sie dann die TPU, die VM und den Cloud Storage-Bucket, indem Sie folgende Befehle ausführen:

    (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. Überprü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.