Fehlerbehebung bei TensorFlow – TPU
In diesem Leitfaden und den häufig gestellten Fragen finden Sie bietet Hilfe bei der Fehlerbehebung für Schulungsteilnehmer TensorFlow-Modelle in Cloud TPU Für die Fehlerbehebung PyTorch oder JAX-Training haben, können Sie in den Dokumenten zur Fehlerbehebung dieser Frameworks:
Allgemeine Anleitungen zur Verwendung von Cloud TPU finden Sie unter:
- Cloud TPU-Kurzanleitungen
- MNIST-Tutorial
- ML-Modelle auf Cloud Tensor Processing Units (TPUs) trainieren
Ü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 in denen TensorFlow nicht mehr reagiert oder einen Fehler ausgibt, wird verbunden auf die TPU übertragen. Der Schritt zur Kompilierung des TPU-Graphen kann bei großen Datenmengen sehr lange dauern. Lassen Sie das Skript daher mindestens 5 Minuten lang reagiert er nicht mehr.
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 den Befehl MNIST-Tutorial mithilfe der TPU-Server-URL und überprüfen Sie, ob er ordnungsgemäß funktioniert. Wenn weiterhin Probleme beim Herstellen der Verbindung mit der MNIST-Anleitung bestehen, bestätigt dies, dass ein Problem beim TPU-Server vorliegt. In diesem Fall gilt:
Führen Sie den folgenden Befehl aus, um die verfügbaren TPUs aufzulisten. zone wird ersetzt 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 demo-tpu us-central1-b v2-8 10.240.1.2:8470 default 10.240.1.0 READY
Prüfen Sie, ob Sie den richtigen Wert an
--tpu
(demo-tpu
in Beispiel oben) und dass diese TPU alsREADY
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_SERVER_NAME && gcloud compute tpus tpu-vm start $TPU_SERVER_NAME
Im vorherigen Beispiel ist
$TPU_SERVER_NAME
demo-tpu
. Dies kann bis zu mehrere Minuten dauern.Führen Sie den Befehl
... tpus list
noch einmal aus und warten Sie, bis sich die TPU imREADY
. Dieser Vorgang kann einige Minuten dauern.Versuchen Sie, die MNIST-Anleitung noch einmal auszuführen.
Wenn Sie weiterhin Probleme beim Ausführen der MNIST-Anleitung haben, können Sie über einen der unter Support beschriebenen Wege Unterstützung anfordern.
Wenn das MNIST-Beispiel korrekt ausgeführt wird, Ihr Modell aber immer noch nicht mehr reagiert,
ist das Problem wahrscheinlich auf Ihre Trainingspipeline zurückzuführen.
Ersetzen Sie zur Fehlerbehebung zuerst die TPUStrategy in Ihrem Code durch die
Standardstrategie. Wenn Sie die Standardstrategie verwenden, unabhängig davon, wo Sie sie verwenden
strategy.scope()
oder strategy.run()
, das Modell wird ausgeführt
auf CPU (oder GPU, falls vorhanden)
auf der TPU. Wenn das Modell auf der CPU und nicht auf einer TPU ausgeführt wird, muss ein
TPU-spezifisches Problem. Wird sie immer noch nicht ausgeführt, empfehlen wir, das Debugging
Problem mit der CPU.
Verlust der ssh
-Verbindung während des Trainings
Ihre ssh
-Verbindung zur Cloud TPU kann während
einem lang andauernden Training (insbesondere, wenn Sie Cloud Shell verwenden).
Dann erfolgt keine Ausgabe an die TPU-Konsole.
Es scheint so, als hätte die TPU das Training beendet. Um dies zu vermeiden, führen Sie den
Schulungseinheit mit einem Terminal-Multiplexer oder einem Tool zur Sitzungsverwaltung wie
als tmux
oder screen
. Dadurch bleiben die ssh
Verbindung unabhängig von der Dauer
des Trainings aktiv ist.
Behebung von allgemeinen Fehlern
In diesem Abschnitt wird beschrieben, wie Sie häufige Fehler beheben, beim Trainieren von Modellen in Cloud TPU.
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 mit dem folgenden Befehl behoben werden kann:
gcloud auth login --update-adc
Dieser Befehl aktualisiert Ihre Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) und sollte das Problem zu lösen. 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 tritt nur während der XLA-Kompilierung mit TensorFlow auf.
Details
Cloud TPU kompiliert das Modell, um ein Modell auf der TPU auszuführen mithilfe des XLA-Compilers. Während wodurch die Trainingsgeschwindigkeit und die Arbeitsspeichernutzung erheblich verbessert werden. die Formen (Dimensionsgrößen) aller Tensoren im Graphen müssen beim Kompilieren des Graphen bekannt sein. Wenn bei der Kompilierung keine Formen ermittelt werden können, schlägt die TPU-Kompilierung fehl mit einem Fehler wie dem vorher gezeigten.
Eine gängige Operation, die eine dynamische Form zurückgibt, ist dataset.batch(batch_size)
.
da die Anzahl der in einem Stream verbleibenden Stichproben möglicherweise unter
die Batchgröße. Legen Sie daher beim Training auf der TPU fest,
drop remainder=True
für dataset.batch
.
Dadurch werden möglicherweise die letzten Stichproben aus einer Datei gelöscht,
dass jeder Batch die statische Form „batch_size“ hat. 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 nicht auf der TPU verfügbar ist.
Hier finden Sie eine Liste der auf der TPU verfügbaren Vorgänge sowie Pläne für zukünftigen Support und finden Sie im Leitfaden zur verfügbaren TensorFlow-Ops.
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 mit 8 GB und v3-TPUs haben 16 GB RAM (oder HBM, einen Arbeitsspeicher mit hoher Bandbreite). Dieser Speicher dient zum Speichern der Gewichtungssensoren (Variable) sowie der Zwischenergebnistensoren, die für die Gradientenberechnung benötigt werden. Wenn das Modell zu groß für den TPU-RAM ist, wird die Initialisierung schlägt fehl und die Fehlermeldung wird ausgegeben. Weitere Informationen finden Sie unter Arbeitsspeichernutzung reduzieren.
Tipps zum Reduzieren der Speichernutzung:
- Prüfen Sie, ob übermäßiges Padding von Tensoren vorhanden ist.
- Verwenden Sie das Format bfloat16.
- Wenn die Eingabegrößen oder das Modell zu groß ist, können Sie experimentelle Modellparallelität von TensorFlow um die Modellgröße zu berücksichtigen.
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. In diesem Fall
drücken Sie CTRL+C
auf der Tastatur, um SIGQUIT
auszulösen,
Python, um es sofort zu beenden.
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.
Wenn beim Wiederherstellen der Verbindung zu Wenn Sie die TPU auf diese Weise verlassen haben, setzen Sie den TPU-Server manuell zurück. mit den folgenden Befehlen:
gcloud compute tpus tpu-vm stop tpu-name --zone=zone gcloud compute tpus tpu-vm start tpu-name --zone=zone
Dabei wird tpu-name aus der ersten Spalte entnommen, die vom
gcloud compute tpus tpu-vm list
und zone ist die Zone, die in
in 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.
Die effektivsten Möglichkeiten, um die Arbeitsspeichernutzung zu reduzieren, 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 Speichernutzung ist proportional zur Anzahl der Gewichtungen im Modell haben.
- 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 Speicher hängt von der Anzahl der Layers in Netzwerk.
Die TPU-Laufzeit versucht, Operatoren so zu optimieren, dass das Modell in den Speicher einzupassen (sogenannte Rematerialisierung, ähnlich wie der Farbverlauf Prüfpunktausführung) aber das ist nicht immer möglich.
So reduzieren Sie die Arbeitsspeichernutzung
Verringern Sie langsam die Batchgröße, bis sie in den Arbeitsspeicher passt. Die Batchgröße insgesamt ist ein Vielfaches von 64 (die Batchgröße pro Kern sollte ein Vielfaches von 8). 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 Informationen finden Sie im Leitfaden zur Leistung. finden Sie weitere Vorschläge zur Verbesserung der Trainingsleistung.
Zu wenige Schritte pro Ausführung und Trainingsschleife
Beschreibung des Leistungsproblems
Argument steps_per_execution
an Model.compile
-Steuerelemente übergeben
wie viele Trainingsschritte zwischen Host-Callbacks ausgeführt werden.
Jeder Host-Callback erfordert eine umfassende Kommunikation.
zwischen der Host-CPU des TPU-Servers und dem TPU-Gerät, also wenn steps_per_execution
zu klein ist, kann das das Training verlangsamen.
So ermitteln Sie, ob Ihr Modell betroffen ist
Wenn ein TPU-Profil häufige Host-CPU-Rückrufe zwischen TPU-Geräteschritten anzeigt,
kann Ihr Training von einem höheren steps_per_execution
-Wert profitieren.
So leiten Sie Gegenmaßnahmen ein
Setzen Sie steps_per_execution
auf einen höheren Wert. Beachten Sie, dass
Für steps_per_execution
kann ein hoher Wert festgelegt werden. Beachten Sie jedoch Folgendes:
kann das Protokollieren von Meldungen und das Speichern eines Prüfpunkts erst erfolgen, nachdem
Anzahl der gelaufenen Schritte.
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 Eingabe 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 zeigt die Ausführungszeit pro Vorgang an, sodass Sie problematische Vorgänge lokalisieren 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. Eine Heuristik für den Wertnum_parallel_calls
gibt die Anzahl der verfügbaren CPU-Kerne an. - 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 Die Geschwindigkeit des lokalen Computers spielt also keine Rolle.
Langsame Schrittzeiten und niedrige 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, die du in diesem Fall siehst, sind langsame Schrittzeiten, niedrige MXU-Auslastung, die angezeigt wird, wenn Sie ein Profil der Leistung erstellen.
So leiten Sie Gegenmaßnahmen ein
Versuchen Sie, die Anzahl der Vorgänge zu reduzieren, die keine Matrixmultiplikationen sind. Nach Reduzierung der Anzahl der Matrixmultiplikationen neue Benchmarks ansetzen um zu sehen, ob die Leistung von 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 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 empfiehlt sich, die größte Batchgröße zu verwenden, die in den Arbeitsspeicher passt und eine Vielfaches von 64. 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
Im Allgemeinen erzielen Ebenengrößen unter 128 eine schlechte Effizienz. auf der TPU, da 128 die integrierte Dimension der TPU-Matrixmultiplikation ist Einheit. 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 müssen so groß sein wie vollständig verbundene Schichten, um eine gleichwertige Effizienz zu erzielen.
So leiten Sie Gegenmaßnahmen ein
Wenn die Trainingsgeschwindigkeit zu niedrig ist, Ihre Modelle mit größeren TPU-Schichten neu zu vergleichen. Beispiel: Wenn die Ausgabegröße einer Ebene von 256 auf 512 erhöht wird, die Trainingszeit um 20% erhöhen, obwohl das Modell Berechnungen.
Modellprofilierung auf Operationsebene
Häufig ist es hilfreich, die Ausführungszeit und Speichernutzung auf der Operationsebene zu messen, um Leistungsengpässe zu identifizieren. Eine Anleitung dazu findest du unter
.
Weitere Informationen finden Sie in der Anleitung Cloud TPU Tools: Trace Viewer.
Debugging verringert die Modellgenauigkeit
Eines der Ziele der Cloud TPU-Umgebung ist, das auf einer CPU oder GPU trainiert wird, erreicht eine ähnliche Genauigkeit. wenn es auf der TPU trainiert wird, mit möglicherweise geringfügigen Anpassungen an den 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
TensorFlow führt Datenfragmentierung durch.
Jede Cloud TPU enthält 8 TPU-Kerne, die als unabhängig voneinander agieren
Verarbeitungseinheiten. Für jeden Schritt des Trainings erhält jeder TPU-Kern einen Batch
von Daten, berechnet die Gewichtungsverläufe, tauscht die Gradienten gegen die
anderen TPU-Kernen haben,
und berechnet dann die Gewichtungsaktualisierung. 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 können Batches Normalisierung kleiner Batches (z. B. weniger als 32) die Genauigkeit beeinträchtigen. 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.
Deterministisches Training
Ein Grund, warum es schwierig ist, Fehler bei Abweichungen bei der Modellgenauigkeit zu beheben dass in verschiedenen Frameworks (TensorFlow, PyTorch, JAX) Trainingssoftware verwendet unterschiedliche Gewichtsinitialisierung und Daten-Shuffle wenn ein Modell trainiert wird. Es ist vorteilhaft, das Trainingsverfahren deterministisch zu gestalten, sodass mehrere Durchläufe nahezu identische Modelle erzeugen. Dieser Abschnitt zeigt, wie die MNIST-Anleitung deterministisch ausgeführt wird:
- Erstellen Sie eine erste Prüfpunktdatei durch Ausführen eines einzelnen Schritts auf der CPU. Mit diesem Schritt erzielen Sie eine deterministische Gewichtungsinitialisierung. Außerdem Stellen Sie sicher, dass Sie für jede Zufallsfunktion einen festen zufälligen Startwert verwenden, im Modell an.
# Run training for 1 step to create an initial checkpoint. python mnist_tpu.py \ --use_tpu=False \ --data_dir=${STORAGE_BUCKET}/data/ \ --model_dir=${STORAGE_BUCKET}/init_output \ --random_seed=12345 \ --iterations=1 --train_steps=1
- Ändern Sie alle Funktionen der Datenfragmentierung in Ihrer Eingabefunktion, um einen zufälligen Ausgangswert zu verwenden. Dies wurde bereits im Rahmen der MNIST-Anleitung durchgeführt. Dies funktioniert für die Vorgänge der Eingabedatenverarbeitung, da diese immer auf der CPU ausgeführt werden. Zufallsvorgänge in der Modellfunktion sind zwischen der TPU und der CPU möglicherweise nicht deterministisch. Bei jedem Anruf einen zufälligen Vorgang, übergeben Sie einen festen Seed-Wert, um dieselben Ergebnisse zu erhalten zwischen den Läufen. Beispiel:
# In the flag definitions
tf.flags.DEFINE_integer("batch_size", None, "Random seed for training")
# In the input_fn
if FLAGS.random_seed is not None:
dataset = dataset.shuffle(seed=FLAGS.random_seed)
-
Führen Sie dasselbe Modell zweimal auf der CPU aus, um zu prüfen, ob das Training
deterministisch. Beachten Sie, dass das Training für eine angemessene Anzahl
(z. B. 1000), muss aber nicht zur Konvergenz ausgeführt werden.
Da das CPU-Training mit einem Einzelkern-TPU-Training verglichen wird, verwenden Sie eine vollständige Batchgröße, die auf einen einzelnen TPU-Kern passt (in der Regel die vollständige Batchgröße geteilt durch 8). TensorFlow garantiert keinen bitweisen Determinismus zwischen Ausführungen, aber der Verlust sollte den dabei erreichten Werten sehr nahe kommen:
Anfängliche Gewichtungen kopieren
gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_1/ --continue-on-error gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_2/ --continue-on-error
Lauf 1
python mnist_tpu.py \ --use_tpu=False \ --data_dir=${STORAGE_BUCKET}/data/ \ --model_dir=${STORAGE_BUCKET}/cpu_output_1 \ --batch_size=128 \ --random_seed=12345 \ --train_steps=2000 \ --eval_steps=10
Ausgabe 1
accuracy = 0.9910644, global_step = 1000, loss = 0.025323588
Lauf 2
python mnist_tpu.py \ --use_tpu=False \ --data_dir=${STORAGE_BUCKET}/data/ \ --model_dir=${STORAGE_BUCKET}/cpu_output_1 \ --batch_size=128 \ --random_seed=12345 \ --train_steps=2000 \ --eval_steps=10
Ausgabe 2
accuracy = 0.9910644, global_step = 1000, loss = 0.025323414
Einzelkern-TPU-Training
Sobald Sie die MNIST-Anleitung deterministisch ausführen können, besteht der nächste Schritt darin, die CPU-trainierten Ergebnisse auf der TPU zu replizieren, wobei ein einzelner TPU-Kern verwendet wird, um festzustellen, ob das Problem mit der Datenfragmentierung oder der TPU-Ausführungsengine selbst zusammenhängt.
So führen Sie das Einzelkern-Training und die Bewertung in der MNIST-Anleitung aus:
Gleiche Gewichtungsinitialisierung wie die CPU verwenden
gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/tpu_output --continue-on-error
Lauftraining für 1.000 Schritte
python mnist.py \ --use_tpu=True \ --master=$GRPC_SERVER \ --train_file=${STORAGE_BUCKET}/data/train.tfrecords \ --model_dir=${STORAGE_BUCKET}/tpu_output \ --random_seed=12345 \ --num_shards=1 \ --batch_size=128 \ --train_steps=1000 \ --eval_steps=10
Ausgabe
accuracy = 0.9910644, global_step = 1000, loss = 0.02514153
Der Verlust stimmt nicht genau mit dem CPU-trainierten Modell überein, sollte aber nah sein. Ist Letzteres bei Ihrem Modell nicht der Fall, kann dies darauf hindeuten, dass ein Fehler in der TPU-Ausführungs-Engine vorliegt. Prüfen Sie Folgendes, bevor Sie einen Fehlerbericht senden:
Sie übergeben
num_shards=1
anTPUConfig
.Sie haben keine zufälligen Operationen in Ihrer Modellfunktion und keine zufälligen Operationen in dass Ihre Eingabefunktion richtig gesetzt wird.
Sie verwenden für das CPU- und das TPU-Training dieselbe initiale Prüfpunktdatei.
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 (a) das Problem ist, trainieren Sie das vollständige Modell auf der CPU/GPU noch einmal und Mehrkern-TPUs mit gleicher Gewichtungsinitialisierung.
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.
- Batchweise Verlustfunktionen werden durch Fragmentierung beeinflusst. Solche Verlustfunktionen sind in der Regel ziemlich speziell. Beispiel: Karras et al. 2017 verwendet beim Trainieren eines generativen kontradiktorischen Netzwerks einen Batchdiskriminator.
Fehlerbehebung bei der Einrichtung von gcloud
- 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
gcloud
verwenden möchten, müssen Sie einengcloud
-Installation, die wird nicht über einen Paketmanager verwaltet. Führen Sie die folgenden Schritte aus, um Installieren Siegcloud
aus dem Quellcode:
sudo apt-get remove google-cloud-sdk curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-311.0.0-linux-x86_64.tar.gz tar -xzf google-cloud-sdk-311.0.0-linux-x86_64.tar.gz ./google-cloud-sdk/install.sh source ~/.bashrc
- Problem
gcloud compute tpus tpu-vm ssh ${TPU_NAME} --zone ${ZONE}
-Befehl wird folgende Fehlermeldung angezeigt: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
Fehlerbehebungsprotokolle
Unterstützte Cloud TPU-Frameworks, JAX, PyTorch und TensorFlow
auf TPUs mithilfe einer gemeinsam genutzten Bibliothek namens libtpu
, die auf dem
jede TPU-VM. Diese Bibliothek enthält den für die Kompilierung verwendeten XLA-Compiler
TPU-Programme, die zum Ausführen kompilierter Programme verwendet werden,
und den TPU-Treiber, der von der Laufzeit für den Low-Level-Zugriff auf die TPU verwendet wird.
Die Bibliothek libtpu
protokolliert Informationen, die für die Fehlerbehebung hilfreich 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 Protokollierungsverhalten zu ändern:
- TPU_LOG_DIR: das Verzeichnis, in das Logs geschrieben werden
- Der Speicherort des Verzeichnisses ist standardmäßig
/tmp/tpu_logs
. Das Verzeichnis ist erstellt werden, falls er noch nicht vorhanden ist, aber es werden keine übergeordneten Verzeichnisse erstellt. Wenn beim Suchen oder Erstellen des angegebenen Verzeichnisses ein Fehler auftritt, wird eine Nachricht an stderr ausgegeben, das Programm wird dadurch aber nicht angehalten. und Logging ist deaktiviert. Legen Sie den Verzeichnisnamen auf „deaktiviert“ fest. bis das Logging auf der Festplatte komplett deaktivieren. - TPU_MIN_LOG_LEVEL: Mindestschweregrad, der auf dem Laufwerk protokolliert wird
- Zur Auswahl stehen 0 (INFO), 1 (WARNING), 2 (FEHLER) und 3 (FATAL). Der Standardwert ist 0.
- TPU_STDERR_LOG_LEVEL: der Mindestschweregrad, der in stderr zusätzlich zum Laufwerk (falls zutreffend) protokolliert wird
- Die Auswahl ist mit der für TPU_MIN_LOG_LEVEL identisch. Der Standardwert ist 3.
- TPU_MAX_LOG_SIZE_MB: die maximale Größe jeder Logdatei in Megabyte
- Eine neue Protokolldatei wird automatisch gestartet, wenn die vorherige die folgende erreicht: ungefähr diese Größe hat. Die Standardeinstellung ist 1.024.