AI 콜드 스타트가 Kubernetes Autoscaling을 깨뜨린다

Source: Dev.to

오토스케일링은 일반적으로 마이크로‑서비스에 대해 매우 잘 작동합니다.

When traffic increases, Kubernetes spins up new pods and they begin serving requests within seconds. 하지만 AI 추론 시스템은 매우 다르게 동작합니다.

While exploring an inference setup recently, something strange appeared in the metrics. Users were experiencing slow responses and growing request queues, yet the autoscaler had already created more pods.

Even more confusing: GPU 노드가 사용 가능했지만 아직 유용한 작업을 수행하고 있지 않았습니다.

The root cause was 모델 콜드‑스타트 time.

왜 자동 스케일링이 마이크로‑서비스에 효과적인가

일반적인 자동 스케일링 워크플로우

대부분의 서비스는 다음만 필요합니다:

• 런타임 시작
• 애플리케이션 코드 로드
• 데이터베이스 연결

시작 시간은 보통 몇 초에 불과합니다.

왜 AI 추론 서비스는 다르게 동작할까

AI 컨테이너는 훨씬 무거운 초기화 과정을 필요로 합니다. 파드가 요청을 서비스하기 전에 보통 다음을 수행해야 합니다:

• 모델 가중치 로드
• GPU 메모리 할당
• 가중치를 GPU로 이동
• CUDA 런타임 초기화
• 토크나이저 또는 전처리 파이프라인 초기화

대형 모델의 경우 이 과정에 수십 초에서 몇 분까지 걸릴 수 있습니다.

예시 모델 초기화

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_name = "meta-llama/Llama-7b"

tokenizer = AutoTokenizer.from_pretrained(model_name)

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16
)

# Move the model to GPU memory
model = model.to("cuda")

위 코드는 모델을 GPU 메모리로 이동시킵니다. 대략적인 로드 시간:

트래픽 급증 시, 모니터링 대시보드에 혼란스러운 내용이 표시될 수 있습니다:

• GPU 노드 사용 가능
• 오토스케일러가 파드 생성 중
• 리소스 할당됨

그럼에도 불구하고 사용자는 여전히 응답이 느리다고 느낍니다.

원인: GPU 노드는 파드가 모델을 로드하는 동안 유휴 상태로 남아 있을 수 있습니다. 쿠버네티스가 파드를 GPU 노드에 스케줄링했더라도, 모델 로드가 완료되어야 파드가 요청을 처리할 수 있습니다. 시스템에는 실제로 계산 용량이 존재하지만 아직 사용 가능한 상태가 아닙니다.

트래픽 급증 시 발생하는 일

Imagine a system normally running 2 inference pods. Suddenly traffic increases.

Kubernetes scales the deployment:

2 pods → 6 pods

The new pods must load the model first. Example timeline:

During this window:

Users → API Gateway → Request Queue grows → Latency increases

Autoscaling worked — but too slowly to prevent user impact.

솔루션 패턴 1 — 사전 워밍된 추론 팟

이미 모델이 로드된 상태인 워밍 팟을 유지합니다.

Architecture

Users
   ↓
API Gateway
   ↓
Load Balancer
   ↓
Warm Inference Pods (model already loaded)
   ↓
GPU inference

During traffic spikes

Traffic spike
   ↓
Warm pods handle traffic immediately
   ↓
Autoscaler creates additional pods
   ↓
New pods join after model loads

Result: dramatically reduced latency spikes. → 결과: 지연 시간 급증이 크게 감소합니다.

Solution Pattern 2 — Event‑Driven Autoscaling (KEDA)

전통적인 자동 스케일링은 주로 CPU 메트릭을 사용합니다. AI 워크로드는 큐 기반 메트릭을 활용할 때 더 효율적으로 스케일됩니다. KEDA와 같은 도구를 사용하면 다음을 기준으로 스케일링할 수 있습니다:

• 요청 큐
• 메시지 백로그
• 이벤트 트리거

Architecture

Incoming Requests
   ↓
Request Queue
   ↓
KEDA monitors queue
   ↓
Scale inference pods

이를 통해 지연 시간이 증가하기 전에 스케일링 결정을 내릴 수 있습니다.

References & Further Reading

• KEDA documentation: https://keda.sh
• Kubernetes Horizontal Pod Autoscaler (HPA): https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• Hugging Face model loading guide: https://huggingface.co/docs/transformers/quickstart

Solution Pattern 3 — 모델 캐싱

모델 캐싱은 매번 파드가 시작될 때마다 원격 스토리지에서 다운로드하거나 로드하는 대신 모델 가중치를 로컬에 보관함으로써 시작 시간을 줄이는 데 도움이 됩니다.

일반적인 접근 방식은 다음과 같습니다:

• 로컬 노드 디스크에 모델을 저장합니다.
• Persistent Volume을 사용합니다.

이러한 방법을 통해 새로운 추론 파드가 스케일링 이벤트 중에 모델을 훨씬 빠르게 로드할 수 있습니다.

솔루션 패턴 4 — 전용 추론 서버

NVIDIA Triton, KServe, 또는 TorchServe와 같은 특화된 추론 플랫폼은 프로덕션 모델 서빙을 위해 설계되었으며 다음과 같은 최적화를 제공합니다:

• 동적 배칭
• 효율적인 GPU 활용
• 모델 캐싱

…이를 통해 대규모 추론 시스템을 보다 쉽게 관리하고 성능을 높일 수 있습니다.

모두 합쳐서

• 트래픽 급증에 대한 빠른 응답
• 효율적인 GPU 활용
• 예측 가능한 확장 동작

주요 엔지니어링 교훈

• AI 워크로드는 일반적인 마이크로서비스와 매우 다르게 동작합니다.
• 모델 초기화 시간이 시작 지연을 지배할 수 있습니다.
• 자동 스케일링은 콜드 스타트 지연을 고려해야 합니다.
• 워밍된 파드는 응답성을 크게 향상시킵니다.
• 관측 가능성에는 모델 로드 시간 메트릭이 포함되어야 합니다.

최종 생각

자동 스케일링은 강력하지만, 컴퓨팅이 즉시 사용 가능하다고 가정합니다. AI 워크로드는 새로운 제약을 도입합니다:

모델이 로드되기 전까지는 컴퓨팅 용량이 유용하지 않습니다.

신뢰할 수 있는 AI 인프라를 설계한다는 것은 단순히 리소스를 확장하는 것뿐만 아니라, 그 리소스가 요청을 처리할 준비가 되는 속도까지 고려한다는 의미입니다.