GVS5H 하네스에서 Qwen3.8-27B 5개가 Fable 5 수준의 성능을 냈습니다

GVS5H는 같은 모델의 새 인스턴스들이 공유 파일의 계획과 메모를 바탕으로 협업하는 학습 없는 코딩 하네스입니다. LiveCodeBench 어려운 문제 100개에서 Qwen3.8-27B의 pass@1이 66.8%에서 92.4%로 올랐지만, 모델별로 개선 폭은 달랐고 비교 조건에도 차이가 있습니다.

주제: AI 개발 도구 벤치마크

에디터 노트

평가 결과만 보면 하네스가 작은 모델의 코딩 점수를 크게 끌어올립니다. 그러나 비교의 공정성은 초록만으로 확인하기 어렵습니다. 원문은 Opus 5가 이전 버전 하네스에서 OpenRouter를 거쳐 한 번 호출됐고, 다른 결과는 고정 백엔드에서 다섯 번 호출됐다고 별도로 밝힙니다. 따라서 Qwen과 Fable 5의 점수 차이는 같은 조건에서 모델만 비교한 결과로 읽을 수 없습니다. 댓글은 벤치마크가 오래됐고 실제 에이전트 작업과 다르며, 하네스를 적용한 다른 모델과 비교하지 않았다는 점을 문제 삼습니다. 반면 계획과 메모를 공유하는 방식 자체는 개발자의 작업 흐름과 닮았다는 경험담도 나옵니다. 이 결과가 뒷받침하는 범위는 특정 벤치마크에서 하네스가 일부 모델의 점수를 높였다는 데까지입니다. 실제 프로젝트의 생산성이나 모델 간 우열은 이 자료만으로 판단하기 어렵습니다.

AI 요약

같은 모델을 여러 번 호출해 코딩 문제를 나누고, 파일에 기록한 계획과 메모, 현재 해답을 공유하는 방식으로 추론 시점 성능을 높입니다. 별도 학습 없이 하네스가 모델의 작업 절차를 구성합니다.

방법과 측정

저자는 11개 오픈·클로즈드 가중치 모델을 LiveCodeBench의 어려운 문제 중 최신 100개로 평가했습니다. 결과는 고정된 백엔드에서 최대 25.6%포인트 상승했습니다. 다만 개선 폭은 모델마다 다르며, 일부 모델은 성능이 그대로이거나 낮아졌습니다.

초록에 따르면 Qwen3.8 Flash Next는 pass@1 93.0%를 기록해 Fable 5의 90.4%를 웃돌았고, 비용은 9% 수준이었습니다. 로컬에서 실행한 오픈 가중치 Qwen3.8-27B는 단일 호출 기준 66.8%에서 하네스 적용 후 92.4%로 올랐습니다. 저자는 성능 향상을 문제 분해와 지속적으로 보존하는 문맥에 연결합니다.

저장소는 Python 3.12와 uv, 사용할 모델 제공자의 API 키를 요구합니다. 안내된 명령은 LCB_RELEASE를 release_v6로 설정하고, multiagent 엔진으로 100개 문제를 병렬 실행합니다. single 엔진은 한 번 호출하는 기준선입니다. 결과 점수는 실행이 끝난 뒤 출력되며, 상세 결과와 작업 공간은 각각 runs/results.json과 runs/ws/에 저장됩니다. 코드는 MIT 라이선스이고 논문, 그림, 실행 데이터는 CC BY 4.0 라이선스입니다. 벤치마크 포크와 문제, LaTeX 템플릿에는 별도 라이선스가 적용됩니다.

Hacker News 반응

@sail0rm00n — 비용을 고려하면 인상적입니다. 로컬 실행은 하드웨어를 한 번 마련하면 이후에는 전기료만 들기 때문입니다.
- @jacquesm — 태양광 10kW 이상이면 도움이 될 수도 있겠네요 ;)
- @chr15m — 로컬 추론 장비를 돌리는 데는 1kW면 됩니다. 햇빛이 있을 때 사용한다면 5kW 설비도 과합니다.
- @jacquesm — 태양광 입사각, 계절, 일조 시간, 배터리 충전도 고려해야 합니다.
@esafak — 시간이 10배 더 드는 건가요?
- @verdverm — 그건 하드웨어 문제입니다. Cerebras는 초당 1,500토큰을 보고했습니다.
- @msikora — 입력 토큰은 0.99달러, 출력 토큰은 1.49달러입니다. 다섯 번 호출하면 비싸네요.
@vikramkr — 이 하네스는 2025년 초의 포화된 코딩 벤치마크에서 Qwen3.8-27B 다섯 개를 사용해 Fable 5와 비슷한 결과를 냈습니다. Astra, 6.1, Sol, Fable 5.1, Opus 5.5와 비교하지 않았고 실제 에이전트 작업을 반영한 벤치마크도 없습니다. 데이터 오염 가능성도 있습니다. 하네스가 흥미로운 접근일 수는 있지만 평가 방식으로는 유용한 정보를 얻기 어렵습니다.
- @hirako2000 — 하네스를 적용한 Qwen과 다른 LLM의 하네스 적용 결과는 왜 비교하지 않았나요?
- @binsquare — 이 하네스의 주장을 신뢰해서는 안 된다고 생각합니다.
@112233 — 흥미로운 결과는 Qwen Flash Next 쪽입니다. 27B 밀집 모델은 최신 DeepSeek Flash보다 활성 파라미터가 많습니다.
- @SwellJoe — 128GB 메모리로 추론하는 사람에게는 확실히 27B가 더 흥미롭습니다. Strix Halo에서는 27B가 매우 느립니다. Qwen 3.8 Flash는 128GB에서 4비트로 여유 있게 실행되고, 27B보다 빠릅니다. 32GB GPU 한두 장을 쓰는 개발자에게는 밀집 모델이 더 나은 선택이라고 봅니다.
@sams99 — 이 벤치마크는 한 번 실행하는 방식과 한 번 실행 후 수정하는 방식만 있습니다. 도구를 쓰지 않는 규칙을 무시하고 위임과 Python 실행을 더해 이겼습니다. 이런 방식은 벤치마크가 아닙니다.
@badsectoracula — PDF를 보면 검증기를 제외한 역할은 모두 같은 모델을 새 문맥으로 호출하고, 작업 파일과 계획, 메모, 현재 해답을 공유합니다. 작업자와 관리자의 왕복 호출이나 새 문맥이 실제로 필요한지 궁금합니다. 저는 Qwen 3.8 27B에 계획과 상태, 주의사항 파일을 주고 직접 작업하게 합니다.
- @verdverm — 저도 비슷한 절차를 쓰며, 한 줄 명령으로 실행하는 작업 흐름이 유용하다고 봅니다. 27~30B 모델은 꽤 좋아졌지만 환각과 잘못된 가정을 더 자주 합니다.
- @Vaushite — 작업을 구현하는 도구가 바로 하네스입니다. LLM은 텍스트만 완성하며, 하네스가 실제 동작이나 채팅 인터페이스로 연결합니다.
@hartator — 문제에 과적합한 것 아닌가요?
- @zrg — 모델 상당수가 평가 점수를 올리는 데만 집중하는 것 같습니다.
@forgingahead — 로컬 오프라인 하네스로 무엇을 쓰나요? 24GB VRAM에서 Qwen3.8-27B를 코딩에 쓰고 싶습니다.
- @badsectoracula — RX 7900 XTX 24GB에서 llama.cpp와 양자화 모델을 사용합니다. 131k 문맥을 설정하고 평균 초당 약 50토큰을 생성하며 문맥이 거의 차면 초당 약 35토큰으로 떨어집니다. 프롬프트 처리는 초당 약 700토큰입니다. 컨테이너 안에서 Pi를 실행해 모델이 실제 파일을 망가뜨리는 일을 막습니다.
@yipinwong — 모델이 똑똑해질수록 하네스에 덜 의존하게 됩니다. 벤치마크 점수를 위해 만든 하네스는 나쁘고 불안정하며 유지하기 어렵습니다.
@mabunday — Opus 5.5와 Fable 5.1을 써 보려고 Claude Code를 다시 실행했지만 하네스가 나빠진 것 같았습니다. 비동기 하위 에이전트를 제대로 실행하고 30초 넘게 걸리는 작업을 추적하는 데 여러 번 시도해야 했습니다.
- @bcherny — 팀의 Boris입니다. 백그라운드 하위 에이전트는 기본값이라 놀랍습니다. 최신 버전인지 확인하고 /bug를 실행해 번호를 알려주시면 문제를 조사하겠습니다.
- @fastball — 뭔가 잘못 설정한 것 같습니다. 제 세션에서는 하위 에이전트와 백그라운드 작업을 계속 사용합니다.
- @octoberfranklin — 모델 문제와 하네스 문제를 분리하려면 모든 모델에 같은 하네스를 써야 합니다. 저는 전경 하위 에이전트를 제거해 혼란을 없앴습니다.
@Olscore — 복잡한 작업에서는 공유 문서로 상태를 맞추는 방식이 자연스럽습니다. 저는 복잡한 프로젝트에서 에이전트 간 일관성을 맞추려 Pullboard를 만들고 있습니다.

원문: GitHub / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗