기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 다중 모델 엔드포인트 배포를 위한 인스턴스 권장 사항
<a name="multi-model-endpoint-instance"></a>

다중 모델 엔드포인트에 대해 SageMaker AI ML 인스턴스 유형을 선택할 때 고려해야 할 몇 가지 항목이 있습니다.
+ 서비스해야 하는 모든 모델에 대해 충분한 [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) 용량을 프로비저닝합니다.
+ 성능(콜드 스타트 최소화)과 비용(인스턴스 용량을 과도하게 프로비저닝하지 않음)의 균형을 유지합니다. 엔드포인트의 각 인스턴스 유형과 다중 모델 엔드포인트에서 SageMaker AI에 연결되는 스토리지 볼륨의 크기에 대한 자세한 내용은 [인스턴스 스토리지 볼륨](host-instance-storage.md) 섹션을 참조하세요.
+ `MultiModel` 모드에서 실행되도록 구성된 컨테이너의 경우, 인스턴스에 프로비저닝된 스토리지 볼륨은 기본 `SingleModel` 모드보다 더 큽니다. 따라서 `SingleModel` 모드에 비해 인스턴스 스토리지 볼륨에 더 많은 모델을 캐싱할 수 있습니다.

SageMaker AI ML 인스턴스 유형을 선택할 때 다음 사항을 고려합니다.
+ 다중 모델 엔드포인트는 현재 모든 CPU 인스턴스 유형과 단일 GPU 인스턴스 유형에 지원됩니다.
+ 모델 크기(인스턴스의 메모리에 로드할 수 있는 모델 수)와 함께 다중 모델 엔드포인트 뒤에 호스팅하려는 모델에 대한 트래픽 분산(액세스 패턴)의 경우 다음 정보를 염두에 두세요.
  + 인스턴스의 메모리 양을 모델을 로드하기 위한 캐시 공간으로 생각하고, vCPU 수를 로드된 모델에서 추론을 수행할 수 있는 동시성 한도라고 생각하면 됩니다(모델 간접 호출이 CPU에 바인딩된다고 가정함).
  + CPU 지원 인스턴스의 경우 vCPU 수는 인스턴스당 최대 동시 간접 호출 수에 영향을 줍니다(모델 간접 호출이 CPU에 바인딩된다고 가정함). vCPU의 양이 많을수록 더 많은 고유 모델을 동시에 간접적으로 호출할 수 있습니다.
  + GPU 지원 인스턴스의 경우, 인스턴스 및 GPU 메모리 용량이 증가할수록 더 많은 모델을 로드하고 추론 요청을 처리할 수 있는 상태가 됩니다.
  + CPU 및 GPU 지원 인스턴스의 경우, 특히 여러 인스턴스가 있는 다중 모델 엔드포인트에서 사용되지 않는 모델을 언로드할 수 있도록 약간의 ‘Slack 메모리를 확보합니다. 인스턴스 또는 가용 영역에 장애가 발생하면 해당 인스턴스의 모델이 엔드포인트 뒤에 있는 다른 인스턴스로 다시 라우팅됩니다.
+ 로드/다운로드 시간 허용 오차 확인:
  + d 인스턴스 유형 패밀리(예: m5d, c5d 또는 r5d) 및 g5s에는 NVMe(비휘발성 메모리 Express) SSD가 함께 제공됩니다. 이 SSD는 높은 I/O 성능을 제공하기 때문에 모델을 스토리지 볼륨으로 다운로드하고 컨테이너가 스토리지 볼륨에서 모델을 로드하는 데 걸리는 시간을 줄일 수 있습니다.
  + d 및 g5 인스턴스 유형은 NVMe SSD 스토리지와 함께 제공되므로 SageMaker AI에서는 다중 모델 엔드포인트를 호스팅하는 이러한 ML 컴퓨팅 인스턴스에 Amazon EBS 스토리지 볼륨을 연결하지 않습니다. Auto Scaling은 모델의 크기가 비슷하고 동질적일 때, 즉 추론 지연 요구 사항과 리소스 요구 사항이 비숫한 경우에 가장 잘 작동합니다.

또한 다음 지침을 사용하여 다중 모델 엔드포인트에서 모델 로딩을 최적화할 수 있습니다.

**모든 대상 지정 모델을 메모리에 담을 수 없는 인스턴스 유형 선택**

경우에 따라 모든 대상 모델을 한 번에 메모리에 저장할 수 없는 인스턴스 유형을 선택하여 비용을 절감할 수 있습니다. SageMaker AI는 새로 대상으로 지정된 모델을 위한 공간을 확보하기 위해 메모리가 부족할 때 모델을 동적으로 로드 해제합니다. 이따금씩 요청되는 모델의 경우 동적 로드 지연 시간이 발생합니다. 지연 시간 요구가 더 엄격한 경우에는 크기가 더 큰 인스턴스 유형이나 더 많은 인스턴스를 선택할 수 있습니다. 성능 테스트 및 분석에 시간을 미리 투자하면 성공적인 프로덕션 배포에 도움이 됩니다.

**모델 캐시 히트 평가**

Amazon CloudWatch 지표는 모델을 평가하는 데 도움이 될 수 있습니다. 다중 모델 엔드포인트에서 사용할 수 있는 지표에 대한 자세한 내용은 [다중 모델 엔드포인트 배포에 대한 CloudWatch 지표](multi-model-endpoint-cloudwatch-metrics.md) 섹션을 참조하세요.

 `ModelCacheHit` 지표에 대한 `Average` 통계를 사용하여 모델이 이미 로드된 요청의 비율을 모니터링할 수 있습니다. `ModelUnloadingTime` 지표에 대한 `SampleCount` 통계를 사용하여 일정 기간 동안 컨테이너로 전송된 언로드 요청 수를 모니터링할 수 있습니다. 모델이 너무 자주 언로드되는 경우(모델 작업 세트에 캐시 공간이 부족하여 모델이 언로드된 후 다시 로드되는 *스래싱* 표시기)에는 메모리 용량이 더 큰 인스턴스 유형을 사용하거나 다중 모델 엔드포인트 뒤의 인스턴스 수를 늘리는 것이 좋습니다. 여러 인스턴스가 있는 다중 모델 엔드포인트의 경우, 모델이 하나 이상의 인스턴스에 로드될 수 있습니다.