Which Local LLM Performs Autoresearch the Best? (Ornith, Qwen, Nemotron, Muse Glimmer)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

동일한 DGX Spark의 AutoResearch 대결에서는 실험 수가 가장 많지 않았던 Qwen이 배치 크기 확대와 학습률 워밍업이라는 효과적인 가설로 최저 validation BPB를 기록해 우승했다.

📌 핵심 요점

1. 네 로컬 LLM은 사람의 추가 개입 없이 가설 수립, train.py 수정, 제한된 학습, 결과 평가, 변경 유지 또는 폐기를 반복하며 validation BPB를 낮추는 과제를 수행했다.
2. Qwen은 21개 실험만 수행했지만 배치 크기를 32에서 64로 늘리고 초기 5% 동안 학습률을 서서히 높여 최종 BPB 1.142를 기록했다.
3. Nemotron은 43개의 유효 실험으로 가장 높은 처리량을 보였고 배치 크기 확대를 통해 BPB 1.143까지 개선했지만 Qwen에 0.001 차이로 뒤졌다.
4. Ornith는 Muon 옵티마이저의 행렬 학습률과 weight decay를 낮춰 두 개의 개선안을 확보했으나, 컨텍스트 압축 이후 상태 복구에 시간을 소비해 33개 실험에 그쳤다.
5. Muse Glimmer는 다음 명령을 실행하지 않는 지시 준수 문제로 자율 루프가 반복해서 중단됐으며, 폴링 방식으로 복구한 뒤에도 가장 높은 최종 BPB를 기록했다.

🧩 배경과 문제 정의

• 시각적 결과물은 품질 비교가 쉽지만, 자율 연구처럼 터미널 내부에서 진행되는 작업은 모델의 추론·실행·복구 능력을 더 직접적으로 시험한다.
• 핵심 문제는 로컬 LLM이 사람의 추가 개입 없이 학습 설정을 수정하고, 결과를 평가하며, 더 나은 학습 레시피를 찾아낼 수 있는가이다.
• 동일한 DGX Spark와 실험 조건에서 Ornith, Nemotron, Muse Glimmer, Qwen을 경쟁시켜 자율성, 실험 처리량, 최종 검증 성능을 함께 비교한다.

🕒 시간순 섹션별 상세정리

1. 시각적 평가에서 자율 연구 평가로의 전환

• 웹사이트나 게임은 결과를 눈으로 비교하기 쉽지만, 이번에는 시각적 산출물 대신 Karpathy의 전통적인 AutoResearch 환경에서 로컬 모델의 연구 능력을 시험한다. [00:36]
• 네 로컬 모델에 동일한 과제를 부여해 직접 미니 모델의 학습 설정을 개선하게 하고, 어떤 모델이 가장 좋은 결과를 내는지 비교한다. [01:18]

2. AutoResearch의 자율 학습 개선 구조

• 네 모델은 자율 연구 컨트롤러로 동작하며, 초기 프롬프트와 환경 설정 이후에는 사람의 추가 입력 없이 학습 레시피를 개선해야 한다. [02:14]
• 목표 지표인 validation BPB는 다음 토큰에 대한 모델의 불확실성을 나타내므로 낮을수록 더 좋은 학습 결과에 해당한다. [03:07]

3. 단일 DGX Spark에서 적용되는 고정 계약

• 각 컨트롤러는 단일 DGX Spark에서 train.py 하나만 수정할 수 있고, 제한된 실행 시간 안에 validation BPB를 최대한 낮춰야 한다. [04:04]
• 대형 모델은 미니 모델 학습에 필요한 추가 메모리까지 확보하기 어려워 제외됐으며, 실행 가능한 크기와 연구 역량을 기준으로 네 모델을 선정했다. [04:43]

4. 네 로컬 모델의 특성과 비교 기준

• Ornith 1.5 35B A3B는 코딩과 자율 연구에 특화된 소규모 연구소 모델이며, 사전 사용 경험이 없어 가장 큰 변수가 된다. [05:00]
• Muse Glimmer는 복구·멀티모달 능력, Nemotron 3.5 Lightning은 희소 활성화 기반 효율성, Qwen 3.8 27B는 이미 검증된 로컬 실행 성능을 강점으로 가진다. [05:20]

5. 데이터셋과 반복 실험 방식

• 학습에는 Karpathy가 사용한 ClimbMix 400B 셔플 데이터셋의 일부를 적용하며, 중국어 아동 이야기보다 일반 언어 분포를 더 폭넓게 반영한다. [06:27]
• 각 모델은 가설 수립, train.py 수정, 제한된 학습, 결과 평가, 변경 유지 또는 폐기의 순환을 반복한다. [07:13]

6. Ornith 실행 환경과 준비 상태 검사

• Hermes Agent의 오케스트레이터가 모델별로 격리된 환경과 프로필을 준비하고, 첫 번째 컨트롤러인 Ornith를 실행한다. [08:14]
• Ornith는 캠페인 계약, 수정 범위, 연구 루프가 담긴 마크다운 지침을 읽은 뒤 하드 준비 상태 게이트를 먼저 검증한다. [08:53]

7. Ornith의 초기 가설과 연속 실패

• 첫 실험은 워밍업 설정을 바꿨지만 BPB가 기준선 1.19에서 1.20으로 악화돼 폐기됐고, 다음 후보로 모델 크기와 학습률 스케줄을 검토한다. [10:24]
• 두 번째 실험은 레이어를 6개에서 8개로 늘려 용량을 키웠지만 성능이 다시 악화돼 기준선으로 복구한다. [11:20]

8. Ornith의 개선 결과와 실행 병목

• 6시간 동안 두 개의 변경을 유지했으며, Muon 옵티마이저의 행렬 학습률과 weight decay를 낮춰 가중치 업데이트를 더 작고 부드럽게 만든 결과 기준선을 개선했다. [12:28]
• 작은 학습 스텝과 약한 weight decay는 이미 학습한 정보를 덜 지우면서 과도한 가중치 변화를 억제해 성능 향상으로 이어졌다. [13:54]

9. Nemotron의 자동 설치와 야간 실행

• Nemotron 3.5 Lightning 30B A3B는 Ornith와 동일한 격리 환경을 사용하되 모델 가중치를 새로 내려받아 야간 6시간 캠페인으로 실행한다. [15:04]
• Grok 오케스트레이터가 가중치 다운로드, 환경 설정, Hermes 프로필 실행, 캠페인 시작과 종료까지 맡아 별도 사람 개입 없이 전체 절차를 완료한다. [16:14]

10. Nemotron의 높은 처리량과 배치 크기 개선

• Nemotron은 43개의 유효 실험을 처리해 Ornith보다 높은 처리량을 기록했고, weight decay와 Muon 관련 학습률을 단계적으로 낮춰 여러 개선안을 유지했다. [16:35]
• 가장 큰 성능 향상은 배치 크기를 32에서 64로 늘렸을 때 발생했으며, 동일한 약 6만5천 토큰을 두 번에 나눠 처리하지 않고 한 번에 처리해 업데이트 오버헤드를 줄였다. [17:53]

11. Muse Glimmer의 대형 컨텍스트 실행 조건

• Muse Glimmer는 기존에 내려받은 가중치 중 성능이 가장 좋은 버전을 사용하고, 다른 모델과 동일한 캠페인 프롬프트로 실행한다. [19:44]
• 13만1천 토큰 컨텍스트와 BF16 가중치 때문에 앞선 두 모델보다 저장 공간을 더 차지하고 실행 속도도 느릴 가능성이 크다. [20:22]

12. Muse의 자율 루프 중단과 폴링 방식 복구

• Muse는 실험 결과를 받은 뒤 다음 실험을 실행하겠다고 응답하면서도 실제 명령을 내리지 않아, 유휴 상태가 반복되고 제한 시간이 낭비된다. [21:29]
• Grok이 결과 수신 직후 유지 또는 초기화하고 다음 가설을 즉시 실행하라는 프롬프트를 반복했지만, Muse의 지시 준수 문제는 계속된다. [21:54]

13. Muse의 제한적인 개선과 최하위 결과

• Muse는 후반부에 두 개의 개선안을 찾았지만 잦은 중단으로 실험 수가 줄었고, 세 모델 중 가장 높은 최종 BPB를 기록해 최하위에 머문다. [23:34]
• 첫 개선은 출력층의 unembedding 학습률을 0.005로 높여 다음 토큰 예측을 약 25% 큰 스텝으로 조정한 것이며, 기준선을 근소하게 넘어섰다. [24:16]

14. Qwen 실행 설정과 중간 성과

• Qwen은 DFlash 2, NVFP4 체크포인트, dense BF16 LM head, 262K 컨텍스트를 지원하는 고성능 최적화 버전으로 실행한다. [25:31]
• 사고 모드를 유지한 탓에 가설 검토와 자기 수정에 시간이 많이 들었고, 약 3시간 동안 10개 실험을 처리하는 데 그쳤다. [26:30]

15. Qwen의 근소한 우승과 결정적 변경

• Qwen은 6시간 동안 총 21개 실험을 완료해 처리량은 Nemotron보다 낮았지만, 최종 비교가 가능한 연구 결과를 확보했다. [28:18]
• 최종 BPB는 Nemotron의 1.143보다 근소하게 낮은 1.142였으며, Qwen이 네 모델 가운데 가장 좋은 점수로 우승했다. [28:54]

16. 실험 횟수보다 중요했던 가설의 품질

• Nemotron Lightning은 총 43회의 실험을 수행해 21회에 그친 Qwen보다 두 배 이상 빠르게 탐색했으며, 모델별 추론 속도 차이가 실험량을 크게 좌우했다. [30:25]
• Qwen은 사고 기능 때문에 실험 횟수가 가장 적었지만 유효한 가설을 찾아 최고 점수를 기록했고, 탐색량보다 가설의 성공률이 최종 성능을 결정했다. [30:48]

17. 모델별 한계와 용도에 따른 선택

• Ornith는 스트리밍과 실험 속도는 준수했지만 다른 모델보다 추론 능력이 부족해 중간 수준에 머물렀고, 추가 설정을 바꾼 재시험 가능성은 남았다. [31:05]
• Muse Glimmer는 명령을 제대로 따르지 않고 실험을 반복해서 중단했으며, Qwen보다 많은 실험을 수행하고도 좋은 가설을 만들지 못했다. [31:28]

🧾 결론

• 최종 승자는 Qwen이며, 실험 처리량보다 성공 가능성이 높은 가설을 선택하는 능력이 성능을 결정했다.
• Nemotron은 최종 점수에서는 근소하게 뒤졌지만 제한 시간 안에 많은 실험을 탐색해야 하는 작업에 적합한 선택지다.
• 자율 연구 모델의 실용성은 추론 성능뿐 아니라 명령 실행, 실패 후 복구, 상태 유지, 다음 실험으로의 즉시 전환 능력에 좌우된다.
• 이번 실험에서 공통적으로 효과가 확인된 핵심 조정은 배치 크기 확대였으며, Qwen의 추가 워밍업이 최종 격차를 만들었다.

📈 투자·시사 포인트

• 로컬 AI 에이전트의 가치는 모델 크기나 단순 추론 속도보다 유효한 가설의 성공률과 무중단 실행 능력으로 평가할 필요가 있다.
• Qwen은 성과 중심의 로컬 머신러닝 연구에, Nemotron은 높은 실험 처리량이 필요한 자동 탐색에 각각 경쟁력을 보였다.
• Muse의 유휴 상태 사례는 지시 준수와 도구 호출 신뢰성이 낮으면 긴 컨텍스트와 멀티모달 역량도 실제 연산 자원 활용으로 이어지지 않을 수 있음을 보여준다.
• 자율 연구 시스템에서는 모델 선택뿐 아니라 격리 환경, 준비 상태 게이트, 폴링, 상태 복구를 담당하는 오케스트레이션 계층도 핵심 인프라가 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• Qwen의 1.142와 Nemotron의 1.143 차이는 매우 작으며, 제공된 내용에는 반복 캠페인의 분산이나 오차 범위가 제시되지 않아 우위의 재현성을 확정하기 어렵다.
• 모델마다 컨텍스트 길이, 가중치 정밀도, 체크포인트와 최적화 구성이 달랐으므로 최종 차이를 순수한 모델 연구 역량만으로 귀속하기 어렵다.
• 단일 DGX Spark와 6시간 캠페인에서 얻은 결과가 다른 하드웨어, 데이터셋, 학습 시간과 모델 규모에서도 유지되는지는 확인되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Qwen과 Nemotron을 동일한 정밀도, 컨텍스트 길이, 체크포인트 조건으로 여러 차례 재실행해 BPB 차이의 재현성을 확인한다.
• 최종 BPB와 함께 유효 실험 수, 실험당 소요 시간, 실패율, 유휴 시간, 복구 시간을 공통 지표로 기록한다.
• 배치 크기 64와 초기 5% 학습률 워밍업을 각각 분리 적용해 Qwen의 최종 개선에 대한 개별 기여도를 검증한다.
• 명령 미실행 상태를 자동 감지하고 다음 가설을 즉시 요청하는 폴링 및 타임아웃 복구 장치를 기본 오케스트레이션에 포함한다.

❓ 열린 질문

• Qwen의 가설 성공률은 반복 캠페인에서도 유지되는가, 아니면 이번 실행에서 유리한 가설을 조기에 발견한 결과인가?
• Nemotron에 Qwen과 동일한 워밍업을 적용하면 1.142보다 낮은 validation BPB를 달성할 수 있는가?
• Ornith의 상태 복구 병목과 Muse의 지시 준수 문제를 제거하면 모델별 최종 순위와 실험 처리량은 어떻게 달라지는가?