LLM 기반 하이퍼파라미터 최적화, 고전 알고리즘을 넘어설 수 있을까?

본 논문은 autoresearch 라는 오픈소스 레포지토리를 활용해 LLM 에이전트가 하이퍼파라미터 최적화를 수행하는 방식을 체계적으로 평가한다. 연구 배경으로는 Karpathy(2025)가 제시한 LLM 기반 코드 편집 에이전트가 100번 이하 트라이로 작은 언어 모델(≈50 M 파라미터)의 val_bpb를 0.978 수준까지 끌어올렸다는 점을 들며, 이후 Ziv(2025)가 TPE를 사용해 동일 예산 내에서 더 나은 성능을 달성했다는 사실을 소개한다. 이를 토대로 두 가지 질문을 제시한다. (i) 다른 고전 HPO 알고리즘은 이 작업에서 어떻게 성능을 보이는가? (ii) LLM 기반 HPO가 고전 방법을 능가할 수 있는가? 실험 설계는 다음과 같다. 24시간 GPU(단일 H200) 예산과 3개의 시드 하에 9가지 방법을 비교한다. 고전 방법은 CMA‑ES, TPE, SMAC, Random Search이며, LLM 기반 방법은 Qwen3.5‑27B를 이용한 Karpathy Agent(14 HP), Karpathy Agent(Code), LLAMBO(Optuna), LLAMBO(Paper)이다. 또한 CMA‑ES와 LLM을 내부 상태로 공유하는 하이브리드 Centaur 를 제안한다. 탐색 공간은 트레이닝 스크립트(train.py)에서 자동 AST 파싱을 통해 추출한 14개의 하이퍼파라미터(13 연속/정수, 1 범주형)로 구성했으며, 각 파라미터의 범위는 도메인 지식을 반영해 수동 설정했다. 결과는 크게 세 축으로 분석된다. 첫째, 고정된 탐색 공간에서는 고전 방법이 일관적으로 우수했다. CMA‑ES와 TPE는 빠른 수렴과 낮은 OOM 비율(16%·11%)을 보였으며, 최종 val_bpb는 0.9785~0.9814 수준이었다. 반면 LLM 전용 방법은 대부분 0.986~0.992 수준으로 뒤처졌고, 특히 LLAMBO 계열은 OOM 비율이 48~61%에 달해 탐색 효율이 크게 저하되었다. 이는 중소형 LLM이 메모리 한계를 예측하지 못해 실패 트라이가 많아지는 현상을 보여준다. 둘째, 코드 편집을 직접 수행하는 Karpathy Agent(Code)는 27 B 모델일 때만 고전 방법에 근접한 성능(0.9814)을 기록했으며, 0.8 B 모델은 0.9910 수준으로 크게 뒤처졌다. 이는 무제한 탐색 공간에서 모델 규모가 직접적인 성능 결정 요인임을 의미한다. 셋째, 하이브리드 Centaur 는 CMA‑ES의 평균(µ), 스텝 사이즈(σ), 공분산 행렬(C)을 LLM에 전달하고, 30% 트라이에서 LLM이 제안을 재작성하도록 설계했다. 27 B LLM은 모든 경우에 제안을 대체했으며, 0.8 B LLM도 95%에서 대체했다. 그 결과 Centaur는 0.9763±0.0005의 최저 val_bpb를 달성했으며, 이는 순수 CMA‑ES와 TPE를 모두 앞선 성과다. 특히 0.8 B 모델이 27 B 모델보다 비용 대비 효율이 높아, 작은 LLM도 강력한 고전 옵티마이저와 결합하면 충분히 경쟁력을 가질 수 있음을 보여준다. 추가 분석에서는 OOM 비율, 탐색 다양성(스프레드, 페어와이즈 거리, 셀 수) 등을 정량화했다. 고전 방법은 낮은 OOM과 안정적인 수렴을 보였고, LLM 기반 방법은 높은 탐색 다양성에도 불구하고 메모리 관리 능력 부족으로 성능이 저하되었다. 하이브리드 접근법은 이러한 약점을 보완하면서도 LLM이 제공하는 도메인 지식(코드 수정, 학습 트릭) 활용을 가능하게 했다. 결론적으로, LLM이 단독으로 고전 HPO를 대체하기는 어려우나, 최적화 상태를 공유하는 하이브리드 설계가 실용적인 성능 향상을 가져올 수 있음을 실증한다. 향후 연구에서는 더 큰 프론티어 모델, 다중 작업 전이, 메모리 예측을 위한 LLM 서브시스템 등을 결합해 자동화 파이프라인을 강화할 여지가 있다.