Mise à l'échelle de l'Autorecherche de Karpathy avec 16 GPU : Résultats et Méthodes

Qu'est-ce qu'Autoresearch ?

Autoresearch est le projet d'Andrej Karpathy où un agent de codage améliore de manière autonome un script d'entraînement de réseau neuronal. L'agent modifie train.py, exécute une expérience d'entraînement de 5 minutes sur un GPU, vérifie la perte de validation, et boucle - conservant les changements qui aident, écartant ceux qui n'aident pas. Lors de la première exécution nocturne de Karpathy, l'agent a trouvé environ 20 améliorations qui se sont cumulées pour une réduction de 11 % du temps jusqu'à GPT-2 sur le classement nanochat.

Comment fonctionne Autoresearch

Le projet comporte trois fichiers :

• prepare.py - Télécharge les données, entraîne un tokeniseur, fournit le chargeur de données et la fonction d'évaluation. En lecture seule. L'agent ne peut pas le modifier.
• train.py - Le modèle GPT, l'optimiseur et la boucle d'entraînement. C'est le seul fichier que l'agent modifie.
• program.md - Instructions pour l'agent : ce qu'il peut changer, comment évaluer les résultats, quand conserver ou écarter les changements.

La contrainte est un budget fixe de 5 minutes d'entraînement en temps réel. Le travail de l'agent est de minimiser val_bpb (bits par octet de validation) dans cette fenêtre. Tout dans train.py est permis - architecture, hyperparamètres, réglages de l'optimiseur, taille de lot, profondeur du modèle - tant que le code s'exécute sans planter.

Le goulot d'étranglement : Un GPU, une expérience

Exécuter les expériences séquentiellement signifie que l'agent passe la plupart de son temps à attendre. Un cycle typique ressemble à :

1. L'agent modifie train.py (~30 secondes)
2. L'entraînement s'exécute (~5 minutes)
3. L'agent lit le résultat, planifie la prochaine expérience (~30 secondes)

L'étape 2 domine. Pendant l'étape 2, l'agent est inactif - il pourrait préparer la prochaine expérience, ou les dix suivantes. Avec une exécution séquentielle, tester des combinaisons de paramètres signifie attendre encore 5 minutes pour chaque test.

Donner à l'agent des GPU cloud

L'équipe a utilisé SkyPilot, un outil open source qui lance des tâches sur plusieurs clouds et Kubernetes à partir d'un fichier YAML. Il inclut une compétence qui apprend aux agents de codage à l'utiliser. L'agent lit la compétence, puis lance et gère des clusters GPU de manière autonome - sans configuration cloud manuelle.

Chaque expérience est définie dans un court YAML (experiment.yaml) qui spécifie le type de GPU, installe les dépendances, exécute train.py et affiche les métriques sur stdout. L'agent vérifie les résultats avec sky logs.

Résultats : ~910 expériences, ~8 heures, 16 GPU

Claude Code a utilisé la compétence SkyPilot pour lancer et gérer des expériences GPU sur 16 GPU. Sur 8 heures, il a soumis environ 910 expériences et a fait passer val_bpb de 1,003 à 0,974 - une amélioration de 2,87 % par rapport à la ligne de base.

Comment le parallélisme a changé la stratégie de recherche de l'agent

Avec un GPU, l'agent fait de l'ascension de colline gloutonne - essayer une chose, vérifier, répéter. Avec 16 GPU, il a exécuté des grilles factorielles de 10-13 expériences par vague, capturant des effets d'interaction entre paramètres qu'une recherche séquentielle aurait manqués.

Par exemple, l'agent a testé six largeurs de modèle en une seule vague, a vu la tendance immédiatement, et s'est concentré sur la meilleure - un tour au lieu de six.

L'agent a également découvert qu'il avait accès à plusieurs types de GPU (H100 et H200) et a développé une stratégie pour exploiter la différence de performance sur du matériel hétérogène : filtrer les idées sur les H100 moins chers, promouvoir les gagnants sur H200 pour validation.

Comparaison des performances

Avec 16 GPU, l'agent parallèle a atteint la même meilleure perte de validation 9 fois plus vite que la ligne de base séquentielle simulée (~8 heures contre ~72 heures).

Phases de l'expérience

• Phase 1 : Balayages d'hyperparamètres (~200 premières expériences)
• Phase 2 : Découverte d'architecture (~expériences 200-420)
• Phase 3 : Affinage du modèle plus large (~expériences 420-560)
• Phase 4 : Réglage de l'optimiseur (~expériences 560-700)
• Phase 5 : Rendements décroissants (~expériences 700-910)

L'agent a découvert que l'augmentation de la largeur du modèle comptait plus que n'importe quel hyperparamètre unique.