HyperPod 추론 콜드 스타트를 줄이는 모델 캐싱

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Amazon SageMaker HyperPod의 대형 LLM 추론 Pod는 Amazon ECR에서 컨테이너 이미지를 받고 Amazon S3 같은 원격 저장소에서 가중치를 내려받느라 시작까지 수십 분이 걸릴 수 있습니다. Model caching은 가중치를 노드별 로컬 NVMe에 미리 저장하고 추론 서버 이미지를 사전 다운로드해 Pod가 약 7 GB/s의 로컬 읽기로 준비되게 만듭니다. 57–145 GB 모델의 Scale-out 시간은 가중치 캐싱으로 약 60% 줄고, 이미지 캐싱은 새 ECR 다운로드 대비 최대 97%의 콜드 이미지 Pull 시간 감소를 달성했습니다. 다만 캐시는 노드마다 별도로 유지되며 최초 활성화 때 원격 다운로드가 필요하고, 같은 경로의 파일 변경은 명시적으로 리소스 사양을 바꿔야 반영됩니다.

섹션별 상세

대형 LLM을 Amazon SageMaker HyperPod에서 추론할 때 Kubernetes 스케줄러가 Pod를 노드에 배치한 뒤 Kubelet이 Amazon ECR에서 다중 GB 컨테이너 이미지를 받고, 이어 추론 서버가 원격 저장소에서 모델 가중치를 내려받습니다. vLLM이나 LMI 이미지 Pull에 5–7분이 걸리고, Amazon S3의 145 GB 모델은 네트워크 조건에 따라 20분 이상, 600+ GB인 DeepSeek-R1은 30분 이상 소요됩니다. HorizontalPodAutoscaler가 5개 Pod를 즉시 요청해도 각 Pod가 이 순서를 독립적으로 거치므로 추가 트래픽 처리는 25–30분 이상 늦어질 수 있습니다.

Model caching은 Pod가 필요해진 뒤 다운로드하는 구조를 노드가 미리 준비하는 구조로 바꿉니다. Weights cache는 Amazon S3, Amazon FSx for Lustre, HuggingFace Hub 또는 JumpStart에서 가중치를 로컬 NVMe로 내려받고, 모든 대상 노드가 준비된 뒤에만 가중치 캐시를 사용하는 배포를 생성합니다. Pod가 캐시가 있는 노드에 배치되면 약 7 GB/s의 로컬 저장소를 읽으므로 네트워크 다운로드 대신 수 초 안에 트래픽을 처리할 수 있습니다.

Image cache는 추론 서버 컨테이너 이미지를 DaemonSet으로 대상 노드에 미리 Pull해 Amazon ECR 대기 시간을 없앱니다. 이미지 캐시는 준비가 끝나기 전에도 배포 생성을 막지 않으며, 해당 노드에 캐시가 없으면 기존 방식으로 이미지를 받습니다. 같은 이미지를 쓰는 여러 배포는 하나의 캐시 리소스를 공유하고, 참조하는 배포가 모두 사라진 뒤에만 캐시가 정리됩니다.

Weights cache는 ModelDataCacheConfig가 관리하고, Image cache는 ModelImageCache가 관리합니다. 전자는 다운로드 완료 노드에 cache-ready 라벨을 붙이고 캐시 상태를 감시하며, 후자는 노드별 이미지 Pull 상태와 image-ready 상태를 추적합니다. 모델 경로나 이미지가 바뀌면 새 캐시와 배포를 만든 뒤 기존 캐시를 정리해 오래된 가중치가 남은 상태를 피합니다.

text

kubectl get modeldatacacheconfig -n NAME STATE TARGET READY AGE
example-model-cache Ready 10 10 5m

ModelDataCacheConfig의 전체 캐시 상태와 대상 노드 수, 준비된 노드 수를 확인하는 명령입니다.

text

kubectl get inferenceimagecache -n hyperpod-inference-system NAME PHASE CACHED TARGET AGE
iic-vllm-openai-ml-g5-24xlarge-a1b2 Complete 10 10 3m

InferenceImageCache의 이미지 사전 다운로드 상태와 캐시된 노드 수를 확인하는 명령입니다.

두 캐시 모두 필수 배치가 아닌 선호 배치를 사용합니다. 캐시가 없는 노드에 Pod가 배치되면 원래 Amazon S3 또는 Amazon FSx에서 가중치를 받고 Amazon ECR에서 이미지를 받지만 실패나 사용자 개입은 발생하지 않습니다. 따라서 빠른 Scale-out으로 캐시된 노드 수를 초과해도 동작은 유지되고, 차이는 일반 다운로드 시간이 다시 발생한다는 점입니다.

yaml

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: example-model
  namespace: default
spec:
  modelName: example-model
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: example-bucket
      region: us-west-2
    modelLocation: "models/example-model"
  modelCacheConfig:
    weightsCache:
      enabled: true
    imageCache:
      enabled: true
  instanceType: ml.g5.24xlarge
  worker:
    image: vllm/vllm-openai:latest
    modelInvocationPort:
      containerPort: 8000
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model
    resources:
      limits:
        nvidia.com/gpu: "4"

InferenceEndpointConfig에서 모델 가중치와 추론 서버 이미지를 모두 캐싱하도록 설정하는 예시입니다.

yaml

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: example-jumpstart-model
  namespace: default
spec:
  model:
    modelId: "meta-textgeneration-llama-3-1-8b-instruct"
    acceptEula: true
  server:
    instanceType: ml.g5.24xlarge
  modelCacheConfig:
    weightsCache:
      enabled: true
    imageCache:
      enabled: true

JumpStartModel에서 JumpStart 모델의 가중치와 이미지 캐시를 동시에 활성화하는 예시입니다.

기존 InferenceEndpointConfig 또는 JumpStartModel에 modelCacheConfig를 추가하면 별도 인프라 설정 없이 기능을 켤 수 있습니다. weightsCache와 imageCache를 각각 독립적으로 활성화할 수 있고, weights cache에는 기본값인 /opt/dlami/nvme 대신 사용할 hostPath를 지정할 수 있습니다. Amazon S3, Amazon FSx for Lustre, HuggingFace Hub, 비게이트 JumpStart와 게이트 JumpStart가 모두 두 캐시 기능을 지원합니다.

벤치마크에서 57–145 GB 모델의 Scale-out은 가중치 캐싱으로 약 60% 빨라졌고, 이미지 캐시는 새 ECR Pull 대비 콜드 이미지 Pull 시간을 2분 이상 줄이며 최대 97% 감소를 기록했습니다. 600 GB를 넘는 DeepSeek-R1에서는 30분 이상 걸릴 수 있는 원격 다운로드를 제거하는 효과가 더 커집니다. 대신 가중치는 노드마다 복사되므로 노드 수가 늘수록 NVMe 사용량도 증가하며, 예를 들어 250 GB NVMe를 가진 인스턴스에는 300 GB 모델을 캐시할 수 없습니다.

리소스를 삭제하면 오퍼레이터가 캐시 파일, DaemonSet, 노드 라벨을 자동으로 제거해 NVMe 공간을 회수합니다. 최초 캐시 생성 때는 원격 소스에서 한 번 다운로드해야 하고, 같은 Amazon S3 경로의 파일만 교체하면 변경을 자동 감지하지 않습니다. 새 가중치를 사용하려면 모델 경로를 바꾸거나 버전 접미사를 추가하는 등 InferenceEndpointConfig 사양을 갱신해야 합니다.

용어 해설

모델 캐싱(Model Caching): — 모델 가중치와 추론 서버 이미지를 Pod 시작 전에 노드의 로컬 NVMe에 저장하는 방식입니다. 이후 Pod는 Amazon S3나 Amazon ECR에서 네트워크로 다시 받지 않고 로컬 저장소에서 읽어 콜드 스타트와 Scale-out 지연을 줄입니다.
콜드 스타트(Cold Start): — 추론 Pod가 처음 실행되거나 새 노드로 확장될 때 컨테이너 이미지와 모델 가중치를 준비하는 데 걸리는 시간입니다. 대형 모델에서는 네트워크 다운로드가 길어져 자동 확장이 실제 트래픽을 처리하기까지 수십 분이 걸릴 수 있습니다.
HorizontalPodAutoscaler: — Kubernetes에서 트래픽이나 리소스 사용량에 따라 실행 중인 Pod 수를 자동으로 늘리거나 줄이는 기능입니다. 새 Pod가 생성돼도 이미지와 모델 다운로드가 끝나야 요청을 처리하므로 Scale-out 효과가 지연될 수 있습니다.
Custom Resource Definition: — Kubernetes API에 애플리케이션별 리소스 종류를 추가하는 확장 기능입니다. 이 글에서는 ModelDataCacheConfig와 ModelImageCache가 모델 가중치와 컨테이너 이미지 캐시의 생성, 상태 관리, 정리를 맡도록 사용됩니다.
로컬 NVMe 저장소(Local NVMe Storage): — 각 클러스터 노드에 연결된 고속 로컬 저장 공간입니다. 모델 캐싱은 이곳에 가중치를 저장하고 약 7 GB/s 수준으로 읽어 원격 저장소에서 네트워크로 내려받는 과정을 Pod 시작 시점에 생략합니다.

기술

Amazon SageMaker HyperPod
Amazon ECR
Amazon S3
Amazon FSx for Lustre
HuggingFace Hub
vLLM
LMI
Kubernetes

활용 사례

대형 LLM 추론 엔드포인트의 Scale-out
HorizontalPodAutoscaler 기반 트래픽 급증 대응
Amazon SageMaker JumpStart 모델 배포
여러 추론 배포가 공유하는 컨테이너 이미지 캐싱

HyperPod 추론 콜드 스타트를 줄이는 모델 캐싱

TL;DR

섹션별 상세

용어 해설

기술

활용 사례

관련 토론

댓글

관련 기사

HyperPod와 Curvine으로 확장하는 계층형 KV 캐시

SageMaker, Prefix-Aware Routing으로 LLM 지연 단축

SageMaker HyperPod에서 Ray 분산 작업 통합

Qwen3.8을 SageMaker HyperPod에 배포하는 방법

SageMaker SDK v3로 모델 코드 바로 실행