아마존 세이지 메이커 다중 모델 엔드포인트(MME)를 사용하면 단일 엔드포인트에서 여러 모델을 비용 효율적으로 배포 및 호스팅한 다음 엔드포인트를 수평으로 확장하여 확장할 수 있습니다. 다음 그림에 나와 있는 것처럼 이는 머신 러닝(ML) 인프라 내에서 모델의 다중 테넌시를 구현하는 효과적인 기술입니다. SaaS(Software as a Service) 비즈니스에서 이 기능을 사용하여 ML 모델에 초개인화를 적용하는 동시에 비용을 절감하는 것을 보았습니다.
MME 작동 방식에 대한 개략적인 개요는 AWS Summit 비디오를 확인하십시오. ML을 다음 단계로 확장: SageMaker에서 수천 개의 모델 호스팅. MME가 지원하는 고도로 개인화된 다중 테넌트 사용 사례에 대해 자세히 알아보려면 다음을 참조하십시오. 다중 테넌트 SaaS 사용 사례에 대한 기계 학습 추론을 확장하는 방법.
이 게시물의 나머지 부분에서는 SageMaker MME의 기술 아키텍처에 대해 자세히 알아보고 다중 모델 엔드포인트를 최적화하기 위한 모범 사례를 공유합니다.
MME에 가장 적합한 사용 사례
SageMaker 다중 모델 끝점은 공유 제공 컨테이너를 통해 제공할 수 있고 동시에 모든 모델에 액세스할 필요가 없는 많은 수의 모델을 호스팅하는 데 적합합니다. 엔드포인트 인스턴스 메모리의 크기에 따라 메모리의 효율적인 사용을 최대화하기 위해 새 모델을 로드하기 위해 모델을 메모리에서 언로드할 수 있으므로 애플리케이션은 언로드된 모델에서 가끔 발생하는 지연 시간 스파이크를 허용해야 합니다.
MME는 또한 공유 컨테이너를 사용하여 여러 모델을 로드하기 때문에 동일한 ML 프레임워크를 사용하는 공동 호스팅 모델용으로 설계되었습니다. 따라서 모델 집합에 혼합 ML 프레임워크(예: PyTorch 및 TensorFlow)가 있는 경우 SageMaker 전용 엔드포인트 또는 다중 컨테이너 호스팅이 더 나은 선택입니다.
마지막으로, MME는 모델이 첫 번째 호출 시 로드되고 자주 사용되지 않는 모델을 메모리에서 오프로드하여 새 모델을 로드할 수 있기 때문에 가끔 콜드 스타트 대기 시간 패널티를 허용할 수 있는 애플리케이션에 적합합니다. 따라서 자주 액세스하는 모델과 자주 액세스하지 않는 모델이 혼합되어 있는 경우 다중 모델 엔드포인트는 더 적은 리소스와 더 높은 비용 절감으로 이 트래픽을 효율적으로 처리할 수 있습니다.
또한 고객이 모든 모델에 맞는 충분한 총 메모리 용량을 갖춘 MME 클러스터를 배포하여 모델 오프로드를 완전히 피하면서도 공유 추론 인프라로 인해 비용 절감을 달성하는 몇 가지 시나리오를 보았습니다.
모델 서빙 컨테이너
SageMaker Inference Toolkit 또는 MME와 호환되는 컨테이너를 제공하는 사전 구축된 SageMaker 모델을 사용하는 경우 컨테이너에는 다중 모델 서버 (JVM 프로세스) 실행 중입니다. MMS(Multi Model Server)를 모델 제공 컨테이너에 통합하는 가장 쉬운 방법은 다음을 사용하는 것입니다. SageMaker 모델 서빙 컨테이너 MME와 호환됩니다(작업 유형=추론 및 CPU/GPU=CPU인 항목을 찾으십시오). MMS는 딥 러닝 모델을 제공하기 위한 사용하기 쉬운 오픈 소스 도구입니다. 단일 호스트에서 여러 모델을 제공하고 관리하기 위해 웹 서버와 함께 REST API를 제공합니다. 그러나 MMS를 반드시 사용해야 하는 것은 아닙니다. 구현하는 한 자체 모델 서버를 구현할 수 있습니다. MME에 필요한 API.
MME 플랫폼의 일부로 사용될 때 MMS 또는 자체 모델 서버에 대한 모든 예측, 로드 및 언로드 API 호출은 MME 데이터 플레인 컨트롤러를 통해 전달됩니다. 데이터 플레인 컨트롤러의 API 호출은 인스턴스 외부의 무단 액세스를 방지하기 위해서만 로컬 호스트를 통해 이루어집니다. MMS의 주요 이점 중 하나는 광범위한 딥 러닝 프레임워크에서 호환되는 모델 로드, 언로드 및 호출을 위한 표준화된 인터페이스를 사용할 수 있다는 것입니다.
MMS의 고급 구성
모델 제공에 MMS를 사용하기로 선택한 경우 다음 고급 구성을 고려하여 MME 인스턴스의 확장성과 처리량을 최적화하십시오.
모델당 추론 병렬 처리 증가
MMS는 다음 값을 기반으로 모델당 하나 이상의 Python 작업자 프로세스를 생성합니다. default_workers_per_model 구성 매개변수. 이러한 Python 작업자는 사용자가 제공하는 사전 처리, 예측 및 사후 처리 기능을 실행하여 각 개별 추론 요청을 처리합니다. 자세한 내용은 커스텀 서비스 핸들러 GitHub 레포.
둘 이상의 모델 작업자가 있으면 주어진 모델에서 제공할 수 있는 예측의 병렬도가 높아집니다. 그러나 많은 수의 CPU가 있는 인스턴스에서 많은 수의 모델을 호스팅하는 경우 MME의 부하 테스트를 수행하여 최적의 값을 찾아야 합니다. default_workers_per_model 메모리 또는 CPU 리소스 고갈을 방지합니다.
트래픽 급증을 위한 설계
엔드포인트 인스턴스 내의 각 MMS 프로세스에는 다음으로 구성할 수 있는 요청 대기열이 있습니다. job_queue_size 매개변수(기본값은 100). 이것은 모든 작업자 프로세스가 사용 중일 때 MMS가 대기열에 넣을 요청 수를 결정합니다. 모델당 최적의 작업자 수를 결정한 후 이 매개변수를 사용하여 엔드포인트 인스턴스의 응답성을 미세 조정하십시오.
최적의 모델당 작업자 비율에서는 대부분의 경우 기본값 100이면 충분합니다. 그러나 엔드포인트에 대한 요청 트래픽이 비정상적으로 급증하는 경우 엔드포인트가 빠르게 실패하여 애플리케이션에 제어를 전달하려는 경우 대기열 크기를 줄이고 엔드포인트가 스파이크를 흡수하도록 하려면 대기열 크기를 늘릴 수 있습니다. .
인스턴스당 메모리 리소스 최대화
모델당 여러 작업자 프로세스를 사용하는 경우 기본적으로 각 작업자 프로세스는 자체 모델 복사본을 로드합니다. 이렇게 하면 다른 모델에 사용 가능한 인스턴스 메모리가 줄어들 수 있습니다. 구성 매개변수를 설정하여 작업자 프로세스 간에 단일 모델을 공유하여 메모리 사용률을 최적화할 수 있습니다. preload_model=참. 여기서는 메모리 효율성이 더 높은 감소된 추론 병렬 처리(단일 모델 인스턴스로 인한)를 트레이드 오프합니다. 여러 작업자 프로세스와 함께 이 설정은 모델 지연 시간이 낮지만 추론 요청당 사전 처리 및 사후 처리(작업자 프로세스에서 수행)가 더 많은 사용 사례에 적합할 수 있습니다.
MMS 고급 구성에 대한 값 설정
MMS는 config.properties 파일을 사용하여 구성을 저장합니다. MMS는 다음 순서를 사용하여 이 config.properties 파일을 찾습니다.
- 경우
MMS_CONFIG_FILE환경 변수가 설정되면 MMS는 환경 변수에서 구성을 로드합니다. - 경우
--mms-config매개변수가 MMS로 전달되면 매개변수에서 구성을 로드합니다. - 있을 경우
config.properties사용자가 MMS를 시작하는 현재 폴더에서config.properties현재 작업 디렉토리에서 파일.
위의 항목이 지정되지 않은 경우 MMS는 기본 제공 구성을 기본값으로 로드합니다.
다음은 명시적 구성 파일로 MMS를 시작하는 명령줄 예입니다.
엔드포인트 성능을 모니터링하기 위한 주요 지표
MME를 최적화하는 데 도움이 되는 주요 지표는 일반적으로 CPU 및 메모리 사용률 및 추론 지연 시간과 관련이 있습니다. 인스턴스 수준 메트릭은 MMS에서 내보내는 반면 지연 시간 메트릭은 MME에서 가져옵니다. 이 섹션에서는 MME를 이해하고 최적화하는 데 사용할 수 있는 일반적인 메트릭에 대해 설명합니다.
엔드포인트 인스턴스 수준 측정항목(MMS 측정항목)
에서 MMS 측정항목 목록, CPUUtilization 및 MemoryUtilization은 인스턴스 또는 MME 클러스터의 크기가 적절한지 여부를 평가하는 데 도움이 될 수 있습니다. 두 측정항목의 비율이 50–80%이면 MME가 적절한 크기입니다.
일반적으로 CPUUtilization이 낮고 MemoryUtilization이 높으면 자주 호출되지 않는 모델이 언로드되지 않음을 나타내므로 MME 클러스터가 과도하게 프로비저닝되었음을 나타냅니다. 이는 MME에 프로비저닝된 엔드포인트 인스턴스의 수가 최적보다 많기 때문일 수 있으며 따라서 최적보다 많은 집계 메모리를 메모리에 유지하기 위해 자주 액세스하지 않는 모델에 사용할 수 있습니다. 반대로, 이러한 지표의 사용률이 100%에 가깝다는 것은 클러스터가 충분히 프로비저닝되지 않았음을 의미하므로 클러스터 Auto Scaling 정책을 조정해야 합니다.
플랫폼 수준 측정항목(MME 측정항목)
에서 MME 측정항목의 전체 목록, 추론 요청의 지연 시간을 이해하는 데 도움이 되는 주요 지표는 ModelCacheHit입니다. 이 메트릭은 모델이 이미 메모리에 로드된 호출 요청의 평균 비율을 보여줍니다. 이 비율이 낮으면 MME 클러스터에 고유한 모델 호출 수에 대한 집계 메모리 용량이 충분하지 않아 모델이 메모리에서 자주 언로드될 수 있기 때문에 MME 클러스터가 충분히 프로비저닝되지 않았음을 나타냅니다.
MME 최적화를 위한 현장 교훈 및 전략
우리는 여러 고객의 대규모 MME 사용에서 다음 권장 사항을 확인했습니다.
더 작은 인스턴스를 사용하는 수평 확장이 더 큰 인스턴스를 사용하는 수직 확장보다 낫습니다.
더 적은 수의 엔드포인트 인스턴스에서 높은 RPS(초당 요청 수)를 실행할 때 모델 호출에서 조절이 발생할 수 있습니다. 초당 호출 수(인스턴스에서 동시에 발생할 수 있는 로드 및 언로드)에는 내부 제한이 있으므로 항상 더 작은 수의 인스턴스를 사용하는 것이 좋습니다. 더 많은 수의 더 작은 인스턴스를 실행하면 엔드포인트에 대한 이러한 제한의 총 총 용량이 더 커집니다.
더 작은 인스턴스로 수평 확장의 또 다른 이점은 더 높은 수준의 병렬 처리와 더 많은 수의 메모리 모델(이 게시물의 앞부분에서 설명)으로 MMS를 실행할 때 인스턴스 CPU 및 메모리 리소스가 고갈될 위험을 줄일 수 있다는 것입니다.
스래싱을 피하는 것은 공동 책임입니다.
대패 MME에서 모델은 메모리에서 자주 언로드되고 메모리 부족으로 인해 개별 인스턴스 또는 클러스터의 집계에서 다시 로드됩니다.
사용 관점에서 볼 때 인스턴스당 충분한 메모리 용량을 사용할 수 있도록 하고 사용 사례에 대한 클러스터에 대해 집계할 수 있도록 개별 엔드포인트 인스턴스의 크기를 적절하게 조정하고 MME 클러스터의 전체 크기를 적절하게 조정해야 합니다. MME 플랫폼의 라우터 플릿도 캐시 적중을 최대화합니다.
더 적은 수의 더 큰 메모리 인스턴스에서 너무 많은 모델을 bin 패킹하는 데 공격적이지 마십시오.
메모리는 인스턴스에서 인식해야 하는 유일한 리소스가 아닙니다. 다음 부하 테스트 결과에서 볼 수 있듯이 CPU와 같은 다른 리소스는 제약 요인이 될 수 있습니다. 다른 경우에는 너무 많은 모델이 로드되고 기본 ML 프레임워크(예: TensorFlow)가 사용 가능한 모델당 스레드를 생성하기 때문에 인스턴스에서 프로세스 ID와 같은 다른 커널 리소스가 소진되는 것을 관찰했습니다. vCPU.
다음 성능 테스트는 모델 지연 시간에 영향을 미치는 CPU 제약 조건의 예를 보여줍니다. 이 테스트에서 큰 인스턴스가 있는 단일 인스턴스 엔드포인트는 XNUMX개의 모델을 모두 메모리에 유지하기에 충분한 메모리를 가지고 있지만 XNUMX개의 작은 인스턴스가 있는 엔드포인트와 비교할 때 로드 시 모델 대기 시간이 비교적 더 나쁩니다.
단일 인스턴스 엔드포인트 모델 지연 시간
단일 인스턴스 엔드포인트 CPU 및 메모리 사용률
XNUMX개의 인스턴스 엔드포인트 모델 지연 시간
XNUMX개의 인스턴스 엔드포인트 CPU 및 메모리 사용률
성능과 비용 효율성을 모두 달성하려면 MME 클러스터를 더 적은 수의 더 작은 인스턴스로 적절한 크기로 조정하십시오. 이는 전체적으로 최적의 메모리와 CPU 용량을 제공하는 동시에 더 적지만 더 큰 메모리 인스턴스에 비해 상대적으로 비용이 비슷합니다.
MME 최적화를 위한 멘탈 모델
MME의 규모를 적절하게 조정할 때 항상 고려해야 하는 XNUMX가지 주요 메트릭이 있습니다.
- 모델의 수와 크기
- 주어진 시간에 호출된 고유 모델의 수
- 인스턴스 유형 및 크기
- 엔드포인트 뒤의 인스턴스 수
세 번째와 네 번째를 알려주기 때문에 처음 두 점으로 시작합니다. 예를 들어, 보유한 고유 모델의 수 또는 크기에 대해 엔드포인트 뒤에 인스턴스가 충분하지 않은 경우 엔드포인트에 대한 총 메모리가 낮아지고 MME가 메모리 안팎에서 모델을 자주 로드 및 언로드합니다.
마찬가지로 고유 모델에 대한 호출이 엔드포인트 뒤에 있는 모든 인스턴스의 총 메모리보다 높으면 캐시 적중률이 낮아집니다. 이는 인스턴스 크기(특히 메모리 용량)가 너무 작은 경우에도 발생할 수 있습니다.
모델이 메모리에 맞을 수 있지만 CPU 및 커널 프로세스 및 스레드 제한과 같은 다른 리소스가 고갈될 수 있기 때문에 정말 큰 메모리 인스턴스를 사용하여 수직으로 확장하면 문제가 발생할 수도 있습니다. MME에 대한 최적의 인스턴스 수와 크기를 얻기 위해 사전 프로덕션에서 수평 확장을 로드 테스트합니다.
요약
이 게시물에서는 MME 플랫폼에 대해 더 깊이 이해했습니다. MME가 적합한 기술 사용 사례를 배우고 MME 플랫폼의 아키텍처를 검토했습니다. MME 아키텍처 내에서 각 구성 요소의 역할과 성능에 직접적인 영향을 줄 수 있는 구성 요소에 대해 더 깊이 이해했습니다. 마지막으로 사용 사례에 대해 MME를 최적화하기 위해 조정할 수 있는 구성 매개변수와 최적의 성능을 유지하기 위해 모니터링해야 하는 메트릭에 대해 자세히 살펴보았습니다.
MME를 시작하려면 다음을 검토하십시오. XGBoost를 사용하는 Amazon SageMaker 다중 모델 엔드포인트 와 하나의 엔드포인트 뒤에 있는 하나의 컨테이너에서 여러 모델을 호스팅합니다..
저자에 관하여
시에드 재프리 AWS의 수석 솔루션 아키텍트입니다. 그는 중간 규모 조직, 대기업, 금융 서비스 및 ISV의 다양한 회사와 협력하여 클라우드에서 비용 효율적이고 확장 가능한 AI/ML 애플리케이션을 구축하고 운영할 수 있도록 지원합니다.
사우라브 트리칸데 Amazon SageMaker Inference의 수석 제품 관리자입니다. 그는 고객과 함께 일하는 데 열정적이며 기계 학습의 민주화라는 목표에 동기를 부여합니다. 그는 복잡한 ML 애플리케이션, 다중 테넌트 ML 모델 배포, 비용 최적화 및 딥 러닝 모델 배포의 접근성 향상과 관련된 핵심 과제에 중점을 둡니다. 여가 시간에 Saurabh는 하이킹, 혁신적인 기술 학습, TechCrunch 팔로우, 가족과 함께 시간 보내기를 즐깁니다.
