▲

$500 GPU가 코딩 벤치마크에서 Claude Sonnet을 능가

 (github.com/itigges22)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 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개 과제를 처리하며, 대형 모델의 코드 생성 능력을 개인 하드웨어로 재현 가능함

개요

  • A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) 은 소비자용 GPU 한 대로 대형 모델 수준의 코드 생성 성능을 구현하는 자체 호스팅 AI 시스템
  • LiveCodeBench v5 기준 74.6% pass@1-v(k=3) 달성, 이전 버전(V2)의 36~41% 대비 큰 향상
  • 14B 파라미터 모델(Qwen3-14B-Q4_K_M) 을 동결(frozen) 상태로 사용하며, 제약 기반 생성, 자체 검증 반복 수정(self-verified repair), 에너지 기반 후보 선택(Geometric Lens) 등으로 성능 확보
  • 클라우드나 API 호출 없이 로컬 환경에서 완전 자율 실행, 데이터 유출이나 사용량 제한 없음
  • 하드웨어 요구사항은 RTX 5060 Ti 16GB GPU, Python 3.10+, Linux (RHEL 9 / Ubuntu 24) 환경

벤치마크 결과

  • 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 에서 이식성 개선 예정

프로젝트 구조

benchmark/       벤치마크 스위트 (V2, V3 파이프라인)
benchmark/v3/    V3 하위 모듈 (PlanSearch, BudgetForcing, PR-CoT 등)
rag-api/         Geometric Lens, RAG, 캐시 등 핵심 API
llama-server/    수정된 llama.cpp 서버 (spec decode + self-embedding)
manifests/       K3s 배포 매니페스트
scripts/         설치 및 관리 스크립트
tests/           테스트 스위트
docs/            아키텍처, 설정, 문제 해결 문서
api-portal/      API 키 관리 포털 (JWT 인증, 웹 UI)
sandbox/         격리된 코드 실행 환경

문서 구성

문서 설명
ARCHITECTURE.md 시스템 구조 및 데이터 흐름
V3_ABLATION_STUDY.md V3 단계별 성능 분석
SETUP.md 설치 및 배포 가이드
CONFIGURATION.md 설정 옵션 및 V3 토글
TROUBLESHOOTING.md 문제 해결 가이드
API.md API 엔드포인트 문서
  • 과거 버전 문서(V2.5, 마이그레이션 등)도 포함

로드맵

  • 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 적용
  • 세부 내용은 LICENSE 참조
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 나는 에이전트에게 큰 코드 블록 생성을 기대하지 않음
    대신 로그를 훑거나 여러 소스 파일을 분석해 테스트 실패 원인을 설명하는 데 훨씬 유용함
    이런 능력을 평가하는 디버깅 벤치마크가 필요하다고 생각함. 빌드 시스템이나 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 비교 결과
    • 나는 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에서도 로컬로 모델을 돌릴 수 있다면 큰 진전임

답변달기