abliteration은 코딩 성능을 올려줄까? Uncensored vs 원본 Qwen3.8, Terminal-Bench 89 맞대결
같은 조건 단일 패스로 붙인 A/B — abliterated(Uncensored) 모델과 원본 mixed-4-8bit 모델의 Terminal-Bench 2.1 89개 결과
요약
앞선 글에서 abliterated(=Uncensored) Qwen3.8 Flash Next(ARC4NUM 4bit)로 Terminal-Bench 2.1 89개를 돌렸습니다. 이번엔 abliteration을 하지 않은 원본 ddalcu/Qwen3.8-Flash-Next-MLX-Serve-mixed-4-8bit를 완전히 같은 조건으로 한 번씩 돌려 맞대결시켰습니다.
결론부터 말하면 같은 조건 단일 패스에서 원본이 45/89, Uncensored가 41/89입니다. abliteration은 코딩·에이전트 성능을 올려주지 않았습니다. 오히려 4개 뒤졌습니다.
abliteration이 뭔가요? 모델의 거부(refusal) 방향 벡터를 제거해 “무엇이든 답하게” 만드는 후처리입니다. 안전 정렬을 깎아내는 대신 능력이 올라간다는 기대가 종종 있는데, 이번 결과는 그 기대와 반대입니다. 연구·비교 목적의 실행이며, abliterated 모델은 그 특성을 명시해 사용해야 합니다.
실험 조건 (양쪽 동일)
| 항목 | 값 |
|---|---|
| 벤치 | Terminal-Bench 2.1 (89 tasks), 에이전트 terminus-2 |
| 서버 | mlx-serve 26.8.11 headless, --mtp --ctx-size 131072 --kv-quant 8 --max-concurrent 2 |
| 샘플링 | temperature 0.3, reasoning_effort high |
| 컨텍스트 | max_input 120K / max_output 16K, agent-timeout ×1.0 |
| 하드웨어 | Apple Silicon, 통합메모리 wired 상한 ~110GB, 모델 상주 70.1GB |
| 시도 | 태스크당 1회 (pass@1) |
결과
| 구분 | 통과 | 통과율 | 비고 |
|---|---|---|---|
| 원본 ddalcu (단일) | 45 / 89 | 50.6% | 이 글의 주인공 |
| Uncensored ARC4NUM (단일) | 41 / 89 | 46.1% | 동일 조건 1:1 |
| Uncensored ARC4NUM (best-of 3회) | 56 / 89 | 62.9% | 시도 3배 |
단일 패스가 공정한 1:1 비교입니다. best-of는 Uncensored를 본실행과 재실행 2회로 총 세 번 돌려 “한 번이라도 통과”를 모은 값이라 단순 비교 대상이 아닙니다.
어디서 갈렸나
원본이 이긴 11개(Uncensored 단일 실패 → 원본 통과)는 대체로 오래 붙들고 디버깅하면 풀리는 종류였습니다. custom-memory-heap-crash는 gdb가 막히자 valgrind에서 코어 파싱, 다시 소스 추론으로 우회했습니다. 그 밖에 llm-inference-batching-scheduler, mteb-leaderboard(GitHub rate limit을 견디며 완주), pytorch-model-recovery, reshard-c4-data, qemu-startup 등이 여기 들어갑니다.
원본이 진 7개는 성격이 달랐습니다. caffe-cifar-10(toronto.edu 다운로드 병목)과 break-filter-js-from-html(20분 제한 타임아웃)처럼 시간·네트워크 요인이거나, configure-git-webserver·filter-js-from-html·financial-document-processor·overfull-hbox처럼 “다 됐다”고 자평하고 성급히 제출했다가 채점 기준을 못 넘긴 경우입니다. 이 “조기 확신” 패턴이 원본의 대표적 약점으로 보입니다.
운영에서 배운 것 (인프라 함정)
24시간짜리 장기 실행이라 모델 성능 못지않게 운영 안정성이 결과를 좌우했습니다.
- watchdog 오탐 재시작. 컨텍스트가 90K를 넘은 태스크는 요청 하나에 56초가 걸리는데, watchdog의 헬스체크 ping 타임아웃이 45초라 두 번 연속 놓치자 멀쩡한 서버를 wedge로 오판하고 죽였습니다. 재시작이 캐시(70GB 모델 + 60GB 디스크 prefix-cache)를 날려 진행 중이던 태스크가 콜드 프리필로 5분 넘게 더 썼습니다. 타임아웃을 120초로 올려 재발을 막았습니다. 그 태스크 fix-ocaml-gc는 다행히 빌드가 끝나 결국 PASS로 살아남았습니다.
- 디스크 포화. 태스크마다 도커 이미지가 쌓여 Colima VM 디스크(59GB)가 100% 차자 컨테이너 안에서 apt가 죽었습니다. 채점이 끝난 태스크의 이미지를 자동 삭제하도록 점검 스크립트에 넣었습니다.
- 131K 컨텍스트 벽. 일부 태스크는 같은 분석을 수십 턴 반복하며 컨텍스트를 131K까지 불렸고, 그때마다 서버가 400으로 거부했습니다. 모델 스펙은 256K를 지원하지만, 70GB 모델이 이미 올라간 이 하드웨어에서는 KV 캐시가 GPU 메모리를 넘겨(circuit-fibsqrt는 122K에서 OOM) 128K가 사실상 물리적 천장이었습니다.
재도전(pass@2): 실패 44개를 한 번 더
단일 실패 44개를 완전히 같은 조건으로 1회 더 돌렸습니다. 8개가 복구되어 **pass@2 = 53/89(59.6%)**가 되었습니다.
| 시도 | 통과 | 통과율 |
|---|---|---|
| pass@1 (단일) | 45 / 89 | 50.6% |
| pass@2 (2회) | 53 / 89 | 59.6% |
복구된 8개는 circuit-fibsqrt(1회차 GPU OOM이었으나 2회차엔 off-by-one을 잡아 통과), code-from-image, build-cython-ext, break-filter-js-from-html, password-recovery, tune-mjcf, 그리고 1회차에 “조기 확신”으로 떨어졌던 configure-git-webserver와 financial-document-processor입니다. 즉 원본의 대표적 약점인 성급한 제출은 재시도로 상당 부분 만회됩니다.
반대로 filter-js-from-html은 2회 모두 “검증 완료”라 자평하고 채점에서 탈락했고, feal 계열과 regex-chess, path-tracing 계열은 시간·컨텍스트 한계로 2회 모두 실패했습니다.
한계와 다음 단계
이 45 대 41은 각 1회의 점추정치입니다. Terminal-Bench 공식 제출 기준은 태스크당 여러 trial(현재 최소 5회)로 Accuracy와 pass@k를 냅니다. 그래서 지금 값은 리더보드 수치가 아니라 “같은 조건 1회 스냅샷”으로 읽어야 합니다.
이 pass@2도 여전히 2-trial일 뿐입니다. 남은 실패 36개는 **3회차(pass@3)**를 진행 중입니다. 궁극적으로 공정한 Accuracy를 내려면 양쪽 모두 동일 조건 5회가 필요합니다. 참고로 같은 89개에서 Uncensored best-of(3회)는 56이었는데, 원본은 pass@2에서 이미 53으로 그 문턱에 근접했습니다.
한 줄 요약: 이 워크로드에서 abliteration은 능력을 더해주지 않았습니다. 안전성만 깎였습니다.