[控场AI]
· 4 分钟阅读· 2,341 字

LLM优化代码反而更耗能?实测44种配置仅2种省电

LLM优化代码反而更耗能?实测44种配置仅2种省电

实测44种LLM代码优化配置,42种产出的代码反而比人类参考解更耗能。

一项针对EffiBench全部1000道题目的实证研究,对11个开源模型、4种解码配置进行了硬件级能耗测量。结果显示,LLM自我精炼产出的“性能优化代码”普遍比人类工程师的参考实现更耗能:44种配置中有42种能耗更高,超出幅度从+4%到+886%。优化过程本身的推理能耗在0.79至8.68 MJ之间,相当于250到2800次GPT-4.1查询。研究还发现,限制最大输出token可削减最多69%的推理能耗,而同等规模下MoE架构比稠密模型更节能。核心结论是性能优化与能效并非天然一致,开发者应把能耗纳入评估指标。

LLM优化代码反而更耗能?实测44种配置仅2种省电

用大模型来自动优化代码性能,听起来既高效又环保:代码跑得更快,自然就更省电。但一项针对EffiBench全量1000道题目的实证研究推翻了这个直觉。研究团队对11个开源模型、4种解码配置进行硬件级能耗测量后发现:LLM自我精炼产出的"性能优化代码",普遍比人类工程师的参考实现更耗能——44种配置中有42种能耗更高,超出幅度从+4%到+886%不等。

Green Code or Costly Code 研究来源截图

一个被默认为真的假设

"代码更快=更省电"是工程界长期沿用的经验法则,LLM代码优化流水线也建立在这一前提上。研究直接检验了两件事:LLM自我精炼生成的性能优化代码,是否相对人类参考解同样节能;优化过程本身的能耗,能否被后续运行节省所抵消。

测量覆盖EffiBench的全部1000个问题,在每一次进程级采集硬件能耗数据,而不是靠理论模型估算。这意味着结论建立在真实功耗曲线上,而非"CPU时间×平均功率"这类粗粒度推算。

EffiBench 是评估大模型生成代码效率的基准测试集,包含1000道编程题,每题都配有经过性能优化的人类参考实现,并标注了执行时间与内存占用等效率指标。与仅考察功能正确性的基准(如HumanEval)不同,EffiBench要求模型在通过测试用例的同时,尽量逼近参考解的资源消耗水平。研究者常用它衡量LLM是否真正具备“写出高效代码”的能力,而本文正是借助其完整题目集,将评测维度从运行时间进一步延伸到硬件能耗。

推理能耗:从250到2800次GPT-4.1查询

优化过程自身的代价首先值得关注。不同模型与解码配置组合之间,推理能耗跨度从0.79 MJ到8.68 MJ,约等于250到2800次GPT-4.1查询的能耗。对于把LLM优化当作日常开发环节的团队来说,这个数量级意味着优化行为本身会留下可观的碳足迹。

一个立竿见影的杠杆是限制最大输出token数:相比默认配置,能耗最多下降69%。这符合直觉——输出越短,解码步数越少——但它也提示,许多优化流水线在默认参数下存在大量"冗余思考"。

研究能耗测量示意

解码配置指影响大模型文本生成过程的一组采样参数,常见的有温度(temperature)、top-p、top-k、束搜索宽度以及最大输出token数等。温度越高、采样越随机,模型越可能“绕路”生成长推理链;束搜索则会并行维护多条候选路径,成倍增加计算量。因此,即便同一个模型,不同解码配置下的推理能耗也可能相差一个数量级。本文测量的4种解码配置,正是为了分离“模型本身”与“生成策略”对能耗的贡献。

执行侧反转:42/44配置更耗能

真正反直觉的是执行阶段。在44种模型-配置组合中,有42种生成的代码在每个问题上都比人类参考解消耗更多能量,额外开销从+4%延伸到+886%。仅有的两个例外也只是边际收益,且盈亏平衡点需要10^6到10^7次执行量级——现实中几乎没有项目会跑到这个规模。

也就是说,LLM追求的那种"跑分更快"的代码,往往通过更大内存占用、更激进的并行或更复杂的控制流换来了速度,代价是更高的实际功耗。性能指标与能耗指标在这里出现了系统性背离。

架构选择比解码参数更重要

研究还给出一个对可持续性实践更有指导意义的发现:同等参数规模下,混合专家(MoE)架构的推理能耗显著低于稠密模型,且不牺牲正确性。相比之下,解码参数调优带来的收益是局部的、有限的。

这把"绿色AI"的讨论从"怎么调参"推向"怎么选型"——模型架构层面的决策,对长期能耗的影响比微调解码配置更深远。

混合专家(MoE) 架构把前馈网络拆分为多个“专家”子网络,并通过门控机制为每个token只激活其中少数几个专家。这样模型总参数量可以做得很大,但单次前向传播实际参与计算的参数(激活参数)远少于稠密模型,从而显著降低推理时的算力与能耗需求。与之相对,稠密模型每个token都要经过全部参数计算。在参数规模相当的前提下,MoE正是凭借“稀疏激活”在能耗上占优,同时保持与稠密模型相近的正确性表现。

对开发者的三点启示

不要默认性能优化等于节能。 如果可持续性是项目目标之一,就需要把能耗纳入评估指标,而不是只看运行时间或基准分数。

为优化流水线设置输出预算。 限制输出token可以带来最高69%的推理能耗削减,是成本最低的改进之一。

把架构选型当作环保杠杆。 在满足正确性前提下,MoE相对稠密模型的能耗优势,比反复调解码参数更值得优先考虑。

研究团队已将全部工件公开(DOI: 10.5281/zenodo.23598170),EffiBench上的测量流程可复现。这项工作最核心的提醒是:LLM自我精炼擅长制造"看起来更快"的代码,但人类工程师写出的参考解,在能效上仍是一个难以逾越的基准。

常见问题

LLM优化代码一定更耗能吗? 并非绝对,但实测44种配置中42种能耗更高,仅2种有边际收益且盈亏平衡点极高。

怎样降低LLM代码优化的能耗? 限制最大输出token可削减最多69%推理能耗;选择MoE架构比调解码参数更有效。

这项研究覆盖多大范围? 11个开源模型、4种解码配置、EffiBench全部1000道题,全程硬件级能耗测量。

#LLM代码优化能耗#EffiBench能效基准#大模型推理能耗#绿色AI#MoE架构能耗#LLM自我精炼#代码性能优化能效
分享:

相关推荐