Baidu’s ERNIE Evolve automates AI research and inference

By Elena Vasquez

On November 9, 2026, Baidu introduced ERNIE Evolve and reported 33.7% higher throughput in one deterministic ERNIE-5.5-Flash inference test.

Baidu’s automated research system does more than write code: it selects research directions, edits AI code, runs experiments, and keeps only improvements that pass separate evaluation and review.

The stakes are practical: ERNIE Evolve targets both AI code and the systems serving the in-development ERNIE-5.5-Flash. Baidu says recursive self-improvement must remain “human-controlled and interruptible,” with oversight built into the loop.

How does ERNIE Evolve run research?

Baidu’s ERNIE Evolve begins with a repository, an optimization objective, and evaluation criteria. It then changes code and runs experiments in isolated environments.

Within Baidu’s design, an outer-loop Director chooses a research direction and a starting version. The Director uses an Experience Bank of previous experiments and a Knowledge Base of papers, open-source code, and domain knowledge.

Baidu’s parallel lanes hold trees of candidate versions. Within each lane, a Selector chooses a candidate and hypothesis. An Executor implements the change.

Baidu’s loop uses failures and successes to guide later iterations. It selects lines of inquiry and executes tests instead of only generating code.

In Baidu’s system, acceptance depends on a fixed Evaluator and a separate Reviewer. The Evaluator sits outside the repository and remains invisible to the agents.

Baidu’s Evaluator excludes out-of-scope changes and requires gains above a noise threshold. The Reviewer checks whether the candidate follows the research direction and discards evaluation-loophole exploits.

Under Baidu’s design, an off-direction candidate cannot become the best version. The two review layers stand between an agent’s proposal and an accepted result.

What did the public benchmarks show?

Baidu compares ERNIE Evolve with the public results used in its evaluation. The company reports:

• NanoChat AutoResearch: With five-minute training on one B200, ERNIE Evolve reached 0.8763 validation bits per byte, below the public comparison’s 0.887791 mean across 10 seeds. Baidu marks lower as better.
• NanoGPT Speedrun Track 1: On eight H100 GPUs, it reached 3.28 FineWeb validation loss in 38.92 seconds over 18 runs, versus 39.9 seconds for the public comparison. Baidu marks lower as better.
• NanoGPT Speedrun Track 3: With fixed data, batch size, and architecture, it took 2,590 steps over eight runs to reach the same loss. The public comparison took 2,690 steps over eight runs. Baidu marks lower as better.
• SOL-ExecBench: Across 235 kernel problems, ERNIE Evolve posted a 0.819 mean speed-of-light score against an analytical B200 roofline. The leading public score was 0.827. Baidu marks higher as better.

The SOL-ExecBench result qualifies the broader claim. ERNIE Evolve did not lead every listed metric, although Baidu’s comparison places it ahead of Recursive and Hyra-1.0 on that task.

On NanoChat, Baidu says the system added two prediction branches alongside the neural network. One used n-gram statistics from the training corpus, and one retrieved matching documents and predicted from their continuations.

A learned gate adjusted the mixture using each branch’s performance at earlier token positions. The disclosed design mixes statistical prediction, document retrieval, and gating, rather than relying on the neural network alone.

Baidu also published a results repository with final code and measurement logs. Each log embeds its executed code or identifies that code by SHA-256.

The repository lists seven SOL-ExecBench kernel artifacts with scores from 0.6669 to 0.9920. It does not redistribute NVIDIA’s task definitions or workload data.

How did ERNIE Evolve speed up ERNIE-5.5-Flash?

Baidu applied ERNIE Evolve to three inference problems for the in-development ERNIE-5.5-Flash: low-latency inference on Kunlunxin P800, deterministic inference throughput on GPUs, and single-request decoding speed.

Baidu said most baselines had already been optimized by engineers. Automated changes still had to pass the same load tests and correctness checks as engineer-submitted work.

On Kunlunxin P800, Baidu reports that four research rounds raised generation speed to 623.6% of baseline. The model and deployment setup remained unchanged, and all rounds passed correctness checks.

Early rounds enabled fused manifold-constrained hyper-connections and speculative decoding. Later rounds reduced host-side scheduling and synchronization overhead.

A fourth-round dispatch fix enabled DeepEP’s low-latency path.

For reinforcement-learning training, the deterministic task required generated tokens and log probabilities to be bitwise identical regardless of batch composition. The output also had to match full-sequence recomputation.

SGLang’s deterministic mode supports those requirements by fixing reduction order, but that limits GPU utilization. After roughly three days, Baidu reports that the work cut average time per output token by 26% and time to first token by 12%, with determinism preserved.

The largest individual gain came from replacing deterministic sampling, which had consumed about 14% of GPU time per step. A Triton kernel processed vocabulary chunks in parallel.

For single-request GPU decoding, Baidu reports a 14.9% speed increase over an already engineer-tuned service, with unchanged accuracy. Three of seven research directions produced gains.

One direction used native FP16 instructions for FP8 matrix multiplications with fewer than eight input rows. Another replaced sequential expert scans with a two-level mixture-of-experts scheduler.

What could make automated optimization less reliable?

Baidu’s tests exposed tighter module and determinism constraints. The company also found measurement noise comparable to individual gains.

Baidu’s environments spanned inference engines, kernel libraries, hardware plugins, and service startup scripts. Some useful changes were smaller than the noise. Candidates therefore had to prove their value in end-to-end load tests rather than isolated kernel measurements.

That shifts the burden from a fast isolated kernel to a faster service under load. It also makes small, repeatable gains harder to separate from background variation.

Where does Baidu take the loop next?

Baidu plans to apply the loop to training-system optimization. It then wants to use model-capability metrics to guide automated hypothesis generation, experiment design, and validation.

The company’s longer-term aim is for AI to identify capability gaps and generate and refine evaluation tasks. That expands the remit from optimizing fixed engineering metrics to shaping the questions the research system tries to answer.

Baidu sets explicit boundaries for goals, permissions, and resources. The company also calls for “continuous safety evaluation and human oversight” as the system moves from fixed engineering metrics toward model capabilities and benchmark design.

Those controls will carry more weight once the loop helps design evaluations, rather than merely optimizing code against a completed benchmark. The next phase will test whether Baidu’s human controls can preserve that discipline as the loop starts generating hypotheses and shaping evaluations.