카테고리
검사 엔진, 리포트 파이프라인, 인프라. 만들면서 내린 선택과 근거.
Qwen3.8-27B MLX 4bit(17GB) 6회차. 5회차 실패 35개를 다시 돌려 복구 2, pass@6 56/89(62.9%)로 Uncensored(59)와 격차 3. 그런데 애초에 여섯 번을 돈 것은 세 번째가 컨테이너 네트워크 ERR로 통째로 날아갔기 때문입니다. 그 회차를 빼면 사실상 pass@5에 가깝습니다.
Qwen3.8-27B MLX 4bit(17GB) 5회차. 서버만 재기동하고 4회차 실패 41개를 다시 돌려 복구 6개, pass@5 54/89(60.7%). 회차별 복구 +0→+2→+6으로 되레 늘고 Uncensored(59)와 격차 5로 좁혔습니다. 원본이 놓친 칸을 메우고 27B만 푼 세 번째 태스크, ERR 13→1→0.
Qwen3.8-27B MLX 4bit(17GB) 4회차. 서버만 깨끗이 재기동하고 43개를 같은 조건으로 다시 돌렸습니다. 복구 2개로 pass@4 48/89(53.9%), 3회차를 13건 유실시켰던 ERR가 1건으로 줄었습니다. 서버 탓이 아니었다는 지난 진단의 검증, 유실 후보 7개의 실제 성적, 모니터링이 속은 순간.
Qwen3.8-27B MLX 4bit(17GB) 3회차. 2회차 실패 43개를 같은 조건으로 다시 돌렸는데 복구 0, pass@3 46/89 그대로입니다. 30개는 1·2회차와 똑같이 실패했고 13개는 모델이 한 턴도 못 돌고 ERR로 유실됐습니다. 서버 탓인 줄 알았던 ERR의 진짜 원인과 pass@k 포화 이야기.
Qwen3.8-27B MLX 4bit(17GB) 2회차. 1회차 실패 54개를 같은 조건으로 다시 돌려 pass@2 46/89(51.7%)로 올렸습니다. 복구 11개 중앙값 6.5분, 세 모델 중 27B만 푼 태스크 2개, 여전히 안 되는 43개. 그리고 실패만 재시도가 왜 더 오래 걸리는가.
Qwen3.8-27B MLX 4bit(17GB)를 Flash Next(100GB)와 같은 조건으로 Terminal-Bench 2.1 89개에 돌렸습니다. 1회차 35/89(39.3%) vs 원본 45·Uncensored 41. 갈린 태스크, 반복 루프 15건, 속도, 운영 메모
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개 태스크, 속도 비교, 하네스가 만든 실패
원본 mixed-4-8bit Qwen3.8 Flash Next의 Terminal-Bench 2.1 5회차(pass@5) 결과. 29개 재시도에서 4개 복구, 타임아웃 직전 제출 2건, 120K 컨텍스트 핸드오프와 fallback 루프까지 12시간 30분의 기록
abliterated Uncensored Qwen3.8 Flash Next의 Terminal-Bench 2.1 4회차(pass@4) 결과. 33개 재시도에서 2개 복구, 400 overflow 3,877건짜리 fallback 루프 2건, Coq 빌드로 40분을 태운 compile-compcert까지 14시간 45분의 기록
원본 mixed-4-8bit Qwen3.8 Flash Next의 Terminal-Bench 2.1 3회차(pass@3) 결과와, 같은 3회 시도 기준으로 abliterated 모델과 다시 붙인 비교. 남은 31개의 실패 패턴 분석
원본 mixed-4-8bit Qwen3.8 Flash Next의 Terminal-Bench 2.1 4회차(pass@4) 결과. 31개 재시도에서 2개 복구, 반복 루프·조기 제출·아슬아슬한 실패까지 남은 29개의 실패 패턴 해부
같은 조건 단일 패스로 붙인 A/B — abliterated(Uncensored) 모델과 원본 mixed-4-8bit 모델의 Terminal-Bench 2.1 89개 결과
커뮤니티 abliterated 파생 모델로 Terminal-Bench 2.1 89개를 사흘간 완주했습니다. 컨텍스트·타임아웃·온도를 네 번 바꾼 과정과 wedge 13회, 최종 56/89 점수의 의미를 정리합니다.
M5 Max에 올린 로컬 LLM이 실제 터미널 작업을 얼마나 해내는지 Terminal-Bench로 밤새 재봤습니다. 통과율보다 서버가 네 번 멈췄다가 스스로 살아난 게 더 인상적이었습니다.
Qwen3.8 27B를 4bit/8bit/Flash Next로 재보고, DFlash2 speculative decoding까지 붙여봤습니다. 속도는 2~3배 빨라졌지만 공식 주장과 달리 M5에서는 출력이 원본과 갈라졌습니다.
125B MoE 모델을 맥 한 대에 올려서 에이전트 백엔드로 썼습니다. 느린 게 모델 탓인 줄 알았는데, 하루 파보니 진짜 범인은 prefill이었습니다. 캐시와 옵션 몇 개로 잡은 기록입니다.
PostgreSQL은 복제 슬롯이 남아 있는 한 WAL을 지우지 않습니다. standby가 죽은 뒤 두 달간 쌓인 WAL과, 공간을 되찾은 뒤에야 드러난 2차 손상까지의 기록입니다.
최신 컨테이너 이미지는 x86-64-v2를 요구합니다. 가상화 하이퍼바이저가 기본으로 주는 CPU 모델에는 그 명령어가 없어, 애플리케이션 오류가 아니라 glibc 단계에서 죽습니다.
iptables 화이트리스트를 ctstate NEW로만 심사하면 핸드셰이크가 끝나지 않습니다. 포트 스캔에는 열려 있다고 나오기 때문에 백업 실패의 원인을 한 달간 찾지 못했습니다.
reload 가 rc=0 을 돌려줘도 설정이 적용되지 않는 경우가 있습니다. 구 프로세스가 살아남아 옛 설정을 서빙하거나, 검증용 파일에만 반영되고 승격되지 않는 두 가지 패턴입니다.
한 단계 건너뛴 LTS 업그레이드가 configure 단계에서 끊기면 sudo와 네트워크가 함께 사라집니다. dpkg 상태를 세어보면 재설치 없이 복구할 수 있는지 판단이 섭니다.
정상 동작 중에는 변하지 않는 값을 감시 지표로 쓰면 시간이 지날수록 반드시 울립니다. 오탐을 만든 지표와, 그것을 고치다 정탐을 놓친 이야기입니다.
timedatectl 로 OS 타임존을 바꿔도 DB와 컨테이너는 옛 시간을 씁니다. 같은 클러스터 안에서 NOW() 가 9시간 차이 나던 사례와, 재시작 없이는 반영되지 않는 이유입니다.