Karpathy의 Autoresearch 스케일링: 에이전트에게 GPU 클러스터를 줬더니 무슨 일이 생겼나

TL;DR Highlight

Claude Code 에이전트가 16개의 GPU로 8시간 내 910개의 실험을 수행하여 validation loss를 2.87% 개선하고 H100/H200 혼합 하드웨어 활용 전략을 자동으로 구축했다.

Who Should Read

ML 실험을 반복적으로 돌리면서 하이퍼파라미터 튜닝에 시간을 많이 쓰는 ML 엔지니어나, AI 에이전트에게 클라우드 인프라를 자율적으로 맡기는 방식에 관심 있는 인프라 엔지니어.

Core Mechanics

Karpathy의 autoresearch는 에이전트가 train.py를 수정하고, 5분짜리 학습 실험을 돌리고, validation loss를 확인한 뒤 좋은 변경만 남기는 루프를 반복하는 구조다. 기본 셋업은 GPU 1개로 순차 실행이라 시간당 약 12개 실험밖에 못 한다.
GPU가 1개뿐일 때 에이전트는 '하나 해보고, 결과 보고, 다음 거 해보고'식의 greedy hill-climbing에 갇힌다. 5분 학습 중에는 에이전트가 아무것도 못 하고 그냥 대기해야 하기 때문에 비효율적이다.
SkyPilot(클라우드/Kubernetes에서 GPU 작업을 YAML 한 장으로 띄울 수 있는 오픈소스 툴)을 이용해 에이전트에게 16개 GPU를 붙여줬다. 에이전트가 SkyPilot 사용법을 스스로 읽고 클러스터를 직접 관리했으며, 수동 클라우드 설정은 전혀 없었다.
16개 GPU를 주자 에이전트는 한 번에 10~13개 실험을 병렬로 돌리는 factorial grid 방식으로 전략이 바뀌었다. 예를 들어 모델 width 6가지를 한 wave에 동시에 테스트해서 추세를 즉시 파악하고, 최적값으로 바로 좁혀들어갔다(원래라면 6번의 순차 실험이 필요).
8시간 동안 총 약 910개 실험을 돌렸고, val_bpb(validation bits per byte, 낮을수록 좋은 언어 모델 성능 지표)를 baseline 1.003에서 0.974로 2.87% 낮췄다. 순차 실행 시뮬레이션 대비 동일한 최적 loss에 9배 빠르게 도달했다(~8시간 vs ~72시간).
실험 5단계로 자연스럽게 분화됐다: 1단계 하이퍼파라미터 스윕(~200개), 2단계 아키텍처 탐색(~200-420), 3단계 넓은 모델 파인튜닝(~420-560), 4단계 옵티마이저 튜닝(~560-700), 5단계 수확 체감(~700-910). 모델 width를 키우는 것이 어떤 단일 하이퍼파라미터보다 효과가 컸다.
에이전트가 H100과 H200 두 종류의 GPU에 접근 가능하다는 걸 스스로 발견하고, 아무도 가르쳐주지 않았는데도 '아이디어는 저렴한 H100에서 스크리닝하고, 유망한 것만 H200으로 검증'하는 전략을 자체적으로 만들어냈다.

Evidence

일부 댓글에서는 이게 결국 하이퍼파라미터 튜닝을 재발명한 것 아니냐는 지적이 나왔다. Bayesian optimization이 소규모 클러스터에서의 SOTA였는데, LLM 에이전트가 그보다 나은 점이 뭐냐는 질문이다. 반면 에이전트 방식의 장점은 물리 시뮬레이션 튜닝에 적용해봤더니 암묵적 제약 조건을 찾아 활용하는 능력이 있어서 단순 브루트포스보다 효과적이었다는 실사용 경험도 공유됐다.
병렬성이 실험 설계 자체를 바꿨다는 주장에 대해 흥미로운 반론이 있었다: 에이전트가 1개 GPU만 있어도 이론적으로는 '실험 12개 계획 → 순차 실행 → 결과 취합 후 방향 결정'이라는 프로토콜을 만들 수 있는데, 실제로는 greedy 전략으로 흘러간 것뿐이라는 지적이다. 즉 '나쁜 실험 설계 + 병렬성 = 좋은 실험 설계 + 순차 실행'이 될 수 있냐는 질문이다.
GPU 효율성 관점에서 블로그가 과대 포장됐다는 비판도 있었다. 16 GPU × 8시간 = 128 GPU-시간을 쓴 반면, 순차 실행은 1 GPU × 72시간 = 72 GPU-시간이다. 동일한 GPU-시간(약 4.5시간)에서 비교하면 순차 실행이 약 2배 더 효율적이라는 계산이다. 즉 더 큰 카드를 써서 빠르게 간 것이지 효율이 좋아진 건 아니라는 지적.
5분짜리 학습으로 장기 성능을 판단하는 방식의 신뢰성에 대한 우려도 나왔다. 초반 5분에는 빠르지만 더 오래 학습하면 asymptote(수렴 한계)가 낮아지는 설정을 에이전트가 잘못 선택할 수 있다는 점이다. 예를 들어 특정 quantizer가 초반엔 빠르지만 결국 노이즈 플로어 때문에 더 이상 개선이 안 될 수 있다.
Optuna 같은 기존 하이퍼파라미터 최적화 툴로 C++ 단일 서버에서 할 수 있는 일을 GPU 클러스터 + LLM으로 복잡하게 만든 것 아니냐는 냉소적인 댓글도 있었다. 반면 SkyPilot을 실제로 멀티클라우드 학습/추론에 쓰고 있다는 긍정적인 사용 경험도 함께 공유됐다.

How to Apply

ML 실험을 반복적으로 돌리면서 하이퍼파라미터 조합을 탐색 중인데 GPU가 여러 대 있다면, SkyPilot의 YAML 설정 한 장으로 Claude Code 같은 코딩 에이전트에게 클러스터 접근권을 주고 autoresearch 패턴을 적용해볼 수 있다. 에이전트가 실험 계획, 제출, 결과 수집을 자율적으로 처리한다.
H100과 H200처럼 성능이 다른 GPU 혼합 환경을 운영 중이라면, 에이전트가 스스로 하드웨어 차이를 감지하고 활용 전략을 만들어낼 수 있다는 점을 활용해라. 명시적으로 하드웨어 스펙을 알려주지 않아도 실험 결과를 통해 에이전트가 스스로 파악한다.
autoresearch를 적용할 때 train.py(수정 가능), prepare.py(읽기 전용), program.md(에이전트 지침) 세 파일 구조를 그대로 가져다 쓰면 된다. 자신의 학습 스크립트를 이 구조에 맞게 분리하고 program.md에 평가 기준(어떤 메트릭을 최소화/최대화할지)만 잘 써주면 다른 ML 태스크에도 바로 적용 가능하다.
5분 실험 예산이 장기 성능을 대표하지 못할 수 있다는 점을 감안해서, 에이전트가 찾아낸 최적 설정은 반드시 더 긴 학습으로 검증하는 단계를 추가하는 것이 좋다. program.md에 '최종 후보는 X 에폭으로 재검증' 같은 지침을 명시하면 에이전트가 이를 따를 수 있다.

Terminology

val_bpbvalidation bits per byte의 약자로, 언어 모델이 텍스트를 얼마나 잘 예측하는지 나타내는 지표. 낮을수록 모델이 더 효율적으로 정보를 압축한다는 의미.

greedy hill-climbing현재 상태에서 가장 좋아 보이는 방향으로만 한 걸음씩 이동하는 탐색 방식. 빠르지만 전체 최적값(global optimum)이 아닌 지역 최적값(local optimum)에 빠질 위험이 있다.

factorial grid여러 파라미터의 조합을 동시에 테스트하는 실험 설계 방식. 예를 들어 learning rate 3가지 × batch size 4가지 = 12가지 조합을 한꺼번에 실험.

asymptote학습이 오래 진행될수록 성능 향상 곡선이 수평으로 수렴하는 지점. 이 한계값이 낮을수록 모델이 더 좋은 성능에 도달할 수 있다.

SkyPilotAWS, GCP, Azure, Kubernetes 등 여러 클라우드/인프라에서 GPU 작업을 YAML 파일 하나로 띄울 수 있는 오픈소스 도구. 멀티클라우드 GPU 조달이 어려울 때 유용하다.

autoresearch코딩 에이전트가 ML 학습 스크립트를 스스로 수정하고, 실험하고, 결과를 보고 다시 수정하는 루프를 자율적으로 반복하는 방식. Karpathy가 공개한 개념.