쿠베에 GPU 꽂아도 바로 못 쓰는 이유

서버에 그래픽카드 꽂는다고 쿠베가 알아서 인식하지 않는다. 개념좀 잡으려고 글쓴다

1. NVIDIA Driver: OS용 드라이버
2. Container Toolkit: 컨테이너가 GPU 접근할 수 있게 뚫어줌
3. Device Plugin: 쿠베 노드에 GPU 몇 개 있는지 리소스로 등록
4. DCGM Exporter: GPU 온도/사용률 모니터링

이걸 노드마다 수동으로 세팅하면 지옥이라, 데몬셋으로 한번에 밀어 넣고 관리해 주는 게 GPU Operator다.

 

 

할당 팁

대형 LLM은 보통 Pod 1개가 GPU 1장(이상)을 통째로 먹는다. 반면 가벼운 음성/비전 모델은 MIG 써서 GPU 1대를 물리적으로 쪼개 여러 Pod에 나눠주는 게 돈 아끼는 길.

 

 

GPU 구조 & KV Cache 우선 요약

• SM / Core: 일하는 작업자
• VRAM: 작업에 필요한 재료 올려두는 초고속 창고
• KV Cache: LLM이 이전 토큰 계산해 둔 거 재사용하려고 VRAM에 올려두는 캐시. 이게 없으면 글자 하나 찍을 때마다 앞 문장 전체를 매번 처음부터 다시 계산해야 함.

보통 7B 모델 FP16으로 띄우면 가중치만 14GB 먹는데, KV Cache랑 여유 공간 때문에 실무에선 최소 24GB VRAM 카드가 필요하다.

 

vLLM & 처리 방식

LLM을 일반 FastAPI로 띄우면 동시 요청 들어올 때 다 뻗는다. 그래서 vLLM 같은 서빙 전용 엔진을 쓴다.

• Continuous Batching: 요청 끝날 때까지 멍때리는 게 아니라, 먼저 끝난 놈은 바로 내보내고 그 빈자리에 새 요청을 동적으로 끼워 넣어서 GPU를 풀로 굴림.
•  

Prefill vs Decode

• Prefill: 유저가 보낸 질문을 한 번에 계산하는 단계 (GPU 연산 집중, 긴 프롬프트일수록 오래 걸림)
• Decode: 답변을 한 토큰씩 순차적으로 뱉는 단계 (VRAM 대역폭 싸움)
• TTFT: 엔터 치고 첫 글자 찍힐 때까지 걸리는 시간. Prefill 계산이나 큐 대기가 길어지면 TTFT가 튀어버린다.

 

실전 옵션 & 장애 상황

vllm serve Qwen/Qwen2.5-0.5B-Instruct \
  --max-model-len 2048 \
  --max-num-seqs 8 \
  --gpu-memory-utilization 0.90

• --gpu-memory-utilization: GPU 메모리를 vLLM이 얼마나 땡겨 쓸지 지정(기본 90%). 물리 VRAM이 늘어나는 게 아니라 KV Cache용으로 공간을 미리 잡아두는 것.

🚨 트래픽 터졌을 때 징후

• GPU 사용률 95% + KV Cache 90% 이상 찍힘
• 큐에 요청 50건 밀리고 TTFT 5초 이상 늘어남

 

해결책

일반 웹서버처럼 무작정 HPA로 Pod Replica 늘리면 안 됨. 노드에 남는 GPU 자원 없으면 Pod가 Pending 상태로 멈춘다.

• --max-model-len 줄여서 메모리 확보
• AWQ/GPTQ 양자화로 모델 크기 다이어트
• 정 안 되면 물리 GPU 노드 추가 증설이 답이다.