Fehlerbehebung bei TensorFlow – TPU
Dieser Leitfaden und die häufig gestellten Fragen enthalten Informationen zur Fehlerbehebung für Nutzer, die TensorFlow-Modelle auf Cloud TPU trainieren. Wenn Sie Probleme mit dem Training mit PyTorch oder JAX beheben möchten, lesen Sie die entsprechenden Dokumente zur Fehlerbehebung:
Allgemeinere Anleitungen zur Verwendung von Cloud TPU finden Sie unter:
Übersicht
Häufige Probleme, die bei Cloud TPUs auftreten, fallen in die folgenden Kategorien:
Fehler beim Herstellen einer Verbindung zum TPU-Server
In diesem Abschnitt wird beschrieben, wie Sie Probleme beheben, wenn TensorFlow beim Herstellen einer Verbindung zur TPU keine Antwort mehr gibt oder einen Fehler ausgibt. Beachten Sie, dass der Schritt zur Kompilierung des TPU-Graphen bei großen Modellen sehr lange dauern kann. Das Skript sollte daher mindestens 5 Minuten lang ausgeführt werden, um zu ermitteln, ob wirklich keine Antworten mehr erfolgen.
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 Verbindungsprobleme auftreten, liegt ein Problem mit dem TPU-Server vor. In diesem Fall gilt:
Führen Sie den folgenden Befehl aus, um die verfügbaren TPUs aufzulisten. Ersetzen Sie zone und project-id durch Ihre Zonen- 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
Prüfen Sie, ob diese TPU als
READY
aufgeführt ist.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
Dies kann einige Minuten dauern.
Führen Sie den Befehl
gcloud compute tpus tpu-vm list
noch einmal aus und warten Sie, bis sich die TPU im ZustandREADY
befindet. Dieser Vorgang kann einige Minuten dauern.Versuchen Sie noch einmal, das Programm auszuführen.
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, ist dies wahrscheinlich auf Ihre Trainingspipeline zurückzuführen.
Ersetzen Sie dazu zuerst die TPUStrategy in Ihrem Code durch die Standardstrategie. Wenn Sie die Standardstrategie verwenden, wird das Modell an allen Stellen, an denen Sie strategy.scope()
oder strategy.run()
verwenden, auf der CPU (oder GPU, falls vorhanden) und nicht auf der TPU ausgeführt. Wenn das Modell auf der CPU und nicht auf der TPU ausgeführt wird, muss es sich um ein TPU-spezifisches Problem handeln. Wenn das Problem weiterhin besteht, empfiehlt es sich, das Problem auf der CPU zu beheben.
Unterbrechung der ssh
-Verbindung während des Trainings
Bei einem langwierigen Training kann es zu einer Zeitüberschreitung bei der ssh
-Verbindung zur Cloud TPU kommen, insbesondere wenn Sie Cloud Shell verwenden.
In diesem Fall wird in der TPU-Konsole keine Ausgabe angezeigt und es sieht so aus, als hätte die TPU das Training beendet. Führen Sie die Trainingssitzung daher mit einem Terminal-Multiplexer oder einem Sitzungsverwaltungstool wie tmux
oder screen
aus. Dadurch bleibt die ssh
-Verbindung unabhängig von der Dauer des Trainings aktiv.
Behebung von allgemeinen Fehlern
In diesem Abschnitt erfahren Sie, wie Sie häufige Fehler beheben, die beim Trainieren von Modellen in Cloud TPU auftreten können.
TPU kann nicht erstellt werden
Beim Erstellen einer Cloud TPU wird möglicherweise der folgende Fehler angezeigt:
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 sich mit dem folgenden Befehl beheben lässt:
gcloud auth login --update-adc
Mit diesem Befehl werden Ihre Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) aktualisiert und das Problem sollte 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. Während dieser Kompilierungsschritt die Trainingsgeschwindigkeit und die Speichernutzung signifikant verbessert, müssen die Formen (Dimensionsgrößen) aller Tensoren im Graphen beim Kompilieren des Graphen bekannt sein. Wenn beim Kompilieren keine Formen erkannt werden können, schlägt die TPU-Kompilierung mit einem Fehler wie dem oben gezeigten fehl.
Ein gängiges Verfahren, das 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. Verwenden Sie daher beim Training auf der TPU drop remainder=True
für dataset.batch
.
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 eine TensorFlow-Operation, die auf der TPU nicht verfügbar ist.
Eine Liste der auf der TPU verfügbaren Operationen sowie Pläne für zukünftige Unterstützung und Vorschläge für Workarounds finden Sie in der Anleitung zu verfügbaren TensorFlow-Operationen.
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. TPUs der Version 2 haben 8 GB und TPUs der Version 3 16 GB RAM (oder HBM, High-Bandwidth Memory). Dieser Speicher dient zum Speichern der Gewichtungssensoren (Variable) sowie der Zwischenergebnistensoren, 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:
- Prüfen Sie, ob zu viel Padding für Tensoren verwendet wird.
- Verwenden Sie das Format bfloat16.
- Wenn die Eingabegrößen oder das Modell zu groß sind, können Sie den experimentellen Modellparallelismus von TensorFlow verwenden, um das Problem zu beheben.
Probleme beim Beenden der Ausführung
Wenn TensorFlow während der TPU-Ausführung einen Fehler feststellt, scheint das Skript manchmal hängen zu bleiben, anstatt die Operation zu beenden und 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 mit der Tastenkombination CTRL+C
während der TPU-Ausführung TensorFlow nicht sofort heruntergefahren, sondern bis zum Ende der aktuellen Iterationsschleife gewartet, um die Operation ordnungsgemäß zu beenden.
Falls bei einem neuen Verbindungsaufbau zum TPU-Server 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 ist die Zone, die in der zweiten Spalte angezeigt wird.
Ü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.
Die effektivsten Möglichkeiten zur Reduzierung der Arbeitsspeichernutzung sind:
- Ü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 hat die Speichernutzung zwei Ursachen:
- Die Arbeitsspeichernutzung ist proportional zur Anzahl der Gewichtungen im Modell.
- 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 Schichten im Netzwerk ab.
Die TPU-Laufzeit versucht, Operatoren zu optimieren, um das Modell an den Arbeitsspeicher anzupassen (sogenannte Rematerialisierung, ähnlich wie die Gradienten-Prüfpunktausführung), dies ist jedoch nicht immer möglich.
So reduzieren Sie die Arbeitsspeichernutzung
Reduzieren Sie die Batchgröße langsam, bis sie in den Arbeitsspeicher passt. Die Gesamt-Batchgröße sollte ein Vielfaches von 64 sein (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 Leistungssteigerung bei Trainings finden Sie im Leitfaden zum Thema Leistung.
Zu wenige Schritte pro Ausführung pro Trainingsschleife
Beschreibung des Leistungsproblems
Mit dem Argument steps_per_execution
an Model.compile
wird festgelegt, wie viele Trainingsschritte zwischen den Host-Callbacks ausgeführt werden.
Jeder Host-Callback erfordert umfangreiche Kommunikation zwischen der Host-CPU des TPU-Servers und dem TPU-Gerät. Wenn also steps_per_execution
zu klein ist, kann das Training verlangsamt werden.
So ermitteln Sie, ob Ihr Modell betroffen ist
Wenn ein TPU-Profil häufige Host-CPU-Callbacks zwischen TPU-Geräteschritten aufweist, kann Ihr Training von einem größeren steps_per_execution
-Wert profitieren.
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. Das Logging von Nachrichten und das Speichern eines Checkpoints ist jedoch erst möglich, nachdem 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 inaktiv, während Ihre Eingabefunktion Daten abruft.
So ermitteln Sie, 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:
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 Operation angezeigt, sodass Sie problematische Operationen ermitteln können.
So leiten Sie Gegenmaßnahmen ein
Beim Laden von Daten mit der Dataset
API gibt es mehrere mögliche Maßnahmen:
- Speichern Sie die Daten als Sammlung von
tf.train.Example
-Strukturen inTFRecord
-Dateien und laden Sie sie mitTFRecordDataset
. Beispiele finden Sie in der Dataset API-Anleitung und der ResNet-Anleitung. - Verwenden Sie
dataset.cache()
oderdataset.prefetch()
, um die Eingabedaten zu puffern. Dadurch wird verhindert, dass sporadische Verlangsamungen beim Dateizugriff zu Engpässen führen. - Legen Sie den Parameter
num_parallel_calls
der Funktiondataset.map()
fest, um Multithread-Vorgänge vom Typmap()
zu aktivieren. Als Heuristik für den Wert vonnum_parallel_calls
kann die Anzahl der verfügbaren CPU-Kerne verwendet werden. - 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 etwa 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 ermitteln Sie, ob Ihr Modell betroffen ist
Die Symptome in diesem Fall sind lange Schrittzeiten in Verbindung mit einer niedrigen MXU-Auslastung, die beim Profilieren der Leistung angezeigt werden.
So leiten Sie Gegenmaßnahmen ein
Versuchen Sie, die Anzahl der Operationen zu reduzieren, die keine Matrixmultiplikationen sind. Nachdem Sie die Anzahl der Matrixmultiplikationen reduziert haben, führen Sie einen weiteren Benchmark durch, um zu sehen, ob die Leistung 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.
Niedrige Durchlaufleistung und geringe Speichernutzung
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 ermitteln Sie, 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 Speicher 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 Modellgenauigkeit 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 ermitteln Sie, ob Ihr Modell betroffen ist
Als allgemeine Regel gilt, dass Ebenengrößen kleiner als 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 ein gleiches Effizienzniveau zu erreichen.
So leiten Sie Gegenmaßnahmen ein
Wenn die primäre Motivation für kleine Schichtgrößen in Ihrem Modell die Trainingsgeschwindigkeit ist, sollten Sie die Leistung Ihrer Modelle mit größeren Schichten auf der TPU noch einmal messen. Wenn Sie beispielsweise die Ausgabegröße einer Schicht von 256 auf 512 erhöhen, erhöht sich die Trainingszeit möglicherweise nur um 20 %, obwohl das Modell doppelt so viele Berechnungen ausfü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 verwenden: Trace Viewer.
Debugging verringert die Modellgenauigkeit
Eines der Ziele der Cloud TPU-Umgebung ist, dass jedes Modell, das auf einer CPU oder GPU trainiert wird, eine sehr ähnliche Accuracy erreicht, wenn es auf der TPU trainiert wird, und zwar mit möglicherweise geringeren Anpassungen an Hyperparametern wie Batchgröße und Lernrate. 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 separate TPU-Kerne, die als unabhängige Verarbeitungseinheiten fungieren. Daher erhält jeder TPU-Kern für jeden Trainingsschritt ein Datenbatch, die Gewichtungsgradienten werden berechnet, die Gradienten werden mit den anderen TPU-Kernen ausgetauscht und anschließend wird die Gewichtungsaktualisierung 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.
Die gängigste nicht unabhängige Operation pro Stichprobe ist die Batchnormalisierung, die jeden Pro-Kern-Batch getrennt durchläuft. Wenn der Batch eine Gesamtgröße von beispielsweise 128 aufweist, 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 hat die Durchführung der Batchnormalisierung für kleine Batches (z. B. weniger als 32) zu einer Verschlechterung der Genauigkeit geführt. Im Idealfall sollte die Gesamt-Batchgröße groß sein (z. B. 256 bis 1.024). Wenn eine solche Batchgröße zu groß ist, um in den Speicher zu passen, muss der Fragmentierungseffekt 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, wie oben beschrieben erneut.
Wenn Sie sicher sind, dass der Genauigkeitsabfall statistisch signifikant ist, handelt es sich bei den Problemen im Zusammenhang mit der Datenfragmentierung mit hoher Wahrscheinlichkeit um die Folgenden:
- Wenn das Modell Batchnormalisierung verwendet, kann eine Gesamt-Batchgröße von weniger als 256 (z. B. weniger als 32 pro Kern) die Accuracy verringern.
- Wenn eine Verlustfunktionen pro Batch sind sie von der Fragmentierung betroffen. Solche Verlustfunktionen sind in der Regel ziemlich speziell. Beispiel: Karras et al. 2017 verwendet beim Trainieren eines generativen kontradiktorischen Netzwerks (GAN, Generative Adversarial Network) 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, ist dazu eine Installation erforderlich, die nicht über einen Paketmanager verwaltet wird.
Führen Sie den folgenden Befehl aus, um die aktuelle gcloud CLI-Installation zu entfernen:
sudo apt-get remove google-cloud-sdk
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
Debug-Logs
Die unterstützten Cloud TPU-Frameworks JAX, PyTorch und TensorFlow greifen über eine freigegebene Bibliothek namens libtpu
auf TPUs 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 untergeordneten Zugriff auf die TPU.
Die libtpu
-Bibliothek protokolliert Informationen, die für die Fehlerbehebung nützlich sein können.
Standardmäßig werden diese Protokolle auf jeder Cloud TPU-VM in /tmp/tpu_logs
geschrieben.
Die folgenden Umgebungsvariablen können vor Beginn des Trainings festgelegt werden, um das Logging-Verhalten zu ändern:
- TPU_LOG_DIR: das Verzeichnis, in das Protokolle geschrieben werden
- Der Standardspeicherort des Verzeichnisses ist
/tmp/tpu_logs
. Das Verzeichnis wird erstellt, falls es noch nicht vorhanden ist. Es werden jedoch keine übergeordneten Verzeichnisse erstellt. Wenn beim Suchen oder Erstellen des angegebenen Verzeichnisses ein Fehler auftritt, wird eine Meldung in stderr ausgegeben. Das Programm wird dadurch jedoch nicht angehalten und die Protokollierung wird deaktiviert. Legen Sie den Namen des Verzeichnisses auf „deaktiviert“ fest, um das Logging auf dem Laufwerk vollständig zu deaktivieren. - TPU_MIN_LOG_LEVEL: der Mindestschweregrad, der auf die Festplatte protokolliert wird
- Als Optionen sind 0 (INFO), 1 (WARNUNG), 2 (FEHLER) und 3 (FATAL) verfügbar. Der Standardwert ist 0.
- TPU_STDERR_LOG_LEVEL: Mindestschwere, die zusätzlich zum Laufwerk in stderr protokolliert wird (falls zutreffend)
- Die Auswahlmöglichkeiten sind dieselben wie bei TPU_MIN_LOG_LEVEL. Der Standardwert ist 3.
- TPU_MAX_LOG_SIZE_MB: die maximale Größe in Megabyte der einzelnen Protokolldateien
- Wenn die vorherige Logdatei ungefähr diese Größe erreicht, wird automatisch eine neue Logdatei gestartet. Der Standardwert ist 1.024.