Small Experiments, Cheaper Decisions: A Case Study in Staged Promotion for Micro-Pretraining

Résumé Technique : Expériences de petite taille, décisions moins coûteuses

Énoncé du problème
Le document traite du compromis opérationnel inhérent à l'utilisation de sessions de pré-entraînement courtes comme filtres pour des budgets plus importants. Bien que les sessions courtes permettent de tester de nombreuses configurations candidates, elles risquent de promouvoir des configurations qui semblent performantes uniquement à de très petits budgets, mais qui échouent à survivre à des horizons d'entraînement plus longs, à des graines (seeds) différentes ou à des hôtes matériels différents. L'étude présente cela non pas comme un problème général d'optimisation des hyperparamètres (HPO), mais comme un problème de « promotion par étapes » pour un exécuteur de micro-pré-entraînement à nœud unique, GPU unique et fixe. L'objectif est de déterminer si un calendrier de promotion à deux agents, petit et auditable, peut conserver une référence de long horizon connue tout en identifiant et en arrêtant les alternatives plausibles qui ne parviennent pas à franchir les seuils de continuation gelés, sans pour autant trop élaguer l'ensemble des candidats sur la base de signaux précoces instables.

Méthodologie
L'étude emploie un protocole de promotion par étapes multi-fidélité sur un exécuteur de micro-pré-entraînement fixe dérivé de travaux antérieurs [1]. L'expérience utilise une matrice de douze conditions, incluant une « référence de pont » (la meilleure condition d'un filtrage précédent), un comparateur gourmand, un contrôle à haute pénalité et diverses variantes plus petites ou locales.

Le protocole se déroule via les étapes suivantes sur deux blocs d'hôtes hétérogènes (Windows avec NVIDIA A100 et Linux avec NVIDIA L40S) :

1. Instrumentation (Étape 0) : Un test de fumée de 2 minutes pour vérifier le fonctionnement de l'exécuteur.
2. Écrans peu coûteux (Étapes 1A–1C) : Exécutions avec des budgets de 5 et 10 minutes. L'écran de 10 minutes est répliqué avec une nouvelle graine (seed 43) pour évaluer la stabilité.
3. Confirmation par réplication (Étapes 2A–2B) : Les quatre meilleurs candidats des écrans peu coûteux sont exécutés pendant 60 minutes en utilisant les graines 44 et 45.
4. Confirmation de long horizon (Étapes 3–3B) : Les trois meilleurs candidats de la porte de 60 minutes sont exécutés pendant 12 heures en utilisant les graines 46 et 47.

Règles de décision et seuils
Les décisions de promotion sont régies par des « portes gelées » et des seuils prédéclarés plutôt que par des algorithmes de recherche adaptatifs :

• Politique de rétention : Le protocole retient explicitement les valeurs de la référence de pont et de contrôle, quel que soit le rang lors des budgets courts, afin d'éviter de rejeter la ligne de base de long horizon.
• Critères d'arrêt :
  • Comparateur gourmand : Doit être à moins de 0,010 val_bpb (bits par octet de validation) de la référence dans toutes les cellules hôte-graine (règle de quasi-équivalence).
  • Sentinelle moins chère (d8/ar48) : Doit être à moins de 0,020 val_bpb de la référence sur l'écart moyen de 12 heures (règle d'architecture plus légère).
• Métriques : Le point final est le val_bpb (plus bas est le mieux), calculé sur un fragment de validation fixe. L'étude utilise des statistiques descriptives (rangs, écarts, écarts types) plutôt que des p-values, reconnaissant le nombre limité de graines et les blocs d'hôtes hétérogènes.

Résultats clés

1. Instabilité des écrans précoces : Les classements précoces étaient hautement instables et sensibles à l'hôte. À 5 minutes, les meilleures conditions différaient entre Windows et Linux. À 10 minutes, la condition moyenne la meilleure était d8/ar48 (un modèle plus petit), et non la référence de pont. Un élagage brutal à ce stade aurait éliminé le gagnant final.
2. Rétention de la référence de pont : La porte de 60 minutes par réplication a réussi à retenir la référence de pont, qui a classé premier dans les quatre cellules hôte-graine. Cela a permis à la référence de pont de passer à la confirmation de 12 heures.
3. Confirmation finale : Dans le paquet de 12 heures, la référence de pont a classé premier dans les quatre cellules hôte-graine (Windows/Linux × graines 46/47).
   • Le comparateur gourmand a échoué à la règle de 0,010 val_bpb pour toutes les cellules (écart max : 0,022927).
   • La sentinelle moins chère (d8/ar48) a échoué à la règle de 0,020 val_bpb de l'écart moyen (écart moyen : 0,032786).
4. Frontière coût-qualité : Les modèles plus petits ont traité nettement plus de tokens dans un même budget de temps réel (par exemple, d8/ar48 a traité ~10,09B de tokens contre ~7,28B pour la référence de pont) mais ont tout de même obtenu un val_bpb final moins bon. Les résultats sont notés comme étant « confondus par la capacité », car la référence de pont est le plus grand modèle (50,3 millions de paramètres) par rapport aux alternatives.
5. Comptabilité du budget : La branche de 12 heures exécutée a consommé 144 heures-GPU. Le protocole complet par étapes (incluant le screening) a totalisé 169,2 heures-GPU. Ceci est comparé à des contre-factuels comptables : continuer les quatre candidats de 60 minutes aurait coûté 192 heures-GPU, et continuer les neuf candidats de 10 minutes aurait coûté 432 heures-GPU.

Signification et affirmations
Le document affirme explicitement que sa contribution est une discipline méthodologique plutôt qu'une nouvelle architecture ou un optimiseur supérieur.

• Discipline opérationnelle : L'étude démontre qu'une règle de promotion par étapes conservatrice (écrans peu coûteux larges, portes intermédiaires répliquées, seuils gelés et arrêt explicite) peut réduire efficacement les dépenses de long horizon tout en conservant une référence de long horizon connue.
• Avertissement sur la stabilité : Elle souligne que les écrans précoces sont insuffisants pour un élagage agressif ; le gagnant final de long horizon n'était pas le leader des budgets courts.
• Complémentarité : Le protocole est présenté comme un enregistrement de décision impliquant l'humain dans la boucle, complémentaire et non un remplacement des systèmes d'HPO automatisés tels que Hyperband, ASHA ou BOHB.
• Portée modeste : Les auteurs soulignent que les résultats sont limités à l'exécuteur spécifique, à la matrice de candidats et aux blocs d'hôtes utilisés. L'étude ne prétend pas prouver l'optimalité globale, ni que la règle de promotion sépare la qualité du flux de travail de la capacité du modèle, car la comparaison finale reste confondue par la capacité. La valeur principale réside dans la « discipline » consistant à s'arrêter lorsque des branches plausibles ne répondent pas aux critères prédéclarés.