LLM 코드 최적화는 빨라져도 실행 에너지는 더 쓴다

무엇인가

이 논문은 LLM으로 코드를 "더 빠르게" 만드는 일이 정말로 "더 친환경적"인지를 측정한다. LLM 기반 코드 최적화에는 두 종류의 에너지 비용이 붙는다. 모델이 코드를 생성할 때 쓰는 추론 에너지와, 그 코드가 나중에 실행될 때 쓰는 실행 에너지다. 둘 다 개발자 눈에는 보이지 않지만, 최적화가 순이익인지 손해인지는 이 둘의 합으로 결정된다. 기존 연구(Coignion 등)는 손익분기점(BEP)을 정의했지만, 각 모델이 자기 자신의 미최적화 출력 대비 얼마나 개선했는지만 봤다. 모델이 자기 기준으로는 크게 개선해도, 숙련된 인간이 쓴 코드보다 여전히 비효율적일 수 있다는 점을 놓친 것이다. 이 논문은 비교 기준을 EffiBench의 정답(human canonical) 솔루션으로 잡아 그 질문을 다시 던진다.

어떻게 동작하나

방법은 EffiLearner라는 반복 자기 개선 파이프라인을 그대로 쓰되, 그 주변의 에너지를 정밀 계측한다. 파이프라인은 코드 생성, 오버헤드 프로파일링, 코드 개선의 세 단계를 반복한다. 각 반복에서 현재 후보를 로컬에서 실행해 line_profiler로 실행 시간 프로파일을, memory_profiler로 메모리 프로파일을 뽑는다. 측정은 스크립트당 60회 반복해 평균을 내고, 연속 실행 사이에 15초 쿨다운을 두며 CPU 부하 50% 미만·패키지 온도 50~60도 조건을 만족할 때만 측정을 허용한다. 프로파일과 문제 설명, 공개 테스트 케이스를 하나의 개선 프롬프트로 합쳐 모델에 되돌려주고, 수정본이 공개 테스트를 통과하면 후보를 교체한다. 최종 평가는 공개 테스트와 분리된 비공개 테스트로 한다. 실험은 EffiBench 1,000문제(쉬움 171, 보통 589, 어려움 240) 전체에서 11개 오픈소스 모델 × 4개 디코딩 설정으로 돌렸다. 설정은 기본(온도 0, 최대 출력 2,048토큰), 온도 0.5, 컨텍스트 64k 제한, 최대 출력 1,024토큰(mt1024)이며 각 설정은 파라미터 하나만 바꾼다. 하드웨어는 Intel Xeon Gold 6438Y+ 2개(논리 코어 128개), 1TB 메모리, NVIDIA L40 46GB 2장이고 vLLM으로 서빙했다. 에너지는 Metrion으로 측정했는데, Intel RAPL과 nvidia-smi, 하드웨어 성능 카운터를 eBPF로 묶어 스레드 단위로 CPU·DRAM·GPU 에너지를 귀속시키고, APERF/MPERF 비율로 DVFS·터보 부스트를 보정하며 SMT 중첩 스레드에 1.15의 경합 계수를 적용한다. 추론 에너지는 1,000문제 전체를 6회 완전 반복한 평균, 실행 에너지는 인터프리터를 유지한 채 60회 실행한 평균이다. 전체 파이프라인에는 약 30일의 연속 실행이 필요했다. 참고로 저자들은 EffiBench 테스트 케이스 1,000개 중 122개가 GPT-3.5 Turbo가 만든 케이스 결함으로 정상 실행이 안 된다는 것을 발견하고 유형별로 수리해 공개했다.

무엇과 다른가

생성 측 결과부터 보면, 모델·설정 조합별 추론 에너지는 0.79~8.68MJ로 약 10배 차이가 났고, 이는 GPT-4.1 질의 250~2,800회에 해당하는 양이다. 디코딩 파라미터 중에서는 최대 출력 토큰을 1,024로 제한하는 mt1024가 가장 효과가 커서 기본 설정 대비 추론 에너지를 13~69% 줄였다. 다만 일부 설정에서는 pass@1이 크게 무너졌다. 정확도 대비 에너지 효율(pass@1/E_total, %MJ⁻¹)에서는 Qwen3.5-4B가 모든 변형에서 프런티어를 지배했고, Ministral-3B가 34.0 %MJ⁻¹로 비-Qwen 최고였다. 반대로 GLM-4.7-Flash와 Nemotron-Cascade mt1024는 4.1, 3.7 %MJ⁻¹로 최하위였다. Qwen3.5-27B는 절대 pass@1이 80.98%로 가장 높았지만 생성 비용 8.58MJ 때문에 효율은 약 9.4 %MJ⁻¹로 떨어졌다. 아키텍처 선택이 디코딩 파라미터보다 훨씬 큰 지렛대라는 점도 확인됐다. MoE인 Qwen3.5-35B-A3B는 dense인 Qwen3.5-27B와 거의 같은 정확도를 내면서 추론 에너지는 절반 이하였다.

어떻게 쓰나

실행 측 결과가 이 논문의 핵심이다. 44개 모델·설정 조합 중 42개에서 LLM이 최적화한 코드가 인간 정답보다 문제당 실행 에너지를 더 많이 썼고, 초과 폭은 +4%에서 +886%에 이르렀다. 최악은 GLM-4.6V-Flash로 모든 변형이 문제당 1.5J를 넘었고 기본 설정에서 1.94J까지 갔다. Qwen 계열은 평균 0.26J로 낮은 편, Ministral은 0.66J로 중간이었다. 인간 정답을 앞선 예외는 두 개뿐이었다. Qwen3.5-9B t0.5가 문제당 0.65J, Nemotron-Cascade mt1024가 0.02J를 아꼈는데, 이마저도 손익분기점이 각각 약 3.4×10⁶회와 6.4×10⁷회 실행으로 사실상 도달 불가능한 수준이다. 즉 42개 설정은 코드를 몇 번 실행하든 생성에 쓴 에너지를 회수하지 못한다. 더 눈에 띄는 건 자기 자신의 초기 생성물과 비교해도 나아지지 않는다는 점이다. 44개 중 20개(45.5%)만 실행 에너지가 개선됐고 24개(54.5%)는 오히려 퇴행했다. Nemotron-Nano t0.5는 문제당 -0.54J, 기본 설정은 -0.44J로 최적 에폭이 최악 에폭보다 더 많은 에너지를 쓰는 코드를 만들었다. 탄소로 환산하면(γ=217 gCO₂eq/kWh) 1,000문제 최적화의 생성 측 배출량은 Ministral-3B 76.8gCO₂eq에서 Qwen3.5-27B 517.0gCO₂eq까지이며, 실행 측 배출량은 생성 측보다 세 자릿수 작다.

전제와 한계

개발자에게 주는 결론은 조건부다. LLM 자기 최적화는 실행 빈도가 매우 높은 핫패스 코드에만 에너지적으로 정당화된다. 한 번 쓰고 마는 스크립트나 가끔 호출되는 유틸리티는 생성 비용을 평생 회수하지 못한다. 정확도 요건이 허락한다면 Ministral-3B나 Qwen3.5-4B 같은 작은 모델을, 가능하면 MoE 아키텍처를 고르는 편이 낫다. 또 EffiLearner류 파이프라인은 실행 시간과 메모리만 보고 후보를 교체할 뿐 실행 에너지를 선택 기준에 넣지 않기 때문에, 절반 이상의 설정에서 퇴행이 발생한다. 자체 최적화 루프를 만든다면 에너지를 명시적 선택 기준으로 넣어야 한다는 것이 저자들의 권고다.

저자들이 밝힌 한계는 분명하다. EffiBench 문제는 짧고 알고리즘 밀도가 높으며 1초 안에 끝나서, 손익분기가 최적화에 유리하게 나올 수 있는 장시간 워크로드를 대표하지 못한다. 비교 기준인 정답 솔루션도 평범한 개발자 코드가 아니라 경쟁 프로그래밍 포럼의 최상위 제출물이라 매우 강한 베이스라인이며, 인간의 작성 비용은 0으로 두고 LLM 생성 비용만 전부 계산했다. 다만 42개 설정에서 반복 비용 차이가 음수이므로 이 가정을 바꿔도 결론은 뒤집히지 않고, 오히려 실행 횟수가 적을 때만 LLM 최적화에 유리해진다. 파이프라인 자체에 에너지 게이트가 없어 퇴행 원인을 모델 능력으로만 돌리기 어렵다는 점, 실험이 인터프리터 언어인 Python에 한정돼 C++나 Rust에서는 격차가 줄 수 있다는 점, 하드웨어 계측 때문에 오픈소스 모델만 다뤄 상용 API 프런티어 모델로 확장되지 않는다는 점, 그리고 측정이 운영 에너지만 포함하고 GPU 제조·데이터센터 냉각·학습·하드웨어 교체 같은 내재 비용은 빠졌다는 점을 함께 밝히고 있다.