또 다른 토큰/초 타령은 그만: 실제 버그 9개로 비교한 로컬 양자화 모델 vs Claude

3비트 양자화의 영향

이게 tok/s 논쟁에서 제일 중요한 부분이야. 같은 모델로 NVFP4랑 3비트 버전을 같은 과제에서 비교했어.

Flash-Next (전문가만 3비트): 점수 -0.02, 토큰 x1.03. 과제 9개로 판단하기엔 사실상 공짜나 다름없어.

27B: 점수 +0.05, 오차 범위 내야. 근데 과제당 토큰을 40% 더 많이 생성해(x1.40, 신뢰 구간 1.25-1.59). 3비트 27B가 내 엔진에서 153 vs 132 tok/s로 더 빨리 디코딩되는데도, 과제당 13분이 아니라 18분이나 걸렸어. 그 차이 중 일부는 내가 나중에 고친 느린 3비트 프리필 경로 때문인데, 최신 빌드로 다시 돌려봐도 토큰은 x1.30 정도 나오더라.

결국 양자화로 인한 손해는 점수 하락으로 나타나지 않았어. 모델이 같은 결론에 도달하려고 더 오래 생각하는 걸로 나타났지. tok/s만 보면 3비트 27B가 이득 같지만, 버그 수정 완료 기준으로 보면 아니야.

컴파일 안 된 패치들은 딱히 결론이 안 나: Flash-Next는 3비트에서 5/27, 원본은 1/27이었고, 27B는 2/27 vs 4/27이었어.

나머지

Flash-Next는 집에서 돌릴 때 Haiku 5.5랑 비슷하고 구형 Sonnet보다는 위야. Sonnet 5.5는 한 단계 위고, Opus 5.5는 그냥 다 압살해.

과제당 토큰 수가 점수만큼이나 많은 걸 말해줘. Sonnet 5.5는 8k 토큰으로 해결할 걸 Flash-Next는 53k 토큰을 써야 해. 내 컴퓨터 기준으로 버그 하나당 1분 30초 걸릴 걸 10분이나 걸리는 셈이지.

Dense 27B는 MoE(Flash-Next +0.16, P = 0.92)보다 뒤처지고, 해결하는 데 토큰도 더 많이 태워.

Gemma 4 26B는 여기서 에이전트로 못 써먹겠어. 생각(thinking) 끄면 9개 과제 내내 파일 수정 한 번도 안 하고, 켜면 수정은 하는데 대부분 틀려.

한계

• 한 도메인(GPU 추론)의 코드베이스에서 가져온 과제 9개고, 버그 리포트는 이탈리아어로 작성됐어. 이건 내 작업 환경에서의 결과지 일반적인 랭킹이 아니야.

• Claude랑 로컬 모델에 서로 다른 하네스(harness)를 썼어.

• 판정은 Claude 모델이 내렸어. 자동 점수는 확인용으로 쓴 거고 결과도 일치하지만, 여전히 한계는 분명해.

• 빌드나 테스트 과정이 없으니까, 이건 전체적인 수정-빌드-테스트 루프가 아니라 코드를 읽고 진단해서 패치하는 능력만 측정하는 거야.

과제 내용은 공개 안 할 거야. 그래야 계속 쓸모가 있을 테니까. 혹시 perplexity나 KL 말고 실제 작업으로 직접 퀀트 모델 테스트해 본 사람 있으면, 나랑 똑같은 패턴인지 알려줘. 점수는 같은데 생각하는 시간만 더 길어지는 거 말이야.

의외네, 난 내 장비에서 (좀 느리긴 하지만) 돌아가던데...

나머지를 평가하는 건 Opus 5이고, 이게 다른 모델들에 더 관대한지 테스트해 봤는데 통계적으로 아니었어. 자동 채점 점수도 Opus 점수랑 비슷해서 편향은 안 보였고. 나중에 더 높은 양자화로 시도해 볼게. 지금은 Qwen4를 기다리는 중이라 내 '토큰'들은 Qwen4가 나오자마자 돌릴 수 있게 capy flash를 준비하는 데 쓰고 있어.