Fehlerbehebung bei TensorFlow – TPU

In diesem Leitfaden und den häufig gestellten Fragen finden Nutzer, die TensorFlow-Modelle auf Cloud TPU trainieren, Informationen zur Fehlerbehebung. Wenn Sie Probleme mit dem PyTorch- oder JAX-Training beheben möchten, können Sie die Dokumente zur Fehlerbehebung für diese Frameworks aufrufen:

Allgemeinere Anleitungen zur Verwendung von Cloud TPU finden Sie hier:

Übersicht

Häufige Probleme bei Cloud TPUs fallen in die folgenden Kategorien:

  1. Probleme beim Herstellen einer Verbindung zur TPU

  2. Behebung von allgemeinen Fehlern

  3. Arbeitsspeichernutzung reduzieren

  4. Verbesserung der Trainingsgeschwindigkeit

  5. Debugging verringert die Accuracy des Modells

Fehler beim Herstellen einer Verbindung zum TPU-Server

In diesem Abschnitt wird beschrieben, wie Sie Problemsituationen lösen, in denen TensorFlow beim Herstellen einer Verbindung zur TPU nicht mehr reagiert oder einen Fehler ausgibt. Beachten Sie, dass die Kompilierung des TPU-Graphen bei großen Modellen sehr lange dauern kann. Das Script sollte daher mindestens 5 Minuten lang ausgeführt werden, um festzustellen, ob es wirklich nicht mehr reagiert.

Der erste Schritt besteht darin, zu überprüfen, ob es sich um ein Problem mit dem Server selbst oder mit Ihrer TensorFlow-Trainings-Pipeline handelt. Führen Sie dazu Ihr TensorFlow-Programm aus und prüfen Sie, ob es ordnungsgemäß funktioniert. Wenn weiterhin Probleme beim Herstellen der Verbindung bestehen, bestätigt dies, dass ein Problem beim TPU-Server vorliegt. In diesem Fall gilt:

  1. Führen Sie den folgenden Befehl aus, um die verfügbaren TPUs aufzulisten. Ersetzen Sie zone und project-id durch Ihre Zone und Projekt-ID.

    (vm)$ gcloud compute tpus tpu-vm list --zone zone --project project-id

    Dabei wird beispielsweise Folgendes ausgegeben: 

    NAME       ZONE           ACCELERATOR_TYPE  NETWORK_ENDPOINT   NETWORK  RANGE          STATUS
TPU_NAME   us-central1-b  v2-8              10.240.1.2:8470    default  10.240.1.0  READY

  2. Prüfen Sie, ob diese TPU als READY aufgeführt ist.

  3. Wenn Ihre TPU nicht als READY gelistet ist oder Sie weiterhin keine Verbindung herstellen können, starten Sie den Server hiermit manuell neu.

    (vm)$ gcloud compute tpus tpu-vm stop TPU_NAME && gcloud compute tpus tpu-vm start TPU_NAME

    Die Ausführung dieses Befehls kann mehrere Minuten dauern.

  4. Führen Sie den oben genannten Befehl gcloud compute tpus tpu-vm list noch einmal aus und warten Sie, bis sich die TPU im Status READY befindet. Dieser Vorgang kann einige Minuten dauern.

  5. Versuchen Sie noch einmal, das Programm auszuführen.

  6. Wenn Sie weiterhin Probleme haben, können Sie über einen der unter Support beschriebenen Wege Unterstützung anfordern.

Wenn Ihr Code korrekt ausgeführt wird, Ihr Modell jedoch weiterhin nicht reagiert, liegt das Problem wahrscheinlich in der Trainingspipeline. Ersetzen Sie zur Fehlerbehebung zuerst die „TPUStrategy“ in Ihrem Code durch die Standardstrategie. Wenn Sie die Standardstrategie verwenden, wird das Modell überall, wo Sie strategy.scope() oder strategy.run() verwenden, auf der CPU (oder GPU, falls vorhanden) anstelle der TPU ausgeführt. Wenn das Modell auf der CPU ordnungsgemäß ausgeführt wird, nicht jedoch auf der TPU, muss ein TPU-spezifisches Problem vorliegen. Wenn das Programm immer noch nicht ausgeführt wird, empfiehlt es sich, das Problem auf der CPU zu debuggen.

Verlust der ssh-Verbindung während des Trainings

Die ssh-Verbindung zur Cloud TPU kann bei einem lang andauernden Training aufgrund einer Zeitüberschreitung abbrechen, insbesondere wenn Sie die Cloud Shell verwenden. Es findet dann keine Ausgabe an die TPU-Konsole statt und es kann so aussehen, als ob das Training der TPU gestoppt wurde. Um dies zu vermeiden, führen Sie die Trainingssitzung mit einem Terminal-Multiplexer oder einem Tool zur Sitzungsverwaltung wie tmux oder screen aus. Dadurch bleibt die ssh-Verbindung unabhängig von der Länge des Trainings aktiv.

Behebung von allgemeinen Fehlern

In diesem Abschnitt wird beschrieben, wie Sie häufige Fehler beheben, die beim Trainieren von Modellen auf Cloud TPU auftreten können.

TPU kann nicht erstellt werden

Beim Erstellen einer Cloud TPU kann der folgende Fehler auftreten:

googleapiclient.errors.HttpError: < HttpError 403 when requesting https://content-tpu.googleapis.com/v1/projects/{PROJECT}/locations/{ZONE}/nodes/{TPU_NAME}?alt=json returned "Request had insufficient authentication scopes."

Dies ist ein Berechtigungsproblem, das durch Ausführen des folgenden Befehls behoben werden kann:

gcloud auth login --update-adc

Mit diesem Befehl werden Ihre Standardanmeldedaten für Anwendungen aktualisiert. Das Problem sollte dadurch behoben werden. Weitere Informationen finden Sie unter gcloud auth login.

Dynamische Formen werden nicht unterstützt

Fehlermeldung

ValueError: shape [Shape] must have a fixed size for dimension
d that is known at graph construction time.

Betroffene Frameworks und Konfigurationen

Diese Meldung wird nur während der XLA-Kompilierung mit TensorFlow angezeigt.

Details

Um ein Modell auf der TPU auszuführen, kompiliert Cloud TPU das Modell mit dem XLA-Compiler. Dieser Kompilierungsschritt verbessert die Trainingsgeschwindigkeit und die Arbeitsspeichernutzung signifikant; die Formen (Dimensionsgrößen) aller Tensoren im Graphen müssen beim Kompilieren des Graphen jedoch bekannt sein. Wenn Formen beim Kompilieren nicht erkannt werden können, schlägt die TPU-Kompilierung mit einem Fehler wie dem obigen fehl.

Ein gängiger Vorgang, die eine dynamische Form zurückgibt, ist dataset.batch(batch_size), da die Anzahl der in einem Stream verbleibenden Stichproben möglicherweise geringer ist als die Batchgröße. Legen Sie daher beim Training auf der TPU drop remainder=True für dataset.batch fest. Dadurch werden möglicherweise die letzten Stichproben aus einer Datei gelöscht, damit jeder Batch die statische Form „batch_size“ aufweist. Beispiel:

dataset = tf.data.Dataset.range(8)
dataset = dataset.batch(3, drop_remainder=True)

Nicht verfügbare TensorFlow-Operation

Fehlermeldung

NotFoundError: No registered 'OpName' OpKernel for XLA_TPU_JIT
devices compatible with node

Betroffene Frameworks und Konfigurationen

Diese Meldung kann beim Training mit TensorFlow auftreten.

Details

Das Modell verwendet einen TensorFlow-Vorgang, der nicht auf der TPU verfügbar ist.

Eine Liste der auf der TPU verfügbaren Vorgänge sowie Pläne für zukünftige Unterstützung und Vorschläge für Workarounds finden Sie in der Anleitung zu verfügbaren TensorFlow-Vorgängen.

Fehlermeldung aufgrund von fehlendem Speicherplatz

Fehlermeldung

ResourceExhaustedError: Ran out of memory in memory space hbm; used:
YYY; limit: 7.48G.

Betroffene Frameworks und Konfigurationen

Diese Meldung kann beim Training mit TensorFlow, PyTorch oder JAX auftreten.

Details

Jede Cloud TPU besteht aus acht TPU-Kernen. v2-TPUs haben 8 GB und v3-TPUs haben 16 GB RAM (oder HBM, High-Bandwidth Memory). Dieser Speicher dient zum Speichern der Gewichtungs-Tensoren (Variable) sowie der Zwischenergebnis-Tensoren, die für die Gradientenberechnung benötigt werden. Wenn das Modell für den TPU-RAM zu groß ist, schlägt die Initialisierung fehl und die Fehlermeldung wird ausgegeben. Weitere Informationen finden Sie unter Arbeitsspeichernutzung reduzieren.

Tipps zur Reduzierung der Arbeitsspeichernutzung:

Probleme beim Beenden der Ausführung

Wenn TensorFlow während der TPU-Ausführung einen Fehler feststellt, reagiert das Script manchmal nicht mehr, statt zur Shell zurückzukehren. Drücken Sie in diesem Fall die Tastenkombination CTRL+C auf der Tastatur, um einen SIGQUIT auszulösen, wodurch Python sofort beendet wird.

Entsprechend wird TensorFlow mit der Tastenkombination CTRL+C während der TPU-Ausführung nicht sofort heruntergefahren, sondern erst nach dem Ende der aktuellen Iterationsschleife ordnungsgemäß beendet.

Falls bei einem neuen Verbindungsaufbau zur TPU nach einer solchen Beendigung neue Fehler auftreten, setzen Sie den TPU-Server mit den folgenden Befehlen manuell zurück: 

gcloud compute tpus tpu-vm stop tpu-name --zone=zone
gcloud compute tpus tpu-vm start tpu-name --zone=zone

Dabei ist tpu-name der Wert aus der ersten Spalte, die durch den Befehl gcloud compute tpus tpu-vm list angezeigt wird, und zone die Zone aus der zweiten Spalte.

Übermäßiges Padding von Tensoren

Mögliche Ursache des Speicherproblems

Tensoren im TPU-Speicher werden mit Leerzeichen aufgefüllt, d. h. die TPU rundet die Größen von Tensoren ab, die im Speicher abgelegt sind, damit Berechnungen effizienter durchgeführt werden. Das Padding erfolgt auf transparente Weise auf der Hardwareebene und hat keine Auswirkungen auf die Ergebnisse. In bestimmten Fällen kann Padding jedoch zu einer deutlich erhöhten Speicherauslastung und Ausführungszeit führen.

So reduzieren Sie die Arbeitsspeichernutzung

Die TPU-Software versucht, Tensoren im Speicher auszulegen, um die Rechenleistung zu maximieren und das Padding zu minimieren. Dieser Speicher-Layout-Prozess ist jedoch komplex. Zur Erzielung optimaler Ergebnisse sollte das Modell nach folgender Faustregel ausgelegt werden. Wenn der Speicheraufwand minimiert und die Recheneffizienz maximiert werden soll, muss eine der folgenden Bedingungen zutreffen:

  • Die Gesamt-Batchgröße sollte ein Vielfaches von 64 sein (8 pro TPU-Kern). Die Feature-Dimensionen sollten ein Vielfaches von 128 sein.

    Oder

  • Die Gesamt-Batchgröße sollte ein Vielfaches von 1.024 (128 pro TPU-Kern) sein. Die Feature-Dimensionen sollten ein Vielfaches von 8 sein.

Die Verwendung einer Batchgröße von 1.024 und von Feature-Dimensionen, die ein Vielfaches von 128 sind, ermöglicht eine optimale Effizienz, obwohl dies unter Umständen nicht für alle Modelle möglich ist. Der Einfachheit halber bezieht sich "Feature-Dimension" auf die versteckte Größe einer vollständig verbundenen Ebene oder die Anzahl der Ausgabekanäle in einer Faltung. Nicht alle Ebenen können dieser Regel entsprechen. Dies gilt insbesondere für die erste und die letzte Ebene des Netzwerks. Das ist in Ordnung und die meisten Modelle erfordern voraussichtlich ein gewisses Maß an Padding.

Arbeitsspeichernutzung reduzieren

Wenn beim Ausführen Ihres Modells auf der TPU ein Fehler aufgrund fehlenden Speichers auftritt, müssen Sie Maßnahmen ergreifen, um die Arbeitsspeichernutzung des Modells zu reduzieren.

Dies sind die effektivsten Möglichkeiten, die Arbeitsspeichernutzung zu reduzieren:

  • Übermäßiges Padding von Tensoren reduzieren
  • Batchgröße reduzieren

Batchgröße oder Modell zu groß

Mögliche Ursache des Speicherproblems

Beim Trainieren eines neuronalen Netzwerks auf einer CPU, GPU oder TPU resultiert die Speichernutzung aus zwei Quellen:

  1. Die Arbeitsspeichernutzung ist proportional zur Anzahl der Gewichtungen im Modell.
  2. Speichern von Zwischenaktivierungen aus dem Vorwärtsdurchlauf, die für die Berechnung des Rückwärtsdurchlaufs erforderlich sind. Die Arbeitsspeichernutzung ist direkt proportional zur Batchgröße, zu den Ebenengrößen und zur Anzahl der Ebenen.

Daher hängt der von einem Modell benötigte Speicher weitgehend von der Batchgröße ab.

Der von einem Modell benötigte Arbeitsspeicher hängt von der Anzahl der Ebenen im Netzwerk ab.

Die TPU-Laufzeit versucht, Operatoren zu optimieren, um das Modell an den Arbeitsspeicher anzupassen (sogenannte Rematerialisierung, ähnlich der Gradienten-Prüfpunktausführung), dies ist jedoch nicht immer möglich.

So reduzieren Sie die Arbeitsspeichernutzung

Reduzieren Sie die Batchgröße langsam dem Speicher entsprechend und achten Sie darauf, dass die Gesamt-Batchgröße ein Vielfaches von 64 ist (die Batchgröße pro Kern sollte ein Vielfaches von 8 sein). Beachten Sie, dass größere Batches auf der TPU effizienter sind. Eine Gesamt-Batchgröße von 1.024 (128 pro Kern) ist im Allgemeinen ein guter Ausgangspunkt.

Wenn das Modell auch mit einer kleinen Batchgröße (z. B. 64) nicht auf der TPU ausgeführt werden kann, versuchen Sie, die Anzahl der Ebenen oder die Ebenengrößen zu reduzieren.

Verbesserung der Trainingsgeschwindigkeit

Wenn Ihr Modell erfolgreich auf der TPU ausgeführt werden kann, die Trainingsgeschwindigkeit jedoch geringer als erwartet ist, finden Sie in diesem Abschnitt eine Beschreibung der verschiedenen Möglichkeiten zur Verbesserung der Geschwindigkeit. Weitere Vorschläge zur Verbesserung der Trainingsleistung finden Sie im Leistungsleitfaden für Cloud TPU.

Zu wenige Schritte pro Ausführung pro Trainingsschleife

Beschreibung des Leistungsproblems

Wenn Sie das Argument steps_per_execution an Model.compile übergeben, wird gesteuert, wie viele Trainingsschritte zwischen Host-Callbacks ausgeführt werden. Jeder Host-Callback erfordert umfangreiche Kommunikation zwischen der Host-CPU des TPU-Servers und dem TPU-Gerät. Wenn steps_per_execution zu klein ist, kann das Training verlangsamt werden.

So finden Sie heraus, ob Ihr Modell betroffen ist

Wenn ein TPU-Profil häufige Host-CPU-Callbacks zwischen TPU-Geräteschritten zeigt, wäre ein größerer Wert für steps_per_execution für Ihr Training von Vorteil.

So leiten Sie Gegenmaßnahmen ein

Setzen Sie steps_per_execution auf einen höheren Wert. steps_per_execution kann auf einen hohen Wert gesetzt werden. Nachrichten können jedoch erst in Logs geschrieben und Prüfpunkte erst gespeichert werden, wenn die angegebene Anzahl von Schritten ausgeführt wurde.

Engpass bei der Eingabeverarbeitung

Beschreibung des Leistungsproblems

Während die TPU an einem bestimmten Datenblock trainiert, bereitet die Eingabeverarbeitungsfunktion den nächsten Datenblock auf der CPU vor. Wenn Ihre Eingabefunktion länger als die Modellfunktion dauert, bleibt die TPU im Leerlauf, während Ihre Eingabefunktion Daten abruft.

So finden Sie heraus, ob Ihr Modell betroffen ist

Folgen Sie der Anleitung unter Cloud TPU Tools: Input Pipeline Analyzer, um die Analyse der Eingabe-Pipeline in TensorBoard aufzurufen:

Bild

Die Seite für die Analyse der Eingabe-Pipeline zeigt eine übersichtliche Zusammenfassung an, der zu entnehmen ist, ob die Eingabeverarbeitung bei Ihrem Modell einen Engpass verursacht hat. Auf derselben Seite wird auch die Ausführungszeit pro Vorgang angezeigt, sodass Sie problematische Vorgänge finden können.

So leiten Sie Gegenmaßnahmen ein

Beim Laden von Daten mit der Dataset API gibt es mehrere mögliche Maßnahmen:

  1. Speichern Sie die Daten als Sammlung von tf.train.Example-Strukturen in TFRecord-Dateien und laden Sie sie mit TFRecordDataset. Beispiele finden Sie in der Dataset API-Anleitung und der ResNet-Anleitung.
  2. Verwenden Sie zum Zwischenspeichern der Eingabedaten dataset.cache() oder dataset.prefetch(). Dadurch wird verhindert, dass sporadische Verlangsamungen beim Dateizugriff zu Engpässen führen.
  3. Legen Sie den Parameter num_parallel_calls der Funktion dataset.map() fest, um Multithread-Vorgänge vom Typ map() zu aktivieren. Eine Heuristik für den Wert von num_parallel_calls ist die Anzahl der verfügbaren CPU-Kerne.
  4. Führen Sie die teure Datenvorverarbeitung offline durch, sodass dafür nur einmal Kosten anfallen und nicht in jeder Epoche jedes Trainings.

Die gesamte Eingabeverarbeitung erfolgt auf CPUs, die sich auf dem TPU-Server befinden, nicht auf dem lokalen Computer. Daher spielt die Geschwindigkeit des lokalen Computers keine Rolle.

Lange Schrittzeiten und geringe MXU-Auslastung

Beschreibung des Leistungsproblems

Die Cloud TPU kann Matrixmultiplikationen und -faltungen bei unglaublich hohen Geschwindigkeiten ausführen. Die meisten anderen TensorFlow-Operationen haben effiziente Implementierungen auf der TPU, diese sind im Verhältnis zu anderer Hardware jedoch nicht deren primäre Stärke. Daher sollte ein Modell von den Matrixmultiplikationen oder -faltungen dominiert werden, um die TPU optimal nutzen zu können.

So finden Sie heraus, ob Ihr Modell betroffen ist

In diesem Fall sind die Symptome langsame Schrittzeiten in Verbindung mit einer geringen MXU-Auslastung, die ersichtlich werden, wenn Sie ein Leistungsprofil erfassen.

So leiten Sie Gegenmaßnahmen ein

Versuchen Sie, die Anzahl der Vorgänge zu reduzieren, die keine Matrixmultiplikationen sind. Wenn Sie die Anzahl der Matrixmultiplikationen reduziert haben, messen Sie die Leistung erneut, um zu sehen, ob sie auf TPUs akzeptabel ist.

Übermäßiges Padding von Tensoren

Beschreibung des Leistungsproblems

Die TPU füllt Tensoren im Speicher auf, sodass die TPU ihre Recheneinheiten effizient nutzen kann. Durch Padding kann die Nutzung des Speichers und auch der Speicherbandbreite gesteigert werden. Weitere Informationen zu Problemen beim Padding von Tensoren und zu deren Behebung finden Sie im Abschnitt Padding von Tensoren.

Langsamer Durchsatz und geringe Arbeitsspeichernutzung

Beschreibung des Leistungsproblems

In der Regel führt die Verwendung größerer Batchgrößen im Hinblick auf Stichproben/Sekunde zu einer höheren Trainingsgeschwindigkeit auf der TPU.

So finden Sie heraus, ob Ihr Modell betroffen ist

Die Batchgröße jedes Modells sollte immer mindestens 64 betragen (8 pro TPU-Kern), da die TPU die Tensoren immer entsprechend der Größe auffüllt. Die ideale Batchgröße beim Training auf der TPU ist 1.024 (128 pro TPU-Kern), da hierdurch Ineffizienzen in Bezug auf die Speicherübertragung und das Padding beseitigt werden.

So leiten Sie Gegenmaßnahmen ein

Es wird empfohlen, die größte Batchgröße zu verwenden, die in den Arbeitsspeicher passt und ein Vielfaches von 64 ist. Der einfachste Weg, dies zu erreichen, besteht darin, mit 1.024 zu beginnen. Wenn dies zu einem Fehler aufgrund fehlenden Speichers führt, versuchen Sie, die Batchgröße zu reduzieren, bis das Modell erfolgreich ausgeführt wird. Wenn Sie die Batchgröße eines Modells ändern, müssen Sie möglicherweise andere Hyperparameter anpassen, um die gleiche Accuracy des Modells wie die Lernrate zu erreichen. Dies muss jedoch von Fall zu Fall überprüft werden.

Ebenengrößen zu klein

Beschreibung des Leistungsproblems

Selbst wenn ein Modell von Matrixmultiplikationen oder -faltungen dominiert wird, läuft die TPU möglicherweise nicht mit voller Effizienz, wenn die Eingangstensoren klein sind. Im Vergleich zu anderer Hardware wird die TPU am effizientesten ausgeführt, wenn die Batchgröße und die Ebenengröße größer sind (z. B. Dimension >= 512).

So finden Sie heraus, ob Ihr Modell betroffen ist

Als allgemeine Regel gilt, dass Ebenengrößen unter 128 eine schlechte Effizienz auf der TPU erreichen, da 128 die integrierte Dimension der TPU-Matrixmultiplikationseinheit ist. Für vollständig verbundene Ebenen wird zur Erzielung einer hohen Effizienz eine minimale versteckte Größe von 512 empfohlen. Beachten Sie, dass Faltungsebenen in der Regel nicht so groß wie vollständig verbundene Ebenen sein müssen, um das gleiche Effizienzniveau zu erreichen.

So leiten Sie Gegenmaßnahmen ein

Wenn die Hauptmotivation für geringe Ebenengrößen in Ihrem Modell die Trainingsgeschwindigkeit ist, messen Sie die Leistung Ihrer Modelle mit größeren Ebenen auf der TPU neu. Wenn Sie beispielsweise die Ausgabegröße einer Ebene von 256 auf 512 erhöhen, erhöht sich die Trainingszeit möglicherweise nur um 20 %, obwohl das Modell die doppelte Anzahl an Berechnungen durchführt.

Modellprofilierung auf Operationsebene

Häufig ist es hilfreich, die Ausführungszeit und Speichernutzung auf der Operationsebene zu messen, um Leistungsengpässe zu identifizieren. Weitere Informationen dazu finden Sie in der Anleitung
Cloud TPU-Tools: Trace Viewer.

Debugging verringert die Accuracy des Modells

Eines der Ziele der Cloud TPU-Umgebung ist, dass jedes Modell, das gerade auf einer CPU oder GPU trainiert wird, eine sehr ähnliche Accuracy erreicht, wenn es auf der TPU trainiert wird. Dafür sollten höchstens geringfügige Anpassungen der Hyperparameter, wie Batchgröße und Lernrate, erforderlich sein. Gelegentlich können Nutzer jedoch eine Verschlechterung der Accuracy beobachten, wenn sie Modelle auf der TPU trainieren. Die Behebung solcher Probleme kann aufgrund der zufälligen Art des neuronalen Netzwerktrainings extrem frustrierend sein. In diesem Abschnitt wird erläutert, wie Sie die Ursache für die Verringerung der Modellgenauigkeit bei der Portierung eines Modells auf die TPU ermitteln können.

Informationen zur Datenfragmentierung (Datenparallelität)

Eines der Hauptziele von TensorFlow besteht darin, dass jeder Vorgang nahezu identische Ergebnisse liefert, unabhängig davon, ob er auf der CPU, GPU oder TPU ausgeführt wird. Hiervon gibt es bestimmte Ausnahmen, z. B. zufällige Vorgänge. Wenn Sie einen signifikanten Unterschied zwischen der Ausgabe nicht zufälliger Operationen auf der TPU und der CPU feststellen, melden Sie dies als Programmfehler.

Für die Trainingspipeline insgesamt besteht jedoch ein deutlicher Unterschied zwischen dem Training auf der CPU/GPU und der TPU. Beim Training auf einer TPU führt TensorFlow eine Datenfragmentierung durch. Jede Cloud TPU enthält 8 TPU-Kerne, die als unabhängige Verarbeitungseinheiten fungieren. Daher wird für jeden Trainingsschritt ein Datenbatch an jeden TPU-Kern gesendet, die Gewichtungsgradienten werden berechnet und die Gradienten mit den anderen TPU-Kernen ausgetauscht. Anschließend wird eine Aktualisierung der Gewichtungen berechnet. Standardmäßig wird der Verlust über die Kerne gemittelt, er kann aber auch summiert werden, indem der Parameter CrossShardOptimizer geändert wird.

Wenn der Gesamtverlust des Modells als der Durchschnitt (oder die Summe) der unabhängigen Verluste pro Stichprobe berechnet werden kann, entspricht dieses Verfahren mathematisch dem Training für einen einzelnen großen Batch.

Der gängigste Vorgang, der nicht für jede Stichprobe unabhängig durchgeführt wird, ist die Batchnormalisierung. Sie wird für jeden Batch pro Kern separat durchgeführt. Wenn die Gesamt-Batchgröße beispielsweise 128 ist, beträgt die Batchgröße pro Kern 16 und jeder der 8 Kerne führt die Batchnormalisierung für die eigenen 16 Stichproben aus. In einigen Fällen ist durch eine Batchnormalisierung bei kleineren Batches (z. B. weniger als 32) eine Verschlechterung der Accuracy zu beobachten. Im Idealfall sollte die Gesamt-Batchgröße groß sein (z. B. 256 bis 1.024). Wenn eine solche Batchgröße jedoch zu groß für den Arbeitsspeicher ist, müssen die Auswirkungen der Fragmentierung von Fall zu Fall bewertet werden.

Fehlerbehebung beim Mehrkern-TPU-Training

Wenn Ihr Modell den gleichen Verlust auf der CPU und der Einzelkern-TPU erreicht, liegt möglicherweise eines der folgenden Probleme vor:

(a) Die Verschlechterung ist auf die natürliche zufällige Varianz zurückzuführen, wenn neuronale Modelle mit unterschiedlichen Initialisierungen trainiert werden.

(b) Die Verschlechterung ist auf ein Problem bei der Datenfragmentierung auf der TPU zurückzuführen.

Um festzustellen, ob Problem (a) zutrifft, trainieren Sie das vollständige Modell auf der CPU/GPU und der Mehrkern-TPU mit der gleichen Gewichtungsinitialisierung erneut.

Wenn Sie sicher sind, dass der Abfall der Accuracy statistisch signifikant ist, handelt es sich bei den Problemen im Zusammenhang mit der Datenfragmentierung mit hoher Wahrscheinlichkeit um die Folgenden:

  1. Wenn das Modell Batchnormalisierung verwendet, kann eine Gesamt-Batchgröße von weniger als 256 (z. B. weniger als 32 pro Kern) die Accuracy verringern.
  2. Die Fragmentierung hat Auswirkungen auf Verlustfunktionen pro Batch. Solche Verlustfunktionen sind in der Regel ziemlich speziell. Karras et al. 2017 verwenden beim Trainieren eines generativen kontradiktorischen Netzwerks (Generative Adversarial Network, GAN) beispielsweise einen Batchdiskriminator.

gcloud-Fehlerbehebung bei der Einrichtung

Problem
gcloud components update zeigt die folgende Fehlermeldung an:
ERROR: (gcloud.components.update)
You cannot perform this action because the Cloud SDK component manager is
disabled for this installation.
Lösung

Wenn Sie die Google Cloud CLI verwenden möchten, benötigen Sie eine Installation, die nicht durch einen Paketmanager verwaltet wird.

  1. Führen Sie den folgenden Befehl aus, um die aktuelle gcloud CLI-Installation zu entfernen:

    sudo apt-get remove google-cloud-sdk

  2. Folgen Sie der Anleitung unter Google Cloud CLI installieren.

Problem

Der Befehl gcloud compute tpus tpu-vm ssh TPU_NAME --zone ZONE ergibt die folgende Fehlermeldung:

Waiting for SSH key to propagate.
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ERROR: (gcloud.compute.tpus.tpu-vm.ssh) Could not SSH into the instance.  It is possible that your SSH key has not propagated to the instance yet. Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.
Lösung

Möglicherweise liegt ein Problem mit der SSH-Schlüsselverteilung vor. Verschieben Sie zur Fehlerbehebung die automatisch generierten Schlüssel an einen Sicherungsspeicherort, damit gcloud sie neu erstellt:

mv ~/.ssh/google_compute_engine ~/.ssh/old-google_compute_engine
mv ~/.ssh/google_compute_engine.pub ~/.ssh/old-google_compute_engine.pub

Debugging-Logs

Die unterstützten Cloud TPU-Frameworks JAX, PyTorch und TensorFlow greifen auf TPUs über eine gemeinsam genutzte Bibliothek namens libtpu zu, die auf jeder TPU-VM vorhanden ist. Diese Bibliothek enthält den XLA-Compiler, der zum Kompilieren von TPU-Programmen verwendet wird, die TPU-Laufzeit, die zum Ausführen kompilierter Programme verwendet wird, und den von der Laufzeit verwendeten TPU-Treiber für den allgemeinen Zugriff auf die TPU.

In der Bibliothek libtpu werden Informationen protokolliert, die für das Debugging nützlich sein können. Standardmäßig werden diese Logs auf jeder Cloud TPU-VM in /tmp/tpu_logs geschrieben. Die folgenden Umgebungsvariablen können vor dem Training festgelegt werden, um das Loggingverhalten zu ändern:

TPU_LOG_DIR: Verzeichnis, in das Logs geschrieben werden.
Das Standardverzeichnis ist /tmp/tpu_logs. Das Verzeichnis wird erstellt, wenn es noch nicht vorhanden ist. Übergeordnete Verzeichnisse werden jedoch nicht erstellt. Wenn beim Suchen oder Erstellen des angegebenen Verzeichnisses ein Fehler auftritt, wird eine Meldung in stderr ausgegeben, das Programm wird jedoch nicht beendet und das Logging wird deaktiviert. Setzen Sie den Verzeichnisnamen auf „disabled“, um das Schreiben von Logs auf das Laufwerk vollständig zu deaktivieren.
TPU_MIN_LOG_LEVEL: Mindestschweregrad zur Aufnahme in das Log, das auf das Laufwerk geschrieben wird.
Die Optionen sind 0 (INFO), 1 (WARNING), 2 (ERROR) und 3 (FATAL). Der Standardwert ist 0.
TPU_STDERR_LOG_LEVEL: Mindestschweregrad zur Aufnahme in stderr zusätzlich zum Log, das auf das Laufwerk geschrieben wird, falls zutreffend.
Die Optionen sind dieselben wie für TPU_MIN_LOG_LEVEL. Der Standardwert ist 3.
TPU_MAX_LOG_SIZE_MB: Maximale Größe jeder Logdatei in Megabyte.
Eine neue Logdatei wird automatisch gestartet, wenn die vorherige Datei ungefähr diese Größe erreicht. Der Standardwert ist 1.024.