[V2] vLLM 기반 Gemma 3 4B 모델 서빙 보고서: GPU 메모리 사용, KV Cache, 양자화 필요성 - 100-hours-a-week/6-nemo-ai GitHub Wiki
1. 개요
Google의 Gemma 3 4B 모델은 강력한 성능을 제공하는 대신, vLLM으로 서빙 시 매우 높은 GPU 메모리 사용량을 요구합니다.
특히, 하나의 NVIDIA L4 (24GB) 인스턴스에서 모델 1개만 로드해도 약 21.2GB의 VRAM을 점유하며, 이는 KV Cache 사전 할당과 continuous batching 구조 때문입니다.
이 보고서는 다음 내용을 다룹니다:
- 왜 GPU 메모리 사용량이 높은가?
- KV Cache의 역할과 필요성
- 여러 모델 컨테이너를 동일 인스턴스에서 띄울 수 없는 이유
- 양자화(quantization)의 필요성 및 효과
2. 실제 시스템 사용 예 (nvidia-smi)
Gemma 3 4B 모델을 vLLM으로 로드했을 때의 GPU 메모리 점유율:
| 항목 | 값 |
|---|---|
| GPU | NVIDIA L4 (24GB) |
| 사용량 | 21,190 MiB / 23,034 MiB (약 92%) |
| 실행 중 프로세스 | Python (vllm) |
| GPU-Util | 0% (대기 상태) |
참고: 모델 로딩 직후 대기 상태에서도 21GB 이상 점유
3. GPU 메모리 사용률이 높은 이유
✅ (1) 모델 파라미터
google/gemma-3-4b-it은 float16 기준 약 8~9GB 메모리를 차지- 모델 내부 버퍼와 layernorm 포함 시 10GB 이상까지 가능
✅ (2) KV Cache 사전 할당
- vLLM은 각 디코딩 요청의 attention 정보를 저장하기 위해 KV Cache를 미리 확보
- 예: max_tokens=512, batch_size=16 기준으로 수 GB 이상의 추가 메모리 사용
✅ (3) Continuous Batching 구조
- vLLM은 여러 요청을 빠르게 처리하기 위해 메모리를 넉넉하게 사전 할당
4. 여러 모델 컨테이너를 동일 인스턴스에 띄울 수 없는 이유
| 시나리오 | 결과 |
|---|---|
| Gemma 3 4B × 1개 | ✅ 가능 (약 21.2GB 사용) |
| Gemma 3 4B × 2개 이상 | ❌ 불가능 (OOM 발생 확정) |
| GPU 24GB 기준 | 최대 1개까지만 수용 가능 |
🔥 문제 요약
- 컨테이너를 나눠도 GPU 메모리는 공유됨
gpu_memory_utilization=0.25처럼 설정해도 모델 자체가 커서 초기 로딩 실패
5. 해결 방안: 양자화 (Quantization)
✅ 양자화란?
- float16 → int8 또는 4bit로 모델 파라미터를 줄이는 방식
- 파라미터 크기를 줄여 메모리 점유량 감소, 복수 모델 서빙 가능성 증가
✅ 예상 효과
| precision | 예상 메모리 | 설명 |
|---|---|---|
| float16 | ~9GB | 기본값 (현 상태) |
| 8bit | GPU 2개까지 가능 | |
| 4bit | 이론상 4개까지 가능 (실험 필요) |
6. 결론
| 항목 | 판단 |
|---|---|
| Gemma 3 4B는 L4에서 몇 개까지 가능한가? | 1개 한정 |
| 이유 | 모델 파라미터 + KV Cache + 버퍼로 21GB 이상 소모 |
| 여러 개 실행하고 싶다면? | 양자화 필수 (4bit 권장) |
| 양자화의 장점 | 메모리 절감, 다중 모델 서빙 가능성 확보 |
7. 권장 사항
- 현재 상태에선 Gemma 3 4B 1개만 안정 서빙
- 양자화된 Gemma 3 4B 모델로 교체 필요 (4bit)
- 양자화 후 실제 nvidia-smi 점유량 측정 → 배치 수 결정
- vLLM이 지원하는 quantization 형식 확인 (
gptq)