모델 선택의 딜레마
보통 Q4가 가장 효율적인 양자화 버전으로 많이 사용된다.
27B가 가장 똑똑하다고 하지만 사실상 Q4 양자화 버전이 초당 16~19토큰밖에 나오질 않는다.
추론이 필요한 경우라면 굉장히 오랜 시간이 걸리기 때문에 실사용에는 어렵다고 판단했다.
최소 초당 30토큰 이상은 나와야 실사용에 문제가 없을 것 같았다.
그러면 여기서 딜레마가 생긴다.
높은 파라미터 모델의 Q3 양자화 버전과 낮은 파라미터 모델의 Q4 양자화 버전 중 뭘 쓰느냐였다.
즉, Qwen3.5 35B-A3B의 Q3 vs Qwen3.5 9B의 Q4 중 뭐가 더 나은지를 비교해보고 싶었다.
VRAM이 16GB밖에 되질 않다보니 큰 모델을 쓰려면 양자화를 깎아야 하고, 작은 모델은 양자화를 널널하게 쓸 수 있지만 파라미터수 자체가 적다.
비슷한 하드웨어를 가진 사람이라면 누구나 한번쯤 고민해봤을 딜레마인 것 같다.
그래서 이번에는 lm-evaluation-harness를 사용해 실제 벤치마크를 돌려보고 직접 비교해보기로 하였다.
테스트 환경
테스트 환경은 아래와 같다.
- GPU: RTX4060Ti 16GB
- 추론 엔진: llama-server (llama.cpp)
- 비교 대상:
- Qwen3.5-35B-A3B UD-IQ3_S (Unsloth Dynamic) — 약 13.6GB
- Qwen3.5-9B Q4_K_M — 약 5.7GB
- 벤치마크 도구: lm-evaluation-harness 0.4.11
- GSM8K — 수학 추론 (1,319문제)
- MMLU-Pro — 지식/이해 (980문제, limit 70)
- IFEval — 지시 따르기 (541문제)
- MATH-500 — 수학 (500문제)
여기서 하나 알고가면 좋을게, MoE(Mixture of Experts) 모델인 35B-A3B는 전체 파라미터는 35B이지만 실제로 한 토큰을 생성할 때 활성화되는 파라미터는 약 3B밖에 안 된다.
그래서 생각보다 추론 속도가 빠르다.
다만 전체 35B의 가중치를 VRAM에 올려야 하다보니 RTX4060Ti 16GB에서는 Q4 양자화가 안 들어간다.
Q3까지 깎아야 간신히 올라가는 수준이다.
반면 9B Dense 모델은 Q4는 물론이고 Q8까지도 넉넉하게 올라간다.
커뮤니티에서는 MoE 모델이 양자화에 더 민감하다는 얘기가 있었다.
그래서 Q3까지 깎으면 성능 손실이 꽤나 클 수도 있겠다 싶었다.
P.S. 약 1주일동안 24/7으로 벤치마크를 돌렸더니 꽤 많은 전력 사용량을 보였다. 요금은 덤.



벤치마크 결과
No-think (추론 비활성화) 모드
추론 모드를 끈 상태에서의 결과는 아래와 같다.
| Benchmark | 35B-A3B Q3 | 9B Q4 | 차이 |
|---|---|---|---|
| GSM8K (수학) | 55.57% | 59.06% | 9B +3.5 |
| MMLU-Pro (지식) | 73.16% | 71.02% | 35B +2.1 |
| IFEval (지시 따르기) | 91.85% | 91.13% | 35B +0.7 |
| MATH-500 (수학) | 7.80% | 6.40% | 35B +1.4 |
생각보다 두 모델의 차이가 거의 없었다. GSM8K에서는 오히려 9B가 3.5%p 더 높게 나왔고, MMLU-Pro에서는 35B가 2%p 정도 앞섰다.
IFEval은 사실상 동일하였다.
추론 모드를 끈 상태에서는 35B Q3이나 9B Q4나 체감할 수 있는 차이가 거의 없었다.
Think (추론 활성화) 모드
여기서 재미있었던 건 Think 모드에서의 결과다.
| Benchmark | 35B-A3B Q3 | 9B Q4 | 차이 |
|---|---|---|---|
| GSM8K (수학) | 70.89% | 68.46% | 35B +2.4 |
| MMLU-Pro (지식) | 58.47% | 50.51% | - |
| IFEval (지시 따르기) | 68.94% | 52.76% | - |
| MATH-500 (수학) | 43.20% | 21.80% | 35B +21.4 |
수학 문제(GSM8K, MATH-500)에서는 35B가 확실히 앞섰다.
특히 MATH-500에서는 43.2% vs 21.8%로 2배 가까운 차이가 났다.
35B의 파라미터 수가 복잡한 수학 추론에서는 확실히 힘을 발휘하는 것 같다.
다만 MMLU-Pro와 IFEval은 Think 모드에서 두 모델 모두 No-think보다 점수가 오히려 떨어졌다.
이건 모델이 멍청해진 게 아니라, 추론 과정에서 생각을 너무 많이 하다가 이미 알고 있던 답을 번복하는 이른바 Overthinking 현상이 발생한 것으로 보인다.
지식 기반 문제에서는 직감이 오히려 맞는 경우가 많은데, 굳이 깊이 생각하면 오답으로 빠지는 것이다.
그렇기에 Think 모드에서 유의미한 비교는 수학 벤치마크(GSM8K, MATH-500)만 해당된다고 보면 될 것 같다.
VRAM 여유와 안정성
35B-A3B를 IQ3_S로 올리면 VRAM 사용량이 약 15.8GB까지 올라간다.
16GB에서 겨우 200MB 남는 수준이다.
컨텍스트를 조금만 늘리거나 parallel을 2로 설정하면 OOM이 터질 수 있어서 꽤나 불안하다.
반면 9B Q4_K_M은 약 5.7GB밖에 안 되어서 10GB 이상이 남는다.
컨텍스트 64K에 parallel 2로 설정해도 넉넉하다. 안정성 면에서는 비교가 안 될 정도로 9B가 편하다.
장시간 서비스를 돌려야 하거나 여러 요청을 동시에 처리해야 하는 경우라면 9B 쪽이 훨씬 현실적인 선택이다.
결론
전체적으로 테스트해보고 내린 결론은 아래와 같다.
- 양자화를 깎아서라도 큰 모델을 쓰는 것이 항상 정답은 아니다.
- No-think 모드에서는 35B Q3이나 9B Q4나 성능 차이가 거의 없다.
- Think 모드에서 수학/추론 작업이 중요하다면 35B-A3B가 확실히 낫다.
- 다만 VRAM 여유, 안정성, 컨텍스트 길이를 생각하면 9B가 압도적으로 편하다.
- 실용적으로는 평소에 9B를 쓰고, 수학/추론이 필요할 때만 35B를 올리는 것이 가장 합리적인 것 같다.
사실 벤치마크를 돌리기 전까지는 당연히 35B가 압도적으로 좋을 거라고 생각했었다.
파라미터수가 4배 가까이 차이나는데 당연하지 않겠는가?
하지만 Q3까지 양자화를 깎으면 그 이점이 생각보다 많이 사라진다.
결국 16GB VRAM에서의 딜레마는 "양자화 품질 vs 파라미터 수"의 트레이드오프인 것이다.
일단 나의 경우에는 35B를 선택하기로 하였다.
MoE 특성 덕분에 활성 파라미터가 3B밖에 안 되어 9B 대비 약 2배 정도 빠른 속도가 나오고, Think 모드에서의 추론 성능도 확실히 더 높았기 때문이다.
무엇보다 빠른 모델을 쓰다가 느린 모델로 내려가니 역체감이 심했다.
벤치마크 점수가 비슷하다 해도 체감 속도의 차이는 꽤나 크다.
게다가 용도에 따라 매번 9B와 35B를 바꿔가며 올리는 것도 현실적으로 귀찮다.
나는 하나의 모델만 올려놓고 쭉 쓸 예정이기 때문에 속도와 추론 성능 모두 우위에 있는 35B를 메인으로 가져가기로 하였다.
같은 하드웨어에서 고민하는 분들에게 이 글이 조금이나마 도움이 되었으면 한다.
'홈서버' 카테고리의 다른 글
| [LLM] 로컬 LLM(Qwen3.5 35B&9B) vs OpenRouter, 비용 면에서 뭐가 더 나을까? (0) | 2026.04.04 |
|---|---|
| [LLM] Qwen3.5 2B, 4B, 9B, 27B, 35B-A3B 구동 후기 (0) | 2026.03.16 |
