Concurrency and parallelism

The concurrency parameter controls how many programs are generated and evaluated simultaneously. This parameter is the most impactful runtime hyperparameter.

  • n = 1 (Sequential chain): Generate one program, wait for evaluation, and then generate the next. Each generation sees the previous result, creating a chain of incremental improvements that zooms in on a local optimum. This approach results in the slowest throughput but the most focused exploitation. Use this mode to intentionally converge on a specific region.

  • n = 3-12 (Sweet spot): This is the most widely used range in practice, balancing exploration and exploitation. Multiple programs are in flight simultaneously, so some generations don't see the latest results, introducing natural diversity. The evolutionary database maintains enough throughput for healthy population dynamics.

  • n = 13-30 (High exploration): Many programs run in parallel. Most generations don't see each other's results. This mode is useful for highly non-convex problems with many local optima where broad exploration matters more than deep exploitation.

  • n = 23-30 (Throttled; avoid): Exceeding 30 parallel generators throttles the LLM backend. Requests queue up, increasing latency per generation. Unless you have a dedicated quota, stay less than 30.

Recommendations

The following recommendations serve as a starting point for configuring concurrency and parallelism for AlphaEvolve.

Problem Type Concurrency Rationale
Well-understood, tuning known approach 3–5 Focused exploitation
General optimization, unknown landscape 8–12 Balanced exploration/exploitation
Highly non-convex, many local optima 15–25 Broad exploration
Intentional local optimum zoom-in 1 Sequential chain

Start with concurrency=10 and adjust based on the following indicators:

  • Score plateau: Increase concurrency to escape local optima.

  • Many failing evaluations: Decrease concurrency to reduce wasted compute.

  • Slow evaluations (greater than 5 minutes): Higher concurrency keeps the evaluation pipeline busy.

  • Fast evaluations (lesser than 10 seconds): Lower concurrency allows successive generations to build directly on each other's results.

Concurrency versus active experiment limits

It's important to distinguish between program-level concurrency and project-level experiment limits:

  • Program concurrency (concurrency): Configured in runSettings (between 1 and 30), this controls the number of candidate programs generated and evaluated simultaneously within a single experiment.
  • Active experiment limit: A project is subject to a cap of 30 concurrently active (STARTED or RUNNING) experiments per location. Attempting to start or resume an experiment beyond this cap returns a RESOURCE_EXHAUSTED error. To resolve this, stop or complete existing running experiments before starting new ones (modifying concurrency within an experiment doesn't change your active experiment count).