FrugalEvo:迈向成本感知的 LLM 引导程序演化
LLM 引导的演化方法(如 AlphaEvolve)已成为求解圆堆积等困难计算优化问题的有力手段。但既有工作大多在固定迭代次数下衡量性能提升,我们认为实用优化应最大化单位成本所能换取的收益。 为此我们提出 FrugalEvo,一个成本感知 的演化框架:由更强、更昂贵的 LLM 负责探索解题策略,由更便宜的 LLM 负责实现并迭代精化生成的代码。我们还设计了缓存高效 的演化流程,让 harness 与 prompt 最大化不同演化步骤之间的前缀共享,从而提升缓存复用率。为在固定成本预算下衡量解的质量,我们提出 BA-AUC(Budget-Aware Area Under the Curve),即预算内 best-so-far 评分曲线对累计 LLM 成本所围的面积。 在 10 个数学与系统优化任务上,FrugalEvo 的最终解质量匹配或超越 OpenEvolve、ShinkaEvolve、AdaEvolve、EvoX 等强基线,并在 9 个任务上取得更高的 BA-AUC;在 ALE-Bench-Lite 的 10 个算法优化任务上,其平均性能同样优于这些基线。值得关注的是,在圆堆积问题上,FrugalEvo 使用 GPT-5.6 Terra 与 Luna 仅花费 1.68 美元、使用 GLM-5.3 及其 Flash 变体仅花费 0.55 美元,就达到新的 SOTA,匹配或超越所有基线,包括平均花费约 50 美元的多智能体方法 CORAL 与 SwarmResearch。
论文精读
TL;DR FrugalEvo 提出成本感知的 LLM 进化框架:昂贵模型探索策略、廉价模型实现并迭代优化代码,以 BA-AUC 衡量预算内收益,在多个优化任务中以极低成本匹配或超越 SOTA。
问题
问题背景
LLM-guided evolutionary methods(如 AlphaEvolve)已在 circle packing 等复杂优化问题中取得显著进展,但现有工作通常只关注固定迭代次数内的性能增益。
现有方法局限
- 忽略推理成本:现有方法假设迭代次数固定,仅最大化最终得分,导致实际 API 开销不可控。例如,多智能体方法(如 CORAL、SwarmResearch)单次运行平均成本约 50 USD,而简单任务可能只需几分钱。
- 缺乏统一性价比指标:没有衡量“单位成本收益”的标准,不同方法间无法公平比较成本效率。
- 缓存复用率低:进化过程中大量 LLM 调用共享前缀,但现有 harness 和 prompt 设计未能有效利用缓存,造成额外 token 消耗和延迟。
为什么这个问题难/重要
成本感知优化需要在探索能力(强模型、高成本)与实施成本(弱模型、低成本)之间做精细权衡。若协作设计不当,节省的成本会被额外调用抵消;若缓存策略不佳,收益进一步缩水。业界关注点正从单一 SOTA 分数转向有限预算下的实际收益,尤其在大规模 API 调用场景中,成本效率决定方法能否落地。BA-AUC 这类预算感知指标能更真实反映方法的性价比。
行业类比
类似 LLM 推理服务中的模型路由:将简单请求分发给小型模型、复杂请求分发给大型模型,在保证质量的同时降低平均成本。
核心洞察
- 以预算感知的曲线下面积(BA-AUC)为核心指标,重新定义优化目标为最大化单位成本增益,而非固定迭代次数下的最终性能。与 AlphaEvolve 等传统 LLM 引导进化方法不同,FrugalEvo 将累计 LLM API 成本显式纳入优化和评估过程,衡量 best-so-far 分数随累计成本的变化曲线下面积。这种转变让算法在探索-利用权衡中天然考虑推理开销,更贴近真实工程预算约束,也为跨模型的成本效率比较提供了统一标尺。
- 通过异构模型协作与缓存高效提示构造,FrugalEvo 在实现低成本 SOTA 上展示了关键工程价值。强模型负责策略探索,弱模型负责代码实现与迭代细化,使得单位性能提升的 token 消耗大幅下降;同时最大化不同进化步骤间提示前缀共享,提升缓存命中率,进一步降低实际 API 成本。这一设计与多智能体基线如 CORAL、SwarmResearch 形成鲜明对比:后者平均成本约 50 USD,而 FrugalEvo 在 circle packing 上仅需 1.68 USD 或 0.55 USD 即可匹配或超越。
方法
输入
- 目标计算优化问题(如函数优化、系统配置)及其评估器。
- 预定义的成本预算(以 LLM API 调用费用计),以及可选的历史程序库
Program Database作为搜索上下文。
关键模块
- 冷启动 与 上下文构建器:从程序数据库中选择相关历史解作为上下文,为新探索提供起点。
- 缓存高效 prompt 构建:同一进化步骤内的 prompt 前缀最大化共享,提升 KV 缓存重用率,从而降低每轮迭代的 token 成本。
- 策略探索器:使用较昂贵但能力更强的 LLM,在高层次上提出解决方案策略或方向。
- 解决方案生成器:使用较便宜的 LLM,将高层策略实现为可执行代码,并在后续迭代中持续优化该代码。
- 评估器与搜索记忆:对生成的代码执行评估,更新 best-so-far 曲线,并将有效解写回程序数据库,供后续上下文构建使用。
输出
- 在给定成本预算下,使 BA-AUC(累计成本下的 best-so-far 曲线面积)最大的程序解。
与传统 LLM 引导进化方法(如 AlphaEvolve)固定迭代次数并只优化最终性能不同,FrugalEvo 显式将单位成本增益作为目标,并通过“强模型探索策略 + 弱模型实现迭代”的双层分工与缓存优化实现成本效率。
实验
实验设计
FrugalEvo 在 10 个数学与系统优化任务,包括 circle packing,以及 ALE-Bench-Lite 的 10 个算法优化任务上评估。基线包括 OpenEvolve、ShinkaEvolve、AdaEvolve、EvoX,以及多智能体方法 CORAL 和 SwarmResearch。实验设定固定 LLM 成本预算,用新指标 BA-AUC,即 Budget-Aware Area Under the Curve,衡量最佳得分曲线下面积。模型配置为:强模型如 GPT-5.6 Terra 负责策略探索,弱模型如 GLM-5.3 Flash 负责代码实现与迭代,并采用缓存高效的 prompt 构建提升前缀复用。
关键发现
FrugalEvo 在 10 个任务上最终方案质量追平或超过所有基线,在 9 个任务上 BA-AUC 更高;在 ALE-Bench-Lite 上平均性能也超过这些基线。circle packing 上以 GPT-5.6 Terra 和 Luna 仅花费 1.68 USD 达到新 SOTA,用 GLM-5.3 和 Flash 变体仅 0.55 USD,而 CORAL 和 SwarmResearch 平均成本约 50 USD。
与基线对比
与 OpenEvolve 等基于固定迭代次数的方法不同,FrugalEvo 直接优化单位成本收益,通过强-弱模型分工降低每次迭代的 token 开销;缓存高效设计进一步减少重复前缀费用。这一思路对工程实践的启示是:在 LLM 驱动的优化流程中,将探索与实现分配给不同成本模型,并结合前缀缓存,可在几乎不损失最终质量的前提下大幅压缩 API 预算。
行业影响
落地场景
FrugalEvo 适用于任何需要程序级优化或参数搜索的业务场景,尤其是调用 LLM 进行自动代码生成、算法改进或超参调优的团队。
- 电商推荐系统:自动搜索更优的排序模型特征组合或策略代码,在固定 API 预算下找到更高 CTR 的配置。
- 金融量化交易:进化生成交易策略代码,用低成本 LLM 快速迭代,昂贵的强模型仅负责探索策略方向,显著降低单次搜索成本。
- 企业服务中的资源调度:如云资源分配、作业调度问题,FrugalEvo 可生成并优化启发式算法代码,在成本约束下提升资源利用率。
商业价值
核心价值在于降本增效:
- 直接降本:通过强模型探索 + 弱模型实现的协作模式,以及缓存高效提示构造,大幅减少 token 消耗。论文显示 circle packing 任务仅需 1.68 USD 或 0.55 USD 即可达到 SOTA,而基线多智能体方法平均约 50 USD。
- 固定预算下的质量提升:引入 BA-AUC 指标衡量整个成本区间的解质量,FrugalEvo 在 9/10 任务上获得更高 BA-AUC,意味着同样预算内能更早获得高质量解。
- 可预测的成本控制:对于企业级 AI 应用,按预算优化而非固定迭代次数,更符合实际采购和运营需求。
跟现有产品/工作流的接口
FrugalEvo 可作为独立的进化优化引擎集成到现有 ML/LLM 流水线中:
- 通过 API 接收优化问题描述、评估函数和成本预算。
- 内部管理
Strategy Explorer和Solution Generator两个 LLM 角色,输出最佳程序及性能-成本曲线。 - 可与 OpenEvolve、EvoX 等现有框架共存,替换其搜索后端;也可嵌入 MLOps 平台(如 Kubeflow、MLflow)作为自动调参组件。
- 由于基于程序合成,天然适配代码仓库、CI/CD 环境,可对生成代码进行版本控制和回归测试。
局限
- - **成本测量依赖于第三方模型定价与可用性**。FrugalEvo 的 BA-AUC 指标直接以 LLM API 调用成本为横轴,但模型价格会随时间调整,不同区域或账号的折扣也会导致成本基线漂移,跨时间或跨团队的对比可能失真。论文未讨论价格波动对指标可比性的影响,也未给出成本归一化方案。此外,实验主要使用 GPT-5.6 与 GLM-5.3 系列闭源模型,未验证在开源本地部署模型上的适用性,当低成本模型能力不足时,强/弱分工的收益可能大幅缩水。
- - **缓存效率依赖固定的前缀构造模式,灵活性受限**。FrugalEvo 通过最大化 prompt 前缀共享来提升缓存复用,但这要求探索与实现阶段采用结构化模板和一致的上下文排序。一旦策略探索产生异构或动态变化的指令(如引入新变量、改变代码骨架),前缀差异增大,缓存命中率下降。论文未在不同变异操作或任务类型下量化缓存命中率的变化,可能高估了实际部署中的节省。另外,强模型仅输出策略而非代码,可能丢失细粒度实现细节,导致后续弱的实现模型出现偏差或需要额外的修复迭代。
- - **与完全自主的高成本方法相比,最终解质量可能仍存在差距,且 baseline 覆盖有限**。FrugalEvo 在 circle packing 上能以 0.55–1.68 美元达到约 50 美元成本方法的性能,但其他任务中是否同样存在“成本墙”尚未说明。论文对比了 OpenEvolve、ShinkaEvolve 等,但对最新的 multi-agent 搜索系统(如 CORAL、SwarmResearch)的对比只在单一任务上给出,缺乏广泛性。此外,BA-AUC 只度量到固定预算的最佳曲线面积,并未考虑收敛后的长期质量,可能诱导算法倾向于早期快速提升而非最终最优。