Optimisation d'AutoResearch sur RTX 5090 : Ce qui a échoué et ce qui a fonctionné

Problèmes initiaux et chemin fonctionnel

La configuration initiale pour exécuter AutoResearch sur un système RTX 5090/Blackwell était "gravement défectueuse" avec des performances extrêmement médiocres—seulement quelques milliers de tokens par seconde et une MFU (Utilisation des FLOPs du modèle) essentiellement inutile, bien que le code fonctionnait techniquement.

Le chemin de configuration fonctionnelle impliquait :

• Éviter le chemin de compilation du modèle complet défectueux sur cette configuration
• Conserver les bonnes améliorations de compilation de l'optimiseur fusionné là où elles aidaient réellement
• Utiliser le chemin d'attention stable SDPA/CuDNN
• Ajuster le lot total et le budget de temps empiriquement au lieu de deviner
• Automatiser la boucle de benchmark/extraction/stratégie/relance

Ce qui a échoué

Plusieurs modes d'échec étaient trompeurs :

• Un chemin techniquement correct mais catastrophiquement lent
• Une interprétation trompeuse de la MFU jusqu'à ce que le dénominateur soit corrigé pour le contexte 5090
• Des paramètres de lot par appareil plus élevés qui semblaient devoir aider mais aggravaient en réalité les choses
• Des bugs d'automatisation autour du nettoyage des verrous/des crochets d'achèvement/de l'ordre de distribution

Comme le développeur l'a noté : "Il y avait plusieurs façons d'obtenir une exécution qui semblait vivante tout en faisant quelque chose de stupide."

Ce qui a aidé

Les véritables améliorations sont venues de :

• La réactivation du chemin de compilation de l'optimiseur fusionné
• La réduction du lot total par rapport au paramètre original plus grand
• La validation de 2**17 comme meilleure région de lot total
• L'augmentation du budget de temps une fois le régime de lot stable trouvé
• Le traitement de l'automatisation comme faisant partie du système de benchmark, pas comme une réflexion après coup

Progression des performances

La progression des exécutions utiles a montré des améliorations claires :

• Exécution saine de base : val_bpb : 1.165452, mfu : 40.49%
• Amélioration de la compilation de l'optimiseur fusionné : val_bpb : 1.155400, mfu : 42.88%
• TOTAL_BATCH_SIZE = 2**18 : val_bpb : 1.108381, mfu : 43.18%
• Validation TOTAL_BATCH_SIZE = 2**17 : val_bpb : 1.089424, mfu : 43.03%
• Meilleur résultat actuel de la boucle automatique : TOTAL_BATCH_SIZE = 2**17, TIME_BUDGET = 1200, multiplicateur LR = 1.0, val_bpb : 0.999445, mfu : 42.56%, total_tokens_M : 387.8, num_steps : 2959

Meilleure configuration actuelle

Le meilleur résultat trouvé jusqu'à présent :

• TOTAL_BATCH_SIZE = 2**17
• TIME_BUDGET = 1200
• Multiplicateur LR = 1.0

Cette combinaison a surpassé les variantes avec lot plus grand, la variante plus petite 2**16, un test avec LR plus bas et des budgets d'entraînement plus courts.

Principaux enseignements

La principale leçon était que la configuration gagnante n'était pas une configuration "tout maximiser". Le meilleur chemin impliquait un régime de lot stable, un horizon d'entraînement plus long et une élimination minutieuse des erreurs d'automatisation et de backend.

Le développeur a souligné que si vous travaillez sur l'entraînement Blackwell/5090 et observez un comportement bizarre, "ce n'est peut-être pas votre imagination. Certains chemins sont simplement bien pires qu'ils ne le paraissent au premier abord." La partie utile de cet exercice a été de trouver un chemin qui est stable, automatisable, reproductible et suffisamment bon pour construire de véritables expériences de suivi dessus.