Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Multi-Worker-Training mit Keras

Ansicht auf TensorFlow.org In Google Colab ausführen Quelle auf GitHub anzeigen Notizbuch herunterladen

Überblick

Dieses Lernprogramm demonstriert das verteilte Training für mehrere Mitarbeiter mit dem Keras-Modell unter tf.distribute.Strategy API tf.distribute.Strategy , insbesondere tf.distribute.experimental.MultiWorkerMirroredStrategy . Mithilfe dieser Strategie kann ein Keras-Modell, das für die Ausführung mit einem einzelnen Mitarbeiter entwickelt wurde, mit minimaler Codeänderung nahtlos an mehreren Mitarbeitern arbeiten.

Das Handbuch für verteilte Schulungen in TensorFlow bietet einen Überblick über die Verteilungsstrategien, die TensorFlow für diejenigen unterstützt, die an einem tieferen Verständnis der APIs von tf.distribute.Strategy interessiert sind.

Konfiguration

Richten Sie zunächst TensorFlow und die erforderlichen Importe ein.

 import os
import tensorflow as tf
import numpy as np
 

Datensatz vorbereiten

Bereiten wir nun den MNIST-Datensatz vor. Der MNIST-Datensatz umfasst 60.000 Trainingsbeispiele und 10.000 Testbeispiele der handschriftlichen Ziffern 0–9, die als 28 x 28-Pixel-Monochrombilder formatiert sind. In diesem Beispiel wird der Trainingsteil der Datensätze zur Demonstration verwendet.

 def mnist_dataset(batch_size):
  (x_train, y_train), _ = tf.keras.datasets.mnist.load_data()
  # The `x` arrays are in uint8 and have values in the range [0, 255].
  # We need to convert them to float32 with values in the range [0, 1]
  x_train = x_train / np.float32(255)
  y_train = y_train.astype(np.int64)
  train_dataset = tf.data.Dataset.from_tensor_slices(
      (x_train, y_train)).shuffle(60000).repeat().batch(batch_size)
  return train_dataset
 

Erstellen Sie das Keras-Modell

Hier verwenden wir die tf.keras.Sequential API, um ein einfaches Keras-Modell für Faltungs-Neuronale Netze zu erstellen und zu kompilieren, das mit unserem MNIST-Datensatz trainiert werden soll.

 def build_and_compile_cnn_model():
  model = tf.keras.Sequential([
      tf.keras.Input(shape=(28, 28)),
      tf.keras.layers.Reshape(target_shape=(28, 28, 1)),
      tf.keras.layers.Conv2D(32, 3, activation='relu'),
      tf.keras.layers.Flatten(),
      tf.keras.layers.Dense(128, activation='relu'),
      tf.keras.layers.Dense(10)
  ])
  model.compile(
      loss=tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True),
      optimizer=tf.keras.optimizers.SGD(learning_rate=0.001),
      metrics=['accuracy'])
  return model
 

Lassen Sie uns zunächst versuchen, das Modell für eine kleine Anzahl von Epochen zu trainieren und die Ergebnisse bei einem einzelnen Arbeiter zu beobachten, um sicherzustellen, dass alles korrekt funktioniert. Sie sollten damit rechnen, dass der Verlust sinkt und sich die Genauigkeit im Verlauf der Epoche 1,0 nähert.

 per_worker_batch_size = 64
single_worker_dataset = mnist_dataset(per_worker_batch_size)
single_worker_model = build_and_compile_cnn_model()
single_worker_model.fit(single_worker_dataset, epochs=3, steps_per_epoch=70)
 
Downloading data from https://storage.googleapis.com/tensorflow/tf-keras-datasets/mnist.npz
11493376/11490434 [==============================] - 0s 0us/step
Epoch 1/3
70/70 [==============================] - 0s 2ms/step - loss: 2.2701 - accuracy: 0.2451
Epoch 2/3
70/70 [==============================] - 0s 2ms/step - loss: 2.1827 - accuracy: 0.4777
Epoch 3/3
70/70 [==============================] - 0s 2ms/step - loss: 2.0865 - accuracy: 0.5955

<tensorflow.python.keras.callbacks.History at 0x7fc59381ac50>

Multi-Worker-Konfiguration

Betreten wir jetzt die Welt der Ausbildung für mehrere Mitarbeiter. In TensorFlow ist TF_CONFIG Umgebungsvariable TF_CONFIG für das Training auf mehreren Computern erforderlich, von denen jeder möglicherweise eine andere Rolle spielt. TF_CONFIG ist eine JSON-Zeichenfolge, mit der die Clusterkonfiguration für jeden Worker angegeben wird, der Teil des Clusters ist.

TF_CONFIG besteht aus zwei Komponenten: cluster und task . cluster bietet Informationen zum Schulungscluster, bei dem es sich um ein Diktat handelt, das aus verschiedenen Arten von Jobs besteht, z. B. worker . In der Multi-Worker-Schulung mit MultiWorkerMirroredStrategy übernimmt normalerweise ein worker etwas mehr Verantwortung wie das Speichern von Checkpoints und das Schreiben einer Zusammenfassungsdatei für TensorBoard zusätzlich zu den Aufgaben eines regulären worker . Solche Arbeitnehmer als bezeichnet wird chief Arbeiter, und es ist üblich , dass der worker mit index 0 als Chef ernannt worker (in der Tat ist dies, wie tf.distribute.Strategy implementiert ist). task hingegen liefert Informationen über die aktuelle Aufgabe. Die erste Komponente cluster ist die gleiche für alle Arbeiter, und die zweite Komponente task unterscheidet sich auf jeden Arbeiter und gibt die type und index dieses Arbeitnehmers.

In diesem Beispiel legen wir die Aufgabe type zu "worker" und der Task - index auf 0 . Dies bedeutet, dass die Maschine mit dieser Einstellung der erste Arbeiter ist, der zum Hauptarbeiter ernannt wird und mehr Arbeit leistet als andere Arbeiter. Beachten Sie, dass andere Maschinen benötigt haben TF_CONFIG Umgebungsvariable Satz als gut, und es sollte die gleiche haben cluster dict, aber verschiedene type oder index je nachdem , was die Rollen von diesen Maschinen sind.

Zur Veranschaulichung zeigt dieses Tutorial, wie man eine TF_CONFIG mit 2 TF_CONFIG auf localhost . In der Praxis würden Benutzer mehrere Worker an externen IP-Adressen / Ports erstellen und TF_CONFIG für jeden Worker entsprechend TF_CONFIG .

 os.environ['TF_CONFIG'] = json.dumps({
    'cluster': {
        'worker': ["localhost:12345", "localhost:23456"]
    },
    'task': {'type': 'worker', 'index': 0}
})
 

Beachten Sie, dass die Lernrate in diesem Beispiel zwar festgelegt ist, es jedoch im Allgemeinen erforderlich sein kann, die Lernrate basierend auf der globalen Stapelgröße anzupassen.

Wählen Sie die richtige Strategie

In TensorFlow besteht verteiltes Training aus synchronem Training, bei dem die Trainingsschritte zwischen den Mitarbeitern und Replikaten synchronisiert werden, und asynchronem Training, bei dem die Trainingsschritte nicht streng synchronisiert werden.

MultiWorkerMirroredStrategy , die empfohlene Strategie für die synchrone Schulung MultiWorkerMirroredStrategy Mitarbeiter, wird in diesem Handbuch vorgestellt. Verwenden Sie zum Trainieren des Modells eine Instanz von tf.distribute.experimental.MultiWorkerMirroredStrategy . MultiWorkerMirroredStrategy erstellt Kopien aller Variablen in den Modellebenen auf jedem Gerät für alle Worker. Es verwendet CollectiveOps , eine TensorFlow-Operation für die kollektive Kommunikation, um Farbverläufe zu aggregieren und die Variablen synchron zu halten. Weitere Informationen zu dieser Strategie finden tf.distribute.Strategy Handbuch tf.distribute.Strategy .

 strategy = tf.distribute.experimental.MultiWorkerMirroredStrategy()
 
WARNING:tensorflow:Collective ops is not configured at program startup. Some performance features may not be enabled.
INFO:tensorflow:Using MirroredStrategy with devices ('/device:GPU:0',)
INFO:tensorflow:Single-worker MultiWorkerMirroredStrategy with local_devices = ('/device:GPU:0',), communication = CollectiveCommunication.AUTO

MultiWorkerMirroredStrategy bietet mehrere Implementierungen über den CollectiveCommunication Parameter. RING implementiert ringbasierte Kollektive unter Verwendung von gRPC als hostübergreifende Kommunikationsschicht. NCCL verwendet Nvidias NCCL , um Kollektive zu implementieren. AUTO die Auswahl auf die Laufzeit. Die beste Wahl für die kollektive Implementierung hängt von der Anzahl und Art der GPUs sowie der Netzwerkverbindung im Cluster ab.

Trainieren Sie das Modell mit MultiWorkerMirroredStrategy

Mit der Integration der API tf.distribute.Strategy in tf.keras können Sie die Schulung nur an mehrere Mitarbeiter tf.keras , tf.keras Sie den Modellaufbau und den Aufruf model.compile() in strategy.scope() einschließen. Der Umfang der Verteilungsstrategie bestimmt, wie und wo die Variablen erstellt werden. Bei MultiWorkerMirroredStrategy handelt es sich bei den erstellten Variablen um MirroredVariable Variablen, die auf jedem Worker repliziert werden.

 num_workers = 4

# Here the batch size scales up by number of workers since 
# `tf.data.Dataset.batch` expects the global batch size. Previously we used 64, 
# and now this becomes 128.
global_batch_size = per_worker_batch_size * num_workers
multi_worker_dataset = mnist_dataset(global_batch_size)

with strategy.scope():
  # Model building/compiling need to be within `strategy.scope()`.
  multi_worker_model = build_and_compile_cnn_model()

# Keras' `model.fit()` trains the model with specified number of epochs and
# number of steps per epoch. Note that the numbers here are for demonstration
# purposes only and may not sufficiently produce a model with good quality.
multi_worker_model.fit(multi_worker_dataset, epochs=3, steps_per_epoch=70)
 
Epoch 1/3
WARNING:tensorflow:From /tmpfs/src/tf_docs_env/lib/python3.6/site-packages/tensorflow/python/data/ops/multi_device_iterator_ops.py:601: get_next_as_optional (from tensorflow.python.data.ops.iterator_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use `tf.data.Iterator.get_next_as_optional()` instead.
70/70 [==============================] - 0s 3ms/step - loss: 2.2682 - accuracy: 0.2265
Epoch 2/3
70/70 [==============================] - 0s 3ms/step - loss: 2.1714 - accuracy: 0.4954
Epoch 3/3
70/70 [==============================] - 0s 3ms/step - loss: 2.0638 - accuracy: 0.6232

<tensorflow.python.keras.callbacks.History at 0x7fc5f4f062e8>

Datensatz-Sharding und Stapelgröße

In der Multi-Worker-Schulung mit MultiWorkerMirroredStrategy ist das MultiWorkerMirroredStrategy des Datasets erforderlich, um Konvergenz und Leistung sicherzustellen. Beachten Sie jedoch, dass im obigen Code-Snippet die Datasets direkt an model.fit() ohne dass ein Shard erforderlich ist. Dies liegt daran, tf.distribute.Strategy API tf.distribute.Strategy das tf.distribute.Strategy des Datasets automatisch übernimmt. Das Dataset wird auf Dateiebene gesplittert, wodurch möglicherweise verzerrte Shards entstehen. In extremen Fällen, in denen nur eine Datei vorhanden ist, erhält nur der erste Shard (dh der Arbeiter) Schulungs- oder Bewertungsdaten, und infolgedessen erhalten alle Arbeiter Fehler.

Wenn Sie für Ihr Training das manuelle Sharding bevorzugen, kann das automatische tf.data.experimental.DistributeOptions über tf.data.experimental.DistributeOptions API tf.data.experimental.DistributeOptions . Konkret,

 options = tf.data.Options()
options.experimental_distribute.auto_shard_policy = tf.data.experimental.AutoShardPolicy.OFF
dataset_no_auto_shard = multi_worker_dataset.with_options(options)
 

Zu beachten ist auch die Stapelgröße für die datasets . Im obigen Code-Snippet verwenden wir global_batch_size = per_worker_batch_size * num_workers ist num_workers mal so groß wie bei einem einzelnen Worker, da die effektive Batch-Größe pro Worker die globale Batch-Größe ist (der in tf.data.Dataset.batch() Parameter tf.data.Dataset.batch() ) geteilt durch die Anzahl der Worker. Mit dieser Änderung behalten wir die Chargengröße pro Worker wie zuvor bei.

Auswertung

Wenn Sie validation_data an model.fit , wird für jede Epoche zwischen Training und Evaluierung gewechselt. Die Bewertung mit validation_data wird auf dieselbe Gruppe von Arbeitnehmern verteilt, und die Bewertungsergebnisse werden aggregiert und stehen allen Arbeitnehmern zur Verfügung. Ähnlich wie beim Training wird der Validierungsdatensatz automatisch auf Dateiebene gespalten. Sie müssen eine globale Stapelgröße im Validierungsdatensatz festlegen und validation_steps festlegen. Zur Auswertung wird auch ein wiederholter Datensatz empfohlen.

Alternativ können Sie auch eine andere Aufgabe erstellen, die regelmäßig Prüfpunkte liest und die Auswertung ausführt. Dies ist, was Estimator tut. Dies ist jedoch keine empfohlene Methode zur Durchführung der Bewertung, weshalb die Details weggelassen werden.

Prognose

Derzeit model.predict nicht mit MultiWorkerMirroredStrategy.

Performance

Sie haben jetzt ein Keras-Modell, das für die Ausführung in mehreren MultiWorkerMirroredStrategy mit MultiWorkerMirroredStrategy . Mit MultiWorkerMirroredStrategy können Sie die folgenden Techniken ausprobieren, um die Leistung des Multi-Worker-Trainings zu MultiWorkerMirroredStrategy .

  • MultiWorkerMirroredStrategy bietet mehrere kollektive Kommunikationsimplementierungen . RING implementiert ringbasierte Kollektive unter Verwendung von gRPC als hostübergreifende Kommunikationsschicht. NCCL verwendet Nvidias NCCL , um Kollektive zu implementieren. AUTO die Auswahl auf die Laufzeit. Die beste Wahl für die kollektive Implementierung hängt von der Anzahl und Art der GPUs sowie der Netzwerkverbindung im Cluster ab. MultiWorkerMirroredStrategy zum Überschreiben der automatischen Auswahl einen gültigen Wert für den communication des MultiWorkerMirroredStrategy von MultiWorkerMirroredStrategy , z. B. communication=tf.distribute.experimental.CollectiveCommunication.NCCL .
  • Cast die Variablen wenn möglich auf tf.float . Das offizielle ResNet-Modell enthält ein Beispiel dafür, wie dies getan werden kann.

Fehlertoleranz

Beim synchronen Training würde der Cluster fehlschlagen, wenn einer der Mitarbeiter ausfällt und kein Mechanismus zur Fehlerbehebung vorhanden ist. Die Verwendung von Keras mit tf.distribute.Strategy den Vorteil der Fehlertoleranz in Fällen, in denen Mitarbeiter sterben oder auf andere Weise instabil sind. Dazu behalten wir den Trainingsstatus im verteilten Dateisystem Ihrer Wahl bei, sodass beim Neustart der Instanz, die zuvor fehlgeschlagen oder zuvor ausgeführt wurde, der Trainingsstatus wiederhergestellt wird.

Da alle Mitarbeiter in Bezug auf Schulungsepochen und -schritte synchron gehalten werden, müssten andere Mitarbeiter auf den Neustart des ausgefallenen oder ausgeschlossenen Arbeitnehmers warten, um fortzufahren.

ModelCheckpoint-Rückruf

ModelCheckpoint Rückruf bietet keine Fehlertoleranzfunktion mehr. Verwenden BackupAndRestore stattdessen den BackupAndRestore Rückruf.

Der ModelCheckpoint Rückruf kann weiterhin zum Speichern von Prüfpunkten verwendet werden. Wenn das Training unterbrochen oder erfolgreich abgeschlossen wurde, ist der Benutzer dafür verantwortlich, das Modell manuell zu laden, um das Training vom Checkpoint aus fortzusetzen. Optional kann der Benutzer das Modell / die Gewichte außerhalb des ModelCheckpoint Rückrufs speichern und wiederherstellen.

Modell speichern und laden

Um Ihr Modell mit model.save oder tf.saved_model.save , muss das Ziel für das Speichern für jeden Worker unterschiedlich sein. Bei den Nicht-Chefarbeitern müssen Sie das Modell in einem temporären Verzeichnis speichern, und bei dem Chef müssen Sie es in dem bereitgestellten Modellverzeichnis speichern. Die temporären Verzeichnisse auf dem Worker müssen eindeutig sein, um Fehler zu vermeiden, die dadurch entstehen, dass mehrere Worker versuchen, an denselben Speicherort zu schreiben. Das in allen Verzeichnissen gespeicherte Modell ist identisch, und normalerweise sollte nur das vom Chef gespeicherte Modell zum Wiederherstellen oder Bereitstellen referenziert werden. Wir empfehlen, dass Sie über eine Bereinigungslogik verfügen, mit der die von den Mitarbeitern erstellten temporären Verzeichnisse nach Abschluss Ihrer Schulung gelöscht werden.

Der Grund, warum Sie gleichzeitig für den Chef und die Mitarbeiter sparen müssen, liegt darin, dass Sie möglicherweise während des Checkpointing Variablen aggregieren, sodass sowohl der Chef als auch die Mitarbeiter am allreduce-Kommunikationsprotokoll teilnehmen müssen. Auf der anderen Seite führt das Speichern von Chef und Arbeitern im selben Modellverzeichnis zu Fehlern aufgrund von Konflikten.

Mit MultiWorkerMirroredStrategy wird das Programm auf jedem Worker ausgeführt. Um festzustellen, ob der aktuelle Worker Chef ist, nutzen wir das Cluster-Resolver-Objekt mit den Attributen task_type und task_id . task_type gibt an, was der aktuelle Job ist (z. B. 'Arbeiter'), und task_id Ihnen die Kennung des Arbeiters an. Der Arbeiter mit der ID 0 wird als Hauptarbeiter bezeichnet.

Im folgenden write_filepath gibt write_filepath den zu schreibenden Dateipfad an, der von der Worker-ID abhängt. Im Fall von Chef (Arbeiter mit ID 0) schreibt es in den ursprünglichen Dateipfad; Für andere wird ein temporäres Verzeichnis (mit der ID im Verzeichnispfad) zum Schreiben erstellt:

 model_path = '/tmp/keras-model'

def _is_chief(task_type, task_id):
  # If `task_type` is None, this may be operating as single worker, which works 
  # effectively as chief.
  return task_type is None or task_type == 'chief' or (
            task_type == 'worker' and task_id == 0)

def _get_temp_dir(dirpath, task_id):
  base_dirpath = 'workertemp_' + str(task_id)
  temp_dir = os.path.join(dirpath, base_dirpath)
  tf.io.gfile.makedirs(temp_dir)
  return temp_dir

def write_filepath(filepath, task_type, task_id):
  dirpath = os.path.dirname(filepath)
  base = os.path.basename(filepath)
  if not _is_chief(task_type, task_id):
    dirpath = _get_temp_dir(dirpath, task_id)
  return os.path.join(dirpath, base)

task_type, task_id = (strategy.cluster_resolver.task_type,
                      strategy.cluster_resolver.task_id)
write_model_path = write_filepath(model_path, task_type, task_id)
 

Damit können Sie jetzt Folgendes speichern:

 multi_worker_model.save(write_model_path)
 
WARNING:tensorflow:From /tmpfs/src/tf_docs_env/lib/python3.6/site-packages/tensorflow/python/training/tracking/tracking.py:111: Model.state_updates (from tensorflow.python.keras.engine.training) is deprecated and will be removed in a future version.
Instructions for updating:
This property should not be used in TensorFlow 2.0, as updates are applied automatically.
WARNING:tensorflow:From /tmpfs/src/tf_docs_env/lib/python3.6/site-packages/tensorflow/python/training/tracking/tracking.py:111: Layer.updates (from tensorflow.python.keras.engine.base_layer) is deprecated and will be removed in a future version.
Instructions for updating:
This property should not be used in TensorFlow 2.0, as updates are applied automatically.
INFO:tensorflow:Assets written to: /tmp/keras-model/assets

Wie oben beschrieben, sollte das Modell später nur von dem Pfad geladen werden, auf dem der Chef gespeichert ist. Entfernen wir also die temporären Pfade, die die Nicht-Chefarbeiter gespeichert haben:

 if not _is_chief(task_type, task_id):
  tf.io.gfile.rmtree(os.path.dirname(write_model_path))
 

Wenn es Zeit zum Laden ist, verwenden wir die praktische API tf.keras.models.load_model und fahren mit der weiteren Arbeit fort. Hier wird davon ausgegangen, dass nur ein einzelner Worker zum Laden und tf.keras.models.load_model Trainings verwendet wird. In diesem Fall rufen Sie tf.keras.models.load_model in einer anderen strategy.scope() tf.keras.models.load_model strategy.scope() .

 loaded_model = tf.keras.models.load_model(model_path)

# Now that we have the model restored, and can continue with the training.
loaded_model.fit(single_worker_dataset, epochs=2, steps_per_epoch=20)
 
Epoch 1/2
20/20 [==============================] - 0s 2ms/step - loss: 1.9825 - accuracy: 0.1102
Epoch 2/2
20/20 [==============================] - 0s 2ms/step - loss: 1.9367 - accuracy: 0.1117

<tensorflow.python.keras.callbacks.History at 0x7fc5f4b0d8d0>

Speichern und Wiederherstellen von Checkpoints

Auf der anderen Seite können Sie mit Checkpointing die Gewichte des Modells speichern und wiederherstellen, ohne das gesamte Modell speichern zu müssen. Hier erstellen Sie einen tf.train.Checkpoint , der das Modell verfolgt, das von einem tf.train.CheckpointManager verwaltet wird, sodass nur der neueste Prüfpunkt erhalten bleibt.

 checkpoint_dir = '/tmp/ckpt'

checkpoint = tf.train.Checkpoint(model=multi_worker_model)
write_checkpoint_dir = write_filepath(checkpoint_dir, task_type, task_id)
checkpoint_manager = tf.train.CheckpointManager(
  checkpoint, directory=write_checkpoint_dir, max_to_keep=1)
 

Sobald der CheckpointManager eingerichtet ist, können Sie die gespeicherten Checkpoints, die keine Hauptmitarbeiter sind, speichern und entfernen.

 checkpoint_manager.save()
if not _is_chief(task_type, task_id):
  tf.io.gfile.rmtree(write_checkpoint_dir)
 

Wenn Sie jetzt wiederherstellen müssen, können Sie den neuesten Prüfpunkt finden, der mit der praktischen Funktion tf.train.latest_checkpoint . Nach dem Wiederherstellen des Checkpoints können Sie mit dem Training fortfahren.

 latest_checkpoint = tf.train.latest_checkpoint(checkpoint_dir)
checkpoint.restore(latest_checkpoint)
multi_worker_model.fit(multi_worker_dataset, epochs=2, steps_per_epoch=20)
 
Epoch 1/2
20/20 [==============================] - 0s 3ms/step - loss: 1.9841 - accuracy: 0.6561
Epoch 2/2
20/20 [==============================] - 0s 3ms/step - loss: 1.9445 - accuracy: 0.6805

<tensorflow.python.keras.callbacks.History at 0x7fc5f49d9d30>

BackupAndRestore-Rückruf

Der BackupAndRestore-Rückruf bietet Fehlertoleranzfunktionen, indem das Modell und die aktuelle Epochennummer in einer temporären Prüfpunktdatei unter backup_dir Argument BackupAndRestore in BackupAndRestore . Dies geschieht am Ende jeder Epoche.

Sobald Jobs unterbrochen und neu gestartet werden, stellt der Rückruf den letzten Prüfpunkt wieder her und das Training wird ab dem Beginn der unterbrochenen Epoche fortgesetzt. Jegliches Teiltraining, das bereits in der unvollendeten Epoche vor der Unterbrechung durchgeführt wurde, wird weggeworfen, so dass es den endgültigen Modellzustand nicht beeinflusst.

tf.keras.callbacks.experimental.BackupAndRestore Sie zur Verwendung eine Instanz von tf.keras.callbacks.experimental.BackupAndRestore beim Aufruf von tf.keras.Model.fit() .

Wenn bei MultiWorkerMirroredStrategy ein Worker unterbrochen wird, wird der gesamte Cluster angehalten, bis der unterbrochene Worker neu gestartet wird. Andere Worker werden ebenfalls neu gestartet, und der unterbrochene Worker tritt dem Cluster wieder bei. Anschließend liest jeder Mitarbeiter die zuvor gespeicherte Prüfpunktdatei und nimmt ihren vorherigen Status wieder auf, sodass der Cluster wieder synchronisiert werden kann. Dann geht das Training weiter.

BackupAndRestore Rückruf verwendet CheckpointManager zum Speichern und Wiederherstellen des Trainingsstatus. Dabei wird eine Datei namens Checkpoint generiert, die vorhandene Checkpoints zusammen mit dem neuesten BackupAndRestore . Aus diesem Grund sollte backup_dir nicht erneut zum Speichern anderer Prüfpunkte verwendet werden, um eine Namenskollision zu vermeiden.

Derzeit unterstützt der BackupAndRestore Rückruf einzelne Mitarbeiter ohne Strategie, MirroredStrategy und mehrere Mitarbeiter mit MultiWorkerMirroredStrategy. Im Folgenden finden Sie zwei Beispiele für die Ausbildung von mehreren Arbeitnehmern und für die Ausbildung von Einzelarbeitern.

 # Multi-worker training with MultiWorkerMirroredStrategy.

callbacks = [tf.keras.callbacks.experimental.BackupAndRestore(backup_dir='/tmp/backup')]
with strategy.scope():
  multi_worker_model = build_and_compile_cnn_model()
multi_worker_model.fit(multi_worker_dataset,
                       epochs=3,
                       steps_per_epoch=70,
                       callbacks=callbacks)
 
Epoch 1/3
70/70 [==============================] - 0s 3ms/step - loss: 2.2837 - accuracy: 0.1836
Epoch 2/3
70/70 [==============================] - 0s 3ms/step - loss: 2.2131 - accuracy: 0.4091
Epoch 3/3
70/70 [==============================] - 0s 3ms/step - loss: 2.1310 - accuracy: 0.5485

<tensorflow.python.keras.callbacks.History at 0x7fc5f49a3080>

Wenn Sie das in backup_dir angegebene Verzeichnis von backup_dir BackupAndRestore , stellen Sie möglicherweise einige vorübergehend generierte Prüfpunktdateien fest. Diese Dateien werden zum Wiederherstellen der zuvor verlorenen Instanzen benötigt und von der Bibliothek am Ende von tf.keras.Model.fit() nach erfolgreichem Beenden Ihres Trainings entfernt.

Siehe auch

  1. Das verteilte Training im TensorFlow- Handbuch bietet einen Überblick über die verfügbaren Verteilungsstrategien.
  2. Offizielle Modelle , von denen viele für die Ausführung mehrerer Vertriebsstrategien konfiguriert werden können.
  3. Der Abschnitt Leistung im Handbuch enthält Informationen zu anderen Strategien und Tools, mit denen Sie die Leistung Ihrer TensorFlow-Modelle optimieren können.