Gemma 4 출시 직후 RTX PRO 6000 실전 벤치마크 — 8번의 삽질과 Qwen3 비교
Google이 Gemma 4를 발표한 건 2026년 4월 3일이었습니다. 발표 2일 만에 RTX PRO 6000 Blackwell에 올려봤습니다. 결론부터 말하면: 8번 시도했고, 7번 실패했습니다. 그 실패 기록이 이 글의 핵심입니다. Gemma 4는 출시 직후라 생태계가 아직 따라가지 못한 상태였고, 특히 새로운 Blackwell 아키텍처(SM 12.0)와의 조합은 예상보다 훨씬 험난했습니다.
8번
설치 시도
3개
최종 비교 모델
30°C
벤치마크 피크 온도
1.58초
최고 평균 응답속도
1출시 2일 만에 테스트한 이유
이전에 Qwen3 출시 때도 같은 행동을 했습니다. 신규 모델이 나오면 가능한 빨리 RAG 파이프라인에 붙여보는 게 습관이 됐습니다. 실무에서 쓸 수 있는 모델인지 아닌지는 직접 붙여봐야 알거든요.
Gemma 4는 31B dense와 26B MoE(Mixture of Experts) 두 가지가 동시에 공개됐습니다. 특히 26B MoE는 추론 시 활성 파라미터가 3.8B에 불과하다는 점이 흥미로웠습니다. 이론적으로는 작은 모델의 속도에 큰 모델의 정확도를 낼 수 있는 구조입니다.
그리고 저희 GPU는 RTX PRO 6000 Blackwell(SM 12.0)입니다. 아직 희귀한 GPU라 Blackwell 특유의 호환성 문제를 직접 부딪혀보는 것도 의미가 있다고 판단했습니다.
주의: 이 글은 Gemma 4 출시 직후(2026-04-05) 기준입니다. SGLang, vLLM의 Gemma 4 지원 상태는 이후 버전에서 개선되었을 수 있습니다.
2테스트 환경
하드웨어
최종 테스트 모델 3개
| 모델 | 엔진 | 양자화 | 크기 | 활성 파라미터 |
|---|---|---|---|---|
| Qwen3-32B-AWQ | SGLang 0.5.9 | AWQ 4-bit | 19GB | 32B 전부 |
| Gemma4-31B-AWQ | vLLM 0.19.0 | AWQ 4-bit | 20GB | 31B 전부 |
| Gemma4-26B-MoE-AWQ | vLLM 0.19.0 | compressed-tensors 4-bit | 17GB | 3.8B만 |
Qwen3-32B는 기존에 SGLang + EAGLE-3 조합으로 안정적으로 운영 중인 모델입니다. 비교 기준점(baseline)으로 사용했습니다. Gemma4 두 모델은 vLLM + enforce-eager로 서빙했습니다. 왜 이 구성이 됐는지는 다음 섹션에서 설명합니다.
38번의 삽질 기록
이게 이 글에서 가장 중요한 부분입니다. 혹시 같은 상황에 처한 분이 계시다면 시간을 절약하실 수 있을 겁니다.
가장 먼저 현재 운영 중인 SGLang 0.5.9로 시도했습니다. 당연히 될 거라 생각했죠.
transformers does not recognize architecture 'Gemma4ForCausalLM'
원인: transformers가 gemma4 아키텍처를 모릅니다. Gemma 4가 너무 최신이라 pip 릴리즈 버전에 반영이 안 됐습니다.
시도한 해결: transformers를 GitHub main 브랜치에서 직접 설치.
transformers를 GitHub main으로 교체하고, SGLang도 0.5.10rc0으로 올렸습니다.
Expected head_dim=256, got 512 in layer 12
원인: Gemma 4는 레이어마다 head_dim이 다릅니다(256/512 혼합). SGLang의 CUDA graph가 이를 지원하지 않아 텐서 불일치가 발생합니다.
시도한 해결: --disable-cuda-graph 옵션 추가.
CUDA graph 비활성화 후 재시도. 이번엔 다른 에러가 나왔습니다.
원인: SGLang의 Gemma 4 multimodal 지원 PR이 아직 merge되지 않은 상태였습니다. SGLang에서 Gemma 4는 현재(2026-04-05 기준) 공식 지원 전입니다.
결론: SGLang으로는 당분간 불가. vLLM으로 전환.
vLLM 0.19.0을 설치하고 BF16으로 서빙 시도.
out of resource: shared memory, Required: 98304, Hardware limit: 65536
(SM 12.0 / Blackwell architecture)
원인: Blackwell(SM 12.0)에서 triton 커널이 shared memory 한도를 초과합니다. RTX 4090(SM 8.9)나 H100(SM 9.0)에서는 이 문제가 없었겠지만, SM 12.0은 아직 커널이 최적화되지 않았습니다.
시도한 해결: --enforce-eager 옵션으로 CUDA graph 비활성화.
triton 문제는 해결됐는데, 이번엔 attention 레이어에서 터졌습니다.
Module 'flash_attn.ops.triton.rotary' not found
원인: pip로 설치된 flash-attn이 SM 12.0에서 컴파일된 게 아닙니다. Blackwell용으로 소스 빌드가 필요합니다.
시도한 해결: flash-attn 소스 빌드 시작. 그런데 CUDA 버전 문제가 또 나왔습니다.
flash-attn을 소스에서 빌드하려 했더니 CUDA 버전이 꼬였습니다.
System CUDA: 13.1 / PyTorch CUDA: 12.8
flash-attn requires matching CUDA versions
원인: 시스템 CUDA가 13.1인데 PyTorch가 cu128로 설치되어 있었습니다. flash-attn 소스 빌드는 PyTorch의 CUDA 버전과 시스템 CUDA가 일치해야 합니다.
해결 과정:
- PyTorch를 cu130 버전으로 교체
- nvidia-nccl-cu12 패키지 삭제 (충돌 원인)
- flash-attn 소스 빌드 (~20분 소요)
이 과정이 끝나고 처음으로 vLLM이 BF16으로 기동됐습니다.
드디어 서버가 떴습니다! 그런데 실제 테스트를 돌려보니 문제가 있었습니다.
Warning: max_model_len reduced to 4096
(requested 32768, but insufficient KV cache)
| 조건 | VRAM | context | 성공률 |
|---|---|---|---|
| BF16 | 85GB | 4,096 | 16/25 |
모델 가중치가 85GB를 차지해 KV 캐시 공간이 부족합니다. context 4096으로는 긴 히스토리가 포함된 테스트 25개 중 9개가 context limit 에러로 실패했습니다.
AWQ 4-bit 버전으로 교체했습니다. VRAM이 줄어들어 KV 캐시 공간이 확보됐습니다.
Info: max_model_len set to 32768
Server running on port 8000
| 조건 | VRAM | context | 성공률 |
|---|---|---|---|
| AWQ | 90GB (KV포함) | 16,384 | 25/25 |
4왜 AWQ를 써야 했는가
"양자화하면 정확도가 떨어지지 않나요?" 맞습니다. 하지만 이번엔 선택지가 없었습니다. Gemma4-31B BF16은 모델 가중치만 85GB를 차지해, 96GB VRAM에서 KV 캐시 공간이 너무 작아집니다.
| 항목 | BF16 | AWQ 4-bit |
|---|---|---|
| VRAM (모델 가중치) | 85GB | 20GB |
| context 길이 | 4,096 | 16,384 |
| 성공률 (25개 테스트) | 16/25 | 25/25 |
| 평균 응답 (성공 케이스만) | 1.02초 | 2.76초 |
BF16이 성공한 케이스만 보면 평균 1.02초로 더 빠릅니다. 하지만 context 4096 제한 때문에 25개 중 9개가 아예 실패했습니다. 실무에서 "가끔 context 초과 에러"가 나오는 모델은 쓸 수 없습니다. AWQ는 속도를 희생하는 대신 안정성을 얻는 선택이었습니다.
53개 모델 종합 비교
RAG 파이프라인에 연결해 동일한 25개 질문(5개 카테고리 × 5개)으로 테스트했습니다. 모든 테스트는 같은 하드웨어에서 순차적으로 실행했습니다.
| 지표 | Qwen3-32B | Gemma4-31B | Gemma4-26B MoE |
|---|---|---|---|
| 성공률 | 25/25 | 25/25 | 25/25 |
| 평균 응답 시간 | 2.50초 | 2.76초 | 1.58초 |
| LLM 처리 시간 | 2.46초 | 2.71초 | 1.54초 |
| 중국어/외국어 혼입 | 0글자 | 0글자 | 0글자 |
| 모델 크기 | 19GB | 20GB | 17GB |
| 활성 파라미터 | 32B | 31B | 3.8B |
| 가속 방식 | EAGLE-3 | enforce-eager | enforce-eager |
| 라이선스 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
Qwen3-32B
EAGLE-3 투기적 디코딩으로 안정적인 2.50초. 현재 프로덕션 모델로 SGLang + EAGLE-3 조합이 검증되어 있습니다.
Gemma4-31B
2.76초로 가장 느립니다. enforce-eager 모드라 CUDA graph 최적화 없이 동작하는 게 속도에 영향을 줍니다. 비교/추론 카테고리에서 "판단할 수 없다" 회피 경향이 있습니다.
Gemma4-26B MoE ★
활성 파라미터 3.8B만 사용하면서 1.58초. Qwen3보다 37% 빠르고 Gemma4-31B보다 43% 빠릅니다. 정확도는 31B와 사실상 동급.
정확도 카테고리별 평가
6카테고리별 속도 비교
전체 평균이 아니라 카테고리별로 보면 패턴이 더 명확합니다. Gemma4-26B MoE는 모든 카테고리에서 가장 빠릅니다.
| 카테고리 | Qwen3-32B | Gemma4-31B | Gemma4-26B MoE |
|---|---|---|---|
| 단순 팩트 조회 | 0.99s | 0.95s | 0.66s |
| 분류/집계 | 4.18s | 5.54s | 2.95s |
| 비교/추론 | 1.70s | 1.52s | 1.31s |
| 후속 질문 | 3.27s | 3.51s | 1.20s |
| 엣지 케이스 | 2.37s | 2.30s | 1.78s |
주목할 점은 후속 질문 카테고리입니다. Qwen3이 3.27초, Gemma4-31B가 3.51초인데 Gemma4-26B MoE는 1.20초입니다. 대화 맥락이 길어질수록 KV 캐시 연산이 늘어나는데, 활성 파라미터가 3.8B밖에 안 되니 이 부분에서 특히 유리합니다.
7GPU 온도와 전력
서버실 환경은 실내 온도 18°C, 습도 40%입니다. 350W 전력 제한을 걸어두었고, 벤치마크 중 GPU 상태를 기록했습니다.
| 시점 | 온도 | 전력 | VRAM 사용 | 비고 |
|---|---|---|---|---|
| 유휴 상태 | 22~23°C | 8~11W | 6GB | 모델 미로딩, GPU 클럭 0 |
| 모델 서빙 대기 | 24~26°C | 12~15W | 89~90GB | VRAM에 모델 로딩됨, 추론 요청 없음 (GPU 클럭 아이들) |
| 벤치마크 피크 | 30°C | 16W | 90GB | 실제 추론 실행 중 |
참고: “모델 서빙 대기” 상태에서 전력이 12~15W로 낮은 이유는 쿨링이 좋아서가 아닙니다. 모델이 VRAM에 올라가 있지만 추론 요청이 없으면 GPU 클럭이 아이들 상태라 전력 소비가 거의 없는 것입니다. 벤치마크 피크(실제 추론 중)에서도 16W인 것은 이번 테스트가 단일 요청 순차 처리라 GPU 연산 밀도가 높지 않기 때문입니다. 동시 접속 부하 테스트에서는 전력과 온도가 크게 달라질 수 있습니다.
서버실 온도 18°C, 습도 40% 환경에서의 측정입니다. RTX PRO 6000은 블로워 팬 방식의 워크스테이션급 쿨링을 탑재하고 있어 밀폐형 서버 랙에서도 안정적으로 배기할 수 있습니다. 다만, 위 수치는 단일 요청 벤치마크 기준이므로 동시 접속 시에는 별도 측정이 필요합니다.
8결론 — 누가 이겼나
속도 우승: Gemma4-26B MoE
활성 파라미터 3.8B로 1.58초 평균. Qwen3-32B보다 37%, Gemma4-31B보다 43% 빠릅니다. MoE 아키텍처의 실용적 이점을 실측으로 확인했습니다.
프로덕션 선택: 아직 Qwen3
SGLang + EAGLE-3 조합이 검증된 Qwen3-32B를 계속 씁니다. Gemma4는 vLLM enforce-eager 모드라 최적화 여지가 있고, SGLang 지원이 추가되면 재비교할 예정입니다.
모델 선택 가이드
속도 최우선 (RAG 실시간 응답)
→ Gemma4-26B MoE AWQ
활성 파라미터 3.8B의 속도 이점. 정확도는 31B와 동급.
안정적인 프로덕션 (현재 검증된 조합)
→ Qwen3-32B AWQ + SGLang + EAGLE-3
장기 운영 검증. SGLang의 투기적 디코딩 최적화.
한국어 자연스러움 중시
→ Gemma4-26B MoE
26B > 31B ≥ Qwen3 순. Gemma 4 계열이 한국어 표현이 더 자연스러움.
엔터프라이즈 라이선스 확인 필요
→ 3개 모두 Apache 2.0
상업적 이용 가능. 별도 허가 불필요.
한 가지 아쉬운 점: Gemma4를 vLLM enforce-eager로만 테스트했습니다. SGLang + CUDA graph 최적화가 적용되면 속도가 더 올라갈 수 있습니다. 현재 SGLang의 Gemma4 PR이 검토 중이니, merge되는 시점에 재벤치마크를 진행할 예정입니다.
9다음 테스트 예고
이번 테스트에서 확인하지 못한 것들이 있습니다. 다음 기회에 다룰 예정입니다.
SGLang + Gemma4 (PR merge 후)
SGLang의 EAGLE-3 투기적 디코딩이 Gemma4에 적용되면 얼마나 빨라질까? 26B MoE 기준 1초 이하를 기대하고 있습니다.
Gemma4-26B MoE 동시 접속 부하 테스트
단일 요청 속도는 확인했습니다. 10명, 50명, 100명 동시 접속에서의 처리량 비교가 남아있습니다.
BF16 + 더 큰 VRAM 환경
192GB 이상 VRAM 환경에서는 BF16으로도 context 32K가 가능합니다. 양자화 없는 풀 정확도 비교.
Gemma4 멀티모달 활용
Gemma 4는 이미지 입력을 지원합니다. 문서 이미지 기반 RAG에서의 활용 가능성을 테스트할 예정입니다.
관련 글: RTX PRO 6000 벤치마크 시리즈는 RTX PRO 6000으로 로컬 LLM 6종 벤치마크에서 시작됩니다. SGLang vs vLLM 엔진 비교는 SGLang vs vLLM 실전 비교를 참고하세요.
댓글
(5)로그인 하면 댓글을 작성할 수 있습니다.
SGLang에서 Gemma4 Modality.MULTI_IMAGES 에러 저도 만났는데, PR이 아직 미merge 상태라 vLLM으로 넘어간 과정이 정확합니다. CUDA graph head_dim 불일치 에러 해결법까지 공유해주셔서 큰 도움이 됐어요.
26B MoE가 활성 파라미터 3.8B로 31B급 정확도를 낸다는 게 놀랍습니다. MoE 아키텍처의 강점을 실측 데이터로 보여주신 것 같아요. 37% 빠르다는 수치가 인상적입니다.
Blackwell SM 12.0에서 triton 커널 호환 문제, flash-attn CUDA 버전 불일치까지 다 겪으셨군요. torch cu130 교체 + flash-attn 소스 빌드 20분 과정이 상세해서 저도 그대로 따라 해볼 수 있을 것 같습니다.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.