AutoLab: Can Frontier Models Solve Long-Horizon Auto Research and Engineering Tasks?

이 논문은 기존 benchmark가 주로 한 번의 응답이나 짧은 agent 궤적을 재서 몇 시간에 걸친 반복 개선 능력이 평가 밖에 남는 문제를, 일부러 덜 최적화한 baseline을 정해진 시간 안에 개선하게 하는 36개 과제의 benchmark AutoLab으로 풀었다.

이 논문은 한마디로 동작은 하지만 최적화 전 상태인 baseline code를 받아 2시간에서 12시간의 wall-clock 예산 안에 측정과 수정을 되풀이해 개선하게 하는 장기 최적화 benchmark다. 시스템 최적화 15개, puzzle과 challenge 10개, 모델 개발 7개, CUDA(NVIDIA GPU용 병렬 프로그래밍 platform) kernel 최적화 4개로 36개 과제를 만들고, 점수는 baseline을 0으로 두고 사람이 쓴 reference 해법을 기준점으로 삼는 0에서 1 사이 연속 점수로 매긴다(parameter 수를 줄이는 과제 두 개는 parameter 0개를 기준점으로 삼는다). 17개 모델을 같은 harness(terminus-2)로 시험하자 claude-opus-4.6이 Avg@3(세 번 실행 점수의 평균) 0.68로 가장 높았고 2위 gemini-3.1-pro는 0.50이었다. 저자들은 성공의 가장 강한 예측 변수가 첫 시도의 질보다 측정, 수정, feedback 반영을 끈질기게 되풀이하는 정도이며, 대부분의 frontier 모델이 너무 일찍 끝내거나 예산을 모두 쓰고 거의 진전 없이 끝났다고 보고했다.

핵심 요약

• 문제: 과학과 공학의 진전은 변경을 제안하고, 실험을 실행하고, 결과를 재고, 산출물을 고치는 장기 반복 과정인데, 기존 frontier 모델 benchmark는 주로 한 번의 응답이나 짧은 agent 궤적을 잰다. AlphaEvolve나 Karpathy의 AutoResearch agent처럼 가장 눈에 띄는 경험적 최적화 사례는 모델별로 깊게 다듬은 harness, tool, 탐색 전략과 함께 설계돼 모델 자체의 기여를 떼어 보기 어렵다. 저자들이 든 기존 장기 benchmark는 ML engineering, 시스템과 kernel 최적화, 실제 공학처럼 한 분야씩 다뤄, 넓은 분야, 높은 난도, 포화 저항을 함께 갖춘 것은 없었다.
• 입력과 출력: 이 논문은 benchmark 논문이다. agent는 자연어 지시와, 동작은 하지만 최적화 전 상태인 baseline code와 local 평가 script가 든 container sandbox(workload에 따라 CPU 또는 GPU 한 장)를 받아, wall-clock 예산 안에 code를 고치고 실행하고 측정한 끝의 구현을 제출한다. agent에게 감춘 verifier가 숨긴 입력으로 지표(실행 시간, perplexity, 처리량, parameter 수 등)를 재고, 이를 baseline과 사람이 쓴 reference 해법을 기준점으로 한 0에서 1 사이 연속 점수로 바꾼다.
• 방법: 과제는 senior 연구자와 engineer가 직접 겪은 실제 문제에서 냈고, 원 제공자와 독립된 전문가 2명 이상과 형식 감사 agent가 validity(높은 점수가 더 좋은 구현을 뜻하는지), solvability(reference가 정한 예산과 hardware에서 목표 점수에 안정적으로 닿는지), integrity(agent가 점수 함수를 hacking해 통과할 수 있는지), 측정 안정성(reference 반복 실행의 분산이 충분히 작은지) 네 기준으로 감사해 떨어진 과제는 고치거나 뺐다. 성능 최적화 과제는 log 척도 점수(baseline 0, reference 0.5, 실질 최적에 다가갈수록 1.0)와 baseline을 넘어야 점수가 붙는 gate를 쓰고, 품질 지표 과제는 선형 점수(baseline 0, reference 1.0)를 쓰되 parameter 수를 줄이는 puzzle 과제 두 개는 parameter 0개를 기준점으로 삼는다. reward hacking을 막으려고 verifier를 감추고, ML 과제에는 개발 때 보이는 입력과 다른 분포에서 뽑은 입력으로 정확성 gate를 두며, 지름길을 찾도록 지시한 적대 agent로 과제를 시험하고, 고정해야 할 핵심 파일은 hash로 묶어 무단 수정이 있으면 0점을 주며, 평가 중에도 궤적을 분석해 새 hacking이 보이면 verifier를 고친다.
• 구현: 36개 과제는 시스템 최적화 15개(C, C++, Rust, Go, Python), puzzle과 challenge 10개, 모델 개발 7개, CUDA 4개이고, wall-clock 예산은 가장 작은 puzzle 과제의 2시간에서 LLM 개발 과제의 12시간까지다. 평가는 Harbor framework의 terminus-2 agent를 모든 모델에 기본으로 쓰고, CPU 과제는 Ryzen 9 9950X(16 core)와 64GB 메모리의 local Docker sandbox에서, GPU 과제는 H100과 L40S(둘 다 NVIDIA GPU)를 단 Modal cloud sandbox에서 실행했으며, 전체 평가에 2,544 wall-clock 시간과 8.60 billion token이 들었다. 공식 저장소(autolabhq/autolab)의 README는 tasks 폴더에 과제마다 task.toml, instruction.md, Dockerfile과 고칠 file, agent에게 감춘 solution, 점수를 매기는 tests를 두고, Harbor의 harbor run 명령으로 한 과제나 전체 과제를 실행하는 방법을 설명한다.
• 결과: 주 평가 11개 모델에서 claude-opus-4.6은 Avg@3 0.68, Best@3(세 번 중 최고) 0.76, Dominance(과제마다 다른 모델과 맞대결한 승률) 0.93으로 네 분야 모두 1위였고, 2위 gemini-3.1-pro는 Avg@3 0.50, open-weight 모델 가운데서는 kimi-k2.6 0.46, mimo-v2.5-pro 0.45, glm-5 0.43이 앞섰으며, gpt-5.4는 0.36, grok-4-20은 0.35였다. 2시간짜리 CPU 과제 flash_attention에서 모델마다 세 번 실행 가운데 가장 좋은 실행(best rollout)을 비교하자, claude-opus-4.6은 약 40분 동안 44번의 feedback 기반 반복으로 agent가 스스로 보고한 실행 시간을 약 750 ms에서 18 ms로 줄여 reference 해법(100 ms)을 넘었다. 점수 0인 rollout 302개를 사람이 모두 분류한 실패 분석에서 저자들은 시간 감각 부족을 두 행동으로 정리했는데, deepseek-v4-pro, hunyuan-3-preview, qwen-3.6-plus는 최종 제출 전에 예산을 모두 쓰는 경우가 잦았고, gpt-5.4와 grok-4-20은 예산이 많이 남았는데도 짧게 탐색하고 제출하는 경우가 잦았다.
• 한계: 저자들은 AutoLab이 실행 가능한 시스템과 ML engineering workflow에 집중하므로 넓은 의미의 과학적 발견보다 측정 가능한 자동 연구의 benchmark로 봐야 한다고 밝혔다. 성능 최적화 과제의 baseline과 reference 값은 이 benchmark의 sandbox와 hardware에 맞춘 값이고, 200B parameter 미만의 작은 open-weight 모델은 benchmark 난도 때문에 대상에서 뺐다. CPU 과제 25개에서 모델 4개를 다른 harness 두 개(pi-mono, 끈질긴 최적화를 요구하도록 system prompt를 바꾼 mini-swe-agent)로 다시 평가하자 같은 모델의 평균 점수가 최대 0.43(kimi-k2.6, pi-mono의 0.21에서 mini-swe-agent의 0.64) 달라졌고, 저자들은 harness가 만드는 점수 차이가 모델 사이 차이와 비슷할 수 있다고 보고했다.

논문 링크

외부 연구를 정리한 자료입니다. HDATF가 발표한 논문이나 제품 성능을 측정한 결과는 아닙니다.