Memdoor team-solve: Qwen3.8-27B 에이전트 5개가 LiveCodeBench Hard에서 Fable 5와 동률
Memdoor의 team-solve 워크플로는 GVS5H 멀티 에이전트 방식을 Qwen3.8-27B에서 재현하며, LiveCodeBench Hard의 처음 10개 문제에 대해 5회 패스에서 평균 10점 만점에 9.8점을 기록했습니다. 이는 원저자 하네스의 9.6점, Fable 5 단독 응답의 8.0점과 비교됩니다. 이 결과가 중요한 이유는 규율 있는 멀티 에이전트 하네스로 감싼 작은 오픈 가중치 모델이 어려운 코딩 벤치마크에서 프런티어 모델과 동등한 성능에 도달할 수 있음을 보여주기 때문입니다. 비용은 약 0.39달러, 실행당 모델 시간 중앙값은 40분입니다.
이 워크플로는 memdoor 저장소의 공개 예제이며, Hacker News에서 385포인트와 188개의 댓글을 얻으며 발표되었습니다. 토론은 로컬 모델 동등성에 대한 열광과 10개 문제 표본에 대한 회의론으로 나뉘었습니다.
team-solve가 실제로 무엇인가
team-solve는 프로그래밍 문제를 위한 멀티 에이전트 하네스로, Memdoor 워크플로로 작성되었습니다. 플래너, 아이디어 제공자 2명, 솔버, 매니저의 5가지 역할과 수리 작업자가 각각 새 컨텍스트에서 시작하며 디스크의 파일을 통해서만 통신합니다. 실행 성공 여부는 모델이 아닌 셸 스크립트가 결정합니다.
이 방법은 GVS5H(Lee, 2026)에서 비롯되었으며, Qwen3.8-27B 모델 5개가 LiveCodeBench Hard에서 Fable 5와 동등한 성능을 보인다는 논문입니다. Memdoor의 기여는 저자의 정확한 프롬프트를 사용하여 자체 워크플로 엔진 내부에서 해당 루프를 재구현한 것입니다.
워크플로 파일은 2026-10-25에 방법 설명에서 코더 자체가 생성했으며, 누구도 직접 작성하지 않았습니다.
벤치마크 수치
Memdoor는 GVS5H의 하네스를 동일한 모델(Qwen3.8-27B, 128K 응답 상한, 저자의 프롬프트와 루프)로 Memdoor 워크플로로 재구축하고, LiveCodeBench Hard 목록의 처음 10개 문제를 5회 패스로 실행했습니다. 모든 프로그램은 저자의 수정된 채점기로 모든 공개 및 숨은 테스트에서 채점되었습니다.
| 패스 | Memdoor 워크플로 | 저자 27B 하네스 | Fable 5 단독 |
|---|---|---|---|
| 1 | 10 / 10 | 9 | 7 |
| 2 | 10 / 10 | 10 | 8 |
| 3 | 10 / 10 | 10 | 10 |
| 4 | 10 / 10 | 9 | 8 |
| 5 | 9 / 10 | 10 | 7 |
| 평균 | 9.8 | 9.6 | 8.0 |
저자 열은 저장소의 재채점 결과 파일(q38_multiagent_pN, fable5_single_pN)에서 가져온 것이며 논문의 수치와 일치합니다. 50개 실행 모두 bench/results/parity-5pass/에 게시되어 있으며, 모든 요청과 응답, 생성된 프로그램, 채점기의 전체 출력, 각 호출의 비용과 서빙 호스트, 그리고 집계되지 않은 모든 시도를 포함합니다.
50개 실행 중 49개가 문제를 해결했습니다. 집계된 50개 실행 비용은 35.79달러(1,530만 출력 토큰)였으며, 클록에 의해 중단되거나 수정을 위해 중지되거나 일시 중지된 16개의 시도를 포함한 총액은 38.77달러였습니다. 실행당 모델 시간 중앙값은 40분, 최장 4시간이었고 비용은 약 0.39달러였습니다.
원래 하네스와 동일한 점과 다른 점
Memdoor의 패리티 테스트 lib/test_parity.py는 스크립트된 모델 하나를 대상으로 저자의 multiagent_solve와 Memdoor 워크플로를 실행하고 각 요청을 비교합니다. 4개 사례는 바이트 단위로 동일했으며, 한 문자 변경으로 차이가 발생합니다.
일치하는 설정은 온도(플랜 0.3, 아이디어 0.4, 매니저 및 작업자 0.2), top_p 0.95, top_k 20(저자의 vLLM이 모델 자체 구성에서 적용한 값), 128K 응답 상한, 최대 10라운드, 중단된 작업자의 요약, 텍스트 없는 응답에 대한 추론 답변입니다.
주요 차이는 호스트입니다. 저자는 자체 vLLM을 FP8로 실행했습니다. Memdoor는 OpenRouter에서 실행했으며, Modal이 14 tokens/s로 느려질 때까지 Modal, CoreWeave, Parasail, Wafer 순서로 호스트를 요청한 후 FP8 호스트(Wafer, Parasail, CoreWeave)로 제한했습니다. 호출 중 203개는 Modal, 27개는 CoreWeave, 115개는 Wafer가 서빙했으며, FP8 전용 순서의 모든 호출은 Wafer로 갔습니다. 3개 실행은 완료된 단계를 보존한 채 중간에 이동되었으며, log/host-switch.txt에 기록되었습니다.
문제 텍스트가 어려운 부분이었습니다
Memdoor의 첫 번째 버전은 각 문제에 대해 자체 작업 파일을 작성했으며, 27B 모델은 저자의 정확한 LiveCodeBench 텍스트보다 해당 텍스트에서 계획을 더 나쁘게 세웠습니다. arc196_c 문제에서 다시 작성된 작업 텍스트로는 계획이 2회 중 0회 성공했지만, 원본 텍스트로는 2회 중 2회 성공했습니다.
워크플로가 저자의 하네스가 묻는 것과 정확히 동일하게 질문하도록 Memdoor에 네 가지 변경이 필요했습니다.
- 작업이 텍스트를 생성하지 않을 때 모델의 추론으로 응답합니다.
- 모델 라인에서
top_p와top_k를 설정할 수 있습니다. mark_cutoff는 상한에서 잘린 응답을 처리합니다.- 호출은 자체 4시간 클록으로 실행될 수 있습니다.
워크플로가 패배한 부분
두 실패 모두 모델이 아닌 저자의 루프에 있는 동일한 두 가지 공백에서 비롯되었습니다.
- 패스 5,
abc399_e(숨은 테스트 44개 중 32개): 1라운드의 프로그램이 정확했습니다. 매니저가 잘못된 예상 답변으로 반례를 만들어냈고, 팀이 프로그램을 다시 작성했으며, 새 버전은 해당 사례를 다루지 않는 공개 샘플을 통과했습니다. - 패스 4,
arc196_c및arc196_d: 모든 숨은 테스트를 통과한 프로그램이 매니저가 작업 완료를 선언하지 않아 이후 라운드에서 덮어쓰여졌습니다. 둘 다 루프가 끝나기 전에 올바른 프로그램을 복구했습니다.arc196_d는 8라운드,arc196_c는 최종 호출에서 복구했으며, 각각 3.44달러와 4.24달러로 가장 비싼 두 실행이었습니다.
Memdoor는 두 가지 모두 방법을 변경하지 않고 수정할 수 있다고 언급합니다. 매니저의 반례를 작은 입력에 대한 무차별 대입과 대조하고, 샘플을 통과한 마지막 프로그램을 유지하는 것입니다. 두 수정 모두 보고된 수치에는 포함되지 않았습니다.
워크플로 구조
단계 그래프는 Memdoor의 기반 엔진인 mario 형식을 사용하는 steps/의 YAML 파일 DAG입니다.
plan ──┬── ideate-a ──┬── solve ── test ── review ── repair ── verify
└── ideate-b ──┘
| 단계 | 종류 | 읽기 | 쓰기 |
|---|---|---|---|
plan |
에이전트 | task.md |
plan.md, 아이디어 제공자별 앵커가 있는 notes.md 원장 |
ideate-a, ideate-b |
에이전트, 병렬 | task.md, plan.md, notes.md |
자체 앵커에 제안: A는 가장 직접적인 증명 가능한 알고리즘, B는 다른 기법 계열 |
solve |
에이전트 | 두 제안 | notes.md의 결정, solution.py |
test |
명령 | tests/ |
test-output.log, test-status.txt(실행을 실패시키지 않음) |
review |
에이전트 | 모델의 주장이 아닌 캡처된 테스트 출력 | review.md, notes.md의 수리 지침 |
repair |
에이전트 | 매니저의 지침 | 수정된 solution.py, 또는 샘플 통과 시 아무것도 없음 |
verify |
명령 | tests/ |
final-test-output.log; 0이 아닌 종료는 실행 실패 |
모든 에이전트 프롬프트는 모델에게 새 컨텍스트에서 시작하고 파일을 읽고 채팅 기록에 의존하지 말라고 지시합니다. 논문은 그 원장 규율이 성과 향상의 원인이라고 설명합니다. 수리 라운드는 한 번이며 인간 게이트는 없습니다. 최종 verify 단계가 전체 판정입니다. check-samples.sh를 실행하고 final-test-output.log를 작성하며 샘플이 하나라도 실패하면 0이 아닌 종료 코드를 반환합니다.
실행 방법
curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter # 또는 anthropic, openai, gemini, chatgpt
# 또는 키 없이: memdoor connect local # 이 머신의 Ollama, llama.cpp, vLLM, LM Studio
git clone --depth 1 https://github.com/guregodevo/memdoor
mkdir -p ~/.memdoor/workflows
cp -r memdoor/examples/workflows/team-solve ~/.memdoor/workflows/ # 라이브러리: 모든 프로젝트가 볼 수 있음
mkdir my-problem && cd my-problem
cp -r ../memdoor/examples/workflows/team-solve/sample/* . # task.md + tests/1.in … 5.out
memdoor workflow run team-solve --wait # stderr에 진행 상황, 모든 샘플 통과 시 exit 0
memdoor tui의 /workflow는 동일한 실행을 실시간으로 그립니다. 사용자 정의 문제의 경우 task.md를 교체하고 짝을 이루는 tests/N.in 및 tests/N.out 파일을 추가하세요. 프로그램은 solution.py이며 stdin에서 읽고 diff로 샘플과 비교합니다. Python 3와 bash가 필요합니다. 워크플로를 단일 저장소에 유지하려면 폴더를 해당 프로젝트의 .memdoor/workflows/에 복사하세요. 프로젝트의 복사본이 우선합니다.
단계는 모델을 지정하지 않습니다. /model에 고정된 모델이 호출에 응답하며, memdoor connect local로 연결된 로컬 런타임도 포함됩니다.
첫 실행에서 발견한 것
번들 샘플은 알파벳 {a, b, c}에 대해 각 문자의 개수가 동일한 부분 문자열의 개수를 최대 200,000자 문자열에 대해 세는 것입니다. OpenRouter를 통한 기본 래더에서:
- 8/8 단계와 5/5 샘플이 통과했습니다. 솔버는 아이디어 제공자 A의 접두사 상태 방법을 선택했습니다. (a−b, a−c) 쌍의 사전을 사용한 O(N)입니다. 이후 300개의 무작위 문자열에 대한 무차별 대입에서 불일치가 발견되지 않았으며, 프로그램은 N = 200,000에서 0.04초에 실행됩니다. 매니저는 수리할 것을 찾지 못했습니다.
- 한 아이디어 제공자의 공급자가 응답 중간에 스트림을 끊었습니다. 코더가
max_retries: 0을 작성했기 때문에 실행이 거기서 중단되었습니다. 에이전트 단계는 이제max_retries: 1을 가지며, 실행은--partition으로 재개되어 플래너와 다른 아이디어 제공자의 작업을 보존했습니다. - 아이디어 제공자 프롬프트는 원래 샘플의 특정 방법(A: 스트리밍 접두사 상태 개수, B: 접두사 상태 정렬)을 명명했으며, 이는 다른 문제를 잘못된 방향으로 이끌 수 있습니다. 이제 A는 가장 직접적인 증명 가능한 알고리즘, B는 다른 기법 계열을 요청합니다(2026-10-28).
- 첫 번째 시도는 "coder라는 에이전트가 없음"으로 0초 만에 모든 단계에서 실패했습니다. 실행이 자체 작업 공간에서만 에이전트를 찾았기 때문입니다. 이는 같은 날 게이트웨이 v1.692.0에서 수정되었습니다.
저자가 명확히 밝힌 주의 사항
결과는 저자의 100개 문제가 아닌 10개 문제를 각각 5회 패스로 다룹니다. 콘테스트는 2025년 3월 29일부터 4월 6일까지이므로 모델이 훈련 중에 이를 보았을 수 있으며 오염을 배제할 수 없습니다. Fable 5 열은 저자의 결과 파일에서 가져온 문제당 단일 호출이며 이 하네스 내에서 실행되지 않았습니다. 루프는 공개 샘플만 보는 반면 점수는 숨은 테스트로 측정됩니다.
Hacker News 토론이 추가한 내용
표본 크기에 대한 회의론
가장 흔한 반대는 10개 문제로 강한 주장을 뒷받침할 수 없다는 것이었습니다. @zihotki는 다음과 같이 썼습니다.
이 벤치마크는 "LiveCodeBench Hard 목록의 처음 10개 문제"만 있으므로 결론을 내리기 전에 더 많은 벤치마크를 기다리겠습니다. 그리고 LiveCodeBench Hard는 몇 년 된 벤치마크입니다. 매우 포화 상태일 수 있습니다.
같은 문제에 몇 주를 보냈다고 보고한 @jbellis는 일반화 위험을 직접적으로 설명했습니다.
제 생각: 단일 평가를 개선하는 하네스를 만드는 것은 놀라울 정도로 쉽고, 일반화되는 하네스를 만드는 것은 놀라울 정도로 어렵습니다.
@0xbadcafebee는 계산 트레이드오프 주장을 했습니다. 결과는 많은 요청과 큰 토큰 예산을 가진 작은 모델이 한 번의 요청과 작은 토큰 예산을 가진 큰 모델을 이긴 것이며, 그 자체로는 놀라운 일이 아닙니다.
팀 구조가 효과적일 수 있는 이유
@topspin은 흥미로운 변수는 모델이 아니라 하네스라고 주장했습니다.
제 추측은 분업이 분리된 컨텍스트를 더 효과적으로 만든다는 것입니다. 이는 컨텍스트 한계에 대한 최적화입니다. 그중 일부는 단순히 가져오는 컨텍스트의 총량입니다. 각 팀원이 컨텍스트를 가지므로 총 컨텍스트 양이 팀원 수만큼 곱해집니다.
@yurimo는 메커니즘을 솔루션 베이신에 대한 검색으로 설명했습니다. 여러 모델과 다양한 의견이 단일 모델이 충분히 강하지 않을 때에도 시스템을 더 나은 답으로 밀어붙일 수 있습니다.
@CharlieDigital은 이 설계를 에모리 대학의 멀티 에이전트 진화 논문과 연결하며, 역할 분리가 노이즈가 많은 사고 토큰과 도구 호출을 다운스트림 에이전트의 컨텍스트에서 제외하여 각 후속 에이전트가 더 작고 집중된 입력을 받는다고 주장했습니다.
@robertkluin은 유사한 파일 기반 아키텍처를 프로덕션에서 실행 중이라고 보고했습니다. 플래너, 연구자, 구현자, 검토자로 구성되며 구현자가 도우미를 생성할 수 있고, 프런티어 모델을 사용하는 동료들이 출력 차이를 구분하지 못했다고 말했습니다.
@mchusma는 더 강한 모델이 생성한 계획과 코드를 더 저렴한 모델이 검토하는 혼합 모델 검토 루프를 설명하며, 더 작은 모델이 무언가를 놓치는 경우가 얼마나 자주 있는지 언급했습니다.
로컬 모델의 중요성
여러 댓글 작성자는 동등성이 소유 하드웨어에서 모델을 실행하는 데 무엇을 의미하는지에 집중했습니다. @roenxi는 Bonsai 2 양자화로 Qwen 27B가 합리적인 가격의 게이밍 머신에서 초당 약 50토큰으로 실행될 수 있다고 추정하며, Steam 하드웨어 설문 조사에서 16GB VRAM과 32GB 시스템 메모리 수치를 인용했습니다.
@novaRom은 완전히 로컬 모델로 전환했다고 보고하며, 27B 모델은 64GB RAM이 있는 모든 현대 PC나 노트북에서 서빙될 수 있고, 주요 단점은 256K 컨텍스트 한계로 인한 주기적인 압축이라고 언급했습니다.
@fedpost는 이 작업을 공급자 통제에 대한 헤지로 설명했습니다.
로컬 모델이 하이퍼스케일러와 경쟁력을 유지하는 것이 절실히 필요합니다. 그들과 그들의 변덕에 영원히 얽매이고 싶지 않습니다.
@cloudking은 벤치마크 중심의 열광에 반박하며, 로컬 모델로 실제 사용자가 있는 품질 높은 프로덕션 앱이나 게임을 만든 사람이 있는지 물었습니다.
글 자체에 대한 반대
@vessenes는 작업 일지 형식이 읽기 어렵다고 말하며 짧은 인간 작성 요약을 요청했습니다. @StilesCrisis는 텍스트가 모델 생성 산문처럼 읽힌다고 주장했습니다. 두 비판 모두 게시된 실행 아티팩트가 아닌 프레젠테이션을 대상으로 합니다.
당연한 후속 질문
여러 댓글 작성자는 자연스러운 대조군을 물었습니다. 작은 모델 5개가 큰 모델 1개를 이긴다면 큰 모델 5개는 무엇을 할까요? @conception은 "fable 모델 5개의 팀은 모든 벤치마크를 압도해야 한다"고 말했고, @amelius는 Fable 5가 이미 스웜이 아닌지 어떻게 아는지 물었습니다. 게시된 실험은 Fable 5가 문제당 단일 호출로만 실행되었기 때문에 두 질문에 모두 답하지 않습니다.
SUMMARY: Memdoor의 team-solve 워크플로는 파일 기반 핸드오프를 통해 Qwen3.8-27B 에이전트 5개와 수리 작업자를 실행하며, LiveCodeBench Hard의 처음 10개 문제에 대해 5회 패스에서 평균 9.8/10을 기록했습니다. 이는 원래 GVS5H 하네스의 9.6점, Fable 5 단독의 8.0점과 비교됩니다.
TITLE: Memdoor team-solve: Qwen3.8-27B 에이전트 5개가 LiveCodeBench Hard에서 Fable 5와 동률
Sources
관련
- Dispatch
- Dispatch
- 프로젝트
- Dispatch