Simultanéité et parallélisme

Le paramètre concurrency contrôle le nombre de programmes générés et évalués simultanément. Il s'agit de l'hyperparamètre d'exécution le plus important.

  • n = 1 (chaîne séquentielle) : générez un programme, attendez son évaluation, puis générez le suivant. Chaque génération voit le résultat précédent, ce qui crée une chaîne d'améliorations incrémentales qui se concentre sur un optimum local. Cette approche entraîne le débit le plus lent, mais l'exploitation la plus ciblée. Utilisez ce mode pour converger intentionnellement vers une région spécifique.

  • n = 3-12 (point idéal) : il s'agit de la plage la plus utilisée en pratique, car elle équilibre l'exploration et l'exploitation. Plusieurs programmes sont en cours d'exécution simultanément. Certaines générations ne voient donc pas les derniers résultats, ce qui introduit une diversité naturelle. La base de données évolutive maintient un débit suffisant pour une dynamique de population saine.

  • n = 13-30 (exploration élevée) : de nombreux programmes s'exécutent en parallèle. La plupart des générations ne voient pas les résultats des autres. Ce mode est utile pour les problèmes très non convexes avec de nombreux optima locaux, où une exploration large est plus importante qu'une exploitation approfondie.

  • n = 23-30 (limité ; à éviter) : le dépassement de 30 générateurs parallèles limite le backend LLM. Les requêtes sont mises en file d'attente, ce qui augmente la latence par génération. Sauf si vous disposez d'un quota dédié, restez en dessous de 30.

Recommandations

Les recommandations suivantes servent de point de départ pour configurer la simultanéité et le parallélisme pour AlphaEvolve.

Type de problème Simultanéité Explication
Approche connue et bien comprise 3–5 Exploitation ciblée
Optimisation générale, paysage inconnu 8–12 Équilibre entre exploration et exploitation
Très non convexe, nombreux optima locaux 15–25 Exploration large
Zoom intentionnel sur un optimum local 1 Chaîne séquentielle

Commencez par concurrency=10 et ajustez-le en fonction des indicateurs suivants :

  • Plateau de score : augmentez la simultanéité pour échapper aux optima locaux.

  • Nombreuses évaluations en échec : diminuez la simultanéité pour réduire le gaspillage de ressources de calcul.

  • Évaluations lentes (plus de cinq minutes) : une simultanéité plus élevée permet de maintenir le pipeline d'évaluation occupé.

  • Évaluations rapides (moins de 10 secondes) : une simultanéité plus faible permet aux générations successives de s'appuyer directement sur les résultats des autres.

Simultanéité et limites des tests actifs

Il est important de faire la distinction entre la simultanéité au niveau du programme et les limites des tests au niveau du projet :

  • Simultanéité du programme (concurrency) : configurée dans runSettings (entre 1 et 30), elle contrôle le nombre de programmes candidats générés et évalués simultanément dans un seul test.
  • Limite des tests actifs : un projet est soumis à une limite de 30 tests actifs simultanément (STARTED ou RUNNING) par emplacement. Si vous tentez de démarrer ou de reprendre un test au-delà de cette limite, une erreur RESOURCE_EXHAUSTED est renvoyée. Pour résoudre ce problème, arrêtez ou terminez les tests en cours d'exécution avant d'en démarrer de nouveaux (la modification de concurrency dans un test ne modifie pas le nombre de tests actifs).