ERNIE Evolve：让自动研究走进真实 AI 研发

从一次性代码生成，走向可持续的自动研究

来源：ERNIE Evolve：让自动研究走进真实 AI 研发，文心大模型研究团队，2026 年 11 月 9 日。

模型研发并不是写出一段代码就结束。研究员需要判断哪一个方向值得投入，设计实验，运行实验，分辨真正的性能提升与随机波动，再根据结果决定继续深入、回退还是换路。有效的研究过程会跨越许多轮实验，每一轮都改变下一轮可选的行动空间。

自动研究系统正在进入这一过程。ERNIE Evolve 的目标不是为某个固定问题生成一次实现，而是在明确的目标、代码仓库、评测标准和修改约束下，连续提出研究方向、修改代码、执行实验、审查结果，并把成功与失败都沉淀为后续决策的上下文。当被优化的对象本身也是 AI 研发流程时，这套机制就构成了递归自我迭代（Recursive Self-Improvement，RSI）的一种早期实践。

ERNIE Evolve 在 NanoChat AutoResearch、NanoGPT Speedrun 和 SOL-ExecBench 三项公开任务上验证了自动研究能力，随后进入 ERNIE-5.5-Flash 的真实推理优化。公开基准说明它能在成熟代码上继续寻找改进；真实任务则说明它必须面对更强的基线、更窄的修改范围、更嘈杂的反馈和更复杂的运行环境。

ERNIE Evolve 如何组织研究

ERNIE Evolve 使用两层嵌套循环。外层循环决定“接下来研究什么”。它从历史实验结果、论文、开源代码和领域知识中寻找值得验证的方向，再把方向交给不同的研究线。多条研究线可以并行推进，每条线维护一棵自己的候选代码树。

内层循环决定“这个方向怎样才能做好”。系统从研究线中的已有版本出发，提出假设、修改代码、运行实验，并把新候选交给独立评测和复核。通过检查的候选进入树的后续位置；失败候选不会被简单丢弃，其失败原因也会成为下一轮选择的依据。

系统内部由五个角色分工：

角色	职责	关键边界
Director	选择下一项研究方向和起始版本。	可以回到原始代码、当前最佳版本、中间版本或上游主干的最新提交。
Selector	在研究线内选择候选，并给出下一轮要验证的假设。	不只看分数，还要读取代码差异、失败原因和历史决策。
Executor	在隔离环境中实施代码修改，产生新候选。	实验失败和错误配置不会污染其他研究线。
Evaluator	在真实负载上测性能并检查正确性。	位于被优化仓库之外，对所有研究智能体不可见。
Reviewer	对照代码改动与评测结果，检查方向漂移和评测套利。	偏离目标的版本不能成为最佳版本，利用评测漏洞的版本直接作废。

经验库保存候选版本、代码改动、实验结果和失败原因；知识库保存论文、开源实现和领域经验。Director 决定研究路线，Selector 决定沿哪条路线继续，因此系统不必在“持续深挖一个有效方向”和“根据证据及时换路”之间二选一。

这也是它和一次性代码生成工具的根本区别。候选树让有价值的局部修改能够被继承，经验回流让一次实验改变后续问题的提法，外层循环则允许系统发现当前方向已经接近收益上限。研究不是一条不断追加提示词的对话，而是一个带状态、可回溯的实验过程。

把“不要把评测骗过去”写进系统边界

自动研究最重要的工程问题之一，是防止优化器找到一条分数更高但实际无效的路径。ERNIE Evolve 的 Evaluator 使用固定评测程序，在工作负载上检查正确性，并限制候选只能修改获准范围内的代码。超出范围的改动不会进入评测，提升必须超过噪声阈值才可能被保留。

Evaluator 被放在待优化仓库之外，也不向任何智能体暴露。Reviewer 进一步检查代码差异和结果之间是否一致：这项提升是否真的来自当前研究假设，是否只是在利用测量漏洞，是否偷偷改变了问题定义。只有通过独立评测和复核的版本才能留下。

这套设计把“可验证”拆成了三个层次。第一层是结果正确，第二层是性能提升超过噪声，第三层是提升与允许的研究方向相符。缺少第三层，系统可能通过修改工作负载、绕过正确性检查或针对评测样本特化来制造表面收益；缺少前两层，Reviewer 又可能被看似合理、实际无效的代码说服。

三项公开基准：领先、接近与边界

公开验证覆盖训练算法、训练速度和 GPU 算子优化。三项任务都有公开评测协议和此前发布的结果，ERNIE Evolve 使用同一套研究闭环，没有针对单个指标或代码结构改写系统。

任务	指标	公开最佳	Recursive	Hyra-1.0	ERNIE Evolve
NanoChat AutoResearch	验证集 BPB，越低越好	0.8878	0.9109	0.9015	0.8763
NanoGPT Speedrun Track 1	达到目标损失的时间，越短越好	39.9 秒	77.5 秒	76.4 秒	38.9 秒
NanoGPT Speedrun Track 3	达到目标损失的步数，越少越好	2690 步	—	—	2590 步
SOL-ExecBench	平均 SOL 分数，越高越好	0.827	0.676	0.736	0.819

这张表需要准确理解。ERNIE Evolve 在 NanoChat AutoResearch 和 NanoGPT Speedrun 上超过了官方页面列出的当时公开最佳结果；在 SOL-ExecBench 上，它高于 Recursive 与 Hyra-1.0，但没有超过榜单第一的 0.827。因此更稳妥的结论是“在两个公开训练任务上领先，在算子任务上接近榜首”，而不是在所有基准上全面领先。

可复核入口包括 ERNIE Evolve 开源结果、NanoChat AutoResearch、NanoGPT Speedrun 和 SOL-ExecBench。官方表格中的公开最佳还分别参考了 Rekursiv 报告、Recursive 与 Hyra-1.0。

NanoChat：把训练语料变成额外预测分支

NanoChat AutoResearch 要求系统在单卡、五分钟训练的固定预算内，同时处理模型结构、优化器、学习率策略和执行效率。社区基线已经被高度优化，单纯修改网络结构留下的空间很小。

ERNIE Evolve 在神经网络之外加入两个预测分支。第一条使用完整训练语料的 n-gram 统计，第二条检索与当前上下文相似的训练文档，并利用匹配文档的后续内容预测下一个 token。门控模块根据各分支在此前 token 位置上的表现调整混合权重。这样，网络来不及在五分钟内充分学习的语料信息，仍能通过非参数路径参与预测。

额外分支会带来开销，因此系统同时修改执行路径：大型输入表使用不保存动量状态的稀疏优化器；softcap 与交叉熵被融合进一个 Triton 算子；CPU 侧的查表结构构建与 GPU 训练重叠。最终验证集 BPB 为 0.8763，低于公开最佳的 0.8878。

NanoGPT：先压缩每步时间，再减少收敛步数

NanoGPT Speedrun 已经经历两年多、九十多次社区改进。Track 1 优化达到目标损失所需的时间，ERNIE Evolve 把重点放在每一步的执行开销上，改进了通信重叠、反向传播和输出层梯度计算，处理成熟训练栈中仍然存在的串行等待、隐藏数据搬运和昂贵梯度计算。最终版本在 38.9 秒达到目标损失，重复运行也满足损失要求。

Track 3 优化达到目标损失所需的步数。ERNIE Evolve 合并了两条搜索分支的发现：一条把矩阵权重拆成方向与幅度，另一条基于历史参数位移计算指数移动平均，并做 EMA-Nesterov 外推。在原始优化器中，归一化会给持续方向和来回振荡的更新施加相近的步长尺度；对外推后，持续一致的位移可以跨步累积，使优化器沿这些方向推进得更远。

组合两项机制时出现了一个实现冲突。优化器会根据内部状态重建权重，如果直接把外推加到权重上，结果会在下一次重建时被覆盖。系统改为对外推后的方向参数和幅度参数做更新，再加入学习率下限和训练末期的权重平均。最终把达到目标损失的步数降到 2590，而公开最佳为 2690。

SOL-ExecBench：真实模型算子仍有局部空间

SOL-ExecBench 包含 235 个来自真实模型的 GPU kernel 问题，每个候选既要正确，又要在评测中足够快。官方榜单发布七个多月后，已有 700 多名开发者提交近 5 万次，公开记录仍在提升。

ERNIE Evolve 的平均 SOL 分数达到 0.819，高于 Recursive 的 0.676 和 Hyra-1.0 的 0.736，并接近榜首的 0.827。这个结果说明，自动研究能够从真实负载中定位局部优化机会，也说明它还没有在所有算子问题上胜过最强的人类或社区实现。

真实研发任务比公开基准难在哪里

公开任务通常从一个训练脚本或一个 kernel 开始，真实推理服务则由推理引擎、算子库、硬件插件、通信路径和服务启动脚本共同组成。一次实验必须在多卡机器上正确启动完整服务，再运行压力测试和正确性检查；环境中任何一处配置错误，都可能让实验失败或产生不可信的结果。

真实任务还带来四类更强约束：

• 基线更强。工程师已经针对目标负载做过专项优化，剩余的收益往往藏在通信、调度和算子实现细节里。
• 修改范围更窄。候选必须能进入生产代码，只能修改指定模块，同时保持确定性、精度和延迟要求。
• 反馈更嘈杂。单项收益可能与测量波动处于同一量级，系统需要借助端到端压测判断真实提升。
• 环境更复杂。一次改动可能同时影响多个依赖的推理组件，正确性检查必须覆盖整个服务，而不能只看局部输出。

ERNIE Evolve 在 ERNIE-5.5-Flash 上选择了三个正在推进的工程问题：昆仑芯 P800 的低时延推理、GPU 上的确定性推理吞吐，以及单请求场景下的极致解码速度。其改动必须通过和工程师提交相同的压测与正确性检查。

昆仑芯 P800：从已有算子路径到 DeepEP 低延迟通信

ERNIE-5.5-Flash 已经能运行在昆仑芯 P800 上，但“能运行”不等于“走的是最优执行路径”。低时延生成阶段每一步的计算量很小，大量时间消耗在 Python 调用、临时张量分配和主机与设备同步上，这些开销会在每层、每一步重复出现。

第一轮先接通已有能力。系统把由大量小算子拼接的 mHC 路径替换为昆仑芯原生融合实现，并利用模型自带的多 token 预测层启用投机解码，累计速度达到基线的 282.9%。

第二轮处理主机调度与同步。小矩阵乘绕过推理不需要的包装层；验证阶段取消设备到主机的等待；索引和中间数据跨层复用；注意力改用原生实现。累计速度达到基线的 588.8%。这一轮还测试了用通用集合通信替换专用通信，但端到端速度反而下降 14.0%，系统因此放弃该方向。

第三轮缓存 MoE 专家计算的索引和工作缓冲区，只比上一轮多提升约 1.4%。收益缩小后，系统没有继续沿着同一假设加码，而是重新测量各阶段耗时。第四轮发现，通信模式虽然设置为自动选择，生成请求实际仍走普通路径。修正分派逻辑并按真实工作负载缩小通信缓冲区后，单流生成才真正使用 DeepEP 低延迟通信，总速度达到基线的 623.6%。

这条曲线说明，外层研究方向的调整与内层代码优化同样重要。第三轮的小幅提升触发了重新剖析；第四轮找到的是路由逻辑错误，而不是继续堆叠 kernel 微优化。

确定性推理：在不能改变归约顺序时提高吞吐

强化学习训练要求推理结果可复现。同一个请求无论与哪些请求共享 batch，生成的 token 和 logprob 都必须逐位一致，还必须与训练端对完整序列重新计算的结果一致。SGLang 的确定性模式通过固定归约顺序满足要求，但会限制 GPU 利用率。

这个场景排除了许多常见加速手段。按 batch 大小选择 kernel、原子加和自适应通信都会改变归约顺序，因此都不能使用。允许的改动仅限确定性相关的设置和实现，并且精度与延迟不能退步。

约三天的搜索最终把吞吐提高 33.7%，平均每 token 生成时间缩短 26%，首 token 延迟缩短 12%，确定性保持不变。剖析显示，确定性采样占每步 GPU 时间约 14%，是最大瓶颈。系统用按词表分块并行的 Triton 算子替代原实现，得到最大的单项收益；稀疏注意力和小 batch 矩阵乘的改进把累计吞吐提升带到 20.6%。

第二阶段处理确定性设置。单独修改 MoE 通信开关的收益与噪声无法区分，但和对应 kernel 改动一起使用时才有效。mHC 的人工调定切分数从 8 调到 32，又把累计收益推到 32.6%。

第三阶段检验一个推广假设：确定性模式下许多 kernel 使用固定切分数，而逐 token 生成时每张 GPU 处理的数据很少，是否会有大量计算单元闲置？逐个测试后，大部分 kernel 并不符合这一假设。系统只保留 mHC 后处理二维并行等少数有效改动，把最终吞吐提升推到 33.7%。这里同样可以看到失败实验的价值：被证伪的假设阻止系统继续扩大无效搜索。

极致解码：没有单一热点时，如何捕捉 0.3% 的改进

第三个任务优化 GPU 单请求解码。服务使用投机解码，草稿模型一次提出多个 token，主模型再一次性验证。跨卡通信和 kernel 间空隙已经被工程团队压低，剩余时间分散在主模型验证和草稿模型生成的大量小算子上，没有单一主导瓶颈。部分有效改动单独只带来 0.3% 到 0.5% 的提升，甚至低于测量噪声。

ERNIE Evolve 共提出七个方向，三个产生收益。第一阶段重新分配 MoE 第一层矩阵乘与路由并行时的计算单元，并让 mHC 后处理直接输出下一层所需的 FP8 量化输入，省去单独量化 kernel，累计速度提升 5.4%。同一轮的长上下文注意力、跨卡通信、kernel 间隙与主机开销等假设被测量否决；单次跨卡通信已接近 NVLink 往返延迟下限，kernel 间隙只占每步的 2% 到 4%。

第二阶段处理主模型矩阵乘与 MoE 调度。输入不足八行时，原 FP8 矩阵乘有一半操作数是零填充。系统交换权重和输入在矩阵两侧的角色，改用原生 FP16 矩阵乘指令；MoE 专家调度器从逐组扫描全部专家改为两级索引。后者是最大的单项收益，加上若干 kernel 融合后累计提升 13.2%。

第三阶段转向仍在关键路径上的草稿模型，把逐位置采样与跨卡归约融合为一个 kernel，并合并草稿注意力中的计算。最终解码速度再提高 14.9%，精度没有变化。

这套系统的真正增量

ERNIE Evolve 的结果不只来自代码生成。它把研究方向、候选版本、实验条件、评测结果、失败原因和后续决策连成一个有状态过程。外层循环负责选择问题，内层循环负责把问题做深，Reviewer 与 Evaluator 则防止“分数变好但问题被做坏”。

公开基准上的收益说明，成熟项目里仍可能存在可验证的局部空间；真实推理任务说明，自动研究可以处理跨引擎、跨硬件和跨服务的工程复杂环境。但这两类结果仍然限定在目标清晰、结果可验证、修改范围明确的研发任务中。系统尚未证明能够在目标模糊、评测不完整或长期研究规划中替代人类研究员。

还应区分“官方披露结果”与“独立复现实验”。本文列出的数字来自文心团队公开页面和其引用的公开排行榜；指标定义、评测版本与提交时间应以对应榜单为准。自动研究要成为可信基础设施，除了展示性能曲线，还需要可复核的代码、固定的评测环境和足够长的运行记录。

RSI 的下一步，必须同时建设控制边界

文心团队把推理基础设施优化视为 RSI 进入真实 AI 研发的第一个落点。沿同一套研究闭环，下一步可以扩展到训练系统优化，再根据模型能力指标自动提出假设、设计实验并验证结果；更远期还可能让 AI 发现能力缺口、生成和完善评测任务，使评测体系与研究过程一起迭代。

能力越强，边界越重要。ERNIE Evolve 的设计强调可控、可暂停和可终止：系统在明确的目标、权限和资源范围内运行，接受持续安全评估与人工监督，只有在人类仍能理解、监督和停止系统时才扩大研究范围。这不是附加在产品说明末尾的原则，而是自动研究能否长期运行的前提。

从工程角度看，一个可部署的 RSI 系统至少需要四类控制：评测器不能由被优化方任意修改；资源消耗和可执行动作必须有硬限制；研究历史必须可审计；人类必须能在任何阶段暂停或终止。性能提升越快，越需要这些机制独立于模型自身的判断。

ERNIE Evolve 展示的不是“AI 已经可以完全自主研发”，而是一个更具体的阶段性结论：在目标清晰、反馈真实、权限受控的任务里，自动研究可以持续产出经过验证的工程改进。

这条路径的价值不只是把单次实验做得更快，而是让成功和失败都成为下一轮研究的可检索经验。只有当研究基础设施、评测可信度和人类控制能力同步成熟，RSI 的效率提升才会转化为可靠的 AI 研发能力。

原文：ERNIE Evolve：让自动研究走进真实 AI 研发