GPU VRAM 할당 구조와 KV 캐시 바이블: 모델별 실제 사용량 완전 정리

결론 먼저

8GB GPU에서 6GB 모델을 올렸는데 갑자기 TPS(초당 토큰)가 반 토막 난다면, 문제는 모델 크기가 아니라 KV 캐시 때문이다. KV 캐시는 컨텍스트가 길어질수록 기하급수적으로 늘어나며, 이 영역이 GPU 한계를 초과하면 CPU로 오프로딩되면서 속도가 폭락한다. 이 글에서는 Qwen3-4B, K2-Horizon-3.7B, Gemma 4 E4B 세 모델의 실제 VRAM 사용량을 벤치마크 수치로 분석한다.

1. GPU VRAM 할당 구조: 정적 vs 동적

+--------------------------------------------------------+
|                   전체 VRAM (8 GB)                       |
+---------------------------+----------------------------+
|  정적 영역 (Static)        |     동적 영역 (Dynamic)     |
|  - 모델 가중치 (6 GB)     |     - KV 캐시 + 액티베이션  |
|                           |       (가용: ~2 GB)         |
+---------------------------+----------------------------+

정적 할당 (Static Allocation): 모델의 양자화 가중치가 차지하는 고정 영역. Q4_K_M 양자화 기준 파일 크기 ≈ VRAM 점유율.

동적 할당 (Dynamic Allocation): 컨텍스트 입력 및 토큰 생성 과정에서 실시간으로 변하는 액티베이션 텐서와 KV 캐시가 상주하는 영역. 이 부분이 문제의 핵심이다.

2. KV 캐시란 무엇인가

트랜스포머의 셀프 어텐션은 이전 모든 토큰과의 관계를 연산해야 한다. 매 토큰마다 처음부터 다시 계산하면 비효율적이므로, 과거 토큰의 Key와 Value 텐서를 메모리에 캐싱한다.

KV 캐시 크기 공식 (GQA 모델 기준):

KV_cache_bytes = 2 × L × H_kv × D_head × C × B

• L: 레이어 수
• H_kv: KV 어텐션 헤드 수 (GQA일 경우 Query 헤드 수보다 적음)
• D_head: 헤드 차원수
• C: 컨텍스트 윈도우 (현재 처리 중인 토큰 수)
• B: 데이터 정밀도 (FP16 = 2 bytes, INT8 = 1 byte)

핵심 포인트: GQA 모델은 H_kv가 H_query보다 작으므로, 동일 컨텍스트でも KV 캐시가 MHA(Full Attention) 대비 4배 적다.

3. 모델별 실제 VRAM 사용량 벤치마크

Qwen3-4B (36 layers, 32 query heads, 8 KV heads, GQA 4:1)

8GB VRAM에서 Q4_K_M 사용 시 32K 컨텍스트부터 5.7GB로 여유가 없어지고, 41K 컨텍스트에서는 6.5GB로 임계치에 근접한다. Q6_K는 8K부터 4.9GB, 32K부터 6.6GB로 여유가 줄어든다.

K2-Horizon-3.7B (36 layers, 32 query heads, 8 KV heads, GQA 4:1)

K2-Horizon의 네이티브 컨텍스트는 512K 토큰이다. Q4_K_M 기준으로 512K 컨텍스트 시 KV 캐시만 34GB에 달한다. 8GB 환경에서는 컨텍스트를 32K 이하로 강제 제한해야 한다.

Gemma 4 E4B (42 layers, 8 query heads, 2 KV heads, GQA 4:1, 하이브리드 어텐션)

Gemma 4 E4B는 하이브리드 어텐션 구조(36개 슬라이딩 윈도우 + 6개 글로벌 레이어)를 사용한다. 슬라이딩 윈도우 레이어는 윈도우 간 KV를 재사용하므로, 공식 공식보다 실제 KV 캐시가 더 작다. 8GB에서 131K 컨텍스트도 4.5GB(Q4_K_M)로 안정적으로 동작한다.

4. GQA가 KV 캐시를 4배 줄이는 메커니즘

GQA를 사용하지 않았다면 (Full MHA, 32 KV heads 기준):

• Qwen3-4B 41K 컨텍스트: KV 캐시 14.4GB (현재 3.6GB)
• K2-Horizon 512K 컨텍스트: KV 캐시 136GB (현재 34GB)

GQA는 소비자 GPU에서 롱 컨텍스트 추론을 현실 가능한 수준으로 만드는 핵심 기술이다.

5. CPU 오프로딩과 병목 현상

대역폭 차이:

• GPU VRAM 대역폭: GDDR6 기준 300~400 GB/s
• PCIe Gen4 x16: 32 GB/s (GPU 대비 약 10배 느림)

GPU VRAM에 가중치 + KV 캐시를 모두 넣지 못하면 초과분이 CPU RAM으로 오프로딩된다. 이때 토큰이 PCIe 버스를 통해 주고받으므로 TPS가 급락한다.

실증 예시 (Qwen3-4B Q8_0, 8GB VRAM):

• 8K 컨텍스트: 5.6GB 사용 → 전체 GPU에서 동작 → TPS 45~60
• 32K 컨텍스트: 7.3GB 사용 → 임계치 근접 → TPS 35~45
• 41K 컨텍스트: 8.1GB 사용 → 100MB 오프로딩 → TPS 25~30 (약 40% 하락)

6. 하드웨어 제약 극복을 위한 최적화 옵션

옵션 1: 컨텍스트 윈도우 제한

llama-server -m model.gguf --ctx-size 8192

8GB 환경에서 안전한 컨텍스트 상한선:

• Qwen3-4B Q4_K_M: 32K (5.7GB)
• K2-Horizon Q4_K_M: 32K (4.8GB)
• Gemma 4 E4B Q4_K_M: 131K (4.5GB)

옵션 2: Flash Attention 활성화

llama-server -m model.gguf --flash-attn --ctx-size 32768

Flash Attention은 어텐션 행렬을 완전히 Materialize하지 않고 타일 기반으로 계산하므로 KV 캐시 메모리를 30~50% 절감한다.

옵션 3: KV 캐시 양자화

llama-server -m model.gguf \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --ctx-size 32768

KV 캐시를 FP16 대신 Q8_0으로 저장하면 메모리가 절반으로 줄어든다. 품질 손실은 1% 미만이다.

옵션 4: Flash Attention + KV 양자화 조합 (최적 조합)

llama-server -m model.gguf \
  --n-gpu-layers 999 \
  --flash-attn \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --ctx-size 131072

Flash Attention과 Q8_0 KV 캐시를 함께 적용하면 컨텍스트 VRAM을 기본 대비 70~80% 절감한다. 24GB GPU에서 128K 컨텍스트도 현실적으로 가능해진다.

7. 모델별 실전 배치 권장사항

8GB VRAM 환경 (RTX 3060, RTX 4060 Ti 등)

16GB VRAM 환경 (RTX 4080, RTX 5070 등)

24GB VRAM 환경 (RTX 3090, RTX 4090, RTX 5090 등)

8. 핵심 요약

1. KV 캐시는 컨텍스트 길이에 비례해 늘어난다: 4K에서 32K로 컨텍스트를 8배 늘리면 KV 캐시도 약 8배 증가한다.
2. GQA는 필수다: Qwen3-4B, K2-Horizon, Gemma 4 E4B 모두 GQA 4:1을 사용하여 KV 캐시를 4배 절감한다.
3. Flash Attention + KV 양자화 = 최적 조합: 컨텍스트 VRAM을 70~80% 절감하여 소비자 GPU에서도 롱 컨텍스트 추론이 가능하다.
4. 8GB 환경에서는 컨텍스트를 8K~16K로 제한하는 것이 안전하다: Q4_K_M 양자화 기준.
5. CPU 오프로딩은 피해야 한다: PCIe 대역폭 병목으로 TPS가 40% 이상 하락한다.