← 返回 PaperDaily
大模型与智能体
1B vs 70B算什么，LLM推理力度自适应才是真省钱
LLM智能体调芯片，烧的是真实美元。这篇鲁汶大学新作给出两个反常识答案：精心雕琢的长期记忆，不如普通拼接有用；真正决定优化质量与成本比的，是推理力度该何时加码。Ares靠一个耐心计数器动态调度，等成本下PPA优化深度提升23–27%，成本仅SotA的12%——继6月聊过让智能体学会止损之后，省钱这件事从动作层面卷到了芯片设计。
龙哥读论文
发布于 2026-09-05 00:31:11
阅读 5
查看原文
原论文信息如下：
一个再形象不过的比喻
鲁汶大学和诺基亚贝尔实验室这篇Ares，做的就是两件事：把每一笔咨询费算清楚，并且让顾问在真正需要深想的时候才启用最贵档位。最终效果是，在同样预算下，芯片设计的功耗-性能-面积综合指标（PPA, Power-Performance-Area）优化深度比固定用任何单一档位都高出不少。故事还得从RTL优化为什么这么烧钱讲起。
给LLM的每一分钱都要花在刀刃上——RTL优化为何需要成本意识
先补个背景。芯片设计里，RTL（Register-Transfer Level，寄存器传输级）
LLM智能体时代的做法是：给大模型一个未优化的RTL，配上测试平台，让它在循环里不断改代码、跑综合工具（如Synopsys Design Compiler）、读回面积功耗延迟数据，再决定下一步怎么改。这个“编辑-综合-评估-再编辑”闭环能自动跑几十轮，每一轮都是一次LLM调用，调用背后都是真金白银的token账单。
Ares用公式把优化目标定义得很干净，FoM（Figure of Merit，品质因数）
FoM = (area/area₀) × (power/power₀) × (delay/delay₀)
初始设计FoM为1，经过优化后低于1意味着PPA整体变好，越低越好。这个乘积让面积、功耗、延迟互相牵制，单独降一个维度不算本事，三个一起降才是真优化。但问题来了：FoM只回答“优化得深不深”，完全不管“为此花了多少钱”。
图1：Ares整体架构概览。LLM智能体编辑当前最优RTL，每个候选设计都要经过功能验证和商业综合流程，只有当其FoM更低时才被保留；右侧展示了自适应推理力度策略在相同成本下达到更低FoM。
Ares的出发点就是把这个缺失的成本轴补上。它给每一次LLM调用都算了一笔归一化美元费用，并把“优化质量降低成本曲线”作为所有对比的基准。这个动作听起来简单，实际上一系列有趣的结论都从这“一把尺子”里量了出来。
推翻常识：跨设计长期记忆的构建方式其实没那么重要
近年来RTL优化智能体的一个主流方向是做“跨设计长期记忆”：把在一个设计上学到的优化经验累积下来，复用到下一个新设计上。业界在这上面花的心思非常多——有的做成结构化的Markdown规则库，每条规则对应一个具体的优化动作；有的做成“上下文-动作-结果”三元组；有的还专门维护一个“反优化”清单，记录哪些操作效果差、千万别做；更讲究的还会在不同设计间去重、排序、抽象出通用技能。
Ares却设计了一个大胆的对照实验：同一批原始优化经验，用三种方式喂给智能体。第一种完全没有长期记忆，只靠单次运行内的短期记忆；第二种把经验简单拼接成描述清单塞进提示词；第三种用上了目前所有花哨技巧——结构化案例、反优化明确标注、跨设计去重排序、以及设计名匿名化，保证规则匹配的是问题结构而不是出处。
结果如图2所示：在三个测试设计上，工程化记忆相比简单拼接，几乎没有带来可依赖的收益提升。两条曲线一起下降、终点接近，谁也没有稳定地压过谁。
图2：三种长期记忆构建方式在三个测试设计（tv80、uart、controller）上的优化结果。横轴为累计成本，纵轴为当前最优FoM，曲线越往下越好。工程化记忆相比简单拼接并未带来稳定优势。
注意，这不是说记忆没有用——两种带记忆的版本都明显优于无记忆版本。这说明跨设计经验的“量”有作用，但“怎么组织”没那么关键。把同样的经验换着花样排版、去重、抽象，不如把注意力放到另一个更本质的变量上：每一次调用到底应该让LLM想多深。
核心机制：耐心计数器如何自适应调度推理力度 大模型API的“推理力度（reasoning effort）”设置，通常有low、medium、high三档，决定模型在生成答案前进行多少隐藏推理（hidden reasoning）。档位越高，模型思考越多、输出质量通常越好，但消耗的token和费用也越高。此前几乎所有的RTL优化智能体都全程锁死一个档位：有的用默认档（实际相当于high），有的用medium。
Ares观察到，一个优化运行的不同阶段，难度天差地别：刚开局时RTL里尽显眼的低垂果实，简单改改就能降FoM，用low甚至medium就够；越到后面，优化进入瓶颈期，连续多次修改都无法提升，这时才真正需要更深入的推理去寻找突破口。如果全程high，早期迭代就是在花冤枉钱；如果始终medium，后期瓶颈就卡死出不来。
Ares用了一个非常优雅的机制来解决这个问题——耐心计数器（Patience Counter）
1. 迭代停滞（候选设计能综合、能验证，但没有降低FoM）：计数器加1；
当计数器累计到阈值p，下一轮自动升级到high档，并重置计数器。写成公式就是：
停滞：C ← C + 1
三个超参数p、w、κ在21个训练设计上做了一次网格搜索联合拟合，得到的值是p=3、w=2.8、κ=0.05。这个拟合过程强调一点：升级动作必须“准”。训练记录里，如果一个时间点之后的3次迭代内medium都没法产生有效改进，就认为这个点值得升级；在所有值得升级的点里，网格搜索要抓到尽可能多，同时保证至少90%实际触发的升级是值得的。最终抓到94%的值得升级点。
图3：Ares的自适应推理力度策略。当耐心计数器C累计到阈值p时，从中等推理力度升级到高推理力度；一次成功改进会按相对改进幅度放电。
w=2.8这个拟合值很有意思：一次失败在训练数据里相当于近三次停滞的“绝望权重”。直观上也说得通——停滞意味着方向可能不对但思路还是走通的，失败则说明LLM可能压根没想明白怎么实现某个优化，需要更多思考空间。一个失败的迭代比三次停滞更强烈地预示着“该上高强度推理了”。
等成本下FoM直降23–27%，三个测试设计全面碾压固定策略 实验设置值得一提。Ares在24个单模块开源RTL设计上验证，其中19个来自Dr. RTL论文的设计集（排除LSTM因其含有推断存储器），2个来自RTL-Rewriter基准（FFT蝶形单元和Huffman解码器），3个来自OpenCores（CORDIC、流水线FFT、JPEG DCT）。三个测试设计覆盖了不同可优化程度：tv80（Z80内核的ALU）、uart（串行收发器）、controller（AES内核的控制单元），其余21个作为训练集，用来构建长期记忆和拟合升级常数。PPA综合采用Synopsys Design Compiler和PrimeTime，工艺库是开源的Nangate 45nm，验证用JasperGold做时序等价性检查。LLM底座是Claude Opus 4.6，运行在Claude Code框架上。
图4是核心结果。先看三条固定档位的基线曲线：low档全程最便宜但效果最差，而且在controller上表现极不稳定；high档早期迟迟不出成果，第一次成功优化要花4.6–7.1个high-calls的成本，而medium在0.9–3.9成本时就已经砍掉5%的FoM了；medium档位开局最快，但中期容易陷入平台期，再多花钱也降不下去。
图4：三个测试设计上，固定低/中/高推理力度与自适应策略的优化曲线对比。自适应策略在三个设计上都以相同成本达到最低FoM。
Ares的自适应策略则模仿了“先medium、卡住就升high”的节奏：开局和medium一样快地吃到早期红利，随后在medium平台期及时升级，突破瓶颈继续下探。三个测试设计上，自适应策略让输入设计的FoM降低了23%–27%，而最好的固定档位只能做到16%–23%。在tv80上，自适应均值FoM达到0.76，而固定high只有0.79；controller上自适应达0.73，固定high为0.79。这表明，同样的预算，花对地方和平均用力，结果差距是质的。
13%的成本、12%的token：Ares如何击败SotA优化器 只看基准设计不够过瘾，Ares还挑了一个“天花板”很明确的任务：一个开源的MX（Microscaling，微缩放）乘加单元（MAC），已有高度手写优化的正式版本。他们让Claude Opus 4.6根据规格和测试平台从头写一个功能等价的版本，然后看Ares能把LLM草稿优化到什么程度。
图5：MX乘加单元优化结果。左图为六次独立运行的固定medium分支（实线）和自适应升级分支（虚线），右图为平均曲线，自适应分支明显把FoM压得更低。
结果令人印象深刻：LLM草稿的未归一化FoM为68.8，Ares经过六次运行平均降到33.6（最好的一次27.5），手写优化版本是18.9，相当于最多弥补了83%的差距。更值得关注的是运行稳定性：固定medium六次运行的终点散落在29.8到52.4之间，标准差8.9；自适应策略把三个高原期运行分别拉低了7.3到20.0个FoM点，标准差降到5.8，方差削减58%。此前优化器靠多次采样取最好来保证靠谱，Ares靠一次运行里的自适应升级把“烂尾”分支救回来。
最后压轴的是与两种SotA优化器的直接对话。同一套商业工具流、同一个初始设计controller、同样是25个候选设计，Ares达到FoM 0.694；REvolution（最强的开源进化式LLM-RTL框架）只到0.943；Dr. RTL（技能库优化器）返回0.923。后面两家的差距得展开看：Dr. RTL只优化时序和面积，不考虑功耗，在Ares这种功耗感知FoM下，它自己的功耗权衡会反噬效果；而且它的多智能体流水线每一步都要跑专门的智能体，总token消耗是Ares的8.3倍，成本换算下来约是Ares的8.7倍。最讽刺的是，Dr. RTL在优化过程中其实遇到过FoM为0.909的更好候选，但它内部选择机制只盯时序，把这个更优候选丢了。
图6：Ares、REvolution和Dr. RTL在controller上从同一初始RTL出发的优化对比。Ares的FoM最低，且累计成本远低于Dr. RTL。
成本归一化评估——可复用到所有LLM智能体研究的方法论 前面反复提到“high-calls”这个单位，这里展开讲清楚。Ares计算每次调用成本的公式如下：
Cost = Σᵢ₌₁ᴺ (p_in·t_i,in + p_cr·t_i,cr + p_cw·t_i,cw + p_out·t_i,out)
这个式子里，输入token（in）、缓存读取token（cr）、缓存写入token（cw）、输出token（out）分别按OpenRouter公布的每token价格乘起来求和。一张看似简单的账单，其实藏着两个坑：第一，只用调用次数做比较会混淆不同档位的价差；第二，只用token数做比较也不行，因为input、cache和reasoning/output token的单价不同，用户最终掏的是美元不是token数。
而“high-calls”是把累计美元成本除以该设计单次high档调用的平均价格。这样做有一个妙处：即使大模型厂商明天调价，high-calls这个相对单位仍然稳定，因为分子分母同步变化。成本横轴从此不再依赖具体价格日期，任何人在任何时间点上都能进行公平对比。这个方法论的通用性远不止RTL——所有需要多次调用LLM迭代优化的智能体研究，都可以用“归一化成本-效果曲线”作为标准评估范式。Ares把价格透明化这件事从可选项变成了必选项。
龙迷三问 1. high-calls到底是什么？为什么不用纯美元？
2. 为什么失败的权重w=2.8而不是1？
3. Ares这套机制能用到RTL以外的场景吗？
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数： ★★★★☆
首次把每次LLM调用的归一化成本作为一等公民引入RTL优化智能体，并用耐心计数器做自适应推理调度。角度新颖，跳出了“堆记忆、堆智能体”的惯性。
实验合理度： ★★★★☆
在24个设计上评估、3个测试设计上做核心结论验证，并与REvolution和Dr. RTL在同一商业工具流上公平对比。测试集规模偏小、同族模块为主，统计功效有限，但对比设计本身是扎实的。
学术研究价值： ★★★★☆
把“成本”从论文脚注变成核心坐标轴，等于给所有LLM智能体研究提供了一套新的评估语言。仅这一点就足以让后续RTL优化论文引用它。相信会公开代码。
稳定性： ★★★☆☆
MX MAC实验显示自适应策略把运行间标准差从8.9降到5.8，方差削减58%，说明它显著提升了“单次运行的可靠性”。但LLM输出本身有随机性，单次运行仍需要多次采样求均值才能获得稳定结论。
适应性以及泛化能力： ★★★★☆
在cpu外围模块（tv80）、串行接口（uart）、加密控制逻辑（controller）以及MAC运算单元上都验证有效。但设计规模都只有几百到几千行RTL，百万门级、多时钟域、复杂流水线的工业级设计还没有触及。
硬件需求及成本： ★★★★☆
运行依赖Claude Opus 4.6这类商业大模型和Synopsys/JasperGold商业EDA工具，软件成本不低，但相比人工优化仍省力。推理调度本身没有额外固定开销。
复现难度： ★★★★☆
代码会在同行评审后开源，数据使用了开源的Nangate 45nm库和公开的RTL模块，不存在私有数据集问题。主要门槛在于合成和验证工具需要商业授权，以及Opus API调用的费用。
产品化成熟度： ★★★☆☆
自适应调度逻辑非常轻量，可直接嵌入现有LLM智能体框架。但要真正产品化，还需要适配多设计层级优化、处理工艺库差异、改到半监督的门级网表优化等。本次结果更像一个充分验证过的原型而非完整产品。
可能的问题： 测试设计集规模偏小，三个测试设计均来自约几千行的小型模块，统计显著性有限，在大规模工业设计上的推广结论尚需更多实验支撑。
主要参考文献
[1] S. Cuyckens et al., "Ares: Adaptive Reasoning-Effort Steering for PPA- and Cost-Aware RTL Optimization with LLM Agents," arXiv:2607.27879, 2026. [2] Dr. RTL: A skill-library-based LLM agent for RTL optimization（原文引用[9]）. [3] REvolution: An evolutionary LLM-RTL optimization framework（原文引用[22]）. [4] VeriAgent: Structured-node-based Verilog generation agent（原文引用[33]）. [5] RTL-Rewriter benchmark（原文引用[34]）. [6] OpenRouter API pricing documentation（原文引用[21, 26]）. *本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击 "阅读原文"， 查看更多原论文细节哦！
