Qwen3.6-35B-A3B 도구 호출 (Tool Calling) 벤치마크: ByteShape vs. Unsloth GGUF, KV 캐시

이전에 몇 가지 소규모 성능 벤치마크를 게시한 적이 있지만, 이번에는 질적인 측면에 흥미가 생겼습니다. u/Substantial_Step_351 님이 며칠 전 왜 모델들이 도구 호출 (tool calling) 성능으로 벤치마크되지 않는지에 대해 게시글을 올렸고, u/complexminded 님은 댓글에서 SeraphimSerapis의 tool-eval-bench 유틸리티를 언급했습니다. 이를 통해 제가 궁금해했지만 명확한 답변을 보지 못했던 몇 가지 질문들을 벤치마크해보고 싶어졌습니다: ByteShape의 Qwen3.6-35B-A3B 양자화 (quants) 모델들이 자신들의 블로그 포스트에서 주장하는 만큼 성능이 좋을까? 그들의 벤치마크에 따르면, 약 4bpw 양자화 모델이 양자화되지 않은 모델 점수의 99% 이상을 유지하며, Unsloth, AesSedai, bartowski와 같은 다른 양자화 모델들과 대등하거나 이를 능가하면서도 더 빠르고 보통 크기도 더 작다고 합니다. KV 캐시 양자화 (KV cache quantization)가 실제 성능에 어떤 영향을 미칠까? q8_0은 공짜 점심 (free lunch)일까? q4_0은 얼마나 더 나쁠까? 짧은 프롬프트 대신 긴 문맥 (long context) 설정을 살펴보면 결과가 달라질까? 요약 (TL;DR): ByteShape와 Unsloth 사이의 명확한 승자는 없으며; q8_0은 공짜 점심이지만, q4_0은 성능이 더 나쁩니다; 긴 문맥은 모든 시나리오에서 도구 호출 (tool calling) 성능을 현저히 저하시킵니다. 실험 재료로, 저는 각 32GB VRAM을 갖춘 V100 GPU 클러스터에 일시적으로 접근할 수 있었기에, llama.cpp와 tool-eval-bench를 사용하여 실험을 진행했습니다. 먼저, IQ 및 Q 타입 양자화를 모두 포함하여 비교할 다음의 Qwen3.6-35B-A3B 양자화 모델들을 선택했습니다: ByteShape IQ3_S-3.48bpw (일명 GPU-3, 15.1 GB), ByteShape가 16GB VRAM용으로 권장하는 모델 (간신히 들어갑니다), ByteShape IQ4_XS-4.15bpw (일명 GPU-5, 18.0 GB), ByteShape가 24GB VRAM용으로 권장하는 모델, ByteShape Q4_K_S-4.22bpw (일명...

CPU-5 (18.3 GB), 제가 6GB VRAM 노트북에서 사용하는 모델, 부분적으로 CPU 사용, Unsloth UD-IQ3_XXS (13.2 GB), 매우 압축된 IQ 양자화 (quant), 16GB VRAM에 적합하며 일부 벤치마크에서 체급 이상의 성능을 보여줌, Unsloth UD-Q3_K_XL (16.8 GB), ByteShape CPU-5와 크기가 유사한 Q 양자화 (quant), Unsloth UD-IQ4_XS (17.7 GB), ByteShape GPU-5와 크기가 유사한 IQ 양자화 (quant), Unsloth UD-Q4_K_M (22.1 GB), 많은 Unsloth 모델의 기본 양자화 크기, Unsloth UD-Q6_K (29.3 GB), 32GB VRAM에 넣을 수 있는 가장 큰 모델

저는 주로 ByteShape와 나머지 모델들을 비교하는 데 관심이 있고, Unsloth가 많은 이들에게 신뢰받는 일반적인 선택지인 것 같아 다른 곳의 양자화 모델들은 테스트하지 않기로 결정했습니다. KV 캐시 양자화 (KV cache quantization)의 효과를 측정하기 위해, 테스트할 세 가지 구성으로 기본 f16, q8_0/q8_0, 그리고 q4_0/q4_0를 결정했습니다. 실행 횟수를 제한하기 위해 이번에는 비대칭 KV 캐시 양자화 (asymmetric KV cache quants)는 테스트하지 않기로 했습니다. 긴 문맥 (long context) 대 짧은 문맥 (short context) 성능을 측정하기 위해, tool-eval-bench의 --context-pressure 파라미터 (이후 cp로 약칭)를 사용하여 0.0 또는 0.5로 설정했습니다. 0.0은 짧은 문맥 (도구 호출 정의를 포함하는 약 5k 토큰의 시스템 프롬프트)을 의미하며, 0.5는 모델을 혼란스럽게 할 수 있는 122k 토큰의 추가 텍스트가 프롬프트에 포함됨을 의미합니다. 이는 컨텍스트 윈도우 (context window)가 대화 및 도구 호출 이력으로 이미 50% 채워졌을 때 모델이 어떻게 동작하는지를 시뮬레이션합니다. 각 벤치마크 실행은 서로 다른 랜덤 시드 (random seeds)를 사용하여 세 번씩 반복했습니다. 이를 통해 총 (8 GGUFs) x (3 KV quants) x (2 context lengths) x (3 repetitions) = 144회의 실행이 이루어졌습니다. 짧은 문맥 실행은 약 15분밖에 걸리지 않았지만, 긴 문맥 실행은 각각 약 4시간이 소요되었습니다. 따라서 일부 실험적 시도와 실패한 실행을 포함하여 총 소요 시간은 약 300 GPU-시간이었습니다.

소프트웨어 설정
모델을 실행하기 위해 CUDA 지원 기능이 포함된 llama.cpp 버전 9529 (96fbe0039)를 사용했습니다. 도구 사용 (tool use) 벤치마크를 위해서는 tool-eval-bench 2.0.4를 사용했습니다.

llama.cpp 파라미터: -m $GGUF --temperature 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 --presence-penalty 0.0 --repeat-penalty 1.0 -ngl 99 --ubatch-size 2048 --fit-target 256 -ctk $KV_QUANT -ctv $KV_QUANT --port $PORT

tool-eval-bench 파라미터: --base-url $BASE_URL --hardmode --weight-by-difficulty --backend llamacpp --context-size 262144 --context-pressure $CONTEXT_PRESSURE --seed $SEED

저는 출력의 품질에만 관심이 있었고 원시 성능 (raw performance)에는 관심이 없었기 때문에, PP/TG 속도를 최적화하거나 심지어 측정하는 데에도 많은 시간을 할애하지 않았습니다. 같은 이유로 MTP나 다른 추측적 디코딩 (speculative decoding)을 활성화하지 않았습니다. 매우 느린 긴 문맥 (long context) 실행 시의 병목 현상은 주로 PP 속도였으므로, --ubatch-size를 2048로 늘렸으며 이는 약간 도움이 되는 것으로 보였습니다.

점수 측정 지표 (Scoring metric)
제가 살펴본 지표는 tool-eval-bench가 "total points"로 보고하는 값입니다. --hardmode가 활성화된 상태에서, 이 버전의 tool-eval-bench는 84개의 개별 테스트를 수행합니다. 각 테스트는 성공적인 도구 사용 (tool use)에 대해 2점, 부분적으로 정확한 도구 사용에 대해 1점, 실패 시 0점을 부여합니다. 이 경우 이론적 최대치는 84 * 2 = 168점입니다. tool-eval-bench는 전체 점수 (overall score)도 반환하지만, 이는 단순히 total points를 반올림한 백분율이며 반올림 과정에서 정밀도가 손실되므로 저는 대신 가공되지 않은 total points를 선택했습니다. --weight-by-difficulty 옵션이 정확히 무엇을 하는지는 파악할 수 없었습니다. 점수에 아무런 영향을 미치지 않는 것처럼 보였습니다.

GGUF별 결과 (Results by GGUF)
다음은 모델들의 개요, 크기, 전체 점수뿐만 아니라 KV 캐시 양자화 (KV cache quant)별 점수 및 짧은 문맥 (short context) 대 긴 문맥 (long context)별로 분류된 점수입니다. 산점도 (scatterplot) 다이어그램도 참조하십시오.

모델 이름 모델 크기 평균 전체 점수 avg_kv_f16 avg_kv_q8_0 avg_kv_q4_0 avg_cp_0.0 avg_cp_0.5 Unsloth UD-IQ3_XXS 13.2 143.6 142.2 143.2 145.5 150.7 136.6 ByteShape GPU-3 15.1 144.5 147.0 144.5 142.0 149.7 139.3 Unsloth UD-Q3_K_XL 16.8 143.8 145.0 143.7 142.8 147.3 140.3 Unsloth UD-IQ4_XS 17.7 144.8 143.0 146.8 144.5 149.7 139.9 ByteShape GPU-5 18.0 146.8 147.8 147.3 145.3 149.0 144.7 ByteShape CPU-5 18.3 142.2 143.0 141.5 142.0 145.4 138.9 Unsloth UD-Q4_K_M 22.1 144.4 143.0 143.7 146.5 148.3 140.4 Unsloth UD-Q6_K 29.3 145.2 147.7 146.7 141.2 150.7 139.7 전반적으로 가장 좋은 모델은 ByteShape GPU-5이며, 평균 점수를 기준으로 Unsloth UD-Q4_K_M 및 UD-Q6_K와 같은 훨씬 큰 모델들을 능가합니다. 특히 긴 문맥 작업에서 좋은 성능을 보여 두드러집니다. ByteShape CPU-5는 최저 성능을 보였습니다. 모델 크기는 벤치마크 점수와 약한 상관관계만 있는 것으로 보이며, 이는 노이즈가 많은 벤치마크 지표일 수 있습니다. KV 캐시 양자화(KV cache quant) 결과 여기서는 사용된 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 KV 캐시 양자화는 실질적으로 동등합니다. 두 가지의 벤치마크 점수가 매우 가까워 오차 범위 내에 있을 가능성이 높습니다. 하지만, f16이 긴 문맥(cp=0.5) 케이스에서 약간의 우위를 가질 수 있습니다. q4_0 양자화는 다른 것들보다 약 1점 정도 뒤처집니다. 발견 사항 ByteShape와 Unsloth 양자화 중 어느 것이 더 나은지는 명확하지 않습니다. ByteShape는 가장 좋은 성능(GPU-5)과 가장 낮은 성능(CPU-5)을 모두 가진 양자화를 보여주었습니다. f16과 q8_0 KV 캐시 양자화는 실질적으로 동등하므로, q8_0은 공짜 점수(free lunch)로 간주될 수 있습니다. q4_0을 사용하는 것은 놀라울 정도로 작은 영향을 미치지만, 존재합니다. 긴 문맥은 성능에 매우 큰 타격을 주며, cp=0.0과 cp=0.5 케이스 사이에 평균적으로 거의 10점의 격차가 발생했습니다.

ByteShape GPU-5 양자화(quant)는 긴 문맥 압박(long context pressure) 상황에서 다른 방식들보다 더 탄력적인 모습을 보였습니다.

주의 사항: 이 벤치마크는 전적으로 tool-eval-bench 태스크와 결과 채점 방식에 의존합니다. 따라서 실제 도구 사용(tool use) 성능을 대표할 수도 있고, 그렇지 않을 수도 있습니다. 제가 보기에는 저자 또는 tool-eval-bench 측에서 --hardmode를 통해 활성화되는 매우 어려운 과제들을 포함하여, 현실적으로 보이는 도구 호출(tool call) 태스크들을 만들어내는 데 훌륭한 역할을 수행한 것으로 보입니다. 긴 문맥 실행의 경우, 저는 tool-eval-bench의 --context-pressure 설정에 의존했습니다. (제 제한적인 이해로는) 이 설정은 모델을 혼란스럽게 만들 수 있는 현실적인 대화 및 도구 호출 이력으로 문맥(context)을 채우는 역할을 합니다.

벤치마크 점수에는 상당한 변동성과 노이즈가 있었으며, 가장 작은 양자화 모델들(GGUF 파일 및 KV 캐시 모두)이 때때로 가장 큰 모델들을 이기는 놀라운 결과나 유사한 이상 현상들이 포함되었습니다. 각각의 개별 측정값은 걸러서 들어들을 필요가 있습니다. 하지만 저는 집계된 점수들이 적어도 어느 정도는 의미가 있다고 생각합니다. 좋은 벤치마크 수치를 수집하기 위해 최선을 다했지만, 이 벤치마크는 본질적으로 매우 노이즈가 심하며, 저는 벤치마크 실행을 반복할 수 있는 자원이 제한적입니다.

참고: 이 포스트를 작성하는 데 AI는 사용되지 않았으며 모두 직접 작성되었습니다. 다만, 벤치마크 스크립트 작성 및 결과 분석과 플로팅(plotting)에는 일부 AI의 도움(동일한 Qwen3.6-35B-A3B!)을 받았습니다.

제출자: /u/OsmanthusBloom [link] [comments]