GPU와 함께 Amazon SageMaker 다중 모델 엔드포인트를 사용하여 모델 서비스를 위한 대규모 고성능 달성

아마존 세이지 메이커 다중 모델 끝점 (MME)는 많은 수의 기계 학습(ML) 모델을 배포하는 확장 가능하고 비용 효율적인 방법을 제공합니다. 단일 엔드포인트 뒤의 단일 서빙 컨테이너에 여러 ML 모델을 배포할 수 있는 기능을 제공합니다. 여기에서 SageMaker는 모델 로드 및 언로드를 관리하고 트래픽 패턴에 따라 리소스를 확장합니다. 호스팅 리소스를 공유 및 재사용하고 많은 양의 모델을 관리하는 운영 부담을 줄이는 이점을 얻을 수 있습니다.

11월 2022에서, MME는 GPU에 대한 지원을 추가했습니다.s를 사용하면 단일 GPU 장치에서 여러 모델을 실행하고 단일 엔드포인트 뒤에서 GPU 인스턴스를 확장할 수 있습니다. 이는 GPU를 사용한 가속화된 컴퓨팅의 이점을 누리는 DNN(심층 신경망) 모델에 대한 강력한 MME 수요를 충족합니다. 여기에는 컴퓨터 비전(CV), 자연어 처리(NLP) 및 생성 AI 모델이 포함됩니다. 요구 이유는 다음과 같습니다.

• DNN 모델은 일반적으로 크기가 크고 복잡하며 빠른 속도로 계속 성장하고 있습니다. NLP 모델을 예로 들면, 많은 모델이 수십억 개의 매개변수를 초과하므로 GPU가 짧은 대기 시간과 높은 처리량 요구 사항을 충족해야 합니다.
• 우리는 개별 사용자에게 초개인화된 경험을 제공하기 위해 이러한 모델을 사용자 정의할 필요성이 증가하는 것을 관찰했습니다. 이러한 모델의 수가 증가함에 따라 많은 모델을 대규모로 배포하고 운영할 수 있는 더 쉬운 솔루션이 필요합니다.
• GPU 인스턴스는 비용이 많이 들기 때문에 이러한 인스턴스를 최대한 재사용하여 GPU 활용도를 극대화하고 운영 비용을 줄이려고 합니다.

이러한 모든 이유는 DNN 모델에 이상적인 옵션으로 GPU가 있는 MME를 가리키지만 사용 사례 요구 사항을 충족하는 올바른 끝점 구성을 찾기 위해 부하 테스트를 수행하는 것이 좋습니다. 인스턴스 유형, 인스턴스 수, 모델 크기 및 모델 아키텍처와 같은 많은 요인이 로드 테스트 결과에 영향을 줄 수 있습니다. 또한 부하 테스트는 반복적인 시행 착오 방식이 아닌 올바른 메트릭을 사용하여 자동 확장 전략을 안내하는 데 도움이 될 수 있습니다.

이러한 이유로 GPU를 사용하여 MME에서 적절한 부하 테스트를 수행하고 ML 사용 사례에 가장 적합한 구성을 찾는 데 도움이 되도록 이 게시물을 작성했습니다. 다양한 인스턴스 유형에서 MME를 사용하여 호스팅되는 NLP 및 CV에서 가장 인기 있는 일부 DNN 모델에 대한 부하 테스트 결과를 공유합니다. 자체 배포 구성에 대한 정보에 입각한 결정을 내리는 데 도움이 되도록 테스트 결과의 통찰력과 결론을 요약합니다. 그 과정에서 GPU에서 MME에 대한 부하 테스트를 수행하는 데 권장되는 접근 방식도 공유합니다. 권장되는 도구 및 기술은 인스턴스 유형별로 로드할 수 있는 최적의 모델 수를 결정하고 최고의 가격 대비 성능을 달성하는 데 도움이 됩니다.

솔루션 개요

GPU를 사용하는 MME 및 MME에 대한 소개는 다음을 참조하십시오. 다중 모델 엔드포인트 생성 및 Amazon SageMaker 다중 모델 엔드포인트를 사용하여 GPU에서 여러 딥 러닝 모델 실행. 이 게시물의 부하 테스트 컨텍스트에 대해 다음에서 샘플 코드를 다운로드할 수 있습니다. GitHub 레포 결과를 재현하거나 자신의 모델을 벤치마킹하기 위한 템플릿으로 사용할 수 있습니다. 리포지토리에는 두 개의 노트북이 제공됩니다. 하나는 CV 모델 로드 테스트용이고 다른 하나는 NLP용입니다. ml.g4dn.2xlarge, ml.g5.2xlarge 및 ml.p3.2xlarge와 같은 다양한 유형의 GPU 인스턴스에서 다양한 크기와 아키텍처의 여러 모델을 벤치마킹했습니다. 이렇게 하면 각 인스턴스 및 모델 유형에 대해 다음 지표에서 합리적인 성능 단면을 제공해야 합니다.

• GPU 메모리에 로드할 수 있는 최대 모델 수
• 각 추론 쿼리에 대해 클라이언트 측에서 관찰되는 종단 간 응답 대기 시간
• 끝점이 오류 없이 처리할 수 있는 초당 최대 쿼리 처리량
• 실패한 요청이 관찰되기 전 인스턴스당 최대 현재 사용자 수

다음 표에는 테스트된 모델이 나열되어 있습니다.

다음 표에는 테스트된 GPU 인스턴스가 나열되어 있습니다.

앞서 언급했듯이 코드 예 다른 모델 및 인스턴스 유형에 채택될 수 있습니다.

MME는 현재 단일 GPU 인스턴스만 지원합니다. 지원되는 인스턴스 유형 목록은 다음을 참조하십시오. 지원되는 알고리즘, 프레임워크 및 인스턴스.

벤치마킹 절차는 다음 단계로 구성됩니다.

1. 모델 허브에서 선행 학습된 모델을 검색합니다.
2. SageMaker MME에서 제공할 모델 아티팩트를 준비합니다(참조: Amazon SageMaker 다중 모델 엔드포인트를 사용하여 GPU에서 여러 딥 러닝 모델 실행 상세 사항은).
3. GPU 인스턴스에 SageMaker MME를 배포합니다.
4. 지정된 임계값 내에서 GPU 메모리에 로드할 수 있는 최대 모델 수를 결정합니다.
5. Locust Load Testing Framework를 사용하여 인스턴스에 로드된 모델을 무작위로 호출하는 트래픽을 시뮬레이션합니다.
6. 데이터를 수집하고 결과를 분석합니다.
7. 선택적으로 모델을 TensorRT로 컴파일한 후 2~6단계를 반복합니다.

4단계와 5단계는 더 자세히 살펴보아야 합니다. SageMaker GPU MME 내의 모델은 동적 방식으로 메모리에 로드됩니다. 따라서 4단계에서 초기 모델 아티팩트를 아마존 단순 스토리지 서비스 (Amazon S3) 모델을 호출하여 메모리에 로드합니다. 초기 호출 후 GPU 메모리 소비량을 측정하고, 초기 모델 사본을 만들고, 모델 사본을 호출하여 메모리에 로드하고, 총 GPU 메모리 소비량을 다시 측정합니다. 이 프로세스는 GPU 메모리 사용률의 지정된 백분율 임계값에 도달할 때까지 반복됩니다. 벤치마크에서는 임계값을 90%로 설정하여 더 큰 배치에서 추론하거나 자주 사용하지 않는 다른 모델을 로드할 공간을 남겨두기 위한 합리적인 메모리 버퍼를 제공합니다.

사용자 트래픽 시뮬레이션

모델 수를 결정한 후 다음을 사용하여 로드 테스트를 실행할 수 있습니다. Locust 부하 테스트 프레임워크. 부하 테스트는 무작위 모델에 대한 사용자 요청을 시뮬레이션하고 응답 대기 시간 및 처리량과 같은 메트릭을 자동으로 측정합니다.

Locust는 사용자 지정 트래픽 패턴을 정의할 수 있는 사용자 지정 부하 테스트 형태를 지원합니다. 이 벤치마크에 사용된 모양은 다음 차트에 나와 있습니다. 처음 30초 동안 엔드포인트는 10명의 동시 사용자로 워밍업됩니다. 30초 후 새로운 사용자가 초당 20명의 속도로 생성되어 40초 지점에서 동시 사용자 20명에 도달합니다. 그런 다음 엔드포인트는 60초가 될 때까지 40명의 동시 사용자로 꾸준히 벤치마킹되며, 이 시점에서 Locust는 다시 동시 사용자가 200명이 될 때까지 초당 200명씩 사용자를 늘리기 시작합니다. 이러한 증가 및 꾸준한 테스트 패턴은 엔드포인트가 최대 XNUMX명의 동시 사용자에 도달할 때까지 반복됩니다. 사용 사례에 따라 locust_benchmark_sm.py에서 부하 테스트 형태를 조정하여 예상되는 트래픽 패턴을 보다 정확하게 반영할 수 있습니다. 예를 들어 더 큰 언어 모델을 호스팅하려는 경우 단일 인스턴스에서 호스팅되는 모델에는 동시 사용자가 XNUMX명인 부하 테스트가 적합하지 않을 수 있으므로 사용자 수를 줄이거나 인스턴스 수를 늘릴 수 있습니다. 더 긴 기간 동안 엔드포인트의 안정성을 보다 정확하게 측정하기 위해 부하 테스트 기간을 연장할 수도 있습니다.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

PyTorch 또는 TensorRT를 사용하여 모두 일관된 서비스 기반에서 실행되는 동종 모델로 엔드포인트를 벤치마킹했습니다. 이는 MME가 메모리 소비 및 응답 시간과 같은 유사한 특성을 가진 많은 모델을 호스팅하는 데 가장 적합하기 때문입니다. 벤치마킹 템플릿은 GitHub 레포 MME에서 이기종 모델을 제공하는 것이 원하는 성능과 안정성을 제공하는지 여부를 결정하는 데 여전히 사용할 수 있습니다.

CV 모델에 대한 벤치마크 결과

cv-benchmark.ipynb 노트북을 사용하여 컴퓨터 비전 모델에 대한 부하 테스트를 실행합니다. 사전 훈련된 모델 이름과 인스턴스 유형 매개변수를 조정하여 다양한 모델 및 인스턴스 유형 조합에서 부하 테스트를 수행할 수 있습니다. 우리는 의도적으로 가장 작은 것부터 가장 큰 것까지 다양한 크기 범위에서 세 가지 CV 모델을 테스트했습니다. resnet50 (25만), convnext_base (88M) 및 vit_large_patch16_224 (304M). 이 목록 이외의 모델을 선택하는 경우 코드에 맞게 조정해야 할 수 있습니다. 또한 노트북은 입력 이미지 모양을 224x224x3 이미지 텐서로 기본 설정합니다. 다른 크기의 이미지를 사용하는 모델을 벤치마킹해야 하는 경우 그에 따라 입력 모양을 조정해야 합니다.

전체 노트북을 실행한 후 몇 가지 성능 분석 시각화를 얻을 수 있습니다. 처음 두 개는 동시 사용자 증가와 관련하여 모델 성능을 자세히 설명합니다. 다음 그림은 ResNet50 ml.g4dn.2xlarge에서 실행되는 모델, PyTorch(왼쪽)와 TensorRT(오른쪽) 비교. 상단 라인 그래프는 x축에 반영된 동시 클라이언트 작업자 수가 증가하면서 y축에 모델 대기 시간 및 처리량을 보여줍니다. 하단 막대 차트는 성공한 요청과 실패한 요청의 수를 보여줍니다.

우리가 테스트한 모든 컴퓨터 비전 모델을 살펴보면 다음을 관찰했습니다.

• 대기 시간(밀리초)은 더 높고 처리량(초당 요청)은 모델이 클수록 더 낮습니다(resnet50 > convnext_base > vit_large_patch16_224).
• 지연 시간 증가는 더 많은 요청이 추론 서버에서 대기하므로 사용자 수에 비례합니다.
• 대형 모델은 더 많은 컴퓨팅 리소스를 소비하며 소형 모델보다 적은 수의 사용자로 최대 처리량 한도에 도달할 수 있습니다. 이것은 다음과 같이 관찰됩니다. vit_large_patch16_224 140명의 동시 사용자에서 첫 번째 실패한 요청을 기록한 모델. 테스트한 다른 두 모델보다 훨씬 크기 때문에 더 높은 동시성에서도 전체적으로 실패한 요청이 가장 많았습니다. 이는 140명 이상의 동시 사용자를 지원하려는 경우 엔드포인트가 단일 인스턴스 이상으로 확장되어야 한다는 분명한 신호입니다.

노트북 실행이 끝나면 네 가지 주요 지표 각각에 대한 PyTorch 대 TensorRT 모델의 요약 비교도 얻을 수 있습니다. 벤치마크 테스트에서 CV 모델은 모두 TensorRT 컴파일 후 모델 성능이 향상되었습니다. 우리의 ResNet50 다시 예시로 모델을 실행하면 대기 시간이 32% 감소한 반면 처리량은 18% 증가했습니다. 최대 동시 사용자 수는 동일하게 유지되었지만 ResNet50, 다른 두 모델 모두 지원할 수 있는 동시 사용자 수가 14% 향상되었습니다. 그러나 TensorRT 성능 향상은 더 높은 메모리 사용률을 희생하여 MME가 로드하는 모델의 수를 줄였습니다. CNN(컨볼루션 신경망)을 사용하는 모델의 경우 그 영향이 더 큽니다. 실제로 ResNet50 모델은 PyTorch에서 TensorRT로 이동하는 GPU 메모리를 약 50배 사용하여 로드된 모델이 46% 더 적었습니다(23개 대 XNUMX개). 다음 섹션에서 이 동작을 자세히 진단합니다.

NLP 모델에 대한 벤치마크 결과

NLP 모델의 경우 nlp-benchmark.ipynb 노트북을 사용하여 부하 테스트를 실행합니다. 노트북의 설정은 매우 유사해야 합니다. bert-base-uncased(109M) 및 roberta-large(335M)의 두 가지 NLP 모델을 테스트했습니다. 사전 훈련된 모델과 토크나이저는 모두 Hugging Face 허브에서 다운로드되며 테스트 페이로드는 샘플 문자열을 사용하여 토크나이저에서 생성됩니다. 최대 시퀀스 길이는 기본적으로 128입니다. 더 긴 문자열을 테스트해야 하는 경우 해당 매개변수를 조정해야 합니다. NLP 노트북을 통해 실행하면 동일한 시각화 세트인 Pytorch(왼쪽)와 TensorRT(오른쪽)가 생성됩니다.

이들로부터 우리는 NLP 모델에 대한 TensorRT의 훨씬 더 많은 성능 이점을 관찰했습니다. 복용 roberta-large 예를 들어 ml.g4dn.2xlarge 인스턴스의 모델에서 추론 대기 시간은 180밀리초에서 56밀리초(70% 향상)로 크게 감소했으며 처리량은 초당 406개 요청에서 33개로 167% 향상되었습니다. 사용자 50% 증가; 실패한 요청은 원래 PyTorch 모델의 경우 180명에 비해 동시 사용자 수가 120명에 도달할 때까지 관찰되지 않았습니다. 메모리 활용 측면에서 우리는 TensorRT에 대해 로드된 모델이 하나 더 적었습니다(XNUMX개 모델에서 XNUMX개 모델로). 그러나 부정적인 영향은 CNN 기반 모델에서 관찰한 것과 비교하여 훨씬 작습니다.

메모리 활용도 분석

다음 표는 PyTorch에서 TensorRT로 이동하는 메모리 사용률 영향에 대한 전체 분석을 보여줍니다. 앞에서 CNN 기반 모델이 더 부정적인 영향을 받는다고 언급했습니다. 그만큼 ResNet50 모델은 세 가지 GPU 인스턴스 유형 모두에서 로드되는 모델 수가 50% 이상 감소했습니다. Convnext_base 전반적으로 약 70%로 더 큰 감소를 보였습니다. 반면에 변압기 모델에 미치는 영향은 적거나 혼합되어 있습니다. vit_large_patch16_224 및 roberta-large 각각 평균 ​​약 20% 및 3% 감소한 반면, bert-base-uncased 약 40% 향상을 보였다.

대기 시간, 처리량 및 안정성의 우수한 성능과 로드된 최대 모델 수에 대한 미미한 영향과 관련하여 모든 데이터 포인트를 전체적으로 살펴보면 변압기 기반 모델 아키텍처에 TensorRT 모델을 권장합니다. CNN의 경우 추가 호스팅 인프라 비용보다 성능 이점이 더 큰지 확인하려면 추가 비용 성능 분석이 필요하다고 생각합니다.

다음 표에는 세 가지 GPU 인스턴스 유형 전체의 모든 지표에 대한 전체 벤치마크 결과가 나열되어 있습니다.

다음 표에는 모든 인스턴스 유형에 대한 결과가 요약되어 있습니다. ml.g5.2xlarge 인스턴스는 최고의 성능을 제공하는 반면, ml.p3.2xlarge 인스턴스는 일반적으로 셋 중 가장 비싸지만 성능이 떨어집니다. g5 및 g4dn 인스턴스는 추론 워크로드에 대한 최고의 가치를 보여줍니다.

정리

부하 테스트를 완료한 후 추가 요금이 발생하지 않도록 생성된 리소스를 정리합니다. 주요 리소스는 Amazon S3의 SageMaker 엔드포인트 및 모델 아티팩트 파일입니다. 쉽게 만들 수 있도록 노트북 파일에는 다음과 같은 정리 코드가 있어 삭제하는 데 도움이 됩니다.

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

결론

이 게시물에서는 GPU를 사용하여 SageMaker 다중 모델 엔드포인트에서 실행되는 다양한 심층 신경망 모델에 대한 테스트 결과 및 분석을 공유했습니다. 우리가 공유한 결과와 통찰력은 다양한 메트릭과 인스턴스 유형에 걸쳐 합리적인 성능 단면을 제공해야 합니다. 그 과정에서 GPU를 사용하여 SageMaker MME에 대한 벤치마크 테스트를 실행하기 위해 권장되는 접근 방식도 도입했습니다. 우리가 제공한 도구와 샘플 코드는 벤치마크 테스트를 빠르게 시작하고 가속화된 컴퓨팅 하드웨어에서 수백 개의 DNN 모델을 비용 효율적으로 호스팅하는 방법에 대해 더 많은 정보에 입각한 결정을 내리는 데 도움이 될 수 있습니다. GPU에 대한 MME 지원으로 자체 모델 벤치마킹을 시작하려면 다음을 참조하십시오. 지원되는 알고리즘, 프레임워크 및 인스턴스 그리고 GitHub 레포 추가 예제 및 문서.

저자 소개

제임스 우 AWS의 수석 AI/ML 전문가 솔루션 아키텍트입니다. 고객이 AI/ML 솔루션을 설계하고 구축할 수 있도록 지원합니다. James의 작업은 컴퓨터 비전, 딥 러닝, 기업 전반에 걸친 ML 확장에 대한 주요 관심과 함께 광범위한 ML 사용 사례를 다룹니다. AWS에 합류하기 전에 James는 엔지니어링 분야에서 10년, 마케팅 및 광고 산업 분야에서 6년을 포함하여 4년 넘게 건축가, 개발자 및 기술 리더였습니다.

비크람 엘랑고 미국 버지니아에 위치한 Amazon Web Services의 AI/ML 전문가 솔루션 아키텍트입니다. Vikram은 금융 및 보험 업계 고객이 설계, 사고 리더십을 통해 기계 학습 애플리케이션을 대규모로 구축 및 배포할 수 있도록 지원합니다. 그는 현재 자연어 처리, 책임 있는 AI, 추론 최적화 및 기업 전반에 걸친 ML 확장에 중점을 두고 있습니다. 여가 시간에는 가족과 함께 여행, 하이킹, 요리, 캠핑을 즐깁니다.

사이먼 자 마린 고객이 데이터 자산에서 가치를 추출하도록 돕는 데 주력하는 AI / ML 솔루션 설계자입니다. 여가 시간에 Simon은 가족과 함께 시간을 보내고, SF를 읽고, 다양한 DIY 하우스 프로젝트 작업을 즐깁니다.

사우라브 트리칸데 Amazon SageMaker Inference의 수석 제품 관리자입니다. 그는 고객과 함께 일하는 데 열정적이며 기계 학습의 민주화라는 목표에 동기를 부여합니다. 그는 복잡한 ML 애플리케이션, 다중 테넌트 ML 모델 배포, 비용 최적화 및 딥 러닝 모델 배포의 접근성 향상과 관련된 핵심 과제에 중점을 둡니다. 여가 시간에 Saurabh는 하이킹, 혁신적인 기술 학습, TechCrunch 팔로우, 가족과 함께 시간 보내기를 즐깁니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/