Cette page a été traduite par l'API Cloud Translation.
Switch to English

Formation multi-ouvriers avec Keras

Voir sur TensorFlow.org Exécuter dans Google Colab Afficher la source sur GitHub Télécharger le cahier

Aperçu

Ce didacticiel présente une formation distribuée multi-ouvriers avec le modèle Keras à l'aide de l'API tf.distribute.Strategy , en particulier tf.distribute.experimental.MultiWorkerMirroredStrategy . Avec l'aide de cette stratégie, un modèle Keras conçu pour s'exécuter sur un seul travailleur peut fonctionner de manière transparente sur plusieurs travailleurs avec un changement de code minimal.

Le guide Formation distribuée dans TensorFlow est disponible pour un aperçu des stratégies de distribution prises en charge par TensorFlow pour ceux qui souhaitent une meilleure compréhension des API tf.distribute.Strategy .

Installer

Tout d'abord, configurez TensorFlow et les importations nécessaires.

 import os
import tensorflow as tf
import numpy as np
 

Préparation du jeu de données

Maintenant, préparons le jeu de données MNIST. L' ensemble de données MNIST comprend 60 000 exemples de formation et 10 000 exemples de test des chiffres manuscrits de 0 à 9, formatés en images monochromes de 28 x 28 pixels. Dans cet exemple, nous prendrons la partie formation des ensembles de données pour démontrer.

 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
 

Construire le modèle Keras

Ici, nous utilisons l'API tf.keras.Sequential pour créer et compiler un modèle Keras de réseaux neuronaux convolutifs simples à former avec notre jeu de données MNIST.

 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
 

Essayons d'abord de former le modèle pour un petit nombre d'époques et observons les résultats dans un seul travailleur pour nous assurer que tout fonctionne correctement. Vous devriez vous attendre à voir la perte chuter et la précision approchant 1.0 à mesure que l'époque avance.

 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>

Configuration multi-ouvriers

Entrons maintenant dans le monde de la formation multi-travailleurs. Dans TensorFlow, la variable d'environnement TF_CONFIG est requise pour l'entraînement sur plusieurs machines, chacune ayant éventuellement un rôle différent. TF_CONFIG est une chaîne JSON utilisée pour spécifier la configuration du cluster sur chaque worker qui fait partie du cluster.

Il existe deux composants de TF_CONFIG : cluster et task . cluster fournit des informations sur le cluster de formation, qui est un dict composé de différents types d'emplois tels que worker . Dans la formation multi-ouvriers avec MultiWorkerMirroredStrategy , il y a généralement un worker qui assume un peu plus de responsabilités comme la sauvegarde du point de contrôle et l'écriture d'un fichier récapitulatif pour TensorBoard en plus de ce qu'un worker régulier fait. Un tel travailleur est appelé le travailleur en chief , et il est de coutume que le worker avec l' index 0 soit désigné comme worker chef (en fait, c'est ainsi que tf.distribute.Strategy est implémenté). task , d'autre part, fournit des informations sur la tâche en cours. Le premier cluster composants est le même pour tous les nœuds de calcul et la deuxième task composant est différente pour chaque opérateur et spécifie le type et l' index de ce nœud de calcul.

Dans cet exemple, nous définissons le type tâche sur "worker" et l' index tâche sur 0 . Cela signifie que la machine qui a un tel réglage est le premier ouvrier, qui sera désigné comme ouvrier principal et effectuera plus de travail que les autres ouvriers. Notez que les autres machines devront également avoir la variable d'environnement TF_CONFIG définie, et il devrait avoir le même dict de cluster , mais un type tâche ou un index tâche différent selon les rôles de ces machines.

À des fins d'illustration, ce tutoriel montre comment définir un TF_CONFIG avec 2 workers sur localhost . En pratique, les utilisateurs créeraient plusieurs TF_CONFIG de TF_CONFIG sur des adresses / ports IP externes et définiraient TF_CONFIG sur chaque TF_CONFIG de manière appropriée.

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

Notez que bien que le taux d'apprentissage soit fixe dans cet exemple, il peut en général être nécessaire d'ajuster le taux d'apprentissage en fonction de la taille globale du lot.

Choisissez la bonne stratégie

Dans TensorFlow, la formation distribuée consiste en une formation synchrone, où les étapes de formation sont synchronisées entre les travailleurs et les réplicas, et une formation asynchrone, où les étapes de formation ne sont pas strictement synchronisées.

MultiWorkerMirroredStrategy , qui est la stratégie recommandée pour la formation synchrone multi-ouvriers, sera MultiWorkerMirroredStrategy dans ce guide. Pour entraîner le modèle, utilisez une instance de tf.distribute.experimental.MultiWorkerMirroredStrategy . MultiWorkerMirroredStrategy crée des copies de toutes les variables dans les couches du modèle sur chaque appareil sur tous les travailleurs. Il utilise CollectiveOps , une opération TensorFlow pour la communication collective, pour agréger les gradients et maintenir les variables synchronisées. Le guide tf.distribute.Strategy contient plus de détails sur cette stratégie.

 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 fournit plusieurs implémentations via le paramètre CollectiveCommunication . RING implémente des collectifs en anneau en utilisant gRPC comme couche de communication inter-hôte. NCCL utilise NCCL Nvidia pour mettre en œuvre des collectifs. AUTO reporte le choix au runtime. Le meilleur choix d'implémentation collective dépend du nombre et du type de GPU, ainsi que de l'interconnexion réseau dans le cluster.

Entraînez le modèle avec MultiWorkerMirroredStrategy

Avec l'intégration de l'API tf.distribute.Strategy dans tf.keras , le seul changement que vous apporterez pour distribuer la formation à plusieurs travailleurs consiste à inclure l'appel de construction de modèle et model.compile() dans strategy.scope() . La portée de la stratégie de distribution dicte comment et où les variables sont créées, et dans le cas de MultiWorkerMirroredStrategy , les variables créées sont des MirroredVariable et elles sont répliquées sur chacun des MultiWorkerMirroredStrategy de MultiWorkerMirroredStrategy .

 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>

Partage de jeu de données et taille de lot

Dans la formation multi-travailleurs avec MultiWorkerMirroredStrategy , le partitionnement de l'ensemble de données est nécessaire pour assurer la convergence et les performances. Cependant, notez que dans l'extrait de code ci-dessus, les ensembles de données sont directement passés à model.fit() sans avoir besoin de partitionner; cela est dû au fait que l'API tf.distribute.Strategy prend en charge automatiquement le partitionnement de l'ensemble de données. Il fragmente l'ensemble de données au niveau du fichier, ce qui peut créer des fragments asymétriques. Dans les cas extrêmes où il n'y a qu'un seul fichier, seul le premier fragment (c'est-à-dire le travailleur) recevra des données de formation ou d'évaluation et, par conséquent, tous les travailleurs recevront des erreurs.

Si vous préférez le partitionnement manuel pour votre entraînement, le partitionnement automatique peut être désactivé via l'api tf.data.experimental.DistributeOptions . Concrètement,

 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)
 

Une autre chose à noter est la taille du lot pour les datasets . Dans l'extrait de code ci-dessus, nous utilisons global_batch_size = per_worker_batch_size * num_workers , qui est num_workers fois plus grand que le cas où il s'agissait d'un seul travailleur, car la taille effective du lot par travailleur est la taille globale du lot (le paramètre passé dans tf.data.Dataset.batch() ) divisé par le nombre de tf.data.Dataset.batch() , et avec cette modification, nous tf.data.Dataset.batch() même taille de lot par tf.data.Dataset.batch() qu'auparavant.

Évaluation

Si vous passez validation_data dans model.fit , il alternera entre la formation et l'évaluation pour chaque époque. L'évaluation prenant validation_data est distribuée sur le même ensemble de travailleurs et les résultats de l'évaluation sont agrégés et disponibles pour tous les travailleurs. Comme pour la formation, l'ensemble de données de validation est automatiquement partitionné au niveau du fichier. Vous devez définir une taille de lot globale dans l'ensemble de données de validation et définir validation_steps . Un ensemble de données répété est également recommandé pour l'évaluation.

Vous pouvez également créer une autre tâche qui lit périodiquement les points de contrôle et exécute l'évaluation. C'est ce que fait Estimator. Mais ce n'est pas une façon recommandée d'effectuer une évaluation et ses détails sont donc omis.

Prédiction

Actuellement, model.predict ne fonctionne pas avec MultiWorkerMirroredStrategy.

Performance

Vous avez maintenant un modèle Keras qui est configuré pour s'exécuter dans plusieurs MultiWorkerMirroredStrategy de MultiWorkerMirroredStrategy avec MultiWorkerMirroredStrategy . Vous pouvez essayer les techniques suivantes pour ajuster les performances de la formation multi-ouvriers avec MultiWorkerMirroredStrategy .

  • MultiWorkerMirroredStrategy fournit plusieurs implémentations de communication collective . RING implémente des collectifs en anneau en utilisant gRPC comme couche de communication inter-hôte. NCCL utilise NCCL Nvidia pour mettre en œuvre des collectifs. AUTO reporte le choix au runtime. Le meilleur choix d'implémentation collective dépend du nombre et du type de GPU, ainsi que de l'interconnexion réseau dans le cluster. Pour remplacer le choix automatique, spécifiez une valeur valide pour le paramètre de communication du MultiWorkerMirroredStrategy de MultiWorkerMirroredStrategy , par exemple communication=tf.distribute.experimental.CollectiveCommunication.NCCL .
  • Si possible, tf.float les variables en tf.float . Le modèle officiel ResNet comprend un exemple de la façon dont cela peut être fait.

Tolérance aux pannes

Dans la formation synchrone, le cluster échouait si l'un des nœuds de calcul échoue et qu'aucun mécanisme de reprise après incident n'existe. L'utilisation de Keras avec tf.distribute.Strategy présente l'avantage de la tolérance aux pannes dans les cas où les travailleurs meurent ou sont instables. Pour ce faire, nous conservons l'état d'entraînement dans le système de fichiers distribué de votre choix, de sorte qu'au redémarrage de l'instance qui avait précédemment échoué ou préempté, l'état d'entraînement soit récupéré.

Étant donné que tous les travailleurs sont synchronisés en termes d'époques et d'étapes de formation, les autres travailleurs doivent attendre que le travailleur défaillant ou préempté redémarre pour continuer.

Rappel de ModelCheckpoint

ModelCheckpoint rappel ModelCheckpoint n'offre plus de fonctionnalité de tolérance aux pannes, veuillez utiliser le rappel BackupAndRestore place.

Le rappel ModelCheckpoint peut toujours être utilisé pour enregistrer les points de contrôle. Mais avec cela, si la formation a été interrompue ou terminée avec succès, afin de continuer la formation à partir du point de contrôle, l'utilisateur est responsable de charger le modèle manuellement. En option, l'utilisateur peut choisir d'enregistrer et de restaurer le modèle / les poids en dehors ModelCheckpoint rappel ModelCheckpoint .

Enregistrement et chargement du modèle

Pour enregistrer votre modèle à l'aide de model.save ou tf.saved_model.save , la destination de l'enregistrement doit être différente pour chaque travailleur. Sur les ouvriers non en chef, vous devrez enregistrer le modèle dans un répertoire temporaire, et sur le chef, vous devrez enregistrer dans le répertoire de modèle fourni. Les répertoires temporaires sur le travailleur doivent être uniques pour éviter les erreurs résultant de plusieurs travailleurs essayant d'écrire au même emplacement. Le modèle enregistré dans tous les répertoires est identique et, en général, seul le modèle enregistré par le chef doit être référencé pour restauration ou service. Nous vous recommandons d'avoir une logique de nettoyage qui supprime les répertoires temporaires créés par les travailleurs une fois votre formation terminée.

La raison pour laquelle vous devez économiser sur le chef et les ouvriers en même temps, c'est parce que vous pourriez agréger des variables pendant le point de contrôle, ce qui oblige le chef et les ouvriers à participer au protocole de communication allreduce. D'un autre côté, laisser le chef et les travailleurs enregistrer dans le même répertoire de modèle entraînera des erreurs dues à des conflits.

Avec MultiWorkerMirroredStrategy , le programme est exécuté sur chaque worker, et afin de savoir si le worker actuel est le chef, nous task_type parti de l'objet de résolution de cluster qui a les attributs task_type et task_id . task_type vous indique quel est le travail en cours (par exemple 'worker'), et task_id vous indique l'identifiant du worker. Le travailleur avec l'ID 0 est désigné comme travailleur en chef.

Dans l'extrait de code ci-dessous, write_filepath fournit le chemin du fichier à écrire, qui dépend de l'ID du worker. Dans le cas du chef (worker avec id 0), il écrit dans le chemin du fichier d'origine; pour les autres, il crée un répertoire temporaire (avec id dans le chemin du répertoire) dans lequel écrire:

 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)
 

Avec cela, vous êtes maintenant prêt à enregistrer:

 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

Comme nous l'avons décrit ci-dessus, plus tard, le modèle ne devrait être chargé qu'à partir du chemin où le chef est enregistré, supprimons donc les temporaires que les ouvriers non en chef ont sauvegardés:

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

Maintenant, quand il est temps de charger, tf.keras.models.load_model API tf.keras.models.load_model pratique et continuons le travail. Ici, nous supposons n'utiliser qu'un seul worker pour charger et continuer la formation, auquel cas vous n'appelez pas tf.keras.models.load_model dans une autre 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>

Enregistrement et restauration des points de contrôle

D'autre part, le point de contrôle vous permet d'enregistrer les poids du modèle et de les restaurer sans avoir à enregistrer le modèle entier. Ici, vous allez créer un tf.train.Checkpoint qui suit le modèle, qui est géré par un tf.train.CheckpointManager afin que seul le dernier point de contrôle soit conservé.

 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)
 

Une fois le CheckpointManager configuré, vous êtes maintenant prêt à enregistrer et à supprimer les points de contrôle non-chefs de file enregistrés.

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

Maintenant, lorsque vous avez besoin de restaurer, vous pouvez trouver le dernier point de contrôle enregistré à l'aide de la fonction pratique tf.train.latest_checkpoint . Après avoir restauré le point de contrôle, vous pouvez continuer la formation.

 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>

Rappel de BackupAndRestore

Rappel BackupAndRestore fournit des fonctionnalités de tolérance aux pannes, en sauvegardant le modèle et le numéro de l' époque actuelle dans un fichier de point de contrôle temporaire en vertu backup_dir argument BackupAndRestore . Cela se fait à la fin de chaque époque.

Une fois que les tâches sont interrompues et redémarrées, le rappel restaure le dernier point de contrôle et la formation se poursuit depuis le début de l'époque interrompue. Tout entraînement partiel déjà effectué à l'époque inachevée avant l'interruption sera jeté, de sorte qu'il n'affecte pas l'état final du modèle.

Pour l'utiliser, fournissez une instance de tf.keras.callbacks.experimental.BackupAndRestore lors de l' tf.keras.Model.fit() à tf.keras.Model.fit() .

Avec MultiWorkerMirroredStrategy, si un worker est interrompu, l'ensemble du cluster s'arrête jusqu'à ce que le worker interrompu soit redémarré. Les autres nœuds de calcul redémarreront également et le collaborateur interrompu rejoindra le cluster. Ensuite, chaque worker lit le fichier de point de contrôle précédemment enregistré et récupère son ancien état, permettant ainsi au cluster de se synchroniser. Ensuite, la formation continue.

BackupAndRestore rappel BackupAndRestore utilise CheckpointManager pour enregistrer et restaurer l'état d'entraînement, ce qui génère un fichier appelé point de contrôle qui suit les points de contrôle existants avec le dernier. Pour cette raison, backup_dir ne doit pas être réutilisé pour stocker d'autres points de contrôle afin d'éviter une collision de noms.

Actuellement, le rappel BackupAndRestore prend en charge un seul travailleur sans stratégie, MirroredStrategy et multi-worker avec MultiWorkerMirroredStrategy. Vous trouverez ci-dessous deux exemples de formation multi-travailleurs et de formation mono-travailleur.

 # 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>

Si vous inspectez le répertoire de backup_dir vous avez spécifié dans BackupAndRestore , vous remarquerez peut-être des fichiers de point de contrôle générés temporairement. Ces fichiers sont nécessaires pour récupérer les instances précédemment perdues, et ils seront supprimés par la bibliothèque à la fin de tf.keras.Model.fit() lors de la sortie réussie de votre formation.

Voir également

  1. Le guide Formation distribuée dans TensorFlow fournit un aperçu des stratégies de distribution disponibles.
  2. Modèles officiels , dont beaucoup peuvent être configurés pour exécuter plusieurs stratégies de distribution.
  3. La section Performances du guide fournit des informations sur les autres stratégies et outils que vous pouvez utiliser pour optimiser les performances de vos modèles TensorFlow.