Qwen3.6-35B-A3B의 ByteShape 퀀트가 블로그 포스트에서 주장하는 만큼 진짜 좋은가? 벤치마크를 보면 ~4bpw 퀀트가 비양자화 모델 대비 99% 이상의 점수를 유지하면서, Unsloth, AesSedai, bartowski 같은 다른 퀀트들과 비슷하거나 더 나은 성능을 보여주는데 속도는 더 빠르고 용량은 보통 더 작다고 하거든.
KV 캐시 양자화가 실제 성능에 어떤 영향을 미칠까? q8_0은 공짜 점심(성능 저하 없는 이득)일까? q4_0은 얼마나 구릴까?
짧은 프롬프트가 아니라 긴 컨텍스트 설정에서 보면 결과가 달라질까?
TL;DR: ByteShape랑 Unsloth 중에 확실한 승자는 없음. q8_0은 공짜 점심 맞음. 근데 q4_0은 확실히 성능 떨어짐. 긴 컨텍스트는 모든 시나리오에서 툴 콜링 성능을 꽤 많이 깎아먹음.
준비물
V100 GPU 32GB VRAM짜리 클러스터가 잠시 비어서, llama.cpp랑 tool-eval-bench를 써서 실험을 좀 돌려봤어. 먼저 비교할 Qwen3.6-35B-A3B 퀀트들을 IQ랑 Q 타입 섞어서 골랐지.
ByteShape Q4_K_S-4.22bpw (일명 CPU-5, 18.3 GB): 내가 6GB VRAM 노트북에서 CPU 섞어서 쓰는 거
Unsloth UD-IQ3_XXS (13.2 GB): 16GB VRAM에 들어가는 아주 컴팩트한 IQ 퀀트, 가끔 체급 이상의 성능을 보여줌
Unsloth UD-Q3_K_XL (16.8 GB): ByteShape CPU-5랑 비슷한 크기의 Q 퀀트
Unsloth UD-IQ4_XS (17.7 GB): ByteShape GPU-5랑 비슷한 크기의 IQ 퀀트
Unsloth UD-Q4_K_M (22.1 GB): 보통 제일 많이 쓰는 기본 퀀트 사이즈
Unsloth UD-Q6_K (29.3 GB): 32GB VRAM에 간신히 들어가는 제일 큰 놈
다른 퀀트들은 굳이 테스트 안 했어. 어차피 ByteShape랑 나머지 비교가 주 목적이고, Unsloth가 다들 많이 믿고 쓰는 거 같아서.
KV 캐시 양자화 효과를 보려고 f16, q8_0/q8_0, q4_0/q4_0 세 가지 설정으로 테스트했어. 테스트 횟수 줄이려고 비대칭 KV 캐시 퀀트는 이번엔 뺐음.
긴 컨텍스트랑 짧은 컨텍스트 성능을 비교하려고 tool-eval-bench의 --context-pressure 파라미터(이하 cp)를 0.0이랑 0.5로 설정했어. 0.0은 짧은 컨텍스트(툴 정의가 포함된 약 5k 토큰 시스템 프롬프트), 0.5는 모델을 헷갈리게 할 수 있는 122k 토큰의 텍스트가 추가로 들어가는 설정이야. 컨텍스트 창이 이미 대화랑 툴 콜 기록으로 50% 차 있을 때 모델이 어떻게 행동하는지 시뮬레이션하는 거지.
각 벤치마크는 랜덤 시드를 바꿔가며 3번씩 반복했어. 총 (8개 GGUF) x (3개 KV 퀀트) x (2개 컨텍스트 길이) x (3번 반복) = 144번 돌린 셈이지. 짧은 컨텍스트는 15분 정도 걸렸는데, 긴 컨텍스트는 한 번 돌릴 때마다 4시간씩 걸리더라. 실험이랑 실패한 것까지 합쳐서 총 300 GPU-시간 정도 쓴 듯.
소프트웨어 설정
모델 돌리는 데는 CUDA 지원 빌드된 llama.cpp 9529 (96fbe0039) 버전을 썼고, 툴 사용 벤치마크는 tool-eval-bench 2.0.4를 썼어.
PP/TG 속도는 딱히 측정 안 했어. 어차피 순수 성능보다는 결과물 퀄리티가 궁금했던 거라. MTP나 다른 추론 가속 기법도 같은 이유로 안 켰고. 긴 컨텍스트 돌릴 때 병목은 주로 PP 속도였는데, --ubatch-size를 2048로 올리니까 좀 낫더라.
점수 산정 방식
tool-eval-bench에서 나오는 "total points"를 기준으로 봤어. --hardmode를 켜면 84개의 개별 테스트를 수행하는데, 성공하면 2점, 부분 성공은 1점, 실패는 0점이야. 이론상 최대 점수는 84 * 2 = 168점이지. tool-eval-bench가 전체 점수도 퍼센트로 보여주긴 하는데, 반올림 때문에 정밀도가 떨어져서 그냥 raw total points를 썼어. --weight-by-difficulty 옵션은 뭔지 모르겠는데 점수에 별 영향은 없는 거 같더라.
전체적으로 ByteShape GPU-5가 제일 좋아. Unsloth UD-Q4_K_M이나 UD-Q6_K 같은 훨씬 큰 모델들도 평균 점수에서 다 발라버림. 특히 긴 컨텍스트 작업에서 성능이 돋보여. ByteShape CPU-5는 제일 구렸고. 모델 사이즈랑 벤치마크 점수는 상관관계가 거의 없는 거 같은데, 이건 벤치마크 지표 자체가 좀 노이즈가 많다는 뜻일 수도 있어.
KV 캐시 퀀트별 결과
KV 캐시 퀀트별로 묶은 점수야. 전체 점수랑 컨텍스트 길이에 따른 점수도 같이 봐. 막대 그래프도 참고하고.
kv_quant
avg_overall
avg_cp_0.0
avg_cp_0.5
f16
144.8
149.2
140.5
q8_0
144.7
149.2
140.1
q4_0
143.7
148.1
139.3
f16이랑 q8_0은 거의 차이가 없어. 오차 범위 내라고 봐도 될 정도야. 긴 컨텍스트(cp=0.5)에서는 f16이 아주 살짝 나은 정도? q4_0은 다른 것들보다 1점 정도 뒤처짐.
결론
ByteShape랑 Unsloth 중에 뭐가 더 나은지는 잘 모르겠음. ByteShape가 제일 잘하는 놈(GPU-5)이랑 제일 못하는 놈(CPU-5)을 다 가지고 있거든.
f16이랑 q8_0은 거의 똑같으니까 q8_0은 공짜 점심이라고 봐도 됨. q4_0은 성능 저하가 생각보다 작긴 한데, 그래도 있긴 함.
긴 컨텍스트는 성능을 엄청 깎아먹음. cp=0.0이랑 cp=0.5 사이에 평균 10점 정도 차이가 나. 그 와중에 ByteShape GPU-5가 긴 컨텍스트 압박 상황에서 다른 것들보다 훨씬 잘 버텼음.
주의사항
이 벤치마크는 전적으로 tool-eval-bench의 작업 내용이랑 채점 방식에 의존함. 실제 툴 사용 성능을 완벽하게 대변한다고 보긴 어려울 수도 있어. 그래도 tool-eval-bench 만든 사람이 --hardmode까지 써가면서 꽤 현실적인 툴 콜링 테스트를 잘 만들어놨다고 생각함. 긴 컨텍스트 테스트는 tool-eval-bench의 --context-pressure 설정을 썼는데, 내 짧은 지식으로는 모델을 헷갈리게 할 만한 현실적인 대화랑 툴 콜 기록을 컨텍스트에 채워 넣는 방식인 거 같아.
벤치마크 점수에 변동이랑 노이즈가 꽤 있었어. 가끔 제일 작은 퀀트가 제일 큰 놈을 이기는 이상한 결과도 나왔고. 개별 측정값은 그냥 참고만 하고, 전체적인 평균 점수 정도만 의미가 있다고 봐. 최대한 좋은 데이터를 뽑으려고 노력했지만, 벤치마크 자체가 워낙 노이즈가 심하고 반복 테스트할 자원도 한정적이었거든.
참고: 이 글 쓰는 데 AI는 안 썼음. 다 직접 쓴 거임. 벤치마크 스크립트 짜거나 결과 분석하고 그래프 그릴 때는 AI(Qwen3.6-35B-A3B!) 도움을 좀 받긴 했지만.
주요 댓글
r/localllama
벤치마크의 신뢰성과 데이터 노이즈에 대한 의문이 제기되었으며, 사용자들은 각자 선호하는 양자화 방식과 툴 호출 성능에 대한 경험을 공유하고 있습니다.
8
데이터에서 어떤 경향성도 보이지 않는데? 점수가 모델 크기에 의존하지 않는 것 같아. 내 생각엔 이 벤치마크가 이 경우에 적합한 벤치마크가 아닌 것 같음.
-1
예상했던 결과야. 품질은 모델 크기와 선형적으로 상관관계가 있는 게 아니라, 데이터 타입을 얼마나 잘 할당하느냐에 달려 있거든. 모든 벤치마크가 같은 패턴을 보일 거야. 게다가 모델이 완전히 망가진 상태가 아니라면 KLD는 다운스트림 품질과 상관관계가 없어. 그래서 모델이 좋은지 알 수 있는 유일한 방법은 최대한 많이 테스트하고 벤치마크해보는 것뿐이야. 우리가 그런 이유로 그렇게 하려고 노력하는 거고.
-2
맞는 말이야, 경향성을 파악하기 어렵지. 그래도 KV 캐시 양자화에 대한 경향성은 하나 있어. 내 생각엔 이런 종류의 벤치마크 자체가 본질적으로 노이즈가 너무 심해서 신뢰할 만한 수치를 얻으려면 훨씬 더 많은 반복 측정이 필요할 것 같아.
2
난 APEX I-Quality가 좋더라. 예전에 ByteShape랑 Unsloth도 써봤는데 별로였어.
[이미지]
2
표준 편차랑 통계적 검정치를 계산하거나, 전체 데이터 링크를 올려줘.
'긴 컨텍스트 = 성능 저하'라는 것 외에 의미 있는 말을 하기엔 측정값이 부족한 것 같아.
그리고 모델 하나에 GPU 두 개를 써서 Q8로 돌릴 수도 있어.
0
여기 전체 데이터가 있으니 알아서 해석해 봐. 'model' 열 값을 파싱해서 KV 캐시 양자화, 컨텍스트 압박, 시드 값을 찾아야 할 거야. 꽤 직관적일 거야: https://www.hostize.com/s/V9PN0t3dUT (링크는 24시간만 유효해, 미안... 더 좋은 호스팅 서비스를 추천해 주면 다시 공유할게)
1
[이미지]
어쨌든, 정말 잘했어. 이런 부분에 대해 확실한 벤치마크가 있다는 건 정말 고마운 일이야. 개인적으로 내 5090에서 --context-size 262144를 쓰니까 128k에 비해 성능이 급격히 떨어지던데, 깊게 파보진 않았어. 결국 그 문제 때문에 대부분 작업에서 128k로 돌리게 되더라.
0
q4_0 KV 캐시가 꽤 잘 버텨줘서 정말 다행이야. 그게 실제 q4_0 양자화랑 비슷한 건가? 즉, ARM 칩용으로 만들어진 것 같은 거 말이야.
(예전 q4_0_4_4랑 q4_0_4_8 GGUF 양자화는 q4_k_m_l 양자화와 비교해도 눈에 띄는 손실 없이 엄청 빨랐거든. 최신 q4_0 포맷은 그만큼 빠르진 않지만, 여전히 ARM/모바일 칩에서 성능 향상을 가져다주긴 해. KV 캐시가 ARM 최적화 포맷이라고 생각되는 걸 테스트하는 건 본 적이 없어서. 그냥 용어가 겹치는 건가? 즉,
Byteshape 써봤는데, 대부분보다 빠르긴 하지만 툴 호출 오류가 너무 많아. Apex Quality도 마찬가지고. Q5에 비양자화 캐시를 쓰는 게 여전히 유일하게 신뢰할 수 있는 장기(최대 128k 컨텍스트) 방식이고, 그것조차 가끔 생각 블록 안에서 툴 호출을 망가뜨리곤 해.
0
어떤 ByteShape 양자화를 써봤어? 내 테스트에서는 GPU-5가 테스트한 모든 양자화 모델 중 최고였고, CPU-5가 최악이었거든. 비슷하게 18GB 크기인 두 양자화 모델 사이에서도 차이가 꽤 커.
