同样的推理成本，ARES 为什么能把 PPA 压得更深？|ares|effort|ppa|推理成本|计数器|调用

给 RTL 优化 Agent 一笔不限额的推理预算，它当然可以继续试、继续改，也可能偶尔撞出更低的 PPA。可工程团队掏钱购买的，始终是经过验证的设计改善。“模型想了多久”本身不交付价值。

过去的论文常把这笔账藏在结果后面：面积、功耗或时延降到多少写得很清楚，模型为此调用了多少次、花了多少钱，却很少出现在同一条坐标轴上。每轮固定用 high reasoning effort，会在简单改动上多烧 token；一直停在 low effort，又可能被平台期困住。

2026 年 7 月底提交至 arXiv 的 ARES 预印本，抓住的正是这个缺口。它让 Agent 在 RTL 编辑、功能验证、商业综合和 PPA 分析之间循环，同时给每次 LLM 调用计价。中等推理先处理显而易见的机会，进展停滞后再升级为高推理。作者在三个未参与训练的设计上报告：相同归一化成本下，自适应策略把输入设计的 FoM 降低 23%—27%，最佳固定策略为 16%—23%。

数字很亮眼，边界也必须放在前面。ARES 目前是预印本实验，测试对象是单体开源 RTL 模块，PPA 来自 Nangate 45nm 库上的商业综合和 PrimeTime 分析。它没有证明布局布线、签核、流片或量产收益。

一次 LLM 调用，就是一次付费设计实验

ARES 的输入是一份功能正确但未优化的 RTL。每轮迭代中，Agent 读取当前最优版本、同一次运行的对话历史，以及从训练设计积累的长期记忆，然后提出一个修改候选。

候选不能只“看起来合理”。论文使用固定种子的 104 个随机向量，在 RTL 与综合后网表阶段对照原设计；RTL 级还加入 JasperGold 顺序等价检查。通过功能检查后，候选进入 Synopsys Design Compiler 与 PrimeTime，在 Nangate 45nm 开源库上得到面积、功耗和时延。

三项指标各自相对原始设计归一化，再相乘为 FoM。原始设计的 FoM 等于 1，数值越低越好。只有验证、综合成功且 FoM 更低的候选，才能替换当前最优版本。失败版本被丢弃，成本却已经发生。

Agent 跑完一个 iteration，不代表完成了一项有效优化。候选可能编译失败、综合失败、等价检查失败，也可能功能正确却没有改善 PPA。企业验收时，更该数每一元预算买到多少“可验证的有效候选”，而非 Agent 一共忙了多少轮。

FoM 旁边，终于多了一根成本轴

只用调用次数衡量成本，会把 low、medium、high 三种 effort 当成同价。只看 token 也不够，因为输入、缓存读取、缓存写入、reasoning 和输出的单价并不相同。ARES 按公开价格把每次调用折成美元，再累加为整次运行成本。

为了让图表不被绝对价格牵着走，论文又把美元成本除以该设计一次 high-effort 调用的平均成本，得到 high-call，也就是一次高推理调用的等价成本。于是同一张图可以回答一个更有工程意义的问题：预算花到 5 次、10 次或 15 次 high-call 时，当前最好的 FoM 到了哪里？

这比只报“最终最好成绩”更接近真实采购与项目管理。无限预算下的最优点未必值得买，率先抵达可接受 PPA 的策略反而可能更有价值。

不过，high-call 也不是跨模型、跨工具的物理常数。模型版本、prompt 长度、缓存命中率和渠道价格一变，实际美元账就要重算。进入企业项目后，还要加上综合与形式验证许可证、机器时间、存储、人工 review 和失败复跑成本。ARES 算清了模型账，还没有覆盖研发总账。

停滞之后，推理预算才升级

ARES 没有为每一轮都购买高 effort。它从 medium 开始，用耐心计数器（patience counter）判断何时值得加码。

如果候选能验证、能综合，却没有降低 FoM，计数器加 1；如果候选连编译、综合或验证都过不了，计数器加 2.8。一次被接受的改善会按相对 FoM 收益降低计数器，收益达到 5% 时可以清零。计数器达到 3，下一轮切换到 high effort，随后重置。

这组参数不是逐个测试设计手调。作者先在 21 个训练设计的 medium-effort 运行记录上做网格搜索，再固定到三个未参与训练的设计。按照论文的定义，它捕捉了 94% 的“应升级”位置，并约束至少 90% 的已触发升级确实值得发生。

这套机制把失败也变成了信号。一个通过验证但没有收益的候选，可能只是策略差一点；一个连合法实现都生成不了的候选，更可能说明当前推理深度不足。ARES 因此给失败更高权重。

ARES 不预测下一次 high effort 一定成功，它检测 medium effort 的边际回报是否已经恶化。便宜策略持续买不到进展，系统才批准更贵的调用。

三个测试设计上，自适应策略走得更深

实验包含 24 个单体开源 RTL 模块，规模从数百到数千行。21 个用于建立记忆并拟合 patience 参数，另外三个作为测试集：Z80 核的 ALU tv80、串行收发器 uart，以及 AES 核的控制单元 controller。

固定 low 在三个设计上都弱于 medium。固定 high 的后劲更强，却在早期显得昂贵：它首次找到成功优化时，已经花掉 4.6—7.1 high-calls 的等价成本；medium 在 0.9—3.9 high-calls 内就先拿到 5% FoM 改善。

自适应策略保留了 medium 的早期效率，在 0.9—3.0 high-calls 内拿到首个 5% 改善；遇到平台期后，它再用 high effort 继续下探。三个测试设计的最终平均 FoM 分别为 0.76、0.77 和 0.73，固定 high 对应为 0.79、0.84 和 0.79。

作者还拿一项 MX 乘加单元做了更直观的对照。Claude Opus 4.6 先按规格和 testbench 生成一份功能等价 RTL，ARES 再向公开的人工优化实现逼近。六次运行中，起始 FoM 从 68.8 降到平均 33.6，最好一次为 27.5；人工版本为 18.9。所谓“最高闭合 83% 差距”，来自这个特定起点、特定单元和特定工具流，结果仍没有追平人工实现。

这组实验更有意思的指标是方差。固定 medium 六次运行的终点标准差为 8.9，自适应后降到 5.8，作者折算为 58% 的下降，代价是平均多花 7.3 high-calls。优化 Agent 有随机性，项目真正关心的不只是平均值，还包括最差一次会落在哪里，以及为了得到稳定结果需要复跑多少次。

复杂记忆，未必是收益主角

ARES 还有一个反直觉结果。论文把同一批跨设计经验写成三种形态：没有长期记忆、简单拼接成功优化，以及经过结构化、去重、抽象和排序的工程化记忆。

带长期记忆通常优于完全没有长期记忆。但在相同成本下，复杂构造与简单拼接在三个未参与训练的设计上曲线接近，没有稳定赢家。至少在这组实验里，额外的记忆工程没有显示出可靠的 PPA 成本收益。

这个结论不能扩大成“memory 没用”。两种带经验的方案通常都胜过无长期记忆，结构化规则对人类阅读、审计和复用也可能更友好。它给行业提了个醒：memory 文件写得漂亮，不等于优化收益就来自 memory。控制预算并保持经验池一致，才能分清知识组织、模型能力、工具反馈和推理投入各自贡献了什么。

把 Agent 的聪明换算成工程收益

如果把 ARES 放进更大的 AI+EDA 版图，它提出了一套比“成功率”更实用的验收方法。

第一，看预算口径。模型 token 只是显性成本，EDA 工具、形式验证、机器资源和工程师复核必须进入总账。

第二，看有效实验率。通过编译、综合和等价检查的候选占多少，真正改善 PPA 的又占多少。大量失败调用会让便宜模型变得昂贵。

第三，看 PPA 成本前沿。在相同累计成本下比较当前最优 FoM，避免拿不同预算的最终成绩硬碰硬。

第四，看稳定性。均值、方差、最坏点和复跑次数共同决定交付成本。一次偶然的好结果不能替代可重复的流程收益。

第五，看签核距离。综合后 PPA 只是中间证据。进入真实 SoC，还要面对层级规模、约束质量、物理拥塞、寄生参数、功耗场景、验证覆盖和 sign-off 责任。