Les options pour réduire le temps d’entraînement pour Transformers

Le but de ce rapport est d’explorer deux optimisations très simples, qui peuvent réduire le temps d’entraînement de manière significative sur la bibliothèque Transformers sans compromettre la précision.

Nous avons exécuté 21 expériences + 12 expériences de reproductibilité sur un grand jeu de données NLP connu (la partie française de X-NLI). Et nous avons démontré qu’en utilisant la version de base du modèle BERT prêt à l’emploi français (CamemBERT), avec les paramètres par défaut, un GPU grand public et ces deux optimisations, nous pouvons atteindre une précision de 81,5% avec un entraînement de 16 minutes, pour une longueur maximale de token (jeton) de 128. Ce qui bat de 0,5 point le score obtenu avec un entraînement de 56 minutes sans aucune optimisation, et de 0,3 point le score obtenu pour cette tâche par les auteurs du modèle CamemBERT.

Le gain de temps est encore plus impressionnant sur le même modèle, pour une longueur maximale de token de 493, où le temps d’entraînement passe de 4h38 sans optimisation à 1h01 avec toutes les optimisations, toujours avec le même score. On a eu un gain de temps d’entraînement similaire sur unmodèle large (de 4h à 1h30 pour longueur maximale de token de128).

Consultez notre article connexe pour plus de détails.

Nous avons réalisé de nombreuses expériences sur la partie française de X-NLI que nous avons enregistrées sur wandb :

• modèle de base CamemBERT : 14 expériences + 5 expériences de reproductibilité
• large modèle Camembert : 7 expériences + 5 expériences de reproductibilité

Dans chacun de ces cas (base/large), les expériences ont été divisées en deux groupes :

• un mini-lot de 64 séquences de 128 tokens max
• un mini-lot de 2X8 séquences de 493 tokens max

Comme expliqué dans cet article, la configuration à 128 tokens génère une troncature de 3% des exemples du set d’entraînement.

Pour chacun de ces groupes, nous considérons la combinaison de 3 optimisations pour l’accélération de l’entraînement :

• la précision mixte (Nvidia Apex compilée avec GCC 7)

• le rembourrage dynamique

• le traitement en lots intelligent – nommé uniform length batching, (traitement en lots à longueur uniforme) dans l’article parce que les expériences ont été enregistrées avec ce nom stupide, je le garde dans ce rapport.

  Si vous voulez essayer ces expériences par vous-mêmes, le code source est disponible sur ce Github gist.

Temps d’entraînement – modèle de base – lot de 2 étapes de 8 séquences de 493 tokens

Dans la première partie de ce rapport, nous nous concentrons sur la version de base de ce modèle.

Lorsqu’on applique aucune limite à la longueur de la séquence, le temps d’entraînement le plus court est atteint avec les 3 options activées : la précision mixte, le rembourrage dynamique et le traitement en lots intelligent, ce qui signifie qu’elles ont chacune leur utilité.

Cependant, ces options n’ont pas toutes le même effet ; le rembourrage dynamique aura de loin le plus d’impact, ce qui est logique dans un jeu de données où 97% les séquences sont inférieures à 128 séquences. Le traitement en lots intelligent favorise cette stratégie, et constitue la deuxième option la plus importante.

Temps d’entraînement – modèle de base – un lot à une étape de 64 séquences de 128 tokens

Lorsqu’on limite la longueur de token à 128, le temps d’entraînement le plus court est encore une fois atteint avec les 3 options activées : la précision mixte, le rembourrage dynamique et le traitement en lots intelligent.

Cependant, l’impact de la précision mixte est plus important qu’auparavant.

• Utilisée seule, la précision mixte génère une vitesse de 4% supérieure à celle du rembourrage dynamique et du traitement en lots intelligent seuls.
• Utilisée seule, la précision mixte est de 34% plus lente que lorsqu’elle est combinée avec le rembourrage dynamique et le traitement en lots intelligent.

Code intégral dans Github gist →

Précision – modèle de base – toutes les configurations

Nous avons analysé toutes les configurations ensemble puisqu’aucune tendance unique n’est apparue, quels que soient les regroupements que nous avions effectués. Cela signifie que l’optimisation de vitesse n’a aucun effet évident sur la précision.

Tout d’abord, on peut remarquer que tous les scores sont entre 0,810 et 0,820, un intervalle très faible par rapport à autant d’expériences avec différents modèles.

Il est très probable que si nous entraînons les modèles pour plus d’1 epoch, nous relèverions un intervalle plus important, mais le score XNLI (la partie française) rapporté dans l’article sur CamemBERT pour 10 epochs est « seulement » de 0,812.

Le meilleur score (0,820) est atteint en 2 configurations :

• un lot de 64 séquences de 128 tokens avec le rembourrage dynamique seul
• un lot de 16 séquences de 493 tokens avec le rembourrage dynamique seul

Il n’y aucune raison qui explique que le rembourrage dynamique seul optimise la précision, nous pensons que c'est seulement dû au hasard.

Une autre option à vérifier est l’impact du traitement en lots intelligent seul, comparé à la configuration n’ayant aucune option activée :

• un lot de 16 séquences de 493 tokens, sans option : 0,814
• un lot de 16 séquences de 493 tokens, avec le traitement en lots intelligent seul : 0,816
• un lot de 64 séquences de 128 tokens, sans option : 0,810
• un lot de 64 séquences de 128 tokens avec le traitement en lots intelligent seul : 0,817

Le traitement en lots intelligent semble avoir un impact légèrement positif sur la précision.

Code intégral dans Github gist →

Compromis entre précision et temps d’entraînement pour le temps d’entraînement – lot de 8X2 séquences de 493 tokens

Compromis entre précision et temps d’entraînement pour un lot de 64 séquences de 128 tokens

Expériences de reproductibilité – modèle de base

Nous réitérons 5 fois le paramétrage le plus rapide (rembourrage dynamique + traitement par lots intelligent + précision mixte + longueur maximale de tokens de 128) avec différentes seeds (graines). Les scores sont stables (entre 0,813 et 0,819), constamment au-dessus de celui rapporté dans l’article sur CamemBERT (0,812) pour cette version du modèle.

Expériences sur un modèle large

La deuxième partie de ce rapport est dédiée à la version large de ce modèle (paramètres 335M) plutôt qu’à la version de base (paramètres 110M).

Dans cette configuration, sur les 12 Go d’une GPU 2080 TI, la taille d’étape (step size) maximale est inférieure à celle du modèle de base :

• pour des longueurs maximales de token de 128, la taille d’étape est de 8, nous cumulons 2 étapespour atteindre un lot de 16 exemples

• pour des longueurs maximales de token de 493, la taille d’étape est de 2, nous cumulons 8 étapespour atteindre un lot de 16 exemples

  Les 2 buts d’optimisations présentés dans l’article Medium se concentrent sur la génération de lots/étapes.

Étant donné que la taille du GPU utilisé pour les tests est limitée à 12 Go, bien que le modèle soit 3 fois plus grand, la taille d’étape est inférieure.

Sans aucune optimisation, les temps d’entraînement sont très longs (15 heures pour des longueurs de tokende 493, 4 heures pour 128 tokens). Avec toutes les optimisations, les temps d’entraînement sont réduits, mais sont encore assez conséquents (7 heures pour 493 tokens, 1h30 pour 128 tokens).

Quelle que soit la configuration appliquée (avec ou sans optimisation), les scores obtenus ici en 1 epoch sont légèrement plus bas que ceux rapportés dans l’article pour 10 epochs + arrêt précoce (le meilleur modèle large optimisé atteint 0,856 et l’article indique 0,857).

Temps d’entraînement – modèle large – lot de 2 étapes de 8 séquences de 128 tokens

Temps d’entraînement – modèle large – lot de 4 étapes de 2 séquences de 493 tokens

Expériences de Reproductibilité – modèle large

Étapes suivantes

Nous espérons que vous avez trouvé cet article utile, et nous vous encourageons à effectuer ces expériences par vous-même, le code source est disponible sur ce Github gist.

Vous pouvez me suivre sur Twitter @pommedeterre33.