研究：LLM 迭代优化代码耗能更高，42/44 配置超人类参考
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载被检验的假设
业界用 LLM 优化代码时，普遍默认执行速度变快就等于总能耗下降。该研究直接检验这一前提：由 LLM 自我精炼流程产出的性能优化代码，相对人类标准参考解是否同样节能；以及优化过程本身消耗的能量，能否被后续运行节省抵消。实验在 EffiBench 的 1000 道题上展开，覆盖 11 个开源模型与四种解码配置，全程按进程采集硬件级能耗数据，而非用估算系数折算。
推理侧能耗与省电手段
不同模型与配置组合的推理能耗跨度很大，从 0.79 MJ 到 8.68 MJ，换算后相当于 250 到 2800 次 GPT-4.1 查询。在所有可调项中，限制最大输出 token 数的作用最突出，相比默认设置最多削减 69% 能耗。研究进一步指出，架构选择比解码参数更能影响可持续性：在参数量相当的情况下，混合专家（MoE）模型的推理能耗明显低于稠密模型，且正确性没有下降。
执行侧的反直觉结果
在生成代码的运行能耗上，44 种配置里有 42 种产出的代码，单题能耗高于人类工程师写出的参考解，额外开销从 4% 一直到 886%。仅有的两个例外也只是取得微弱收益，要把优化过程投入的能量赚回来，需要 10^6 到 10^7 次量级的执行。也就是说，追求更快的代码与追求更省电的代码并不总是一致，LLM 自我精炼倾向于产出运行更快但更耗能的实现。
对使用者的含义
这项工作的结论指向一个具体做法：把 LLM 用于代码优化时，应同时核算推理阶段与运行阶段的能耗，而不是只看执行时间。控制输出长度是当下最容易落地的降耗手段，模型架构选型则带来更大幅度的差异。论文的全部工件已公开，作者信息与录用信息显示该工作被 ICSE 2027 软件工程方向接收。
为什么值得看
用 LLM 自动优化代码未必更省电，这项实测给出了能耗账本和可操作的省电开关。
信源1 家
关键事实
相关 · 论文
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。