nanoGPT 스피드런을 위한 자율적 AI 연구

지난 2주 동안, 우리는 유휴 컴퓨팅 자원을 활용하여 Codex (gpt 5.5 xhigh)와 Claude Code (opus 4.7 xhigh)가 nanoGPT 스피드런 최적화 트랙(optimizer track)을 반복 수행하도록 했습니다. 목표는 간단합니다. 옵티마이저(optimizer), 스케줄(schedules), 초기화(initialization) 및 일부 하이퍼파라미터(hyperparameters)만을 변경하면서 목표 검증 손실(validation loss)에 도달하는 데 필요한 단계(steps) 수를 줄이는 것입니다.

에이전트들은 약 1만 번의 실행을 수행했으며, 약 14,000 H200 시간을 소모했습니다. 두 에이전트 모두 인간 기준점(human baseline)을 뛰어넘었으며 매 세션마다 새로운 기록을 세웠습니다. 현재 Opus가 2,930단계로 기록을 보유하고 있으며, 이는 인간의 기준점인 2,990단계를 경신한 것입니다.

기록 자체를 넘어, 우리는 에이전트들이 어떻게 탐색하는지, 어떻게 행동하는지, 그리고 자율성이 어디에서 무너지는지를 심층 분석했습니다. 우리는 에이전트들이 자신의 생각을 기록한 모든 스크래치패드(scratchpads), 약 1만 번의 실행 로그, 스크립트 및 설정 파일(configs)을 공개합니다: github.com/PrimeIntellect-ai/experiments-autonomous-speedrunning.

우리는 에이전트들이 옵티마이저 탐색(optimizer search), 하이퍼파라미터 스윕(hyperparameter sweeps), 그리고 방법론들을 결합(stacking)하는 데 매우 능숙하다는 것을 발견했습니다. 하지만 스스로 새로운 아이디어를 내는 데는 어려움을 겪으며, 계속해서 개선하기 위해서는 상위 단계의 인간 기록(upstream human records)이 필요하다는 점도 확인했습니다. 우리는 Opus가 반복적으로 중단하고 자율 루프(autonomous loop)에 머물기를 거부하는 행동이나, Codex가 멈추지는 않지만 몇 시간 동안 동일한 하이퍼파라미터 표면(hyperparameter surface)을 맴돌며 정체될 수 있는 등의 행동들을 기록했습니다.

문맥 (Context)

nanoGPT 스피드런은 Keller Jordan이 만든 커뮤니티 벤치마크로, 사람들이 작은 GPT(124M 파라미터)를 가능한 한 효율적으로 훈련하기 위해 경쟁하는 것입니다. 이전 트랙들은 정해진 실제 시간(wallclock time) 내에 가장 낮은 손실(loss)에 도달하는 것에 관한 것이었습니다. 트랙 3은 다릅니다. 옵티마이저와 초기화, 학습률(learning rate), 스케줄(schedule), 가중치 감쇠(weight decay)와 같은 관련 하이퍼파라미터를 제외한 모든 것(모델, 데이터, 아키텍처)이 고정되어 있습니다. 목표는 실제 시간 제약 없이 가능한 한 적은 단계로 목표 검증 손실에 도달하는 것입니다. 결과는 시드 해킹(seed hacking)을 방지하기 위해 통계적 노이즈 플로어(statistical noise floor)를 통과해야 합니다.

Muon은 기준 최적화 도구 (reference optimizer)이며, 현재 대부분의 제출물에서 시작점으로 사용되고 있습니다. 최근 커뮤니티는 매우 활발하게 움직이고 있으며, 지난 2주 동안 새로운 방법론을 제안하는 여러 개의 PR (Pull Request)이 올라왔습니다.

Harness

우리의 자율적 스피드런 (autonomous speedruns)이 가이드라인을 따르도록 하기 위해, 우리는 harness라고 부르는 일련의 마크다운 (markdown) 파일 세트를 만들었습니다. AGENTS.md는 벤치마크 규칙과 자율성 규칙을 정의합니다. goal.md는 미션의 맥락을 제공합니다. plan.md는 현재 시도의 가변적 상태 (mutable state)입니다. scratchpad/THREAD.md는 내구성이 있는 미션 로그 (durable mission log)로, 컨텍스트 압축 (context compaction) 이후에도 새로운 오케스트레이터 (orchestrator)가 복구할 수 있도록 합니다. scratchpad의 나머지 부분에는 변형 (variants), 실행 로그 (run logs), 논문 노트 (paper notes), 아이디어 노트 (idea notes), 그리고 스윕 결과물 (sweep outputs)이 담깁니다.

우리는 처음에 THREAD.md를 제외하고는 에이전트들이 직접 scratchpad 구조를 결정하도록 허용했으며, 그것이 어떤 모습일 수 있는지에 대한 예시를 제공했습니다. 에이전트들은 이를 거의 똑같이 복사했으며 일부 폴더는 비워둔 채로 두었습니다.

선택된 스레드 없음.

우리는 harness를 네 번 반복 실행했습니다. 그래프에는 각각 v1, novelty, v2, v3로 표시되어 있습니다. 이를 유용하게 읽는 방법은 다음과 같습니다:

**첫 번째 실행 (**두 에이전트 모두 벤치마크에서 시작하여 독립적으로 탐색합니다. 원래 계획은 Claude만 실행하는 것이었기 때문에 첫 번째 harness는 거의 전적으로 Claude에 의해 작성되었습니다. Codex는 두 번째 harness 단계 없이 나중에 동일한 파일들을 상속받습니다. 이 실행 단계에서는 에이전트가 유휴 클러스터 노드 (idle cluster nodes)에서 작업을 시작할 수 있는 preempt 워크플로우와, 각 에이전트가 상대방을 위해 최선의 방향을 작성하는 핸드오프 (handoff) 단계가 도입됩니다. 핸드오프 시점에 Claude는 이미 더 유용한 스택을 가지고 훨씬 앞서 나가 있습니다.)

**신규성 제한 탐색 (**이제 harness는 모든 아이디어가 신규성 검사 (novelty check)를 통과할 것을 요구합니다. 에이전트들이 공개 리더보드, 논문, 그리고 이전 실행 상태를 단순히 재조합하는 대신, 진정으로 새로운 최적화 도구 아이디어를 제안할 수 있을까요? 결과: 그들은 베이스라인 (baseline)을 개선하지 못했습니다. 우리는 Codex와 Claude가 생성한 아이디어들을 novelty로 게시합니다.)

).**연속 실행 (Continuation run) (**정리된 하네스 (harness), 두 에이전트 모두 더 많은 컨텍스트를 가지고 시작합니다: novelty-run 아이디어와 이전의 Claude 및 Codex 상태를 포함합니다. 이는 완전히 새로 시작하는 것이 아닙니다.v2

).또 다른 연속 실행 (v3와 동일한 아이디어)

).v2

. 인간의 기록이 우리 에이전트들을 앞질렀기에, 우리는 이 블로그를 게시하기 전 하룻밤 동안 얼마나 더 밀어붙일 수 있는지 확인하기로 했습니다.

두 에이전트 전체에 걸쳐 우리는 총 100회 정도의 개입 (intervention)을 수행했습니다. 대부분은 에이전트가 무엇을 작업하고 있는지 확인하는 것이며, 나중에는 GitHub에 보고서를 업로드하는 모니터링 에이전트로 대체되었습니다. 우리는 또한 에이전트가 스피드런 (speedrun) 규칙을 어기거나, 한 가지 방법에 너무 집중하거나, 재시작이 필요한 경우에도 개입합니다. 예를 들어, 매우 중요했던 초기 개입 중 하나는 목표가 단순히 3500 단계를 돌파하는 것이 아니라, 각각의 새로운 기록으로부터 계속해서 개선해 나가는 것임을 명확히 하는 것이었습니다. 이는 처음부터 AGENTS.md에 명시되어 있었지만, 에이전트들이 이를 포착하지 못했습니다.

결과 (Results)

각 반복 (iteration)이 무엇을 만들어냈는지 살펴보겠습니다. 에이전트들이 많은 시도를 했으므로, 통계적으로 유효한 주요 스택 (stacks)부터 시작하겠습니다.

NorMuon beta schedule; hidden AggMo; MLP error feedback; momentum refresh

Longer hidden horizon; MLP projection LR

MuonEq before NS; Contra-Muon after NS

Muon momentum schedule; hard cooldown compression; attention/MLP LR split

Embed init scale 0.7; eta floor; Polar Express soft/borderline

Muon2F

Tail EMA endpoint smoothing, borderline

MuonEq

Muon schedule; attention LR multiplier 0.6x

Polar Express; CGI/DI/embed init/Adam beta2

MuonEq

Muon schedule; rolelr2 per-role LR split (attention 0.62, MLP 1.0)

Lookahead; Polar Express

Contra-Muon, normal phase to step 2500; MLP+V SOAP; Soft-Muon and NorMuon-lite disabled

LR power 1.2; schedule 3050; Muon LR 0.0375; Muon WD 0.025

Radial damping 0.5/1.0; u/w floor 0.3825; AdamW betas (0.8, 0.99)

Contra-Muon; Soft-Muon; NorMuon-lite; MLP+V SOAP with warmstart/skip-first; tangent-sphere radial kept

LR power 1.2; schedule 3025; q/k/mlp_proj에 LACV 적용; q/k floor lambda=0.060; q/k Contra scale 0.125

Radial damping 0.45/1.0; u/w floor 0.3825; SOAP target u/w 0.395; tail radial tightening; sphere pull pruned; AdamW betas (0.8, 0.99)

다음은 v1, v2, v3 전체에 걸쳐 각 옵티마이저 (optimizer) 및 스케줄 (schedule) 아이디어를 포함하는 실행 (run)의 비율입니다.

각 실행은 여러 아이디어를 포함할 수 있으므로, 백분율은 중복될 수 있으며 합계가 100%가 되지 않습니다.

위의 모든 실행에 대해, 스택에서 불필요한 복잡성을 제거하기 위해 leave-one-out pruning을 수행했습니다. Claude v3의 경우, 모델이 일부 하이퍼파라미터 (hyperparameters)를 다시 스윕 (resweep)하도록 하는 특히 철저한 라운드를 진행했습니다. 이를 통해 실제로 성능을 저해하던 구성 요소들을 제거함으로써 기록을 약 20 스텝 (steps) 단축했습니다.

Pruning 라운드는 전체 실행의 약 5%를 차지합니다. 주목할 점은, v3에서 훈련 스케줄 (training schedule)이 모델이 실제로 목표 검증 손실 (validation loss)을 통과하는 시점을 넘어까지 연장된다는 것입니다. 예를 들어, 스케줄은 3050으로 설정되어 있지만 모델은 2920에서 목표를 통과합니다. 이는 LR power 1.2 → 1.0과 같은 스케줄 관련 하이퍼파라미터에 영향을 미칩니다.

동작 (Behavior)

자율성 (Autonomy)

이제 에이전트 (agent)의 동작과 실패 모드 (failure modes)를 기록하는 부분입니다. 가장 큰 문제부터 시작하겠습니다: Claude Code는 자율적으로 작동하기를 원하지 않습니다. AGENTS.md에 명시된 내용 및 사용자의 명시적 요청에 정면으로 배치됨에도 불구하고, 계속해서 사용자의 입력을 요구합니다.

Claude v1을 살펴보면, 약 22시간 동안 에이전트 중단 (agent-stopped) 상태로 유휴 (idle) 상태였습니다. 패턴은 항상 동일합니다: Claude는 자신이 결론에 도달했다고 생각하면, 하네스 (harness)가 연구 서브 에이전트 (research subagent)를 생성하라고 명시적으로 지시했음에도 불구하고, 방향을 묻고 기다립니다. Claude v2와 v3도 더 짧은 실행 시간 동안 동일한 현상을 보입니다. 다음은 v1에서 약 3시간 동안 중단되기 전 Claude가 남긴 마지막 메시지입니다:

T+43h 03-23m cf cooldown sweep (0.6, 0.65, 0.75) all fail; system reframes as "retune or accept v11c final"
T+43h 23-25m ❌ "SESSION FINAL"; loop ended; not re-arming wakeup
T+43h 26m ↩️ continues per user mandate; starts qkvp test
...

Codex는 유휴 시간(idle gap)이 거의 없습니다. 컴팩션(compaction)을 계속 수행하며, 작업 큐(job queue)를 유지하고, 자체적인 통계적 주장들을 감사(audit)합니다.

연산 효율성 (Compute efficiency)

모델이 우리의 유휴 연산 자원(idle compute)을 효율적으로 사용하도록 만드는 것은 놀라울 정도로 어려웠습니다. Claude는 유휴 노드(idle nodes)를 충분히 사용하지 않았고, Codex는 별다른 성과가 없는 스윕(sweeps)으로 컨텍스트(context)를 팽창시켰을 수 있습니다. 다음은 유휴 연산 자원(preempt 파티션)의 사용량과 에이전트들이 연산 자원을 사용하는 방식입니다.

연구 품질 (Research quality)

범위 (Breadth): 실제로 꽤 좋습니다. 전체 scratchpad/를 공개하므로 직접 판단하실 수 있습니다. 또한 novelty 트랙 동안 생성된 아이디어들도 공개합니다. 에이전트들이 그 아이디어 중 어느 것도 실제로 작동하게 만들지는 못했습니다.

Novelty-track 아이디어 브라우저

novelty-gated Codex 및 Claude Code 실행 중에 생성된 아이디어 노트들을 찾아보세요.

찾은 마크다운(markdown) 아이디어 노트가 없습니다.

안목 (Taste): 작지만 시사하는 바가 큰 실수들이 있었습니다. 새로운 옵티마이저(optimizer)를 테스트할 때, 모델이 학습률(learning rate)과 같은 베이스라인 하이퍼파라미터(baseline hyperparameters)를 먼저 재조정하지 않고, 곧바로 옵티마이저 특화 파라미터로 넘어가는 경우가 있습니다. 이로 인해 유망한 연구 방향이 조기에 중단되는 결과로 이어졌으며, 저희는 그 모든 방향이 중단될 만한 가치가 있었다고 확신하지 않습니다. v1에서의 Shampoo/SOAP가 한 가지 예입니다.

더 일반적으로, 에이전트들은 구성 요소(components)를 추가하는 경향이 있으며, 가지치기(pruning) 단계를 실행하거나 이전 방법들을 제거하려고 시도하는 경우는 드뭅니다. 그들은 구성 요소들이 어떻게 상호작용하는지에 대한 좋은 멘탈 모델(mental model)을 가지고 있지 않습니다. 또한 아래에 표시된 것처럼, Codex는 스케줄(schedule)이 완전히 내려오기도 전에 실행을 조기에 종료해 버립니다.

추가 통계 (Additional statistics)

서브에이전트(subagent)의 동작을 살펴보면, Codex는 더 많은 서브에이전트를 생성하며, 이들은 더 오래 실행되고 더 많은 토큰(tokens)을 소비합니다. v1은 서브에이전트 생성 수에서 이상치(outlier)인데, 이는 하네스(harness)에 codex-cli의 기본값인 6이라는 엄격한 제한이 있었기 때문이며, 이후 실행에서는 이를 50으로 상향했습니다.

Codex는 또한 스크래치패드(scratchpad)를 훨씬 더 집중적으로 사용하며, 이를 라이브 데이터베이스(live database)처럼 취급하여 THREAD.md를 빈번하게 읽고 씁니다.

, 목표(goal), 그리고 기타 스크래치패드(scratchpad) 파일들입니다. 이는 복구와 감사(audit)를 더 쉽게 만들지만, 로컬 탐색 루프(local-search loop)를 더욱 강화합니다. 즉, Codex가 프런티어(frontier)를 포착하면, 이를 계속해서 기록하고 확장해 나갑니다.

마지막으로, 우리의 토큰 사용량은 다음과 같습니다: 캐시된 토큰(cached tokens)을 포함하여 단 239억 개의 토큰만을 사용했습니다.

아이디어 → 실험 흐름 (Idea → experiment flow)

개별 아이디어를 살펴보기 전에, 에이전트들이 실제로 무엇을 볼 수 있는지 이해하는 것이 중요합니다. 이것이 성능 차이의 많은 부분을 설명하기 때문입니다. 두 에이전트 모두 업스트림 리포지토리(upstream repo)의 현재 PR(Pull Request), 과거 track-3 파일들이 담긴 records/ 폴더, 그리고 각자의 스크래치패드에 저장된 정보에 접근할 수 있습니다. 아래 그래프는 활성 에이전트 시간(active agent hours)으로 정규화된 소스 접근 도구 호출(source-access tool calls) 횟수를 나타냅니다.

Codex는 git을 거의 건드리지 않으며, 주로 로컬 벤치마크 이력과 자신의 실행 상태(run state)를 읽습니다. 반면 Claude는 정보 예산(information budget)의 더 많은 부분을 PR, 포크(forks), 그리고 구현 리포지토리(implementation repos)에 할당합니다.

이제 아이디어가 실제로 어떻게 실험으로 이어지는지 살펴보겠습니다. 우리는 모두 동일한 부분, 즉 Muon 업데이트 단계(Muon update step)를 변경하는 세 가지 Muon 변형(variants)을 추적합니다.

그래프는 아이디어당 세 가지 순간을 표시합니다: 가시적인 소스(visible source)에 처음 등장하는 시점, 실행 가능한 방향(actionable direction)이 되는 시점, 그리고 첫 번째 실행(first run) 시점입니다.

다음은 NorMuon과 MuonEq가 어떻게 작동하는지에 대한 시각적 자료입니다: