How Large Models and Compute Expand the Boundaries of Evolution

Evolutionary computation has long been constrained by a practical question: how many candidates can actually be evaluated within a limited time. Today, this constraint is being loosened simultaneously by two engineering forces—GPU parallel computeandlarge-model semantic generation. Together they form the dual engineering foundation of evolutionary computation:compute determines “how many candidates can be explored at once,” while large models determine “what forms of candidates can be explored”, and together they push the boundary of evolutionary objects beyond numerical parameters to programs, model structures, and algorithmic mechanisms themselves.

The compute foundation: moving candidate space from serial loops to tensors

In traditional implementations, population evaluation is a serial loop on the CPU: only one individual is processed at a time, and scheduling overhead accumulates with population size. Open-source foundations such as EvoX organize candidates, evaluation results, and algorithm states uniformly astensors that can be computed as a whole: mutation acts on the entire population, and evaluation and state updates, together with selection, enter the computation graph for compiler optimization. The direct engineering result is that “exploring tens of thousands of candidates simultaneously” has gone from a laboratory trick to standard practice.

Such foundations divide the system into algorithms, problem modules, workflows, and a Runtime scheduler: researchers only need to focus on “how to evolve,” while the Runtime handles scheduling batch computation to GPUs, accelerators, or distributed clusters. What must be clearly understood is that compute solvesthroughput, not “intelligence.” It does not judge whether candidates are good; it is only responsible for computing the fitness of the entire population in one pass. It is theunderlying supportfor expanding candidate space, but it does not determine what candidates look like.

The semantic foundation: raising candidate form from numerical vectors to structural solutions

The contribution of large models is not faster computation, but that they understand code, domain knowledge, and task context, and possesssemantic-level generation capability. As a result, they can construct structurally complex candidates—a piece of directly callable solver code, the topology of a surrogate model—rather than only outputting a numerical vector. The “form” space of candidates is thereby opened up.

The three-level expansion of evolutionary object boundaries

Numerical parameters: the classic setting, where population members are a set of parameter values under a fixed structure.
Program / model structure: population members become executable code snippets, or the topology of networks and surrogate models. Large-model generation capability is precisely the gateway to this level.
Algorithmic mechanisms: even the process of “how to generate and how to evaluate” itself becomes an object of evolution. This is precisely the premise that makes later approaches of “using evolution to improve evolution” (such as MetaDE and AutoPSO) possible.

Take airfoil optimization as an example: traditional approaches can only search over a number of preset numerical parameters; when a large model can read and write solver code and construct surrogate model structures, and the GPU can evaluate an entire population in parallel batches, the search object shifts upward from “a set of parameter values” to “a generation-and-evaluation scheme itself.”

Complementary, not substitutive

The two are complementary: compute expands searchBreadth, while large models improve candidatequality and formal complexity; without either one, boundary expansion does not hold. With only compute and no semantic generation, the search object remains confined to pre-hardcoded encodings; with only generation capability and no batch evaluation, massive candidates cannot be screened within an acceptable time.

The cost of expanding boundaries

Expanding boundaries also introduces new constraints: first,evaluation cost rises, as a single evaluation may go from milliseconds to minutes; second,correctness verification becomes harder, since generated code may fail to compile or may not satisfy physical and engineering constraints; third,the criteria for what counts as a “usable answer” become more ambiguous, requiring integration with multi-objective trade-offs, expert decision-making, and other stages.

Common misconceptions

Treating large models as “faster fitness calculators” is the most typical misreading. The value of large models lies in candidategeneration—expanding the form and complexity of candidates; batch evaluation is still handled by tensorized parallel pipelines. Conversely, assuming that sufficient compute alone can automatically search out program-level candidates also ignores the question of “where candidates come from.”

Flowchart: GPU Parallelism and Large Models Collaboratively Expanding Evolutionary Boundaries

The diagram shows that expanding evolutionary boundaries depends on a dual foundation: GPUs and a tensorized Runtime move population evaluation from serial loops to batch parallelism, determining how many candidates can be explored at once; large models provide semantic-level generation, determining what forms of candidates can be constructed. Once the two complement each other, evolutionary objects can expand from numerical parameters to program/model structures, and further to algorithmic mechanisms—but this also brings new constraints such as evaluation cost, correctness verification, and criteria for judging answers.

Question 1

In the dual engineering foundation described on this page, what is the most direct role of GPU parallel compute?

Automatically rewriting candidate encodings from numerical vectors into executable programs

Changing population evaluation from serial CPU loops to tensorized batch computation, making simultaneous exploration of large-scale candidates engineering-feasible

Deciding which selection operator and crossover method an evolutionary algorithm should use

Automatically judging whether candidate solutions satisfy domain constraints, thereby replacing manually set evaluation criteria

Question 2

Which is the key capability that large models bring to the evolutionary process?

Understanding code, domain knowledge, and task context, thereby generating structurally complex candidate solutions

Guaranteeing that every generated candidate is correct and directly deployable

Replacing batch evaluation for each candidate and directly providing precise fitness values

Expanding the population size by another order of magnitude under the same budget

Question 3

According to the ladder model on this page, what is the correct order for expanding evolutionary object boundaries?

Numerical parameters → program / model structure → algorithmic mechanisms

Numerical parameters → hyperparameters → training data scale

Algorithmic mechanisms → model structure → numerical parameters

Model structure → numerical parameters → data scale

Question 4

Regarding the relationship between compute and large models in evolutionary computation, which of the following statements is correct?

Large models can replace compute, because high generation quality means large-scale batch evaluation is unnecessary

The two are complementary: compute expands search breadth, while large models improve candidate quality and formal complexity—neither can be missing

Compute can replace large models, since sufficiently high parallelism can automatically search out program-level candidates

The two can substitute for each other, and in practice it is enough to keep only the lower-cost one

Question 5

Once evolutionary objects expand to the level of programs and algorithmic mechanisms, what is most necessary to build up in tandem?

Reducing population size to lower overall computational complexity

Controlling candidate evaluation cost, verifying correctness, and defining criteria for “usable answers,” while integrating with multi-objective trade-offs and expert decision-making

Disabling surrogate models and evaluating all candidates with exact simulation

Removing the fitness function and letting large models directly provide the final answer

Case Study: Shifting the Search Object Upward in Airfoil Optimization

Read the scenario and answer the questions below.

A certain aerodynamic design team works on airfoil optimization. Their early approach was to fix the solver and mesh, search only over a number of preset numerical parameters such as camber and thickness distribution, and evaluate fitness serially on a single CPU, requiring several hours for one full run. Now the team has done two things: first, let large models read and write solver code and construct surrogate model structures; second, move population evaluation to GPUs, evaluating the whole population at once in a tensorized batch manner. After the redesign, the searchable range has expanded noticeably, but new problems have also appeared, such as candidate code failing to compile and some candidate evaluations taking far longer than expected.

1. In this scenario, how has the team's search object changed? Explain with reference to the ladder “numerical parameters → program / model structure → algorithmic mechanisms.”

Answer:
Before the redesign, the search object was a set of numerical parameter values under a fixed structure, and the candidate space was locked in by the encoding scheme. After introducing the semantic generation capability of large models, solver code snippets and surrogate model structures themselves enter the candidate set, and the search object shifts upward from “a set of parameter values” to “a generation-and-evaluation scheme itself.” If the process of “how to generate candidates and how to allocate evaluation budget” is further parameterized so that this part also undergoes selection and mutation, then the algorithmic mechanism level is reached—exactly the kind of approach that “uses evolution to improve evolution.” The role of compute is to ensure that the shifted-up search space can still be evaluated in batches; otherwise, the expanded space cannot be screened within an acceptable time.

2. What supporting capabilities does the team still need to build up? Identify at least two and explain why.

Answer:
First, evaluation cost and budget management. The more complex the candidate form, the more expensive a single evaluation becomes (the scenario already shows candidates taking longer than expected), requiring tiered evaluation, surrogate-model pre-screening, or an evaluation budget allocation mechanism to prevent compute from being consumed by a few expensive candidates. Second, correctness verification and fallback mechanisms. Code generated by large models may fail to compile or may not satisfy physical and engineering constraints, so automated syntax, interface, and constraint validation must be established, with the ability to fall back to usable candidates on failure; otherwise, the population will be polluted by invalid individuals. Third, criteria for “usable answers” and an interface for expert decision-making. After boundary expansion, superiority and inferiority are no longer clearly expressed by a single fitness value but involve multi-objective trade-offs such as aerodynamic performance and structural feasibility, requiring clear acceptable boundaries and integration with domain expert decision-making.