한 엔드포인트 뒤에 있는 한 컨테이너에 여러 모델 호스트 - 아마존 SageMaker

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

한 엔드포인트 뒤에 있는 한 컨테이너에 여러 모델 호스트

다중 모델 엔드포인트는 많은 수의 모델을 배포하도록 확장 가능하고 비용 효율적인 솔루션을 제공합니다. 이들은 동일한 리소스 플릿과 공유 제공 컨테이너를 사용하여 모든 모델을 호스팅합니다. 즉, 단일 모델 엔드포인트를 사용하는 것에 비해 엔드포인트 사용률을 높여 호스팅 비용을 절감합니다. 또한 Amazon이 메모리에서 모델 로딩을 SageMaker 관리하고 엔드포인트로 향하는 트래픽 패턴을 기반으로 모델을 조정하므로 배포 오버헤드가 줄어듭니다.

다음 다이어그램은 단일 모델 엔드포인트와 비교하여 다중 모델 엔드포인트의 작동 방식을 보여줍니다.

다중 모델 엔드포인트가 모델을 호스팅하는 방식과 단일 모델 엔드포인트가 모델을 호스팅하는 방식을 보여주는 다이어그램입니다.

다중 모델 엔드포인트는 공유 서비스 컨테이너에서 동일한 ML 프레임워크를 사용하는 다수의 모델을 호스팅하는 데 적합합니다. 자주 액세스하는 모델과 자주 액세스하지 않는 모델이 혼합되어 있는 경우 다중 모델 엔드포인트는 더 적은 리소스와 더 큰 비용 절감으로 이러한 트래픽을 효율적으로 처리할 수 있습니다. 애플리케이션은 자주 사용하지 않는 모델을 간접 호출할 때 가끔 발생하는 콜드 스타트 관련 지연 시간 페널티를 허용할 수 있어야 합니다.

다중 모델 엔드포인트는 CPU 및 GPU 지원 모델 호스팅을 모두 지원합니다. GPU 지원 모델을 사용하면 엔드포인트와 기본 가속 컴퓨팅 인스턴스의 사용량을 늘려 모델 배포 비용을 줄일 수 있습니다.

다중 모델 엔드포인트를 사용하면 모델 전체에서 메모리 리소스도 시분할할 수 있습니다. 모델들의 크기와 호출 지연 시간이 상당히 비슷한 경우에 가장 효과적입니다. 이 경우 다중 모델 엔드포인트는 모든 모델에서 인스턴스를 효과적으로 사용할 수 있습니다. 초당 트랜잭션 수(TPS) 또는 지연 시간 요구 사항이 상당히 높은 모델을 사용하는 경우에는 전용 엔드포인트에 이들을 호스팅하는 것이 좋습니다.

다음과 같은 기능을 가진 다중 모델 엔드포인트를 사용할 수 있습니다.

Amazon Elastic Inference에서는 multi-model-enabled 컨테이너를 사용할 수 없습니다.

AWS SDK for Python (Boto) 또는 SageMaker 콘솔을 사용하여 다중 모델 엔드포인트를 생성할 수 있습니다. CPU 지원 다중 모델 엔드포인트의 경우 다중 모델 서버 라이브러리를 통합하여 사용자 지정 구축 컨테이너로 엔드포인트를 만들 수 있습니다.

지원되는 알고리즘, 프레임워크 및 인스턴스

다중 모델 엔드포인트에서 사용할 수 있는 알고리즘, 프레임워크 및 인스턴스 유형에 대한 자세한 내용은 다음 섹션을 참조하세요.

CPU 지원 인스턴스를 사용하는 다중 모델 엔드포인트에 지원되는 알고리즘, 프레임워크 및 인스턴스

다음 알고리즘 및 프레임워크의 추론 컨테이너는 다중 모델 엔드포인트를 지원합니다.

다른 프레임워크나 알고리즘을 사용하려면 SageMaker 추론 툴킷을 사용하여 다중 모델 엔드포인트를 지원하는 컨테이너를 구축하십시오. 자세한 내용은 다중 모델 엔드포인트를 위한 자체 컨테이너 구축 SageMaker 을 참조하세요.

다중 모델 엔드포인트는 모든 CPU 인스턴스 유형을 지원합니다.

GPU 지원 인스턴스를 사용하는 다중 모델 엔드포인트용으로 지원되는 알고리즘, 프레임워크, 인스턴스

Triton Inference 서버를 통해 다중 모델 엔드포인트에서 여러 GPU 지원 모델을 호스팅할 수 있습니다. SageMaker 이는 NVIDIA® TensorRT™, PyTorch MXNet, Python, ONNX, XGBoost, scikit-learn, OpenVino, 사용자 지정 C++ 등과 같은 모든 주요 추론 프레임워크를 지원합니다. RandomForest

다른 프레임워크 또는 알고리즘을 사용하려면 Python 또는 C++용 Triton 백엔드를 사용하여 모델 논리를 작성하고 맞춤형 모델을 제공할 수 있습니다. 서버가 준비되면 한 엔드포인트 뒤에서 수백 개의 딥 러닝 모델을 배포할 수 있습니다.

다중 모델 엔드포인트는 다음 GPU 인스턴스 유형을 지원합니다.

인스턴스 패밀리 인스턴스 타입 vCPU vCPU당 메모리 GiB GPU GPU 메모리

p2

ml.p2.xlarge

4

15.25

1

12

p3

ml.p3.2xlarge

8

7.62

1

16

g5

ml.g5.xlarge

4

4

1

24

g5

ml.g5.2xlarge

8

4

1

24

g5

ml.g5.4xlarge

16

4

1

24

g5

ml.g5.8xlarge

32

4

1

24

g5

ml.g5.16xlarge

64

4

1

24

g4dn

ml.g4dn.xlarge

4

4

1

16

g4dn

ml.g4dn.2xlarge

8

4

1

16

g4dn

ml.g4dn.4xlarge

16

4

1

16

g4dn

ml.g4dn.8xlarge

32

4

1

16

g4dn

ml.g4dn.16xlarge

64

4

1

16

다중 모델 엔드포인트를 위한 샘플 노트북

다중 모델 엔드포인트 사용 방법을 자세히 알아보려면 다음 샘플 노트북을 사용해 보세요.

에서 이전 예제를 실행하는 데 사용할 수 있는 Jupyter 노트북 인스턴스를 생성하고 액세스하는 방법에 대한 지침은 을 참조하십시오. SageMaker 아마존 SageMaker 노트북 인스턴스 Notebook 인스턴스를 만들고 연 후 SageMaker Examples 탭을 선택하면 모든 샘플 목록이 표시됩니다. SageMaker 다중 모델 엔드포인트 노트북은 ADVANCED FUNCTIONALITY(고급 특성) 단원에 있습니다. 노트북을 열려면 사용 탭을 선택한 후 사본 생성을 선택합니다.

다중 모델 엔드포인트의 사용 사례에 대한 자세한 내용은 다음 블로그 및 리소스를 참조하세요.

다중 모델 엔드포인트 작동 방식

SageMaker 컨테이너 메모리의 다중 모델 엔드포인트에 호스팅된 모델의 수명 주기를 관리합니다. 엔드포인트를 생성할 때 Amazon S3 버킷의 모든 모델을 컨테이너로 다운로드하는 대신, 모델을 호출할 때 SageMaker 동적으로 로드하고 캐싱합니다. 특정 모델에 대한 호출 요청을 SageMaker 받으면 모델은 다음을 수행합니다.

  1. 엔드포인트 뒤의 인스턴스로 요청을 라우팅합니다.

  2. S3 버킷에서 해당 인스턴스의 스토리지 볼륨으로 모델을 다운로드합니다.

  3. 해당 가속 컴퓨팅 인스턴스의 컨테이너 메모리(CPU 또는 GPU 지원 인스턴스가 있는지 여부에 따라 CPU 또는 GPU)로 모델을 로드합니다. 모델이 이미 컨테이너 메모리에 로드되어 있는 경우 모델을 다운로드하고 로드할 필요가 SageMaker 없으므로 호출 속도가 더 빠릅니다.

SageMaker 모델에 대한 요청을 모델이 이미 로드된 인스턴스로 계속 라우팅합니다. 그러나 모델이 많은 호출 요청을 수신하고 다중 모델 엔드포인트에 대한 추가 인스턴스가 있는 경우 트래픽을 수용하기 위해 일부 요청을 다른 인스턴스로 SageMaker 라우팅합니다. 모델이 두 번째 인스턴스에 아직 로드되지 않은 경우 해당 인스턴스의 스토리지 볼륨으로 모델이 다운로드되고 컨테이너 메모리에 로드됩니다.

인스턴스의 메모리 사용률이 높아 다른 모델을 메모리로 SageMaker 로드해야 하는 경우 해당 인스턴스의 컨테이너에서 사용하지 않는 모델을 언로드하여 모델을 로드하기에 충분한 메모리가 있는지 확인합니다. 언로드된 모델은 인스턴스의 스토리지 볼륨에 남아 있으며 나중에 S3 버킷에서 다시 다운로드하지 않고도 컨테이너 메모리로 로드할 수 있습니다. 인스턴스의 스토리지 볼륨이 해당 용량에 도달하면 스토리지 볼륨에서 사용하지 않는 모델을 모두 SageMaker 삭제합니다.

모델을 삭제하려면 요청 전송을 중단하고 S3 버킷에서 삭제하십시오. SageMaker 서빙 컨테이너에서 다중 모델 엔드포인트 기능을 제공합니다. 다중 모델 엔드포인트에 모델을 추가하고 삭제할 때 엔드포인트 자체를 업데이트할 필요가 없습니다. 모델을 추가하려면 S3 버킷에 모델을 업로드하고 호출합니다. 사용하기 위해 코드 변경을 수행할 필요가 없습니다.

참고

다중 모델 엔드포인트를 업데이트하면 다중 모델 엔드포인트의 스마트 라우팅이 트래픽 패턴에 맞게 조정되므로 엔드포인트의 초기 간접 호출 요청의 지연 시간이 길어질 수 있습니다. 하지만 트래픽 패턴을 학습하고 나면 가장 자주 사용되는 모델에서 지연 시간이 짧아질 수 있습니다. 사용 빈도가 낮은 모델은 인스턴스에 동적으로 로드되므로 콜드 스타트 지연 시간이 약간 발생할 수 있습니다.

SageMaker 다중 모델 엔드포인트 모델 캐싱 동작 설정

기본적으로 다중 모델 엔드포인트는 자주 사용되는 모델을 메모리 (CPU 또는 GPU 지원 인스턴스가 있는지 여부에 따라 CPU 또는 GPU)와 디스크에 캐시하여 지연 시간이 짧은 추론을 제공합니다. 캐시된 모델은 컨테이너의 메모리나 디스크 공간이 부족하여 새로 대상 지정된 모델을 수용할 수 없는 경우에만 디스크에서 언로드 및/또는 삭제됩니다.

create_model을 호출할 때 파라미터 ModelCacheSetting을 설정하여 다중 모델 엔드포인트의 캐싱 동작을 변경하고 모델 캐싱을 명시적으로 활성화 또는 비활성화할 수 있습니다.

모델 캐싱의 이점이 없는 사용 사례의 경우 ModelCacheSetting 파라미터 값을 Disabled로 설정하는 것이 좋습니다. 많은 수의 모델을 엔드포인트에서 제공해야 하는데 각 모델이 한 번만(또는 매우 이따금씩) 호출되는 경우를 예로 들 수 있습니다. 이러한 사용 사례의 경우 ModelCacheSetting 파라미터 값을 Disabled로 설정하면 기본 캐싱 모드에 비해 invoke_endpoint 요청에 대한 초당 트랜잭션 수(TPS)를 늘릴 수 있습니다. 이러한 사용 사례에서 TPS가 더 높은 SageMaker 이유는 요청 후 다음을 수행하기 때문입니다. invoke_endpoint

  • 모델을 메모리에서 비동기식으로 언로드하고 간접 호출된 직후 디스크에서 모델을 삭제합니다.

  • 추론 컨테이너에서 모델을 다운로드하고 로드할 때 더 높은 동시성을 제공합니다. CPU 및 GPU 지원 엔드포인트 모두에 대해, 동시성은 컨테이너 인스턴스의 vCPU 수에 영향을 미칩니다.

다중 모델 엔드포인트의 SageMaker ML 인스턴스 유형 선택에 대한 지침은 을 참조하십시오. 다중 모델 엔드포인트 배포를 위한 인스턴스 권장 사항

다중 모델 엔드포인트 배포를 위한 인스턴스 권장 사항

다중 모델 엔드포인트에 대한 SageMaker ML 인스턴스 유형을 선택할 때 고려해야 할 몇 가지 항목이 있습니다.

  • 서비스해야 하는 모든 모델에 대해 충분한 Amazon Elastic Block Store(Amazon EBS) 용량을 프로비저닝합니다.

  • 성능(콜드 스타트 최소화)과 비용(인스턴스 용량을 과도하게 프로비저닝하지 않음)의 균형을 유지합니다. 엔드포인트 및 다중 모델 엔드포인트의 각 인스턴스 유형에 연결되는 SageMaker 스토리지 볼륨의 크기에 대한 자세한 내용은 을 참조하십시오. 호스트 인스턴스 스토리지 볼륨

  • MultiModel 모드에서 실행되도록 구성된 컨테이너의 경우, 인스턴스에 프로비저닝된 스토리지 볼륨은 기본 SingleModel 모드보다 더 큽니다. 따라서 SingleModel 모드에 비해 인스턴스 스토리지 볼륨에 더 많은 모델을 캐싱할 수 있습니다.

SageMaker 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 스토리지와 함께 제공되므로 다중 모델 엔드포인트를 호스팅하는 이러한 ML 컴퓨팅 인스턴스에 Amazon EBS 스토리지 볼륨을 연결하지 SageMaker 않습니다. Auto Scaling은 모델의 크기가 비슷하고 동질적일 때, 즉 추론 지연 요구 사항과 리소스 요구 사항이 비숫한 경우에 가장 잘 작동합니다.

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

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

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

모델 캐시 히트 평가

Amazon CloudWatch 메트릭은 모델을 평가하는 데 도움이 될 수 있습니다. 다중 모델 엔드포인트에서 사용할 수 있는 지표에 대한 자세한 내용은 CloudWatch 다중 모델 엔드포인트 배포를 위한 메트릭 단원을 참조하세요.

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