# A.T.L.A.S - $500 GPU가 코딩 벤치마크에서 Claude Sonnet을 능가 > Clean Markdown view of GeekNews topic #27922. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27922](https://news.hada.io/topic?id=27922) - GeekNews Markdown: [https://news.hada.io/topic/27922.md](https://news.hada.io/topic/27922.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-28T01:33:22+09:00 - Updated: 2026-03-28T01:33:22+09:00 - Original source: [github.com/itigges22](https://github.com/itigges22/ATLAS) - Points: 12 - Comments: 1 ## Summary 소비자용 **GPU 한 대로 대형 모델 수준의 코드 생성 성능**을 구현한 자체 호스팅 AI 시스템 **A. T. L. ## Topic Body - **A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization)** 은 **소비자용 GPU 한 대**로 대형 모델 수준의 코드 생성 성능을 구현하는 **자체 호스팅 AI 시스템** - **LiveCodeBench v5** 기준 **74.6% pass@1-v(k=3)** 을 기록해 **Claude 4.5 Sonnet(71.4%)** 을 앞섰으며, 이전 버전 대비 두 배 가까운 성능 향상 달성 - **14B 파라미터 모델(Qwen3-14B-Q4_K_M)** 을 동결한 채 **제약 기반 생성**, **자체 검증·수정 루프**, **Geometric Lens 후보 선택**으로 고성능 확보 - **클라우드나 API 호출 없이 로컬 환경에서 완전 자율 실행**되며, **비용은 전력비만 발생**해 API 기반 모델 대비 **비용 효율성**이 매우 높음 - **RTX 5060 Ti 16GB GPU** 환경에서 약 2시간 내 599개 과제를 처리하며, **대형 모델의 코드 생성 능력을 개인 하드웨어로 재현 가능**함 ### 벤치마크 결과 - **LiveCodeBench v5**: 74.6% pass@1-v(k=3), 599개 과제 수행 - **V3 파이프라인**: PlanSearch + self-verified PR-CoT repair - **GPQA Diamond**: 47.0%, 198개 과제 - **SciCode**: 14.7%, 341개 과제 - pass@k-v(k=3)는 단일 시도 결과가 아닌, **3개 후보 생성 후 Lens 선택 및 실패 시 반복 수정**을 포함한 방식 - ## V3 단계별 기여도 (Ablation Study) - A: 기본형 (V3 미적용) → 54.9% - B: Phase 1 (PlanSearch + BudgetForcing + DivSampling) → 67.3% (+12.4pp) - C: Phase 1+2 (Lens routing) → 67.3% (+0.0pp) - D: Phase 1+3 (self-verified refinement) → **74.6% (+7.3pp)** - Phase 3은 **모델이 자체 생성한 테스트 케이스**로 내부 검증 수행, 실제 정답은 사용하지 않음 - PR-CoT는 Phase 3에서 42개 중 36개(85.7%) 문제를 복구 ### 비용 및 성능 비교 | 시스템 | LCB pass@1 | 과제당 비용 | 비고 | |--------|-------------|-------------|------| | DeepSeek V3.2 Reasoning | 86.2% | ~$0.002 | API, 단일 시도 | | GPT-5 (high) | 84.6% | ~$0.043 | API, 단일 시도 | | **ATLAS V3** | **74.6%** | **~$0.004** | 로컬 전력만 사용, best-of-3 + repair | | Claude 4.5 Sonnet | 71.4% | ~$0.066 | API, 단일 시도 | | Claude 4 Sonnet | 65.5% | ~$0.066 | API, 단일 시도 | - ATLAS는 **전력비만 발생**, API 비용 없음 - **165W GPU** 기준 599개 과제 수행 시 약 1시간 55분 소요 - **지연(latency)** 은 길지만 **비용 효율성**이 매우 높음 ### 작동 원리 - ## 전체 파이프라인 - **Phase 1: Generate** - **PlanSearch**: 제약 추출 및 다양한 계획 생성 - **Budget Forcing**: 토큰 사용량 제어 - **Verify 단계** - **Geometric Lens (C(x))**: 5120차원 자체 임베딩 기반 에너지 스코어링 - **Sandbox**: 코드 실행 및 검증 - **Phase 3: Repair** - **Self-Test Generation**: 모델이 자체 입출력 쌍 생성 - **PR-CoT Repair**: 다중 관점 체인오브소트 기반 코드 수정 - **단일 llama-server 인스턴스**가 K3s 상에서 실행되며, **추측적 디코딩(speculative decoding)** 과 **자체 임베딩 생성**을 동시에 수행 - **Geometric Lens** 는 후보 중 최적 코드를 선택 (혼합 결과 과제에서 87.8% 정확도) - 실패한 과제는 Phase 3으로 이동하여 **자체 테스트 생성 및 반복 수정** 수행 ### 설치 및 실행 - GitHub 저장소 클론 후 설정 파일 복사 및 설치 스크립트 실행 - `benchmark/v3_runner.py` 로 V3 벤치마크 실행 - 세부 설치 절차는 **docs/SETUP.md** 참고 ### 하드웨어 및 재현 | 자원 | 최소 | 테스트 환경 | |------|------|-------------| | GPU VRAM | 16 GB | RTX 5060 Ti 16 GB | | 시스템 RAM | 14 GB | 16 GB | | Python | 3.10+ | 3.11 | | OS | RHEL 9 / Ubuntu 24 | RHEL 9 (Proxmox VM) | - **Proxmox VM + VFIO GPU 패스스루** 환경에서 재현됨 - 16GB 이상 VRAM의 다른 NVIDIA GPU에서도 가능하나, 드라이버 및 VRAM 설정 조정 필요 - 주요 조정 변수: - `--parallel` 슬롯 수 (기본 2, VRAM 부족 시 1로 감소) - KV 캐시 양자화(Q4_0) - 슬롯당 컨텍스트 길이(기본 20480 토큰) - CUDA 12.8 버전 테스트 완료 - **V3.1** 에서 이식성 개선 예정 ### 로드맵 - ## V3.0 (완료, 2026-03-05) - Qwen3-14B-Q4_K_M 기반, 74.6% LCB 성능 - PlanSearch + BudgetForcing + Geometric Lens + PR-CoT 파이프라인 완성 - ## 알려진 한계 1. **LCB 전용 최적화**: GPQA, SciCode 등 타 벤치마크 최적화 미흡 2. **Phase 2 (Lens routing)**: 데이터셋 부족으로 효과 미미 (+0.0pp) 3. **G(x) metric tensor 비활성화**: C(x) 미훈련으로 의미 있는 기하 구조 부재 4. **단일 스레드 처리**: 과제 병렬화 미지원 5. **SandboxAdapter stdio 버그**: 입력 구분 기능 비활성화 (V3.1에서 수정 예정) - ## V3.1 (진행 중) - **모델 교체**: Qwen3-14B → Qwen3.5-9B (DeltaNet 선형 어텐션, 3~4배 속도 향상) - **Lens 재학습**: 실시간 피드백 기반 C(x) 재보정 - **Phase 2 재설계**: G(x) 재구현 또는 제거, SandboxAdapter 버그 수정 - **병렬 처리 도입**: 과제 병렬 실행으로 처리 속도 향상 - **확장된 벤치마크 스위트**: 코딩 외 추론·지식 평가 포함 - ## 예정된 V3.1 벤치마크 - **코딩**: LiveCodeBench v5, SciCode, 추가 오염 저항형 데이터셋 - **추론/지식**: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt 등 - **Confidence Router** 가 과제 난이도에 따라 경로 선택: - 단순 질의 → RAG 기반 빠른 추론 (~30초) - 복잡한 코딩 문제 → 전체 파이프라인 (~20분) - 목표: **80~90% LCB pass@1-v(k=3)** 및 **더 빠른 처리 속도** ### 라이선스 - **A.T.L.A.S Source Available License v1.0** 적용 ## Comments ### Comment 54004 - Author: neo - Created: 2026-03-28T01:33:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47533297) - 나는 에이전트에게 **큰 코드 블록 생성**을 기대하지 않음 대신 로그를 훑거나 여러 소스 파일을 분석해 테스트 실패 원인을 설명하는 데 훨씬 유용함 이런 능력을 평가하는 **디버깅 벤치마크**가 필요하다고 생각함. 빌드 시스템이나 CLI 숙련도를 측정하는 테스트가 있으면 좋겠음 - 나도 동의함. 코드베이스 전체에 일관된 **소규모 변경**을 적용할 때 특히 유용함 예를 들어 앱 전체를 hard delete에서 soft delete로 리팩터링했는데, 삭제 로직과 쿼리 모두 수정해야 했음 수동으로 하면 지루하고 실수하기 쉬운데, 에이전트가 빠르게 처리해줘서 정말 고마웠음 - 이런 장기적 작업에는 **SWE Bench Pro**나 **Terminal Bench 2**가 적합함 SWE Bench Pro는 아직 과도하게 최적화되지 않아 신뢰할 만함 반면 일반 SWE나 LCB는 이미 수치 부풀리기 경쟁으로 실효성이 떨어짐 - 빌드 시스템 관련 테스트는 **CompileBench**(Quesma의 벤치마크)에서 다룸 참고로 나는 Quesma의 창립자임 - 나는 하루 종일 **대규모 코드 생성**만 함 이제는 회사든 사이드 프로젝트든 직접 코드를 거의 쓰지 않음 주로 Rust와 TypeScript로 개발자 도구를 만드는 일을 함 - 나도 환경 구성을 에이전트에게 맡김 **kubectl / helm**으로 배포하고 문제 발생 시 에이전트가 직접 디버깅함 몇 시간 걸리던 일이 순식간에 끝나서 놀라울 정도임 - 개발자들에게 **MiniMax**, **Kimi** 같은 모델을 실제 업무에 써보라고 권하고 싶음 하지만 단점도 빠르게 드러남 — **추론 토큰 사용량 증가**, 느린 출력, 품질 저하 등 그래도 모델 라우팅과 **reasoning budget**을 잘 관리하면 비용을 크게 절약할 수 있음 앱과 프롬프트를 최적화해 출력 토큰을 줄이는 것도 중요함 - 나도 Kimi로 괜찮은 결과를 얻고 있음 하지만 어려운 작업에서는 단순한 **토큰 단가**보다 효율이 더 중요함 링크에 나온 접근법은 Sonnet과 Opus에도 효과가 있음 다만 MiniMax나 Qwen은 아직 그 수준에 미치지 못함 결국 어떤 작업에 어떤 모델이 비용 효율적인지 구분하는 **하네스 설계**가 핵심임 - 나는 SOTA 이하 모델은 쓰지 않음 Opus 4.6 medium을 써봤다가 바로 후회했음. 품질 차이가 너무 큼 - 이 링크에서 보듯, MiniMax는 **비코딩 작업**에서는 성능이 낮음 [aibenchy 비교 결과](https://aibenchy.com/compare/minimax-minimax-m2-7-medium/moo...) - 나는 MiniMax를 매일 코딩용으로 사용함 토큰 사용량은 신경 안 씀, 월 10유로 요금제에서 5시간마다 1500회 요청 가능함 실제로는 Opus나 Sonnet보다 느리지 않음 벤치마크에서는 Anthropic 모델이 더 좋아 보이지만, **현실 작업**에서는 차이가 거의 없음 MiniMax가 막히면 Opus로 전환하고, 다시 MiniMax로 돌아오면 됨 Opus는 예산을 빨리 소모하지만 MiniMax는 사실상 무제한임 - Kimi는 최근 내 **디버깅용 주력 모델**임 Claude나 GPT보다 문제를 더 빨리 찾아냄 하지만 **문맥 일관성 문제**가 심각함 — 코드 재작성 시 작은 오차가 생겨 전체를 망칠 수 있음 - 지금은 **가격 경쟁의 끝없는 레이스**임 DeepSeek이 단일 실행 기준으로 모든 모델을 이기고, 비용도 로컬 전력의 절반 수준임 > DeepSeek V3.2 Reasoning 86.2% ~$0.002 API, single-shot > ATLAS V3 (pass@1-v(k=3)) 74.6% ~$0.004 Local electricity only, best-of-3 + repair pipeline - 나는 로컬에서 돌릴 수 있다면 **전기요금 0.004달러**쯤은 감수하겠음 - 하지만 여전히 **1989년 톈안먼 사건** 같은 질문에는 답하지 않음… - 여러 오픈모델을 테스트했지만, DeepSeek 3.2만이 진짜 SOTA 수준임 - DeepSeek에도 이 접근법을 적용할 수 있음 여러 해답을 생성하고, 작은 모델로 유망한 후보를 선택해 테스트 후 피드백을 반복하는 방식임 일종의 **유전 알고리즘**처럼 점진적으로 수렴함 - “전기요금보다 싸다”는 게 무슨 뜻인지 설명해줄 수 있음? - 작은 모델들은 테스트에 맞춰 **과도하게 미세조정**되어 실제 환경에서는 성능이 형편없음 - 나는 항상 회의적임 벤치마크는 통과하지만 실제로는 **범용성**이 떨어지는 경우가 많음 그래도 모델을 **슬림화**하려는 시도 자체는 흥미로움 - 언어와 분야에 따라 차이가 큼 시스템 프로그래밍(C++, Rust)에서는 여전히 Sonnet 4.5 수준과 큰 격차가 있음 오픈모델들은 구문 오류 해결에 너무 많은 시간을 쓰고, **논리적 일관성**을 잃는 경우가 많음 로컬 GPU를 충분히 갖고 있지만, 클라우드 모델의 **라이선스 문제**도 걱정됨 - ATLAS의 접근법은 꽤 영리함 여러 솔루션을 생성하고, 각 코드의 **임베딩 지문(fingerprint)** 을 계산해 정확도를 예측함 작은 신경망인 **Cost Field**가 이를 점수화해 가장 가능성 높은 코드를 선택함 덕분에 테스트 시간을 줄이면서도 88% 정확도로 올바른 해답을 고름 - 모델을 줄이면 각 뉴런이 여러 역할을 맡게 되어 **일반화 능력**이 떨어짐 오히려 큰 모델이 구조적으로 단순할 수 있음 - 읽는 사이에 GPU 가격이 **$1000**이 되어버렸음 - 이 AI가 작성한 프로젝트는 **LiveCodeBench**와 완전히 다른 방식으로 자체 벤치마크를 돌림 README에는 ATLAS 점수가 599개 LCB 작업을 기반으로 한 **V3 파이프라인(best-of-3 + Lens + iterative repair)** 결과라고 명시되어 있음 반면 경쟁 모델 점수는 단일 실행(pass@1) 기준이라 **비교가 불공정함** Sonnet이나 GPT5.4도 같은 방식으로 테스트하면 더 높은 점수를 낼 수 있음 README에는 실제로 사용되지 않는 구조들이 많아 **AI 자동 생성 코드의 허술함**이 드러남 - 이런 벤치마크가 **문제 전용 최적화**에만 효과적인지 궁금함 결국 우리는 **일반성을 압축할 수 없는 한계**를 배우게 될 것임 - “**Geometric Lens routing**”이란 표현이 너무 이상함 그냥 GPT가 만들어낸 용어처럼 들림 - 회의적이긴 하지만 이런 **오픈모델 실험**은 정말 반가움 중상급 PC에서도 로컬로 모델을 돌릴 수 있다면 큰 진전임