进化搜索的算力分配重构：从深度-广度到多臂老虎机

arXiv: 2605.29268 ｜ 2026-05-28 ｜ Code 关键词：LLM Evolutionary Search ｜ AlphaEvolve ｜ Compute Allocation ｜ Multi-Armed Bandit ｜ Depth-Breadth Trade-off

一句话结论

LLM 驱动的进化搜索（AlphaEvolve、ShinkaEvolve、ThetaEvolve 等）目前都靠"运行很多次取最好"来吹榜单，作者第一次把"该跑多深 vs 该跑多宽"这个朴素问题量化成两条经验规律，并据此提出一个不改模型、不改 prompt、只改算力分配的多臂老虎机算法 BaSE，平均提升 12.3% fitness，关键是大幅降低 run-to-run 方差。

为什么值得读

进化搜索（Evolve）类系统在 2025-2026 年成为 LLM 推理算力的最大消耗户之一。AlphaEvolve、ShinkaEvolve、CodeEvolve、OpenEvolve、ThetaEvolve 都遵循同一范式：

  • 维护一个候选解种群；
  • 用 LLM 当 mutation engine，从父解生成子解；
  • 用 evaluator 打分，按 fitness 选种繁衍。

但这类系统有两个公认的"脏秘密"：

  1. 算力消耗差出两个数量级——ShinkaEvolve ~150 次 LLM 调用 vs ThetaEvolve 204,800 次，没有公认的"性价比"基线；
  2. 基本只报 best-of-many——AlphaEvolve 在 Circle Packing n=26 这种榜单上只报一个数字，单次跑出这个数字的可靠性如何？无人公开。

这篇论文的核心贡献是把"在固定 LLM 调用预算下怎么分配"这个看似简单的问题做成了第一个系统的实证研究：扫了 5 个模型 × 3 个任务的 depth × breadth 网格，发现两条干净的经验规律，再据此设计算法。它不是又一个新 Evolve 框架，而是给所有现有 Evolve 框架的"运行配方"提供科学依据的工作。

背景：Evolve 系统的两个关键参数

LLM-guided 进化搜索的算力可以拆成两个正交维度：

  • Depth（深度）：单条进化轨迹跑多少代；
  • Breadth（广度）：并行跑多少条独立轨迹。

总预算 = Depth × Breadth = 固定的 LLM 调用次数。

实践里大家凭直觉调：要么深-窄（一条路走到黑），要么浅-宽（多个并行赛跑）。但到底哪种好，取决于什么因素，没有人系统答过。

不同 Evolve 系统的算力消耗跨两个数量级

研究方法

实验设计

作者扫了一个完整的 depth-breadth 网格：

维度 配置
模型 5 个（覆盖不同能力区间的开/闭源 LLM）
任务 3 个（数学优化 + 组合优化代表，含 Circle Packing 这个 AlphaEvolve 的标志任务）
Depth × Breadth 多组配比，总预算固定
Repeat 每个 cell 多次重复，刻画方差分布

两条经验规律

规律一：Fitness-Compute Envelope（适应度-算力包络）

把不同模型在不同 depth-breadth 配比下的 fitness 画在以 effective FLOPs 为横轴的图上，模型间的能力排序在很大程度上塌缩到一条共同曲线：

  • 高能力模型在低算力区位也能达到弱模型的高算力位结果；
  • 但给定算力预算后，分配方式决定上限——不是模型唯一决定。

Fitness-Compute Envelope

规律二：Bilinear Depth-Breadth Fit（双线性 D×B 拟合）

固定模型与任务后，fitness 关于 depth 和 breadth 服从近似的双线性关系，且任务特定的交互项显著：

  • 数学类任务（连续/可微方向探索）更吃 depth；
  • 组合类任务（离散搜索空间）更吃 breadth；
  • 最优 depth × breadth 比例因模型-任务对而异。

这两条规律共同的含义是：

存在一个"模型 × 任务"决定的算力天花板（capability gate），分配只能逼近这个天花板，不能突破。 但"逼近 vs 远低于"之间的空间，完全可以靠分配策略捞回来。

Depth-Breadth 网格

核心方法：BaSE 算法

基于上述规律，作者提出 BaSE (Bandit-based Self-Evolving)：

  • 把每条并行进化轨迹看成 multi-armed bandit 的一条 arm；
  • 每个 arm 有自己的 fitness 增长率（受当前种群多样性、LLM 输出质量影响）；
  • 用 bandit 算法动态地把后续 LLM 调用预算分配给"边际收益最高"的 arm；
  • 不改模型、不改 prompt、不改 evaluator，只改"下一个 LLM 调用花在哪个轨迹上"。

工程上 BaSE 是 OpenEvolve 这类岛屿协议（island protocol）的直接替代——岛屿协议是简单地等比例分配，BaSE 是带探索-利用权衡的自适应分配。

BaSE 算法示意

为什么 bandit 适合这件事

进化轨迹的进展高度非平稳：

  • 早期所有 arm 看起来都差不多；
  • 中期某条 arm 因为种群多样性枯竭"卡住"；
  • 后期某条 arm 突破后产出大量优质后代。

bandit 的 explore-exploit 权衡天然匹配这种"早期均衡探索 + 中后期向高产 arm 倾斜"的需求。 作者也在附录讨论了 arm-pool size 的消融。

关键实验结果

主实验：BaSE vs 岛屿协议基线

在 8 个 (model, task) cell 上：

指标 数值
平均 fitness 提升 +12.3% vs 最强 island-protocol baseline
方差降低 高方差设置下提升最显著（即"原本最不可靠的场景修得最厉害"）
改动成本 不改模型 / prompt / evaluator

这个 12.3% 在 Evolve 类工作里是接近"换一代模型"才能拿到的提升，但成本几乎为零。

BaSE 结果对比

Circle Packing case study：为什么会卡住

作者在附录给了一个非常诚实的案例分析（D.1 Circle Packing: scipy acquisition is the gating event）：

  • Circle Packing 任务里 LLM 在两种模式间震荡：healthy（在调 scipy.optimize 的好用法上做小改） 和 stagnant（陷入死循环或调用错误的 API）；
  • 一旦某个 arm 进入 stagnant 模式，再多 LLM 调用也救不回来，这正是岛屿协议浪费算力的地方；
  • BaSE 通过 bandit 选择尽快放弃 stagnant arm。

消融与分析

  • C. Capability Gate of the Collapse：解释为什么 Fitness-Compute Envelope 会塌缩——本质是模型-任务能力上限决定；
  • G.3 Bandit Arm-Pool Size：arm 数量过少 BaSE 退化为单轨迹，过多则探索成本高；
  • H. Prompts 公开：OpenEvolve / CodeEvolve / ShinkaEvolve 三套 prompt 在附录全开，复现性极佳。

这篇论文给"做 LLM 推理算力优化"的人的启示

  1. best-of-N 不是科学指标：报告 mean ± std，至少给 run-to-run 分布；
  2. 分配优化是"零成本免费午餐"：不动模型、不动 prompt 也能拿 10%+；
  3. bandit 比硬调度灵活：当任务的"成功率轨迹"非平稳时，bandit 的 regret bound 比静态分配优；
  4. 算力预算应该按"effective FLOPs"算：作者在附录 A 给了把 prefix cache、active params、non-embedding 都纳入的统一公式，这是未来 Evolve 类工作的标准记账方式。

这篇论文给"做 Agent / RL"的人的启示

虽然是 Evolve 框架的论文，但 BaSE 思路对所有"多并行轨迹 + 共享算力预算"的 Agent 系统都适用：

  • 多 agent 协作（每个 agent 是一条轨迹）；
  • Self-consistency / Best-of-N / MCTS（每条采样路径是一条轨迹）；
  • RL 自我对弈（每个 self-play instance 是一条轨迹）；

凡是这类系统，"等比例分配并行预算"几乎肯定不是最优的。BaSE 提供的范式可以直接迁移：把每条并行的 trajectory 当 arm，用 bandit 在线分配下一步算力。

批判性看法

优点：

  • 第一篇系统刻画 Evolve 系统 run-to-run 方差的工作，在该方向是空白；
  • 两条经验规律（Envelope + Bilinear）清晰可视化、可复现、可外推；
  • BaSE 算法接口最小——不需要 Evolve 框架本身做大改动；
  • 代码与 prompt 公开（GitHub: keruiwu/self-evolving-allocation），可信度高。

局限：

  • 任务覆盖只有 3 个：Circle Packing、组合优化等，没有覆盖 AlphaEvolve 那种通用代码进化，迁移到更广任务的可靠性未知；
  • 模型只有 5 个：未必涵盖最新一代推理模型（如 OpenAI o3、Claude 4 系列）的实际行为；
  • BaSE 的 bandit 算法选型论文交代相对简略，没有对比 UCB / Thompson Sampling / EXP3 不同变体；
  • Effective FLOPs 公式虽然给了，但跨不同推理后端（vLLM、SGLang、闭源 API）实际可比性需要更多验证；
  • 没有理论结果：纯实证规律 + 启发式算法，缺乏 regret bound 等理论支撑。

不该过度外推：

  • "12.3% 提升"是这 8 个 cell 上的均值，到具体任务可能高也可能低；
  • "分配比 prompt engineering 更有效"是论文的口号，但作者比较的 prompt baseline 强度有限——更精细的 prompt 工程仍可能在某些任务上击败 BaSE。

复现建议

代码已开源：github.com/keruiwu/self-evolving-allocation

如果你已经在跑 OpenEvolve / ShinkaEvolve，把 BaSE 接入只需要：

  1. 把岛屿协议的"轮询调度"换成 bandit 调度；
  2. 维护每个 arm 的最近 k 步 fitness 增长率；
  3. 用 UCB 或 Thompson 更新 arm 选择概率。

代价极低，值得作为现有 Evolve pipeline 的标配 ablation。

总结：这是一篇把"算力分配"从工程直觉提升为科学问题的工作。它对 LLM-guided Evolve 系统的方法论意义远大于具体算法 BaSE 本身——未来 Evolve 类论文如果不报告 run-to-run 分布、不交代 depth-breadth 配比，就应该被拒。在 LLM 推理算力日益昂贵的今天，这种"零成本捞 10%+"的研究值得每个 RL/Agent/Evolve 团队认真读一遍。