SageMaker Training Compiler : bonnes pratiques et considérations

Bonnes pratiques d’ordre général

• Pensez à consulter Types d’instance pris en charge et Modèles testés.

• Lorsque vous créez un générateur de jetons pour un modèle NLP en utilisant la bibliothèque des transformeurs Hugging Face dans votre script d’entraînement, veillez à utiliser une forme de tenseur d’entrée statique en spécifiant padding='max_length'. N’utilisez pas padding='longest', car le remplissage à la séquence la plus longue du lot peut changer la forme du tenseur pour chaque lot d’entraînement. La forme d’entrée dynamique peut déclencher une recompilation du modèle et augmenter la durée totale d’entraînement. Pour obtenir plus d’informations sur les options de remplissage des créateurs de jetons de transformeur, consultez Remplissage et troncature dans la documentation des transformeurs Hugging Face.

• Mesurez l’utilisation de la mémoire du GPU pour vous assurer que vous utilisez la taille maximale de lot que peut contenir cette mémoire. Amazon SageMaker Training Compiler réduit l’empreinte mémoire de votre modèle pendant l’entraînement, ce qui vous permet généralement d’augmenter la taille du lot batch_size dans la mémoire du GPU. L’utilisation d’une batch_size plus importante permet une meilleure utilisation du GPU et réduit la durée totale de l’entraînement.

  Lorsque vous ajustez la taille du lot, vous devez également ajuster learning_rate de manière appropriée. Par exemple, si vous avez augmenté la taille du lot d’un facteur de k, vous devez procéder à un ajustement linéaire de learning_rate (simple multiplication par k) ou multiplier par la racine carrée de k. Vous obtiendrez ainsi un comportement de convergence identique ou similaire avec un temps d’entraînement réduit. Pour connaître les références des tests de batch_size pour les modèles les plus populaires, consultez Modèles testés.

• Pour déboguer la tâche d’entraînement accélérée par le compilateur, activez l’indicateur debug dans le paramètre compiler_config. Cela permet à SageMaker AI de placer les journaux de débogage dans les journaux des tâches d’entraînement SageMaker.

  huggingface_estimator=HuggingFace(
      ...
      compiler_config=TrainingCompilerConfig(debug=True)
  )

  Notez que si vous activez le débogage complet de la tâche d’entraînement avec le compilateur, cela peut ajouter une surcharge.

Bonnes pratiques pour PyTorch

• Si vous apportez un modèle PyTorch et que vous souhaitez le vérifier, assurez-vous d’utiliser la fonction de sauvegarde du modèle de PyTorch/XLA pour vérifier correctement votre modèle. Pour plus d’informations sur la fonction, consultez torch_xla.core.xla_model.save dans la documentation PyTorch sur les périphériques XLA.

  Pour savoir comment ajouter les modifications à votre script PyTorch, consultez Modèles linguistiques de grande taille utilisant directement PyTorch (sans l’API Trainer des transformeurs Hugging Face).

  Pour plus d’informations sur l’application réelle de l’utilisation de la fonction d’enregistrement de modèle, consultez Checkpoint Writing and Loading dans le billet de blog Hugging Face on PyTorch/XLA TPUs: Faster and cheaper training.

• Pour bénéficier d’une durée d’entraînement optimale pour l’entraînement distribué, considérez ce qui suit.

  • Utilisez des instances avec plusieurs GPU à la place d’instances à un seul GPU. Par exemple, une seule instance ml.p3dn.24xlarge présente une durée d’entraînement plus courte que 8 instances ml.p3.2xlarge.

  • Utilisez des instances avec prise en charge d’EFA, telles que ml.p3dn.24xlarge ou ml.p4d.24xlarge. Ces types d’instance présentent de plus grandes vitesses réseau et réduisent la durée d’entraînement.

  • Réglez le paramètre preprocessing_num_workers pour les jeux de données, afin que l’entraînement des modèles ne soit pas retardé par un prétraitement lent.

• Évitez la journalisation, les points de contrôle et le profilage des tenseurs de modèles qui conduisent à des évaluations explicites. Pour comprendre ce qu’est une évaluation explicite, prenons l’exemple de compilation de code suivant.

  a = b+c
  e = a+d

  Un compilateur interprète le code comme suit et réduit l’empreinte mémoire de la variable a :

  e = b+c+d

  Considérons maintenant le cas suivant où le code est modifié pour ajouter une fonction d’affichage de la variable a.

  a = b+c
  e = a+d
  print(a)

  Le compilateur effectue une évaluation explicite de la variable a comme suit.

  e = b+c+d
  a = b+c    # Explicit evaluation
  print(a)

  Dans PyTorch, par exemple, évitez d’utiliser torch.tensor.items(), qui pourrait introduire des évaluations explicites. Dans le cadre du deep learning, ces évaluations explicites peuvent entraîner une surcharge, car elles rompent les opérations fusionnées dans le graphe de compilation d’un modèle et conduisent à un nouveau calcul des tenseurs.

  Si vous souhaitez continuer à évaluer périodiquement le modèle au cours de l’entraînement tout en utilisant SageMaker Training Compiler, nous vous recommandons d’effectuer la journalisation et les points de contrôle à une fréquence plus faible afin de réduire la surcharge due aux évaluations explicites. Par exemple, effectuez une journalisation toutes les 10 époques plutôt qu’à chaque époque.

• La compilation des graphes est exécutée durant les premières étapes de l’entraînement. Par conséquent, les premières étapes sont généralement très lentes. Cependant, il s’agit d’un coût de compilation unique qui peut être amorti par un entraînement de plus longue durée, car la compilation permet d’accélérer considérablement les prochaines étapes. La surcharge de compilation initiale dépend de la taille du modèle, de la taille des tenseurs d’entrée et de la distribution des formes des tenseurs d’entrée.

• L’une des erreurs les plus courantes lors de la compilation d’un modèle PyTorch est due à un type de périphérique incorrect pour les opérateurs et les tenseurs. Pour compiler correctement un modèle PyTorch, assurez-vous d’utiliser des périphériques XLA (xm.xla_device()) au lieu d’utiliser CUDA ou de mélanger des périphériques CUDA et XLA.

• mark_step() est une barrière uniquement pour XLA. Si la tâche d’entraînement n’est pas correctement définie, cela entraînera son blocage.

• PyTorch/XLA fournit des API d’entraînement distribué supplémentaires. La mauvaise programmation des API entraîne une collecte incorrecte des gradients, ce qui conduit à l’échec de la convergence de l’entraînement.