또 다른 토큰/초(tok/s) 게시물은 아닙니다: 9가지 실제 버그에 대한 로컬 양자화 모델 대 Claude 비교

여기에서는 모델을 마비시키면서까지 토큰/초(tok/s)를 추구하지 말자는 이야기가 많이 오가고 있으며, 제가 올리는 내용 중 대부분은 여전히 속도 수치입니다. 그래서 이번에는 다른 절반의 내용을 다루겠습니다. 즉, 제가 집에서 구동하는 모델들이 실제로 제 작업에 무엇을 수행하는지, 그리고 고정된 참조점(fixed reference points)으로 Claude 모델을 추가하여 비교한 결과입니다. 모든 로컬 실행은 2x RTX 5070 Ti 16 GB, Ryzen 9900X, 96 GB DDR5를 사용하는 제 자체 엔진(capy-flash)에서 구동됩니다. 전문가의 플래시 최적화는 다음 기회에 다루겠습니다. 제가 이 작업에 사용한 것은 해당 엔진(C++/CUDA)의 비공개 기록에서 가져온 9가지 실제 회귀(regressions) 문제입니다. 각 문제에 대해 저는 수정되기 직전의 코드를 꺼내어, 마치 저 자신에게 버그 보고서를 작성하듯이 작성했습니다: 증상, 수치, 로그 등, 어디를 봐야 할지에 대한 단서는 전혀 없습니다. 성능 절벽(Performance cliffs), 숫자 표류(numeric drift), WSL2 환경에서 두 개의 GPU로만 나타나는 버그 같은 것들입니다. 이 중 어느 것도 공개된 적이 없습니다. 에이전트는 원인을 찾아내고 패치(patch)를 작성해야 합니다. 이는 네트워크 연결과 CUDA 툴체인(CUDA toolchain)이 없는 Mac에서 격리된 환경(sandboxed)으로 실행되므로, 무언가를 빌드하거나 실행할 수 없고 오직 코드로부터 추론해야만 합니다. 최대 80단계로 제한되며, 작업당 모델별로 3번씩 실행됩니다. Claude 모델은 Claude Code에서, 로컬 모델은 OpenCode에서 구동됩니다. 처음에는 브릿지(bridge)를 통해 Claude Code에서 로컬 모델들을 시도해봤는데 성능이 훨씬 나빴기 때문에, 각 측면이 가장 잘 작동하는 하네스(harness)를 사용하게 했습니다. 평가 점수 산정: 모든 패치는 두 번 채점됩니다. 첫째는 실제 수정된 코드로부터 구축된 숨겨진 키(hidden key)에 대해 자동적으로 이루어집니다: 정확한 파일 및 함수, 패치 정밀도(patch precision), 코드에 대한 몇 가지 확인 사항 등입니다. 둘째는 Claude Opus 5가 블라인드 심사위원(blind judge) 역할을 합니다. 이 모델은 버그 보고서, 코드,

제가 가진 것은 9가지 작업이며, 신뢰 구간(confidence intervals)은 약 ±0.2로 넓습니다. 등급별 성능 차이는 유지됩니다. 두 모델 간의 점수 차이가 0.1 미만이면 우연에 가깝습니다. 결과 판단자 점수는 01점이며, 토큰에는 추론 과정이 포함되어 있습니다. 신뢰 구간(CIs)과 자동 점수는 이미지에 나와 있습니다.

이것이 토큰/초(tok/s) 논점에서 중요한 부분입니다. 동일한 모델을 NVFP4와 3-bit로 비교하고, 같은 작업에 적용했습니다. Flash-Next (전문가 레이어만 3-bit): 점수 -0.02, 토큰 x1.03. 9가지 작업을 기준으로 볼 때, 큰 차이는 없습니다. 27B: 점수 +0.05로 노이즈 범위 내입니다. 하지만 작업당 토큰을 40% 더 생성합니다 (x1.40, CI 1.25-1.59). 3-bit 27B는 제 엔진에서 더 빠르게 디코딩되며, 153 vs 132 tok/s를 기록했지만 여전히 작업당 13분 대신 18분이 필요했습니다. 이 격차의 일부는 제가 수정한 느린 3-bit prefill 경로 때문이었습니다. 최신 빌드로 재실행해도 x1.30 토큰으로 나왔습니다. 따라서 양자화(quantization)로 인한 손상이 낮은 점수로 나타난 것이 아니라, 모델이 같은 결과에 도달하기 위해 더 오래 생각하는 방식으로 나타났습니다. 오직 tok/s만 본다면 3-bit 27B가 더 나은 선택입니다. 하지만 버그당 수정된 시간으로 따지면 그렇지 않습니다.

비컴파일 패치(Non-compiling patches)는 명확한 이야기를 들려주지 못합니다: Flash-Next의 3-bit에서의 5/27 대 1/27, 27B의 2/27 대 4/27. 나머지 작업에서는 Flash-Next가 Haiku 5.5와 구형 Sonnet 모델들보다 우위에 있습니다. Sonnet 5.5는 한 단계 발전했으며, Opus 5.5는 모든 것보다 앞서 있습니다. 토큰당 작업량은 점수만큼이나 많은 것을 말해줍니다. Sonnet 5.5는 Flash-Next의 53k 토큰에 비해 8k 토큰으로 더 멀리 나아가며, 이는 제 컴퓨터에서 버그 하나당 10분 대 1시간 반을 의미합니다. 밀집형(dense) 27B는 MoE (Flash-Next +0.16 페어링, P = 0.92)에 뒤처지며, 그곳까지 도달하는 데 더 많은 토큰을 소모합니다.

Gemma 4 26B는 여기에서 에이전트(agent)로 작동하지 않았습니다. 'thinking' 기능을 끄면 9가지 작업 중 파일을 수정한 적이 없습니다. 반면, 'thinking' 기능을 켜면 수정은 하지만 대부분 틀립니다. 이 테스트는 한 코드베이스에서 하나의 도메인(GPU 추론)에 국한된 9가지 작업을 대상으로 하며, 버그 보고서는 이탈리아어로 작성되었습니다. 이는 일반적인 순위가 아니라 제가 진행하는 작업 환경에서 모델들이 보이는 방식입니다. Claude와 로컬 모델을 위해 서로 다른 테스트 환경(harnesses)이 사용되었습니다. 심사관은 Claude 모델이며, 자동 점수는 이를 확인하기 위한 것이고 그들은 동의하지만 여전히 한계가 있습니다. 빌드나 테스트 과정이 없기 때문에, 이는 전체 수정-빌드-테스트(edit-build-test) 루프가 아닌 코드 읽기를 통한 진단 및 패치(patching) 능력을 측정합니다. 저는 이 작업을 공개하지 않을 것입니다. 그렇지 않으면 유용성을 잃을 것이기 때문입니다. 만약 여러분이 퍼플렉서티(perplexity)나 KL 대신 실제 작업에 대한 자체 양자화(quants)를 확인했다면, 동일한 패턴(같은 점수, 더 긴 사고 과정)을 발견하는지 알고 싶습니다.

제출자: /u/FeydRowan [링크] [댓글]