Reduce inference cold starts on Amazon SageMaker HyperPod with model caching

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker HyperPod의 모델 캐싱은 가중치와 컨테이너 이미지를 노드에 미리 적재해, 캐시가 준비된 노드에서 대형 모델의 추론 시작 대기를 수십 분에서 통상 수초로 줄이는 기능이다.

📌 핵심 요약

• 캐싱이 없으면 Amazon ECR의 컨테이너 이미지와 원격 저장소의 모델 가중치를 순차적으로 다운로드한다. 이미지 다운로드는 5~7분, Amazon S3의 145 GB 모델 가중치는 네트워크 조건에 따라 추가로 20분 이상 걸릴 수 있으며, 600 GB 이상인 DeepSeek-R1은 가중치 다운로드에 30분 이상이 걸릴 수 있다.
• 가중치 캐시는 대상 노드의 로컬 NVMe에 모델을 미리 저장하고 모든 대상 노드가 준비된 뒤 추론 배포를 생성한다. 이미지 캐시는 이미지를 미리 가져오지만 배포 생성을 막지 않으며, 준비된 가중치는 로컬 NVMe에서 통상 약 7 GB/s로 읽는다.
• 57~145 GB 모델 벤치마크에서 가중치 캐싱은 스케일아웃을 약 60% 빠르게 했고, 이미지 캐싱은 콜드 이미지 다운로드 시간을 2분 넘게 제거하며 최대 97% 줄일 수 있었다. 캐시가 없는 노드에 파드가 배치되면 기존 원격 다운로드 방식으로 동작한다.
• InferenceEndpointConfig 또는 JumpStartModel의 modelCacheConfig에서 가중치·이미지 캐싱을 각각 활성화할 수 있다. Amazon S3, Amazon FSx for Lustre, HuggingFace Hub와 gated·non-gated Amazon SageMaker JumpStart 모델을 지원하며, Amazon SageMaker HyperPod가 제공되는 모든 리전에서 정식 출시됐다.
• 가중치 캐시는 노드별 NVMe 용량을 사용하고 최초 원격 다운로드는 필요하다. 250 GB NVMe에는 300 GB 모델을 캐싱할 수 없으며, 같은 Amazon S3 경로의 파일 변경은 자동 감지하지 않아 새 가중치 적용에는 InferenceEndpointConfig spec 변경이 필요하다. 상위 리소스를 삭제하면 캐시와 관련 리소스는 자동 정리된다.

🧩 주요 포인트

1. 순차 다운로드가 스케일아웃을 지연시키므로, 모델 캐싱의 핵심 효과는 반복 다운로드를 파드 시작 이전으로 옮겨 추가 트래픽 수용까지의 대기를 줄이는 데 있다.
2. 가중치 캐시는 준비 완료를 기다리고 이미지 캐시는 배포를 즉시 허용하므로, 두 기능의 효과는 캐시 준비 상태와 새 파드가 배치되는 노드에 따라 달라진다.
3. 노드별 NVMe 복제와 InferenceEndpointConfig spec 기반 갱신이 필요하므로, 캐싱 활용에는 모델 크기에 맞는 저장 용량과 명시적인 모델 버전 변경이 중요하다.

🧠 상세 정리

1. 콜드 스타트가 오토스케일링을 지연시키는 이유

Amazon SageMaker HyperPod에서 추론 파드를 요청한 뒤 실제 트래픽을 처리하기까지의 간격은 컨테이너 이미지와 모델 가중치를 순서대로 내려받는 과정이 지배한다. Kubernetes 스케줄러가 파드를 노드에 배치하면 Kubelet이 Amazon ECR에서 이미지를 가져오며, GPU 드라이버와 CUDA 라이브러리, 서빙 프레임워크를 포함한 vLLM·LMI 이미지는 이 과정에 5~7분이 걸린다. 컨테이너가 시작된 다음에는 가중치를 다운로드하므로 Amazon S3의 145 GB 모델은 네트워크 상태와 가용 대역폭에 따라 추가로 20분 이상, 600 GB 이상인 DeepSeek-R1은 30분 이상이 필요할 수 있다. 트래픽 급증으로 HorizontalPodAutoscaler가 새 파드 5개를 요청해도 각 파드는 이 다운로드 순서를 독립적으로 거친다. 따라서 오토스케일링 정책이 수초 안에 반응하더라도 추가 트래픽을 실제로 처리하기까지는 25~30분 이상이 걸릴 수 있다.

2. 가중치 캐시의 사전 적재와 배포 대기

모델 캐싱은 파드가 필요로 하기 전에 노드에 데이터를 미리 적재하며, 가중치 캐시와 이미지 캐시를 함께 또는 별도로 활성화할 수 있다. InferenceEndpointConfig나 JumpStartModel에 modelCacheConfig의 weightsCache를 활성화해 적용하면 HyperPod Inference Operator가 ModelDataCacheConfig를 자동 생성한다. 이어 Amazon S3, Amazon FSx for Lustre, HuggingFace Hub 또는 JumpStart에서 모든 대상 노드의 로컬 NVMe로 가중치를 다운로드하고, 완료된 노드에 cache-ready 레이블을 붙인다. 오퍼레이터는 모든 대상 노드가 cache-ready 상태가 된 다음 추론 배포를 생성하며, 파드는 네트워크 다운로드 대신 통상 약 7 GB/s의 로컬 읽기를 활용한다. 캐시는 같은 노드에서 파드가 재시작해도 유지되고, 스케일아웃 시 이미 가중치가 저장된 노드에 배치되는 새 파드는 다운로드 대기 없이 시작할 수 있다.

3. 이미지 캐시와 캐시 미준비 시 대체 동작

imageCache를 활성화하면 오퍼레이터가 DaemonSet을 생성해 추론 서버 컨테이너 이미지를 모든 대상 노드에 미리 가져온다. 가중치 캐시와 달리 이미지 캐시는 추론 배포 생성을 기다리게 하지 않으며, 이미지가 준비된 노드에서는 Amazon ECR 다운로드를 건너뛰어 설명상 5~7분을 절약한다. 이미지 캐시가 완료되기 전에 파드가 시작되면 평소처럼 Amazon ECR에서 이미지를 가져오고, 같은 이미지를 사용하는 여러 배포는 하나의 이미지 캐시 리소스를 공유한다. 두 캐시 모두 캐시 보유 노드를 필수 조건으로 강제하지 않고 선호하는 스케줄링을 사용하므로, 급격한 확장으로 캐시가 없는 노드에 배치될 수도 있다. 이 경우 가중치는 원래 Amazon S3 또는 Amazon FSx 소스에서 읽고 이미지는 Amazon ECR에서 가져오며, 원문은 통상적인 다운로드 시간 외에 추가적인 성능 저하나 실패, 사용자 개입은 없다고 설명한다.

4. 캐시 수명주기와 변경 처리

오퍼레이터는 캐싱을 활성화할 때 두 종류의 Custom Resource Definition을 자동으로 생성하고 관리하므로 사용자가 직접 만들 필요가 없다. ModelDataCacheConfig는 가중치 캐싱을 사용하는 InferenceEndpointConfig 또는 JumpStartModel마다 하나씩 생성되며, 다운로드와 준비 레이블 부여, 캐시 상태 감시, 비정상 캐시의 노드 레이블 제거, 상위 리소스 삭제 시 파일 정리를 담당한다. 원문에서 ModelImageCache로 설명하는 이미지 관리 리소스는 사전 이미지 가져오기, image-ready 레이블 부여, 노드별 진행 상태 보고와 참조 배포가 없어졌을 때의 정리를 담당한다. 상태는 가중치의 경우 kubectl get modeldatacacheconfig로, 이미지의 경우 hyperpod-inference-system 네임스페이스에서 kubectl get inferenceimagecache로 확인하는 예시가 제시된다. 모델 소스를 새 Amazon S3 경로로 바꾸거나 이미지를 변경하면 새 캐시 생성, 배포 갱신, 이전 캐시 정리 순서로 처리하며, 원문은 이를 오래된 데이터가 남지 않는 무중단 전환으로 설명한다.

5. 설정 방법과 지원 모델 소스

기존 InferenceEndpointConfig 또는 JumpStartModel의 spec에 modelCacheConfig를 추가하고 weightsCache와 imageCache의 enabled 값을 true로 설정하면 별도 인프라 구성 없이 캐싱을 활성화할 수 있다. InferenceEndpointConfig 예시는 Amazon S3 모델 소스, ml.g5.24xlarge 인스턴스, vllm/vllm-openai:latest 이미지와 /opt/ml/model 마운트 경로를 사용하며, JumpStartModel 예시는 meta-textgeneration-llama-3-1-8b-instruct를 지정한다. 이미지 캐시만 필요하면 weightsCache를 생략하거나 비활성화할 수 있고, 가중치 캐시는 hostPath를 지정해 기본 NVMe 경로인 /opt/dlami/nvme를 바꿀 수도 있다. Amazon SageMaker JumpStart에서 설정한 캐싱 구성은 해당 JumpStart의 각 배포에도 이어진다. 지원 소스는 Amazon S3, Amazon FSx for Lustre, HuggingFace Hub와 gated·non-gated Amazon SageMaker JumpStart이며, 이들 모두 가중치 캐시와 이미지 캐시를 지원한다.

6. 벤치마크 결과와 효과의 범위

원문은 57~145 GB 모델을 대상으로 한 벤치마크에서 가중치 캐싱을 켜면 스케일아웃이 약 60% 빨라졌다고 보고한다. 이미지 캐시는 콜드 이미지 다운로드 시간을 2분 넘게 제거할 수 있었고, 파드 시작 때마다 Amazon ECR에서 새로 가져오는 방식과 비교해 최대 97%의 시간 감소를 제시한다. 이는 앞서 설명한 일반적인 이미지 다운로드 5~7분과 함께 제시된 결과이지만, 벤치마크별 상세 조건이나 개별 측정값은 본문에 포함되지 않는다. 원문은 모델이 커질수록 원격으로 전송해야 할 데이터가 많아져 캐싱의 이점도 커지며, 600 GB 이상인 DeepSeek-R1에서는 30분 넘게 걸릴 다운로드를 제거할 수 있다고 설명한다. 다만 통상 수초 내 트래픽 처리라는 효과는 사전 캐시를 활용하는 경우에 해당하며, 최초 적재와 캐시가 없는 노드의 원격 다운로드는 여전히 필요하다.

7. NVMe 용량과 모델 갱신의 제약

가중치 캐시는 노드마다 모델 사본을 보관하므로, 각 노드에 충분한 로컬 NVMe가 있어야 하고 전체 저장 공간 사용량은 노드 수에 따라 증가한다. 원문에 제시된 용량은 ml.g5.xlarge 250 GB, ml.g5.12xlarge 3,800 GB, ml.g5.48xlarge 7,600 GB, ml.p4d.24xlarge 8,000 GB, ml.p5.48xlarge 30,000 GB다. 예를 들어 모델이 300 GB인데 인스턴스의 NVMe가 250 GB라면 캐싱이 동작하지 않으므로 모델 크기에 맞춰 인스턴스를 선택해야 한다. 최초 활성화 때는 원격 소스에서 캐시를 채우는 다운로드가 필요하고, 이후 해당 노드의 파드가 로컬 데이터를 활용한다. 또한 같은 Amazon S3 경로에서 파일만 교체하면 변경을 자동 감지하지 않아 캐시된 버전을 계속 사용하므로, 새 가중치를 반영하려면 모델 경로나 버전 접미사 등을 바꾸는 InferenceEndpointConfig spec 갱신이 필요하다.

8. 자동 정리와 정식 제공 범위

InferenceEndpointConfig 또는 JumpStartModel 리소스를 삭제하면 오퍼레이터가 클러스터의 캐시 데이터와 DaemonSet, 노드 레이블을 자동으로 제거한다. 따라서 별도의 수동 정리 없이 NVMe 공간을 다른 워크로드에 다시 사용할 수 있으며, 여러 배포가 공유하는 이미지 캐시는 앞서 설명한 참조 관리에 따라 더 이상 이를 참조하는 배포가 없을 때 정리된다. 이 기능은 Amazon SageMaker HyperPod를 이용할 수 있는 모든 리전에서 정식 제공된다고 원문은 밝힌다. 시작 절차는 기존 배포 명세에 modelCacheConfig를 추가해 적용하는 것이며, 이후 캐시 리소스 생성과 사전 적재, 상태 관리 등은 오퍼레이터가 수행한다. 원문은 전체 설정과 사용법을 확인할 자료로 SageMaker HyperPod Inference 문서를 안내하며, 사전 적재부터 삭제까지의 캐시 관리를 기존 배포 리소스에 연결하는 방식으로 설명을 마무리한다.

🧾 핵심 주장 / 시사점

• 모델 캐싱은 최초 다운로드를 없애기보다 반복 파드 시작에서 분리한다. 따라서 오토스케일링의 실질적인 응답 속도는 정책 반응 시간뿐 아니라 캐시가 준비된 노드의 가용성에도 좌우된다.
• 캐시 보유 노드를 선호하되 강제하지 않는 방식은 캐시 미준비로 인한 배치 차단을 피하지만, 캐시 범위를 넘어선 확장에서는 기존 다운로드 지연이 다시 나타날 수 있다.
• 로컬 읽기 성능의 이점은 노드별 저장 공간 사용과 명시적인 모델 갱신 관리라는 조건을 동반한다. 특히 같은 소스 경로의 파일 교체만으로는 캐시된 모델이 갱신되지 않는다는 점이 운영상 중요하다.

✅ 액션 아이템

• InferenceEndpointConfig 또는 JumpStartModel의 modelCacheConfig에서 가중치 캐시와 이미지 캐시의 활성화 범위 검토.
• 모델 크기와 노드별 NVMe 용량을 비교하고, 300 GB 모델과 250 GB NVMe처럼 캐싱이 불가능한 조합 확인.
• 새 가중치 적용 시 InferenceEndpointConfig spec 변경을 반영하고, 캐시가 없는 노드의 원격 다운로드 대기 고려.

❓ 열린 질문

• 스케일아웃 시 새 파드가 배치될 노드에 가중치 캐시와 이미지 캐시가 어느 정도 준비되어 있는가?
• 대상 모델 크기를 수용할 노드별 NVMe 용량이 충분한가?
• 같은 Amazon S3 경로의 모델 파일을 변경할 때 InferenceEndpointConfig spec도 갱신하고 있는가?