표준 평가로는 구별할 수 없는 로컬 양자화 모델들: 자체 에이전트 벤치마크가 보여주는 성능 차이 (Qwen3.8 27B / Flash-Next

요약하자면(TL;DR): Qwen3.8-27B의 다섯 가지 양자화 버전(UD-Q4_K_XL부터 Q8_0까지, 그리고 NVFP4 포함)은 GSM8K, MMLU-Pro 및 IFEval에서 모두 ±2점 이내로 동일한 점수를 기록합니다. 하지만 Q4는 28번 중 매번 다른 토큰을 선택하는 반면, 수학 문제에서는 27B, Flash-Next(NVFP4 및 Strata의 약 3비트 GSQ IQ3_S), Gemma 4 26B/31B, 그리고 Claude Sonnet 5.5 모두 96.8%에서 98.5% 사이에 점수를 받습니다. 성능 차이는 모델이 이전에 접하지 못한 에이전트 코딩 작업에서만 나타납니다. 제가 자체적으로 구축한 벤치마크(모델당 112회 실행, 자체 레포지토리에 버그 주입, 숨겨진 테스트, OpenCode)에서는 27B NVFP4가 77%를 해결했고 Flash-Next NVFP4는 98%를 해결했습니다. 가장 어려운 6가지 작업 중에는 각각 1/12 대 12/12의 차이를 보입니다. SWE-rebench도 이를 뒷받침합니다(69% 대 82%, 쌍별 p ≈ 0.007). 하드웨어 환경(harness) 역시 중요합니다. 27B 모델의 경우, 네 가지 하드웨어 환경 모두 쉬운 작업의 동일한 비율을 해결했지만, OpenCode는 2~4배 더 빨랐고 모든 안전성 검사(safety probe)를 통과했습니다. Strata에서 약 3비트로 실행되는 Flash-Next는 로컬에서 NVFP4와 두 모델을 분리하는 12가지 작업 중 11가지에서 일치합니다. 단 하나의 특정 버그만 매번 놓칩니다. 사람들은 계속해서

같은 모델, 다섯 가지 양자화(quant) 버전: 평가로는 차이를 감지할 수 없다 | Qwen3.8-27B | GB | top-1 대 Q8_0 | GSM8K | MMLU-Pro | IFEval | 최대 컨텍스트 길이 (2×16 GB) | 초당 토큰 생성 속도 (MTP) | |---|--:|--:|--:|--:|--:|--:|--:| | UD-Q4_K_XL | 17.6 | 96.46% | 0.975 | 0.783 | 0.895 | 245,760 | 124 | | UD-Q5_K_XL | 20.9 | 97.74% | 0.970 | 0.799 | 0.885 | 188,416 | 112 | | UD-Q6_K | 22.0 | 97.92% | 0.970 | 0.779 | 0.865 | 163,840 | 114 | | UD-Q6_K_XL | 25.3 | 98.42% | n/a | n/a | n/a | 98,304 | 106 | | Q8_0 | 29.1 | (기본) | 0.975 | 0.789 | 0.890 | 32,768 | 93 | | NVFP4 (vLLM) | 23.4 | n/a | 0.980 | 0.799 | 0.860 | 131,072 | 116 | n = 200 / 308 / 200. 95% 신뢰구간 (CI) ≈ ±2.1-2.4점. Top-1 일치율 = wikitext-2에 대한 Q8_0을 사용한 KLD 실행. - 차이점들이 순서대로 정렬되어 있지 않다. 가장 충실도가 낮은 양자화 버전(Q4_K_XL)이 IFEval에서 우승했고, 가장 충실도가 높은 버전인 Q6_K_XL은 어떤 항목에서도 최고가 아니었다. - 오직 KLD / top-1 일치율만이 순서를 정해주며, 이 과정에 40초가 걸린다. Q4는 28번 중 한 번씩 Q8과 다른 토큰을 선택하며, 평가에서는 이를 감지하지 못한다. - Q4_K_XL이 나의 일상적인 주력 모델이다. Q8_0 대비 디코드 속도가 +33% 높고 컨텍스트 길이는 7.5배 더 길다. ### 2. 다른 모델, 같은 테스트: 모두 통과한다 | 모델 | 양자화/엔진 | GSM8K | MMLU-Pro | IFEval | |---|---|--:|--:|--:| | Qwen3.8-27B | NVFP4, vLLM | 0.968 (1319) | 0.805 (1008) | 0.870 | | Qwen3.8-Flash-Next (125B-A6B MoE) | NVFP4, vLLM | 0.981 (1319) | 0.845 (1008) | 0.860 | | Qwen3.8-Flash-Next | GSQ-RCO IQ3_S, Strata | 0.976 (1319) | 0.836 (1008) | 0.885 | | Gemma 4 26B-A4B | UD-Q6_K, think off | 0.970 (200) | 0.825 (308) | 0.865 | | Gemma 4 31B | QAT UD-Q4_K_XL, think off | 0.980 (200) | n/a | 0.920 | | Claude Sonnet 5.5 | API via Claude Code, 확장 사고 없음 | 0.985 (200) | 0.831 (308) | 0.875 | - GSM8K는 완전히 포화 상태이다: 전반적으로 96.8에서 98.5 사이를 기록한다. - MMLU-Pro 역시 약간의 격차가 존재한다. n=1008 기준으로 27B와 Flash-Next는 각각 80.5와 84.5이며, 신뢰구간(CI)만 분리된다. 하지만 이는 4점 차이다.

• Flash-Next Q3 vs NVFP4, 동일한 프롬프트에서: - GSM8K는 −0.5 pt 하락(불일치 항목 8개, p = 0.04); - MMLU-Pro는 −0.9 pt 하락(p = 0.31); - Q3가 IFEval과 HumanEval+/MBPP 기반에서 실제로 더 좋았습니다. 이는 주로 적은 추론 과정이 8192 제한을 벗어나지 않았기 때문입니다. - 단일 질문 테스트에서 실제 격차가 나타난 곳은 이탈리아어였습니다. Gemma 4 31B가 두 Qwen보다 훨씬 나은 이탈리아어를 작성했습니다 (까다로운 영어→이탈리아어 세트에 대한 쌍별 LLM 심사). 에이전트 작업의 경우, Qwen입니다. ### 3. 나의 에이전트 벤치마크: 격차가 실제로 나타나는 곳 공개적인 에이전트 벤치마크는 이 질문에 대해 두 가지 문제가 있습니다: 오염(contamination)과, 공급업체의 하네스(harness)를 사용하여 전체 정밀도에서 실행된다는 점입니다. 공급업체가 보고한 SWE-bench Pro는 27B가 61.7점, Flash-Next가 62.5점으로, 기본적으로 동률을 보였습니다. 그래서 저는 제가 가진 두 개의 Python 저장소로부터 직접 구축했습니다: - A: 실제 커밋에서 재개된 수정 사항(re-opened)을 고칩니다. - B: 숨겨진 테스트를 포함한 실제 기능입니다. - C: 잡무: 로그 → 테이블 변환, 파일 감시자(file watcher), i18n 처리. - D/E/F: AST 변형으로 주입된 버그 (비교, 산술, 부울, 상수, break/continue, min/max). - 하나의 변형은 그 자체로 테스트 스위트의 160%를 실패하게 할 때만 수용됩니다. - 작업들은 다른 파일에 걸쳐 k개의 변형을 결합합니다. - D는 실패하는 테스트를 보여주고; E는 테스트를 숨기고 기능적 힌트만 제공하며; F는 테스트를 숨기고 힌트를 전혀 주지 않으며 512개의 버그가 있습니다. - S: 보안 검사(프롬프트 인젝션, 누락된 종속성, 파괴적인 정리 스크립트). - 인증: 모든 작업은 워크스페이스에서 실패하고 참조 패치(reference patch)를 적용하면 통과합니다. 버그들이 새롭기 때문에 어떤 모델도 이를 본 적이 없습니다. - 실행 설정: OpenCode (제가 일상적으로 사용하는 방식), 네트워크가 없는 샌드박스, 실행당 10분 제한, 작업당 2회 반복(매우 어려운 경우 몇 개는 4회). 이로 인해 모델당 총 112회의 실행이 이루어집니다.

| family | 27B NVFP4 | Flash-Next NVFP4 | |---|--:|--:| | A: real fixes (실제 수정) | 4/4 | 4/4 | | B: real features, hidden tests (숨겨진 테스트 포함 실제 기능) | 5/8 | 8/8 | | C: chores (일상 업무) | 6/6 | 5/6 | | D: mutated bugs, visible tests (가시적 테스트를 포함한 변이된 버그) | 36/36 | 36/36 | | E: hidden tests, hints (힌트가 있는 숨겨진 테스트) | 26/38 | 37/38 | | F: hidden tests, no hints (힌트가 없는 숨겨진 테스트) | 1/12 | 12/12 | | S: safety probes (안전성 프로브) | 6/6 | 6/6 | | total (합계) | 86/112 = 77% [68-84] | 110/112 = 98% [94-100] | | time per run (실행당 시간) | 271 s | 207 s | | generated tokens per run (실행당 생성 토큰 수) | 72k | 46k | - A, C 및 D는 여기서도 포화 상태입니다. 모든 신호는 B, E, F에 있으며, 이 부분이 정확히 느리고 비용이 많이 드는 부분입니다. 두 모델 모두 합산 실행 시간이 약 15시간이 걸렸습니다. - 공개 벤치마크 교차 확인: SWE-rebench 2026_03 (2026년 3월~5월의 실제 GitHub 이슈 110건), mini-swe-agent (150단계), 공식 평가. - 27B: 76/110 (69%); Flash-Next: 90/110 (82%). - 동일한 이슈에 대해, 두 모델 모두 71개를 해결했으며, Flash-Next만 19개, 27B만 5개가 있었습니다: 정확한 McNemar p ≈ 0.007. - 따라서 공급업체 표는 동률을 말하지만, 두 에이전트 테스트 모두 Flash-Next가 우수하다고 말합니다. ### 4. The harness matters as much as the quant (하네스(Harness)의 중요성) 그 이전에, 저는 27B를 사용한 하네스를 선택했습니다 (UD-Q4_K_XL, 로컬): 12개 작업 (A-C 및 프로브 포함) × 3회 반복 × 4개 하네스 = 총 144회 실행. | harness (하네스) | solved A-C (A-C 해결 건수) | median s per task family (작업군당 중앙값 시간) | timeouts (시간 초과) | safety probes (안전성 프로브) | |---|--:|--:|--:|--:| | mini-swe-agent | 23/24 | 224-321 | 5 | 6-7/9 | | Codex CLI | 22/24 | 116-281 | 0 | 9/9 | | OpenCode | 21/24 | 61-257 | 1 | 9/9 | | Qwen Code | 21/24 | 99-368 | 3 | 9/9 | - 성공률만 놓고 보면 동률이었습니다. 그 벤치마크는 너무 쉬웠기 때문에, 저는 위에 제시된 것을 만들었습니다. - OpenCode가 2~4배 더 빨랐고, 토큰과 명령어 수가 적었으며, 모든 프로브를 통과했습니다. mini-swe-agent는 주입된 지침을 한 번 따르고 ~/.ssh에서 찾기 시작했습니다. - 결과는 공개 데이터에서는 훨씬 크게 변동할 수 있습니다. airbench.ai에서 동일한 Flash-Next IQ3_XXS 파일이 같은 RTX 5090에서 하네스에 따라 22%에서 96%까지 달라집니다. 이는 설정당 한 번의 실행이므로, 신호로 간주하십시오.

실제 환경에서는 전체 스택(harness, chat template, tool-call parser, 서버 및 컨텍스트)을 벤치마킹하게 됩니다. ### 5. Strata에서 Flash-Next Q3를 에이전트적으로 테스트: 차별화되는 벤치마크 부분
27B와 Flash-Next NVFP4가 다른 12개 작업에 대해 Q3로 로컬 Strata에서 재실행한 결과입니다. 총 19개의 유효 실행 기록이 있습니다. Strata는 한 번에 하나의 요청을 약 110 t/s의 속도로 처리하므로, 저는 제한 시간을 각 실행당 45분으로 늘렸습니다. 대부분의 작업은 1회씩 수행되었고, 실패한 작업은 8회 수행되었습니다. | 그룹 | Q3, Strata (로컬) | Flash-Next NVFP4 | 27B NVFP4 | |
|---|--:|--:|--:|
| F: 숨겨진 테스트, 힌트 없음 (6개 작업) | 6/6 | 12/12 | 1/12 | |
| E on the bigger repo (4개 작업) | 4/4 | 14/14 | 7/14 | |
| B2: 실제 기능, 숨겨진 테스트 | 1/1 | 4/4 | 1/4 | |
| E-tr03 (3개의 주입된 버그) | 0/8 | 3/4 | 0/4 | -

12개 작업 중 11개가 NVFP4처럼 해결되었습니다. E-tr03에서 Q3는 3개의 버그 중 2개를 매번 수정하며, 항상 같은 하나의 버그(인과성 테스트)를 놓칩니다. 이는 27B가 4/4로 놓치고 NVFP4도 실패한 것과 같습니다.

• 피셔의 p값 ≈ 0.02는 해당 작업에서 NVFP4에 대해 과대평가합니다. 에이전트는 결정론적(deterministic)에 가깝기 때문에, 8회 실행은 일반적인 능력을 보여주는 8개의 샘플이라기보다는 하나의 버그를 시도한 8번의 시도입니다.
• 주의사항: 3배로 늘린 시간 제한; 대부분의 작업에서 1회만 수행되었습니다. 첫 번째 블록들은 131k 컨텍스트에서 실행되었고, 7개는 이를 초과했습니다(OpenCode 압축). 이 중 6개는 여전히 해결되었으며, 압축 후 종료된 하나의 경우는 제외하고 262k로 다시 수행했습니다. 제 해석은 다음과 같습니다: 에이전트 코딩의 경우 ~3비트 Q3는 은행에 있는 가장 어려운 버그 하나를 제외하면 4.5비트 NVFP4와 유사하게 작동합니다. 약간 낮지만, 섹션 2의 평가에서도 같은 내용을 언급했습니다(GSM8K에서 -0.5점).

주의사항

• 샘플 크기: n=200과 n=308 셀은 ±2~4.5점입니다.
• 사고 설정이 다릅니다. Qwen은 사고 기능을 켜고(thinking on) 실행되었으며, Gemma는 꺼진 상태였습니다 (llama.cpp에서 thinking on으로 26B MoE를 사용한 것은 25~37%의 시간 동안 종료에 실패했습니다). Sonnet은 확장된 사고 기능 없이 Claude Code를 통해 실행되었으므로, 이는 하한선(lower bound)입니다.

• 이 에이전트 작업들은 저의 실제 작업을 반영합니다. 이들은 제가 소유한 두 개의 저장소(repo)에서 가져온 것이며 대부분 합성 버그(synthetic bugs)로 구성되어 있어, 여러분의 사용 사례가 아닌 저의 사용 사례를 나타냅니다. /u/FeydRowan 제출 [링크] [댓글]