회사 테크

4회차도 이겼다 — 원본 Qwen3.8 pass@4 60/89 (67.4%), 4번 시도 만에 뒤집힌 2개의 이야기

원본 mixed-4-8bit Qwen3.8 Flash Next의 Terminal-Bench 2.1 4회차(pass@4) 결과. 31개 재시도에서 2개 복구, 반복 루프·조기 제출·아슬아슬한 실패까지 남은 29개의 실패 패턴 해부

삽질하는개발자

노트와 노트북이 놓인 상담 책상

요약

1편에서 단일 45 → 2회 53, 2편에서 pass@3 58/89로 Uncensored(ARC4NUM, abliterated)의 best-of-3 56을 넘었습니다. 남은 31개를 완전히 같은 조건으로 네 번째 돌린 4회차가 끝났습니다.

결론은 **pass@4 = 60/89(67.4%)**입니다. 2개 복구, 29개는 네 번 모두 실패했습니다.

시도 원본 ddalcu Uncensored ARC4NUM
1회 (pass@1) 45 / 89 (50.6%) 41 / 89 (46.1%)
2회 누적 53 / 89 (59.6%)
3회 누적 58 / 89 (65.2%) 56 / 89 (62.9%, best-of-3)
4회 누적 (pass@4) 60 / 89 (67.4%)

증분은 8 → 5 → 2로 급격히 줄고 있습니다. 예상대로 곡선은 포화 중이고, 이제 남은 29개는 “운이 나빠서” 실패한 게 아니라는 뜻입니다.

4회차에서 무슨 일이

31개를 돌려 2개 복구, 9개 FAIL, 20개 TO였습니다. 12시간 59분, 태스크당 평균 23.3분입니다. 복구된 2개는 둘 다 Uncensored가 3회 전패한 태스크라 원본 전용 통과는 8개에서 10개로 늘었습니다.

extract-elf (2.6분, 11턴) — 세 번 실패한 이유가 재밌습니다. 태스크는 ELF 바이너리에서 메모리 값을 뽑는 Node.js 파서를 쓰라는 건데, 3회차의 모델은 문제에 딸린 예시 값(0x6a617e69 같은)이 파일 바이트와 안 맞는다며 “angr 심볼릭 실행으로 매번 랜덤 값을 만드는 참조 구현일 것”이라는 가설에 빠졌고, 그 뒤 같은 분석 문장을 15분 내내 반복하다 TO가 됐습니다. 4회차는 첫 두 턴 만에 예시 값 1784774249 = 0x6A56F589를 바이트 순서 뒤집어 89 F5 56 6A = endbr64; push rbp, 즉 .text 시작임을 알아채고 섹션 헤더 순회로 240개 워드를 뽑아 통과했습니다. 첫 가설 하나가 15분 루프와 2.6분 통과를 갈랐습니다.

train-fasttext (60분 꽉 채움, 62턴) — fastText 모델을 정확도와 크기 제한 안에서 학습시키는 태스크입니다. 3회차는 22분 만에 크기 제한을 못 맞추고 FAIL이었습니다. 4회차는 grid search로 dim·epoch·wordNgrams를 돌리며 정확도를 잡은 뒤 양자화(quantize)로 65.4 MB / 정확도 0.6218짜리 모델을 저장했고, 그 직후 시간이 끝났습니다. 기록은 AgentTimeoutError지만 저장된 모델이 test_accuracy·test_model_size를 모두 통과해 reward>0 = PASS입니다. 2편의 mcmc-sampling-stan과 같은 “타임아웃 직전 제출” 케이스입니다.

어디서 갈렸나 (원본 4회 vs Uncensored 3회, 89개 전체)

구분 개수 태스크
둘 다 통과 50
둘 다 전패 23 path-tracing 계열, regex-chess, feal-linear, make-*-mips, install-windows-3.11, compile-compcert, schemelike 등
원본만 통과 10 circuit-fibsqrt, custom-memory-heap-crash, dna-insert, llm-inference-batching-scheduler, mteb-leaderboard, qemu-startup, sparql-university, tune-mjcf, extract-elf, train-fasttext
Uncensored만 통과 6 feal-differential-cryptanalysis, filter-js-from-html, model-extraction-relu-logits, overfull-hbox, polyglot-rust-c, winning-avg-corewars

Uncensored만 통과한 6개는 4회차에서 전부 다시 실패했습니다. 특히 winning-avg-corewars — Uncensored는 1.0× 재실행에서 통과한 태스크인데, 원본은 4회차에도 60분·146턴·ctx 127K를 쓰고 TO였습니다. 이 6개는 이제 시도 횟수 문제가 아니라 두 모델의 실제 편차로 보는 게 맞습니다.

남은 29개의 실패 해부

2편의 세 덩어리가 그대로인데, 4회차엔 각 덩어리의 구체적 형태가 더 선명하게 보였습니다.

① 반복 루프 — 이번 회차의 주범. TO 20개 중 세 개가 노골적인 루프였습니다.

  • schemelike-metacircular-eval 40분 · 188턴 · ctx 92K. 처음 26턴은 정상적으로 Scheme 평가기를 고치다가 이후 162턴이 동일 메시지 반복이었습니다. 63개 테스트 중 0개 통과.
  • winning-avg-corewars 60분 · 146턴 · ctx 127K. 39턴 정상, 이후 107턴 루프. 2편과 똑같이 “루프에서 빠져나와야 한다”고 자각하는 문장을 반복합니다.
  • regex-chess 60분 · 156턴 · ctx 120K. 3회차의 322턴보다는 줄었지만 마지막 65턴이 루프였습니다.

공통점이 있습니다. 루프는 항상 25~40턴의 정상 작업 뒤에 시작하고, 시작하면 턴당 0.4~1K 토큰씩 컨텍스트만 불리며 새 명령은 내지 않습니다. terminus-2의 컨텍스트 요약이 122K 부근에서 발동하면 루프가 끊길 때도 있지만, 대부분 그 전에 시간이 끝납니다. 이 크기의 모델에 필요한 건 더 긴 컨텍스트가 아니라 “같은 말을 N번 했으면 강제로 다른 행동”을 시키는 하네스 쪽 안전장치라는 생각이 굳어졌습니다.

② 아슬아슬한 실패. 채점 문턱 바로 아래에서 떨어진 게 둘 있습니다.

  • rstan-to-pystan 18.2분 — Stan 모델을 PyStan으로 옮기는 태스크입니다. 포팅 자체는 됐고 사후 분포 상관계수 ρ = 0.8813, 기준은 ≥ 0.886입니다. 샘플링 시드 하나 차이입니다.
  • query-optimize 9.2분 — 6개 테스트 중 5개 통과. 남은 하나는 최적화한 쿼리의 실행 시간이 0.970초, 기준은 골든 쿼리 0.759초의 1.05배입니다. 4회 모두 “충분히 빨라졌다”고 자평하고 제출했습니다.

③ 조기 확신 제출. 4회차에도 그대로입니다. overfull-hbox 3.8분, raman-fitting 3.4분, sanitize-git-repo 3.9분 — 제한의 1/5도 안 쓰고 “검증 완료”입니다. video-processing은 17.9분에 걸쳐 파이프라인을 만들고 제출했는데 채점기의 assert 240 <= 223(프레임 수 초과)에 걸렸습니다. 자기 검증이 채점 기준과 다른 것을 보고 있다는 증거가 회차마다 쌓입니다.

29개 중 23개는 Uncensored도 전패한 태스크입니다. 4회차의 복구 2개가 모두 Uncensored 전패 태스크에서 나왔다는 건, 원본이 “재시도로 더 뒤집을 여지가 있는 모델”이라는 뜻이기도 합니다.

운영 메모

13시간 동안 서버 재시작 0회, wedge 0건, 400 overflow 0건입니다. 가동 시간은 2일 12시간을 넘겼습니다. ctx 100K 이상 태스크(filter-js-from-html 101K, path-tracing-reverse 123K, regex-chess 120K, corewars 127K)가 돌 땐 커널이 mlx-serve 페이지를 스왑으로 밀어내 메모리 여유가 18%까지 떨어졌지만 태스크가 끝나면 80%대로 회복했습니다. 2편의 인프라(watchdog 120초, 이미지 자동 정리)는 손댈 곳이 없었습니다.

한 가지 배운 것이 있습니다. watchdog가 서버 로그를 새 파일로 돌려쓰고 있었는데 저는 옛 로그 파일을 tail 하며 “서버 정체”를 의심했습니다. stall 진단은 반드시 서버가 지금 쓰는 로그로 해야 합니다. 7분 동안 새 턴이 없던 건 서버가 아니라 에이전트 쪽이 긴 명령을 돌리던 것이었습니다.

다음

남은 29개로 **5회차(pass@5)**를 이미 돌리고 있습니다. 공식 Terminal-Bench가 5 trial 기준이라 이걸로 원본 쪽 시도는 채워집니다. 기대치는 4회차와 같습니다 — 0~2개, 나온다면 ②번 아슬아슬한 실패(rstan, query-optimize)나 ③번 조기 제출 부류에서 나올 것입니다.

한 줄 요약: 4번째 시도에서도 원본이 앞섭니다. 60 vs 56, 그리고 뒤집힌 2개는 둘 다 Uncensored가 못 푼 문제였습니다.