AI 워크로드를 위한 Kubernetes GPU 스케줄링 실전 가이드

GPU 노드 한 대의 시간당 비용은 일반 CPU 노드의 수십 배입니다. 그런데 많은 팀의 실제 GPU 활용률은 30%도 안 됩니다. 학습 job이 끝났는데 파드가 안 내려가거나, 추론 서버 하나가 GPU 한 장을 통째로 점유한 채 놀고 있기 때문이죠.

이 글에서는 Kubernetes에서 GPU를 낭비 없이 쓰는 실전 설정을 다룹니다.

1. 기본: GPU를 K8s가 인식하게 만들기

Kubernetes는 기본적으로 GPU를 모릅니다. NVIDIA Device Plugin을 설치해야 GPU가 스케줄링 가능한 리소스(nvidia.com/gpu)로 노출됩니다.

kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/deployments/static/nvidia-device-plugin.yml

정상 인식됐는지 확인:

kubectl get nodes -o json | jq '.items[].status.capacity."nvidia.com/gpu"'

파드에서 GPU를 요청하는 방법은 간단합니다:

resources:
  limits:
    nvidia.com/gpu: 1   # GPU 1장 요청

중요: GPU는 CPU·메모리와 달리 분할되지 않습니다. nvidia.com/gpu: 0.5 같은 요청은 불가능하며, limits에만 지정할 수 있습니다(requests는 자동으로 같은 값이 됩니다). 즉 파드 하나가 GPU 한 장을 통째로 독점합니다.

2. GPU 활용률을 죽이는 가장 큰 원인

바로 위의 "통째로 독점" 특성 때문입니다. 추론 서버가 GPU 메모리의 10%만 쓰더라도 다른 파드는 그 GPU를 전혀 쓸 수 없습니다. A100 80GB를 8GB짜리 모델 하나가 점유하는 상황이 흔하게 벌어집니다.

해결책은 두 가지입니다.

방법 A: MIG (Multi-Instance GPU)

A100·H100 같은 GPU는 하드웨어 수준에서 여러 개의 독립 GPU로 분할할 수 있습니다. 분할된 인스턴스는 메모리·연산이 물리적으로 격리되어 서로 간섭하지 않습니다.

# A100 80GB를 7개 인스턴스로 분할 (각 10GB)
sudo nvidia-smi mig -cgi 19,19,19,19,19,19,19 -C

분할 후에는 nvidia.com/mig-1g.10gb 같은 리소스로 노출됩니다:

resources:
  limits:
    nvidia.com/mig-1g.10gb: 1

• 장점: 완전한 격리, 성능 예측 가능
• 단점: 분할 크기가 고정, A100/H100 이상에서만 지원
• 적합: 여러 팀이 공유하는 추론 클러스터

방법 B: Time-Slicing (시분할)

MIG를 지원하지 않는 GPU라면 시분할로 하나의 GPU를 여러 파드가 번갈아 쓰게 할 수 있습니다.

# device plugin ConfigMap
version: v1
sharing:
  timeSlicing:
    resources:
      - name: nvidia.com/gpu
        replicas: 4   # GPU 1장을 4개로 "보이게" 함

• 장점: 모든 GPU에서 동작, 설정 간단
• 단점: 메모리 격리 없음 — 한 파드가 OOM을 내면 다른 파드도 영향
• 적합: 개발·실험 환경, 부하가 낮은 추론

주의: time-slicing은 GPU를 실제로 나누는 게 아니라 "나눠 보이게" 하는 것입니다. 메모리 총량은 그대로이므로, 4개 파드가 각각 큰 모델을 올리면 바로 OOM이 납니다. 프로덕션 격리가 필요하면 MIG를 쓰세요.

3. GPU 노드를 아무나 못 쓰게 막기

비싼 GPU 노드에 CPU만 쓰는 파드가 스케줄링되면 최악입니다. GPU 노드에 taint를 걸어 GPU 파드만 들어오게 하세요.

kubectl taint nodes gpu-node-1 nvidia.com/gpu=present:NoSchedule

GPU를 쓰는 파드에만 toleration을 추가합니다:

tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule

nodeSelector:
  accelerator: nvidia-a100   # 특정 GPU 타입 지정

4. 학습 job과 추론 서비스의 우선순위 분리

실무에서 흔한 요구사항입니다: "추론 서비스는 절대 죽으면 안 되고, 학습 job은 밀려도 된다." PriorityClass로 해결합니다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: inference-critical
value: 1000000
preemptionPolicy: PreemptLowerPriority   # 필요시 낮은 우선순위 파드를 밀어냄
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: training-batch
value: 100
preemptionPolicy: Never

이렇게 하면 GPU가 부족할 때 학습 job이 선점(preempt)당하고 추론 서비스가 우선 확보됩니다. 단, 학습 job은 체크포인트를 반드시 저장하도록 만드세요. 언제든 죽을 수 있다는 전제로 설계해야 합니다.

5. 놀고 있는 GPU 찾아내기

가장 중요한 건 측정입니다. DCGM Exporter로 GPU 메트릭을 Prometheus에 수집하세요.

helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts
helm install dcgm-exporter gpu-helm-charts/dcgm-exporter

주목해야 할 핵심 메트릭:

"파드는 GPU를 점유 중인데 활용률은 5%" — 이 조합이 보이면 즉시 손봐야 할 낭비입니다.

6. 비용 절감 체크리스트

• 노드 오토스케일링 — 학습이 없을 땐 GPU 노드를 0까지 축소 (Karpenter, Cluster Autoscaler)
• Spot 인스턴스 — 학습 job은 spot으로 (체크포인트 필수). 최대 70~90% 절감
• 추론은 MIG로 분할 — 작은 모델이 큰 GPU를 독점하지 않게
• 유휴 파드 정리 — 개발자가 띄워놓고 잊은 노트북 파드에 TTL 설정
• 배치 큐 도입 — Kueue 등으로 학습 job을 대기열에 넣어 GPU를 빈틈없이 사용

마치며

GPU 최적화의 핵심은 화려한 기술이 아니라 "놀고 있는 GPU를 찾아내는 것"입니다. 먼저 DCGM으로 측정하고, 활용률이 낮은 워크로드부터 MIG 분할이나 노드 축소를 적용하세요.

대부분의 팀은 측정과 오토스케일링만으로도 GPU 비용을 절반으로 줄입니다.

※ MIG 지원 여부와 분할 프로파일은 GPU 모델마다 다릅니다. 적용 전 NVIDIA 공식 문서에서 해당 모델의 지원 스펙을 확인하시기 바랍니다.

참고 자료

• Kubernetes 공식 문서 — Device Plugin, taint/toleration, PriorityClass 등 스케줄링 관련 공식 레퍼런스
• NVIDIA 공식 블로그 — MIG, DCGM 등 GPU 인프라 기술 소식과 활용 사례
• AWS 공식 블로그 — Karpenter·spot 인스턴스 등 GPU 노드 비용 최적화 관련 소식 채널