OCI의 단일 A10 GPU 비용은 시간당 $1.52입니다. 24시간 내내 가동하면 한 달에 $1,094가 듭니다. 트래픽이 꾸준한 프로덕션 추론 (Inference) 서비스라면 괜찮습니다. 하지만 저에게는 하루에 요청이 20건 정도 발생하는 스테이징 환경과 몇 가지 내부 도구들이 있었습니다. 저는 시간의 95% 동안 유휴 (Idle) 상태로 방치되는 GPU를 위해 매달 $2,000 이상을 지불하고 있었습니다.

명확한 해결책은 트래픽이 없을 때는 scale-to-zero(0으로 확장)하고, 요청이 들어오면 다시 가동하는 것입니다. KEDA는 Kubernetes에서 이를 수행하지만, GPU Pod와 함께 제대로 작동하도록 만드는 데는 약간의 시행착오가 필요했습니다.

GPU 스케일링이 CPU Pod 스케일링보다 어려운 이유

일반적인 HTTP 서비스의 경우, KEDA가 메트릭(HTTP 요청, 큐 깊이 등)을 감시하면 Kubernetes는 몇 초 내에 새로운 Pod를 생성할 수 있습니다. 사용자는 거의 눈치채지 못합니다.

GPU Pod는 다릅니다:

1. Cold start (콜드 스타트)가 느림 - 모델 로딩에 60~120초가 소요됩니다.
2. 노드 스케일링이 느림 - 풀(Pool)에 GPU 노드가 없다면, OKE는 새로운 VM을 프로비저닝해야 합니다 (3~5분).
3. 이미지 크기가 매우 큼 - 캐싱되지 않은 경우 5~15GB의 풀(Pull) 시간이 소요됩니다.
4. GPU 리소스는 이진적(Binary)임 - (MIG 없이는) Pod에 "GPU 절반"을 할당할 수 없습니다.

따라서 단순히 scale-to-zero를 적용하고 트래픽이 돌아왔을 때 1초 미만의 응답 시간을 기대할 수는 없습니다. 트레이드오프(Trade-off)는 비용 절감 대 콜드 스타트 지연 시간(Latency)입니다. 저의 사용 사례(내부 도구, 스테이징)에서는 2~3분의 콜드 스타트가 허용 가능한 수준이었습니다.

설정 방법

1. OKE에 KEDA 설치

helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda \
  --namespace keda-system \
...

2. 요청 메트릭을 위한 Prometheus

저는 요청률을 추적하기 위해 nginx 인그레스 컨트롤러(Ingress Controller)의 Prometheus 메트릭을 사용하고 있습니다. 만약 OCI의 네이티브 로드 밸런서를 사용 중이라면, 대신 OCI Monitoring 메트릭을 사용하면 됩니다.

# prometheus-scaledobject.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...

주요 설정 사항:

주요 설정 사항:

• minReplicaCount: 0 — 이것이 scale-to-zero를 가능하게 합니다.
• cooldownPeriod: 300 — 트래픽이 없으면 5분 동안 스케일 다운을 막아줍니다 (플래핑 방지).
• activationThreshold: "0.1" — 미미한 양의 트래픽만으로도 0에서 스케일 업을 트리거합니다.

3. 콜드 스타트 처리(Handling the Cold Start)

Pod가 0에서 스케일 될 때 간극이 생깁니다. 스케일 업을 촉발한 요청은 Pod가 준비될 때까지 기다려야 합니다. 저는 간단한 큐 패턴으로 이를 처리합니다:

# queue-proxy.yaml — 콜드 스타트 동안 요청을 보관하는 경량 프록시
apiVersion: apps/v1
kind: Deployment
...

이 프록시는 작은 Go 서비스(항상 실행되며 비용이 거의 들지 않음)로, 다음 기능을 수행합니다:

• 들어오는 요청을 즉시 수락합니다.
• 요청을 vLLM 백엔드로 전달합니다.
• 백엔드가 준비되지 않은 경우, 최대 3분까지 지수 백오프(exponential backoff)를 사용하여 재시도합니다.
• 시간 초과 시 "모델 로딩 중이므로 다시 시도해 주세요"라는 메시지와 함께 503 응답을 반환합니다.

func proxyHandler(w http.ResponseWriter, r *http.Request) {
    backendURL := os.Getenv("BACKEND_URL")
timeout, _ := strconv.Atoi(os.Getenv("TIMEOUT_SECONDS"))
...

4. GPU 노드 유지하기(Keeping a Warm GPU Node)

콜드 스타트에서 가장 느린 부분은 모델 로딩이 아니라, OKE가 GPU 노드를 프로비저닝할 때 아무것도 없을 경우를 기다리는 것입니다. 이는 3~5분이 걸립니다.

제 해결책: 하나의 GPU 노드는 항상 사용 가능하게 유지하되, 그 위의 추론(inference) Pod들이 0으로 스케일 되도록 합니다. 이 노드는 유휴 상태일 때도 비용이 발생하지만, 여러 개의 노드와 비교하면 적습니다. 그리고 트래픽이 들어오면, Pod는 5분 이상 걸리는 (노드 프로비저닝 + 모델 로딩) 대신 약 90초 만에 시작됩니다.

# 최소 1개의 노드를 가진 GPU 노드 풀 (항상 따뜻하게 유지)
oci ce node-pool update \
  --node-pool-id $GPU_NODE_POOL_ID \
...

5분 콜드 스타트가 허용되는 스테이징 환경의 경우, 노드 풀을 0개에서 2개로 자동 스케일되도록 설정하고 OKE에 맡깁니다.

비용 절감 효과(The Savings)

저의 세 가지 GPU 워크로드 (스테이징 vLLM, 내부 요약기, 내부 코드 검토 도구)는 A10 인스턴스 3개에서 24시간 연중무휴로 실행되었습니다:

이전	이후
3x A10 상시 가동 (always-on)	1x A10 웜 노드 (warm node) + scale-to-zero 포드 (pods)
...

65%의 비용을 절감했습니다. 내부 도구들은 누군가 사용할 때(하루에 몇 번) 스케일 업 (scale up) 되고, 5분 동안 유휴 (idle) 상태가 되면 다시 스케일 다운 (scale down) 됩니다. 웜 노드 (warm node) 덕분에 콜드 스타트 (cold start) 시간은 90초이며, 이는 내부 사용자들에게는 수용 가능한 수준입니다.

이 방식을 적용하면 안 되는 경우

• 고객 대상 API (Customer-facing APIs) - 90초의 콜드 스타트 (cold start)는 용납될 수 없습니다. 레플리카 (replicas)를 웜 (warm) 상태로 유지하세요.
• 지속적인 트래픽 (Steady traffic) - GPU 사용률이 시간의 60% 이상을 차지한다면, scale-to-zero (스케일 투 제로)를 통해 얻는 절감액이 복잡성을 감수할 만큼 충분하지 않습니다.
• 실시간 애플리케이션 (Real-time applications) - 지연 시간 (latency)에 민감한 모든 서비스는 상시 가동 (always-on) 상태를 유지해야 합니다.

이 방식은 내부 도구, 배치 엔드포인트 (batch endpoints), 스테이징 환경 (staging environments), 그리고 "잠시만 기다려 주세요"라는 응답이 허용되는 모든 상황에 적합합니다.

Pavan Madduri — Oracle ACE Associate, CNCF Golden Kubestronaut. 저는 또한 GPU 인식 오토스케일링 (GPU-aware autoscaling)을 위한 keda-gpu-scaler를 개발하고 있습니다. GitHub | LinkedIn | Website | Google Scholar | ResearchGate