Amazon SageMaker 서버리스 추론 벤치마킹 툴킷 소개

플라톤에 의해 재발행

팔로워 : 0

Amazon SageMaker 서버리스 추론 머신 러닝(ML) 모델을 쉽게 배포하고 확장할 수 있도록 특별히 제작된 추론 옵션입니다. 엔드포인트 호출이 드물고 예측할 수 없는 서비스에 이상적인 종량제 모델을 제공합니다. 장기 실행 인스턴스가 지원하는 실시간 호스팅 엔드포인트와 달리 서버리스 엔드포인트의 컴퓨팅 리소스는 온디맨드로 프로비저닝되므로 인스턴스 유형을 선택하거나 확장 정책을 관리할 필요가 없습니다.

다음 상위 수준 아키텍처는 서버리스 엔드포인트가 작동하는 방식을 보여줍니다. 클라이언트는 AWS 관리형 인프라에서 지원하는 엔드포인트를 호출합니다.

그러나 서버리스 엔드포인트는 몇 초 만에 콜드 스타트하는 경향이 있으므로 간헐적이거나 예측할 수 없는 워크로드에 더 적합합니다.

비용 및 성능 관점에서 서버리스 엔드포인트가 올바른 배포 옵션인지 판단하는 데 도움이 되도록 SageMaker 서버리스 추론 벤치마킹 툴킷, 다양한 엔드포인트 구성을 테스트하고 가장 최적의 구성을 유사한 실시간 호스팅 인스턴스와 비교합니다.

이 게시물에서는 툴킷을 소개하고 구성 및 출력에 대한 개요를 제공합니다.

솔루션 개요

툴킷을 다운로드하여 설치할 수 있습니다. GitHub 레포. 시작하는 것은 쉽습니다. 라이브러리를 설치하고 생성하기만 하면 됩니다. 세이지메이커 모델, 페이로드 본문 및 콘텐츠 유형을 포함한 샘플 호출 매개변수 세트가 포함된 JSON 라인 형식 파일과 함께 모델 이름을 제공하십시오. 샘플 호출 인수 목록을 이미지, 비디오 또는 오디오와 같은 바이너리 페이로드에 대한 JSON 라인 파일 또는 피클 파일로 변환하는 편의 기능이 제공됩니다.

툴킷 설치

먼저 pip를 사용하여 Python 환경에 벤치마킹 라이브러리를 설치합니다.

pip install sm-serverless-benchmarking

다음 코드를 실행할 수 있습니다. 아마존 세이지 메이커 스튜디오 예, SageMaker 노트북 인스턴스, 또는 모든 인스턴스 프로그래밍 방식 액세스 AWS 및 적절한 AWS 자격 증명 및 액세스 관리 (IAM) 권한. 필수 IAM 권한은 GitHub 레포. IAM에 대한 추가 지침 및 예제 정책은 다음을 참조하십시오. Amazon SageMaker가 IAM과 작동하는 방식. 이 코드는 두 개의 예제 레코드가 있는 CSV 입력을 예상하는 모델에서 기본 매개변수 세트로 벤치마크를 실행합니다. 엔드포인트가 다양한 입력 페이로드로 수행되는 방식을 분석하기 위해 대표적인 예시 세트를 제공하는 것이 좋습니다.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

또한 벤치마크를 SageMaker Processing 작업으로 실행할 수 있습니다. 이는 호출 횟수가 많은 장기 실행 벤치마크에 대해 보다 안정적인 옵션일 수 있습니다. 다음 코드를 참조하십시오.

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

벤치마크 기간 동안 ml.m5.large SageMaker Processing 인스턴스를 실행하는 데 추가 비용이 발생합니다.

두 방법 모두 벤치마킹할 메모리 구성 목록 및 각 구성이 호출되는 횟수와 같이 구성할 여러 매개변수를 허용합니다. 대부분의 경우 기본 옵션이 시작점으로 충분해야 하지만 GitHub 레포 각 매개변수의 전체 목록과 설명을 보려면

벤치마킹 구성

벤치마크가 수행하는 작업과 벤치마크가 생성하는 출력에 대해 자세히 알아보기 전에 서버리스 엔드포인트 구성과 관련하여 몇 가지 핵심 개념을 이해하는 것이 중요합니다.

다음의 두 가지 주요 구성 옵션: MemorySizeInMB 와 MaxConcurrency. MemorySizeInMB 인스턴스에 할당되는 메모리 양을 구성하며 1024MB, 2048MB, 3072MB, 4096MB, 5120MB 또는 6144MB가 될 수 있습니다. vCPU의 수도 할당된 메모리 양에 비례하여 확장됩니다. 그만큼 MaxConcurrency 매개변수는 엔드포인트가 서비스할 수 있는 동시 요청 수를 조정합니다. 와 MaxConcurrency 1이면 서버리스 엔드포인트는 한 번에 하나의 요청만 처리할 수 있습니다.

요약하면 MemorySizeInMB 매개변수는 수직 확장성을 위한 메커니즘을 제공하여 메모리와 컴퓨팅 리소스를 조정하여 더 큰 모델을 제공할 수 있는 반면 MaxConcurrency 엔드포인트가 더 많은 동시 요청을 처리할 수 있도록 수평 확장성을 위한 메커니즘을 제공합니다.

엔드포인트 운영 비용은 주로 메모리 크기에 따라 결정되며 최대 동시성 증가와 관련된 비용은 없습니다. 그러나 모든 엔드포인트에서 최대 동시성에 대한 리전별 계정 제한이 있습니다. 인용하다 SageMaker 엔드포인트 및 할당량 최신 제한을 위해.

벤치마킹 출력

이를 감안할 때 서버리스 엔드포인트를 벤치마킹하는 목표는 가장 비용 효율적이고 안정적인 메모리 크기 설정과 예상 트래픽 패턴을 처리할 수 있는 최소 최대 동시성을 결정하는 것입니다.

기본적으로 이 도구는 두 가지 벤치마크를 실행합니다. 첫 번째는 지정된 각 메모리 구성에 대한 엔드포인트를 배포하고 제공된 샘플 페이로드로 각 엔드포인트를 호출하는 안정성 벤치마크입니다. 이 벤치마크의 목표는 가장 효과적이고 안정적인 MemorySizeInMB 설정을 결정하는 것입니다. 벤치마크는 호출 대기 시간을 캡처하고 각 엔드포인트에 대해 예상되는 호출당 비용을 계산합니다. 그런 다음 유사한 실시간 호스팅 인스턴스와 비용을 비교합니다.

벤치마킹이 완료되면 도구는 지정된 result_save_path 다음 디렉토리 구조를 가진 디렉토리:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

XNUMXD덴탈의 benchmarking_report 디렉토리에는 이 게시물에서 설명하는 모든 요약 결과가 포함된 통합 보고서가 포함되어 있습니다. 추가 디렉토리에는 추가 분석에 사용할 수 있는 원시 및 중간 출력이 포함되어 있습니다. 참조 GitHub 레포 각 출력 아티팩트에 대한 자세한 설명은

컴퓨터 비전 MobileNetV2 TensorFlow 모델을 제공하는 엔드포인트에 대한 몇 가지 실제 벤치마킹 출력을 살펴보겠습니다. 이 예를 재현하려면 다음을 참조하십시오. 예시 노트북 GitHub 리포지토리의 디렉터리입니다.

통합 보고서 내의 첫 번째 출력은 각 항목에 대한 최소, 평균, 중간 및 최대 대기 시간 메트릭을 제공하는 요약 표입니다. MemorySizeInMB 성공적인 메모리 크기 구성. 다음 표와 같이 평균 호출 지연 시간(invocation_latency_mean) 메모리 구성이 3072MB로 증가함에 따라 계속 개선되었지만 이후에는 개선이 중단되었습니다.