source https://news.ycombinator.com/item?id=47533297

A.T.L.A.S

• 동결된 14B 모델을 소비자용 GPU 1장으로 돌려 LiveCodeBench 74.6%를 기록한 프로젝트

• 성능을 끌어올린 핵심은 모델 자체보다, 생성 → 검증 → 수정으로 이어지는 하네스 구조

• 파인튜닝 없이, API 없이, 클라우드 없이 로컬에서만 동작

• 데이터가 외부로 나가지 않는 완전한 self-hosted 방식

• 목표는 작은 로컬 모델도 잘 설계된 파이프라인으로 상위권 API 모델에 가깝게 만드는 것

벤치마크 결과

하드웨어: RTX 5060 Ti 16GB | 모델: Qwen3-14B-Q4_K_M (frozen)

비용 및 성능 맥락

방법론 메모 및 출처

동작 방식

• llama-server 하나가 생성과 임베딩 계산을 같이 담당함

• 여러 후보 답안을 만든 뒤, Geometric Lens가 가장 유망한 후보를 먼저 고름

• 고른 답안이 실패하면, 모델이 직접 테스트 케이스를 만들고 다시 수정함

• 이런 식으로 생성 → 선택 → 수정 단계를 반복해 정답률을 높임

• 실제 테스트는 마지막 평가 단계에서만 사용됨

빠른 시작

시작하기 전에: ATLAS는 특정 하드웨어를 기준으로 개발 및 테스트되었습니다. 실행 전에 아래 Hardware & Reproduction 섹션을 읽고, 현재 환경에서 호환되는지 확인한 뒤 설정값을 조정하세요.

git clone https://github.com/itigges22/ATLAS.git && cd ATLAS

cp atlas.conf.example atlas.conf    # MODEL_PATH, DATA_DIR, GPU device 설정
sudo ./scripts/install.sh
./scripts/verify-install.sh

# V3 benchmark 실행
python3 benchmark/v3_runner.py

전체 설치 방법은 SETUP.md 에 정리되어 있습니다.

하드웨어 및 재현

프로젝트 구조

benchmark/       벤치마크 스위트 (V2 runner, V3 pipeline, datasets)
benchmark/v3/    V3 하위 시스템 (16개 모듈: PlanSearch, BudgetForcing, PR-CoT 등)
rag-api/         핵심 API: Geometric Lens, confidence router, RAG, cache
llama-server/    패치된 llama.cpp server (spec decode + self-embeddings)
manifests/       K3s 배포 매니페스트
scripts/         설치 및 운영 스크립트
tests/           테스트 스위트 (infrastructure, integration, V3)
docs/            아키텍처, 설치, 설정, 트러블슈팅 문서
api-portal/      API key 관리 포털 (JWT auth, web UI)
sandbox/         격리된 코드 실행 환경

반응들:

• 벤치마크 수치 자체보다, 실제로 디버깅을 얼마나 잘하느냐가 더 중요하다는 의견이 많음

  • 특히 로그를 훑고, 테스트 실패 원인을 좁히고, 빌드 시스템이나 CLI 맥락까지 이해하는 벤치마크가 필요함

• 전반적으로는 모델 자체보다 하네스가 성능을 끌어올린 핵심이라는 평가

• 여러 해답을 만들고, 그중 유망한 후보를 고르고, 테스트로 검증한 뒤, 실패하면 다시 고치는 구조 자체는 꽤 영리함

  • 다만 이런 구조는 느리다는 점이 가장 큰 약점

• 태스크당 20분 정도 걸리는 수준이면 인터랙티브 작업에는 쓰기 어려움

  • 대신 비동기 작업이나 배치성 워크로드에는 충분히 의미 있을 수 있음

• 로컬 실행의 장점으로는 데이터가 밖으로 나가지 않는다는 점, API 정책이나 계정 제한에 덜 휘둘린다는 점이 자주 언급됨

  • 반대로 비용 면에서는 API가 더 유리할 수 있음

    • 전기료만 계산해도 DeepSeek 같은 API보다 비쌈

• 데이터센터는 높은 배치 효율을 활용할 수 있어서, 개인이 로컬에서 한 건씩 처리하는 것보다 더 효율적일 수 있음

• 모델 선택에서는 여전히 최고 난도 작업은 SOTA 모델이 낫다는 분위기가 강함

  • 그렇더라도 MiniMax, Kimi, Qwen 3.5, GLM 5 같은 모델들은 가성비 좋은 대안임

• 성능은 작업 도메인에 따라 편차가 큼

  • 특히 시스템 프로그래밍이나 Rust, C++ 같은 영역에서는 아직 한계가 큼

• 복잡한 문제로 갈수록 결국 사람이 검수하고 다시 잡아줘야해서 시간이 크게 줄지 않음

• cost field가 실제로 무엇을 구분하는지, 그리고 그 설계가 정말 코드 품질 판별에 유효한지 불명확함

  • 그럼에도 로컬 소형 모델을 더 실용적으로 만들려는 방향 자체는 긍정적임

• 전체적으로는 재미있는 실험이고 배울 점은 많지만, 아직 범용 실무 대안이라고 보긴 이름.