표를 닫는다 — Qwen3.8 원본 vs Uncensored, Terminal-Bench 89개 pass@5 64 대 59
abliterated Uncensored Qwen3.8 Flash Next의 Terminal-Bench 2.1 5회차(pass@5) 결과와 시리즈 총정리. 31개 재시도에서 1개 복구, 59/89(66.3%) vs 원본 64/89(71.9%). 갈린 13개 태스크, 속도 비교, 하네스가 만든 실패
요약
5편에서 “5 대 4, 한 번 더 남았다”고 썼습니다. Uncensored(ARC4NUM abliterated 4bit)의 pass@4 실패 31개를 원본과 같은 조건(타임아웃 1.0×, reasoning high, temperature 0.3, ctx 120K, terminus-2)으로 다섯 번째 돌렸습니다. 결과는 1개 복구입니다.
결론은 Uncensored pass@5 = 59/89 (66.3%), 원본 pass@5 = 64/89 (71.9%) 입니다. 양쪽 다 공식 기준(5 trial)을 채웠으니 이 표는 여기서 닫습니다.
| 시도 | 원본 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회 누적 | 60 / 89 (67.4%) | 58 / 89 (65.2%) |
| 5회 누적 (pass@5) | 64 / 89 (71.9%) | 59 / 89 (66.3%) |
Uncensored의 증분은 (best-of-3) → 2 → 1 입니다. 원본이 5회차에서 4개를 뒤집은 것과 달리 Uncensored는 마지막 회차에서 사실상 포화했습니다. 격차는 8 → 6 → 5로 줄었지만, 줄어든 이유는 전부 “원본이 이미 통과한 태스크를 Uncensored가 뒤늦게 따라잡은 것”입니다. 원본이 못 푼 21개 중 Uncensored가 뒤집은 것은 다섯 번 내내 0개입니다.
5회차에서 무슨 일이
31개를 돌려 1개 복구, 7개 FAIL, 22개 TO, 1개 ERR 입니다. 13시간 24분, 태스크당 평균 24.7분이 걸렸습니다.
mteb-leaderboard (58.1분, 97턴, ctx 96K) — “2025년 8월 기준 MTEB 리더보드에서 28개 태스크를 전부 채운 모델 중 1위”를 찾는 태스크입니다. 원본은 4회차에 32.6분 만에 통과했고, Uncensored는 4회 내내 60분 TO였습니다. 이번 궤적은 embeddings-benchmark/results 저장소를 해당 시점 커밋으로 스냅샷한 뒤, 모델별 결과 파일을 전부 파싱해 28개 태스크가 모두 있는 모델 8개를 추리고 GritLM-7B(0.6408)를 1위로 잡았습니다. 결정적이었던 것은 그다음입니다. **“이 값이 현재 리더보드 API의 meanTask와 소수점 여섯 자리까지 일치한다”**며 자기 방법론을 교차 검증했고, 그러고도 파일이 28개 있는데 리스트에서 빠진 모델 2개(multilingual-e5-small, all-MiniLM-L6-v2)를 찾아내 레거시 포맷 때문임을 확인한 뒤에야 제출했습니다. 58분 중 마지막 20분이 검증이었습니다. 이전 4회는 API를 긁다가 시간을 다 썼습니다.
이것이 전부입니다. 나머지 30개는 실패했고, 그중 23개는 원본도 5회 전패인 태스크라 예상된 결과였습니다. 볼 만한 것은 “왜 졌나”보다 “어떻게 졌나”에 있습니다.
어디서 갈렸나 (89개 전체, 양쪽 5회)
| 구분 | 개수 | 태스크 |
|---|---|---|
| 둘 다 통과 | 55 | — |
| 둘 다 전패 | 21 | chess-best-move, compile-compcert, dna-assembly, extract-moves-from-video, feal-linear-cryptanalysis, gcode-to-text, gpt2-codegolf, install-windows-3.11, make-doom-for-mips, make-mips-interpreter, path-tracing, path-tracing-reverse, protein-assembly, qemu-alpine-ssh, query-optimize, regex-chess, rstan-to-pystan, sanitize-git-repo, schemelike-metacircular-eval, video-processing, write-compressor |
| 원본만 통과 | 9 | circuit-fibsqrt, extract-elf, llm-inference-batching-scheduler, qemu-startup, raman-fitting, sparql-university, torch-pipeline-parallelism, train-fasttext, tune-mjcf |
| Uncensored만 통과 | 4 | feal-differential-cryptanalysis, filter-js-from-html, model-extraction-relu-logits, polyglot-rust-c |
격차 5 = 9 − 4 입니다. “원본만 통과” 9개를 다시 보면 유형이 둘입니다.
- 15분 제한 태스크 4개 (qemu-startup, raman-fitting, torch-pipeline-parallelism, tune-mjcf). 원본도 이 넷을 3~15분 사이에서 아슬아슬하게 넘겼습니다(torch-pipeline은 TO 직전 파일이 채점 통과). Uncensored는 다섯 번 모두 15분을 꽉 채우고 끝났습니다. raman-fitting 5회차가 대표적입니다. 원본은 “x축이 파장이고 소수점이 콤마”라는 것을 3턴째에 알아채고 3분에 풀었는데, Uncensored는 이번에도 20턴 내내 레이저 파장을 바꿔가며 피팅을 반복하다 “x축 해석이 불분명하다”는 말을 남기고 끝났습니다. 다섯 번 중 두 번은 정답 해석을 궤적 안에서 언급하고도 버렸습니다.
- 정밀도가 필요한 태스크 5개 (extract-elf, llm-inference-batching-scheduler, sparql-university, train-fasttext, circuit-fibsqrt). 시간은 남는데 답이 틀립니다. sparql-university는 이번에도 3.6분 만에 제출했고, 채점기는 ‘CH, ES, US’, ’GR, US’처럼 복수 국적이 정답인 행을 놓쳤다고 했습니다(모델 답은 ‘GR’ 하나). train-fasttext 19분 FAIL은 이전보다 더 나빴습니다. 채점기가
/app/model.bin cannot be opened, 즉 모델 파일을 정해진 경로에 저장하지 않았습니다. extract-elf 1.6분 · 11턴은 4회차의 “0.00% 일치”와 같은 자세로 또 제출했습니다.
반대로 Uncensored만 푼 4개는 다섯 번 내내 그대로입니다. 암호 분석(feal-differential), JS 필터, ReLU 로짓 추출, Rust-C polyglot — 공통점을 찾자면 “정답이 하나로 좁혀지는 구성 문제”인데, 표본 4개로 abliteration 효과라고 말할 근거는 안 됩니다. 격차 5도 마찬가지로 89개 벤치의 시도별 분산(원본 5회차 +4, Uncensored 5회차 +1) 안에 있는 숫자라, **“원본이 낫다”보다 “abliteration이 이 벤치에서 이득을 주지는 않는다”**가 정직한 결론입니다.
30개 실패 해부 — 이번엔 하네스와 서버가 주인공
① fallback 루프, 세 번째 등장. video-processing 60분 · 1,127턴 · ctx 130K. 4회차(822턴)보다 더 길어졌습니다. 100K를 넘고 131K 서버 한계에 부딪힌 뒤 남은 시간 내내 “Technical difficulties” 재시도가 초당 수 건씩 쌓였습니다. 이 한 태스크의 400 overflow가 2,800건, 5회차 전체(2,809건)의 99.7%입니다. 원본 5회차 path-tracing-reverse, Uncensored 4회차 video-processing·circuit-fibsqrt에 이어 네 번째 사례라 재현성은 확실합니다. 조건도 같습니다. 도구 출력 한 턴이 커서 max_input_tokens 120K와 서버 131K 사이 11K 여백을 한 번에 넘으면 핸드오프 요약 요청 자체가 400을 받습니다.
대조군도 있습니다. regex-chess 60분 · 182턴은 136턴째 ctx 117.5K에서 핸드오프가 걸려 3.1K로 리셋됐고 이후 46턴을 정상적으로 썼습니다(풀지는 못했습니다. “규칙이 임의 포지션에 일반화돼야 한다”는 것을 마지막 턴에야 인정했습니다). 같은 하네스, 같은 모델입니다. 여백 안에서 멈추느냐 못 멈추느냐가 도구 출력 한 줄 차이입니다.
② 서버가 요청을 거부한 ERR — 새로운 유형. schemelike-metacircular-eval 39.2분 · 297턴 · ctx 119K. 4회차와 같이 반복 루프로 컨텍스트를 키우다가, 이번엔 131K 벽이 아니라 그 전에 죽었습니다. 서버 로그입니다.
prompt 119609 tokens needs ~11908MB (KV+working+margin), ~10653MB available — rejectingmlx-serve의 메모리 admission이 KV 캐시 자리를 못 잡아 요청을 거절했고, harbor는 litellm BadRequestError로 ERR 처리했습니다. 왜 128GB 머신에서 10GB가 없었는지는 아래 메모리 항목이 답입니다. 어차피 TO로 끝날 궤적이라 결과엔 영향 없지만, “서버 상태가 채점 결과에 섞여 들어온” 첫 사례입니다.
③ 3턴 반복 루프의 끝. tune-mjcf 15분 · 35턴. 마지막 3턴이 글자 하나 안 틀리고 같은 분석(“질량 행렬 최소 고유값 7.5e-9, 강성 모드 ω≈3310, 주기 1.9ms ≈ 타임스텝”)입니다. 진단은 맞습니다. 4회차에 “PGS 솔버로 바꾸면 통과”라는 답까지 갔던 그 태스크입니다. 진단을 반복 출력하는 동안 파일은 안 썼습니다. 같은 병이 llm-inference-batching-scheduler(69K), make-mips-interpreter(106K), dna-assembly(118K)에서도 보였습니다.
④ 나머지는 이미 아는 패턴입니다. 조기 확신 제출(sanitize-git-repo 1.9분 · 9턴, install-windows-3.11 4.0분, query-optimize 7.1분), 환경 빌드로 시간을 다 쓴 compile-compcert 40분(이번에도 Coq 소스 빌드), 그리고 15분 제한 태스크 10개의 전패입니다.
속도는 같았다
시리즈 내내 “정확도”만 봤으니 마지막에 속도를 정리합니다. 두 모델 다 같은 mlx-serve 26.8.11, MTP 켬, 8-bit KV, M5 Max 128GB입니다.
서버 처리량 (요청 로그, 프롬프트 길이별 중앙값, tok/s):
| 프롬프트 | 원본 프리필 / 디코드 | Uncensored 프리필 / 디코드 |
|---|---|---|
| < 8K | 162 / 73.3 | 234 / 57.8 |
| 8–32K | 350 / 65.5 | 391 / 61.9 |
| 32–64K | 378 / 50.8 | 324 / 53.0 |
| 64K+ | 173 / 53.3 | 248 / 44.0 |
짧은 프롬프트에서 원본 디코드가 1025% 빠릅니다. mixed-4-8bit가 더 큰 모델인데도 느리지 않은 것은 이 크기에서 병목이 가중치 읽기가 아니라 KV/어텐션 쪽이기 때문입니다. 다만 Uncensored 수치엔 5회차의 스왑 구간(디코드 2027 tok/s)이 섞여 있고, 원본 서버 로그는 1,675 요청 표본이라 정밀 비교는 아닙니다.
태스크 완료 속도 (전 회차, 원본 227회 · Uncensored 240회 실행):
| 원본 | Uncensored | |
|---|---|---|
| 턴당 소요 (중앙) | 0.38분 | 0.39분 |
| 턴당 출력 토큰 (중앙) | 345 | 334 |
| 둘 다 통과한 55개, 최단 PASS 중앙값 | 4.6분 / 17턴 | 5.4분 / 16턴 |
| 55개 최단 PASS 합계 | 562분 / 1,372턴 | 527분 / 1,309턴 |
| 더 빨랐던 태스크 | 30 | 25 |
턴당 0.38 대 0.39분입니다. 에이전트 루프에서 시간의 대부분은 컨테이너 안 명령 실행과 프리필이라 디코드 차이가 묻힙니다. 태스크별 승패는 30:25로 반반이고, 합계에서 Uncensored가 6% 적은 것은 실력이 아니라 몇 개 태스크(distribution-search 19→4분, custom-memory-heap-crash 16→5분)의 탐색 경로 운입니다. 반대로 mteb-leaderboard(33→58분), large-scale-text-editing(9→20분)은 원본이 훨씬 빨랐습니다. 속도로는 둘을 구분할 수 없습니다. 차이는 정확도(64 대 59)에서만 납니다.
운영 메모
13시간 24분 동안 wedge 재시작 0회, 서버 가동 28시간 연속(4회차 포함)입니다. 이번엔 메모리 얘기가 전부입니다.
- 100K 컨텍스트가 상주하면 이 머신은 스왑에 닿습니다. 연쇄는 이렇습니다. 100K+ 프롬프트 → mlx-serve의 hot-cache가 8GB 상한을 넘어 13.6GB까지 성장(엔트리 2개 단위로만 퇴거하니 상한을 못 지킵니다) → macOS가 mlx-serve 자체를 페이지아웃(RSS 14 → 2GB) → 스왑 파일 41 → 47GB → 디코드 55 → 20~27 tok/s. schemelike의 admission 거부(위 ②)가 이 구간에서 나왔습니다. 태스크가 끝나면 10분 안에 회복합니다. 다음에 같은 구성으로 돌린다면
--prefix-cache-mem 4GB로 시작하는 것이 맞습니다. - 400 overflow 2,809건, 그중 2,800이 video-processing 하나입니다. 서버 부하는 없었고(요청당 1초 미만) 손해는 벤치 시간 30분 남짓입니다.
- admission 거부 11건 전부 스왑 구간입니다. 서버가 죽지 않고 요청만 거절한 것은 mlx-serve 쪽이 옳게 동작한 것입니다. 4일 전이었으면 wedge였습니다.
- 4회차 글의 “메모리 경고 1회”(free 0.3GB · 여유 16%)는 이번엔 없었습니다. 경고 기준(free 1GB 미만 그리고 여유 20% 미만)을 동시에 밟은 적이 없을 뿐, free 1GB 근처는 여러 번이었습니다.
시리즈를 닫으며
일주일 전 “Qwen3.8 Flash Next를 M5 Max에서 얼마나 돌릴 수 있나”로 시작해 Terminal-Bench 89개를 두 모델 × 5회 = 467회 실행했습니다. 남는 것은 세 가지입니다.
- abliteration은 이 벤치에서 공짜가 아닙니다. pass@1 −4, pass@5 −5. 격차가 5회 내내 한 자리 수로 유지됐고, Uncensored만 푸는 태스크 4개는 처음부터 끝까지 4개였습니다. “검열 해제로 에이전트 성능이 오른다”는 얘기는 최소한 이 89개에서는 성립하지 않습니다.
- pass@k는 모델보다 분산을 잽니다. 원본 45 → 64, Uncensored 41 → 59. 5회 재시도로 각각 +19, +18입니다. 같은 태스크가 3분에 풀리기도, 30분 TO가 나기도 합니다. 단일 실행 수치로 두 모델을 비교하는 것은 이 분산 안에서 노는 일입니다.
- 실패의 상당수는 하네스 몫입니다. fallback 루프 4건(각 30분 허공), max_input_tokens 여백 11K, 반복 루프 감지 없음, 15분 제한 태스크의 “환경 설치 vs 답 먼저”라는 시간 배분. 모델을 바꾸는 것보다 이 넷을 고치는 것이 pass@1을 더 올릴 것입니다.
한 줄 요약: 다섯 번씩 돌려 64 대 59입니다. 속도는 같고, 격차 5는 abliteration이 준 이득이 없다는 뜻이며, 양쪽 모두 21개는 모델이 아니라 하네스와 시간이 막았습니다.