이제 Amazon Elastic Inference를 사용하여 Amazon SageMaker와 Amazon EC2에서 PyTorch 모델의 추론을 가속화하고 추론 비용을 줄일 수 있음을 알려드립니다.

PyTorch는 동적 계산 그래프를 사용하는 인기있는 딥 러닝 프레임 워크입니다. 이를 통해 명령적이고 관용적 인 Python 코드로 딥 러닝 모델을 쉽게 개발할 수 있습니다. 추론은 훈련 된 모델을 사용하여 예측하는 과정입니다. PyTorch와 같은 프레임 워크를 사용하는 딥 러닝 응용 프로그램의 경우 추론이 컴퓨팅 비용의 최대 90 %를 차지합니다. 딥 러닝 모델에는 다른 양의 GPU, CPU 및 메모리 리소스가 필요하므로 추론에 적합한 인스턴스를 선택하는 것은 어려울 수 있습니다. 독립형 GPU 인스턴스에서 이러한 리소스 중 하나를 최적화하면 일반적으로 다른 리소스를 충분히 활용하지 못합니다. 따라서 사용하지 않은 리소스에 대한 비용을 지불 할 수 있습니다.

아마존 탄성 추론 적절한 양의 GPU 기반 추론 가속 기능을 모든 장치에 연결하여이 문제를 해결합니다. 아마존 세이지 메이커 or EC2 인스턴스 또는 아마존 ECS 직무. 애플리케이션의 전체 컴퓨팅 및 메모리 요구에 가장 적합한 AWS의 모든 CPU 인스턴스를 선택하고 애플리케이션의 대기 시간 요구 사항을 충족시키는 데 필요한 적절한 GPU 구동 추론 가속화를 별도로 연결할 수 있습니다. 따라서 리소스를보다 효율적으로 사용하고 추론 비용을 줄일 수 있습니다. 현재 PyTorch는 Elastic Inference에서 지원하는 딥 러닝 프레임 워크로 TensorFlow 및 Apache MXNet에 합류했습니다. 이 글을 쓰는 시점에 출시 된 버전은 1.3.1입니다.

Amazon SageMaker는 모든 개발자 및 데이터 과학자에게 TensorFlow, Apache MXNet 및 PyTorch와 같은 딥 러닝 프레임 워크에서 머신 러닝 (ML) 모델을 신속하게 구축, 교육 및 배포 할 수있는 기능을 제공하는 완전히 관리되는 서비스입니다. Amazon SageMaker를 사용하면 필요한 모든 것을 제공하여 예측을 쉽게 생성 할 수 있습니다 배포 생산에서의 기계 학습 모델 및 모델 품질 모니터링.

이 게시물에서는 Elastic Sference를 사용하여 Amazon SageMaker에서 PyTorch 모델의 비용을 절감하고 지연 시간을 개선하는 방법을 보여줍니다.

TorchScript : 연구와 생산의 격차 해소

이제 PyTorch 코드에서 직렬화 가능하고 최적화 가능한 모델을 작성하는 방법 인 TorchScript에 대해 설명합니다. PyTorch에서 Elastic Inference를 사용하려면 모델을 TorchScript로 변환해야합니다.

PyTorch의 동적 계산 그래프를 사용하면 모델 개발 프로세스가 크게 간소화됩니다. 그러나이 패러다임은 프로덕션 모델 배포에있어 고유 한 과제를 제시합니다. 생산 상황에서는 모델의 정적 그래프 표현이 유리합니다. 이를 통해 Python이없는 환경에서 모델을 사용할 수있을뿐만 아니라 성능 및 메모리 최적화도 가능합니다.

토치 스크립트 모델을 컴파일하고 파이썬없는 그래프 기반 표현으로 내보내는 기능을 제공함으로써 이러한 격차를 해소합니다. PyTorch 모델을 TorchScript로 변환하여 모든 프로덕션 환경에서 모델을 실행할 수 있습니다. 또한 TorchScript는 적시에 그래프 수준 최적화를 수행하여 표준 PyTorch보다 성능을 향상시킵니다.

PyTorch와 함께 Elastic Inference를 사용하려면 모델을 TorchScript 형식으로 변환하고 Elastic Inference에 대한 추론 API를 사용해야합니다. 이 게시물에서는 모델을 TorchScript로 컴파일하고 Elastic Inference 지원 PyTorch를 사용하여 엔드 투 엔드 추론 대기 시간을 벤치마킹하는 방법의 예를 제공합니다. 이 포스트는 다양한 인스턴스 및 가속기 조합에 대한 성능 및 비용 지표를 독립형 CPU 및 GPU 인스턴스와 비교하여 결론을 맺습니다.

TorchScript를 사용하여 모델 컴파일 및 직렬화

다음 중 하나를 사용하여 PyTorch 모델을 TorchScript로 컴파일 할 수 있습니다 트레이싱 or 스크립팅. 둘 다 계산 그래프를 생성하지만 계산 그래프는 다릅니다.

모델 스크립팅은 일반적으로 모든 모델 로직을 유지하므로 TorchScript로 컴파일하는 데 선호되는 방법입니다. 그러나이 글을 쓰는 시점에서 PyTorch 1.3.1을 사용하는 스크립트 가능한 모델 세트는 추적 가능한 모델 세트보다 작습니다. 모델은 추적 가능하지만 스크립트 가능하지 않거나 추적 가능하지 않을 수 있습니다. TorchScript와 호환되도록 모델 코드를 수정해야 할 수도 있습니다.

Elastic Inference가 현재 PyTorch 1.3.1에서 제어 흐름 작업을 처리하는 방식으로 인해 많은 조건부 분기가 포함 된 스크립트 모델의 경우 추론 대기 시간이 차선책 일 수 있습니다. Elastic Inference에서 모델의 성능을 확인하려면 추적 및 스크립팅을 모두 시도하십시오. 1.3.1 릴리스에서는 추적 된 모델이 스크립팅 된 버전보다 성능이 우수합니다.

자세한 내용은를 참조 TorchScript 소개 PyTorch 웹 사이트의 자습서.

스크립팅

스크립팅은 소스 코드를 직접 분석하여 계산 그래프를 구성하고 제어 흐름을 유지합니다. 다음 예제는 스크립팅을 사용하여 모델을 컴파일하는 방법을 보여줍니다. ResNet-18에는 TorchVision의 사전 훈련 된 가중치를 사용합니다. 스크립트 결과 모델을 파일로 저장 한 다음 torch.jit.load Elastic Inference 지원 PyTorch 사용 다음 코드를 참조하십시오.

import torchvision, torch # Call eval() to set model to inference mode
model = torchvision.models.resnet18(pretrained=True).eval()
scripted_model = torch.jit.script(model)

트레이싱

추적은 샘플 입력을 사용하여 해당 입력에서 모델을 실행할 때 수행 된 조작을 기록합니다. 즉, 단일 입력으로 코드를 추적하여 그래프를 컴파일하기 때문에 제어 흐름이 지워질 수 있습니다. 예를 들어, 모델 정의에는 특정 크기의 이미지를 채우는 코드가있을 수 있습니다. x. 다른 크기의 이미지로 모델을 추적하는 경우 y미래의 크기 입력 x 추적 된 모델에 공급 된 것은 채워지지 않습니다. 주어진 입력으로 추적하는 동안 모든 코드 경로가 실행 된 것은 아니기 때문입니다.

다음 예제는 무작위 텐서 입력으로 추적을 사용하여 모델을 컴파일하는 방법을 보여줍니다. 또한 ResNet-18에 대해 TorchVision의 사전 훈련 된 가중치를 사용합니다. 당신은 사용해야합니다 torch.jit.optimized_execution Elastic Inference에서 추적 모델을 사용하기위한 장치 서수에 대한 두 번째 매개 변수가있는 컨텍스트 블록. 두 개의 매개 변수를 허용하는이 수정 된 함수 정의는 Elastic Inference 가능 PyTorch 프레임 워크를 통해서만 사용할 수 있습니다.

표준 PyTorch 프레임 워크를 사용하여 모델을 추적하는 경우 torch.jit.optimized_execution 블록. 결과 추적 모델을 파일에 저장하고 다음과 같이로드 할 수 있습니다 torch.jit.load Elastic Inference 지원 PyTorch 사용 다음 코드를 참조하십시오.

# ImageNet pre-trained models take inputs of this size.
x = torch.rand(1,3,224,224)
# Call eval() to set model to inference mode
model = torchvision.models.resnet18(pretrained=True).eval() # Required when using Elastic Inference
with torch.jit.optimized_execution(True, {‘target_device’: ‘eia:0’}): traced_model = torch.jit.trace(model, x)

컴파일 된 모델 저장 및로드

추적 및 스크립팅의 결과는 스크립트 모듈표준 PyTorch의 TorchScript 아날로그입니다. nn. 모듈. TorchScript 모듈의 직렬화 및 역 직렬화는 호출하는 것만 큼 쉽습니다. torch.jit.save () 및 torch.jit.load ()각각. 다음을 사용하여 표준 PyTorch 모델을 저장하고로드하는 JIT 아날로그입니다. torch.save() 및 torch.load(). 다음 코드를 참조하십시오.

torch.jit.save(traced_model, 'resnet18_traced.pt')
torch.jit.save(scripted_model, 'resnet18_scripted.pt') traced_model = torch.jit.load('resnet18_traced.pt')
scripted_model = torch.jit.load('resnet18_scripted.pt')

저장된 TorchScript 모델은 저장된 표준 PyTorch 모델과 달리 특정 클래스 및 코드 디렉토리에 바인딩되지 않습니다. 모델 클래스를 먼저 인스턴스화하지 않고 저장된 TorchScript 모델을 직접로드 할 수 있습니다. 이를 통해 Python이없는 환경에서 TorchScript 모델을 사용할 수 있습니다.

Elastic Inference PyTorch를 사용하여 Amazon SageMaker에서 엔드 투 엔드 추론 벤치마킹

이 게시물에서는 Amazon SageMaker 호스팅 엔드 포인트를 사용하여 DenseNet-121에 대한 Elastic Inference 지원 PyTorch 추론 대기 시간을 벤치마킹하는 프로세스를 안내합니다. DenseNet-121은 다양한 데이터 세트에서 이미지 분류의 최첨단 결과를 달성 한 CNN (Convolutional Neural Network)입니다. 이 아키텍처는 이미지 분류를위한 또 다른 인기있는 CNN 인 ResNet을 기반으로합니다.

Amazon SageMaker 호스팅을 사용하면 모델을 HTTPS 엔드 포인트에 배포 할 수 있으므로 HTTP 요청을 통해 모델을 추론 할 수 있습니다.

사전 조건

이 연습에서는 EC2 인스턴스를 클라이언트로 사용하여 Amazon SageMaker 호스팅 엔드 포인트를 시작하고 상호 작용합니다. 이 클라이언트 인스턴스에는 가속기가 연결되어 있지 않습니다. 액셀러레이터가 연결된 호스팅 인스턴스를 프로비저닝하는 엔드 포인트를 시작합니다. 연습을 완료하려면 먼저 다음 전제 조건을 완료해야합니다.

• IAM 역할을 생성하고 AmazonSageMakerFullAccess 이 정책은 Amazon Elastic Inference 및 Amazon SageMaker를 사용할 수있는 권한을 제공합니다.
• m5.large CPU EC2 인스턴스를 시작하십시오.
  • Linux 또는 DLAMI (Ubuntu Deep Learning AMI) v27을 사용하십시오.

이 게시물은 DLAMI의 내장 Elastic Inference 지원 PyTorch Conda 환경을 사용하여 Amazon SageMaker SDK에 액세스하고 PyTorch 121을 사용하여 DenseNet-1.3.1 가중치를 저장합니다. Amazon SageMaker Notebook 지원이 릴리스되면 대신 노트북 커널을 사용할 수 있습니다.

호스팅 된 인스턴스 및 가속기는 Elastic Inference 지원 PyTorch를 통해 AWS DL 컨테이너. 클라이언트 인스턴스의 환경 선택은 PyTorch 1.3.1을 사용하여 Amazon SageMaker SDK를 쉽게 사용하고 모델 가중치를 저장하는 것입니다.

연습

다음 단계를 완료하십시오.

1. 생성 한 인스턴스에 로그인하십시오.
2. 다음 명령으로 Elastic Inference-enabled PyTorch Conda 환경을 활성화하십시오.

   source activate amazonei_pytorch_p36

3. 라는 빈 파일 만들기 script.py이 파일은 호스팅 된 컨테이너의 진입 점 역할을합니다. 기본값을 트리거하기 위해 파일이 비어 있습니다 model_fn 및 predict_fn. 기본 predict_fn 표준 PyTorch 및 Elastic Inference 지원 PyTorch 모두에 사용할 수 있습니다. 기본 model_fn그러나 Elastic Inference 지원 PyTorch에 대해서만 구현됩니다. 표준 PyTorch를 벤치마킹하는 경우 자체 PyTorch를 구현해야합니다. model_fn 이전과.
4. 동일한 디렉토리에서라는 스크립트를 작성하십시오. create_sm_tarball.py 다음 코드로 :

   import torch, torchvision
   import subprocess # Toggle inference mode
   model = torchvision.models.densenet121(pretrained=True).eval()
   cv_input = torch.rand(1,3,224,224)
   model = torch.jit.trace(model,cv_input)
   torch.jit.save(model, 'model.pt')
   subprocess.call(['tar', '-czvf', 'densenet121_traced.tar.gz', 'model.pt'])
   

   이 스크립트는 Amazon SageMaker가 사용하는 명명 규칙에 따라 타르볼을 생성합니다 (model.pt 기본적으로). DenseNet-121의 모델 무게는 ImageNet에 사전 훈련되어 TorchVision에서 가져옵니다. 자세한 내용은 SageMaker Python SDK와 함께 PyTorch 사용.

5. 다음 명령으로 스크립트를 실행하여 tarball을 작성하십시오.

   python create_sm_tarball.py

6. 라는 스크립트를 만듭니다 create_sm_endpoint.py 다음 코드로 :

   import sagemaker
   from sagemaker.pytorch import PyTorchModel sagemaker_session = sagemaker.Session()
   region = YOUR_DESIRED_REGION
   role = YOUR_IAM_ROLE_ARN instance_type = 'c5.large'
   accelerator_type = 'eia2.medium' ecr_image = '763104351884.dkr.ecr.{}.amazonaws.com/pytorch-inference-eia:1.3.1-cpu-py3'.format(region) # Satisfy regex
   endpoint_name = 'pt-ei-densenet121-traced-{}-{}'.format(instance_type, accelerator_type).replace('.', '').replace('_', '')
   tar_filename = 'densenet121_traced.tar.gz' # script.py should be blank to use default EI model_fn and predict_fn
   # For non-EI PyTorch usage, must implement own model_fn
   entry_point = 'script.py' # Returns S3 bucket URL
   print('Upload tarball to S3')
   model_data = sagemaker_session.upload_data(path=tar_filename) pytorch = PyTorchModel(model_data=model_data, role=role, image=ecr_image, entry_point=entry_point, sagemaker_session=sagemaker_session) # Function will exit before endpoint is finished creating
   predictor = pytorch.deploy(initial_instance_count=1, instance_type='ml.' + instance_type, accelerator_type='ml.' + accelerator_type, endpoint_name=endpoint_name, wait=False)

   AWS 계정 ID, 리전 및 IAM ARN 역할을 포함하도록 스크립트를 수정해야합니다. 이 스크립트는 이전에 생성 된 tarball 및 빈 진입 점 스크립트를 사용하여 Amazon SageMaker 호스팅 엔드 포인트를 프로비저닝합니다. 이 예제 코드는 ml.eia5.medium 가속기가 연결된 ml.c2.large 호스팅 인스턴스를 벤치마킹합니다.

   엔드 포인트를 작성하기 위해 이미지를 직접 제공 할 필요는 없지만이 게시물은 명확성을 위해이를 제공합니다. 다른 프레임 워크에서 사용 가능한 Docker 컨테이너에 대한 자세한 정보는 다음을 참조하십시오. 딥 러닝 컨테이너 이미지.

7. 다음 명령을 사용하여 ml.c5.large 및 ml.eia2.medium이 첨부 된 호스트 엔드 포인트를 작성하려면 스크립트를 실행하십시오.

   python create_sm_endpoint.py

8. SageMaker 콘솔로 이동하여 엔드 포인트 배치가 완료 될 때까지 기다리십시오. 약 10 분이 소요됩니다. 이제 추론을 수행하기 위해 엔드 포인트를 호출 할 준비가되었습니다.
9. 라는 스크립트를 만듭니다 benchmark_sm_endpoint.py 다음 코드로 :

   import sagemaker
   from sagemaker.pytorch import PyTorchPredictor
   import torch
   import boto3
   import datetime
   import math
   import numpy as np
   import time instance_type = 'c5.large'
   accelerator_type = 'eia2.medium' endpoint_name = 'pt-ei-densenet121-traced-{}-{}'.format(instance_type, accelerator_type).replace('.', '').replace('_', '')
   predictor = PyTorchPredictor(endpoint_name)
   data = torch.rand(1,3,224,224) # Do warmup round of 100 inferences to warm up routers
   print('Doing warmup round of 100 inferences (not counted)')
   for i in range(100): output = predictor.predict(data)
   time.sleep(15) client_times = []
   print('Running 1000 inferences for {}:'.format(endpoint_name))
   cw_start = datetime.datetime.utcnow()
   for i in range(1000): client_start = time.time() output = predictor.predict(data) client_end = time.time() client_times.append((client_end - client_start)*1000)
   cw_end = datetime.datetime.utcnow() print('Client end-to-end latency percentiles:')
   client_avg = np.mean(client_times)
   client_p50 = np.percentile(client_times, 50)
   client_p90 = np.percentile(client_times, 90)
   client_p95 = np.percentile(client_times, 95)
   client_p100 = np.percentile(client_times, 100)
   print('Avg | P50 | P90 | P95 | P100')
   print('{:.4f} | {:.4f} | {:.4f} | {:.4f}n'.format(client_avg, client_p50, client_p90, client_p95, client_p100)) print('Getting Cloudwatch:')
   cloudwatch = boto3.client('cloudwatch')
   statistics=['SampleCount', 'Average', 'Minimum', 'Maximum']
   extended=['p50', 'p90', 'p95', 'p100'] # Give 5 minute buffer to end
   cw_end += datetime.timedelta(minutes=5) # Period must be 1, 5, 10, 30, or multiple of 60
   # Calculate closest multiple of 60 to the total elapsed time
   factor = math.ceil((cw_end - cw_start).total_seconds() / 60)
   period = factor * 60
   print('Time elapsed: {} seconds'.format((cw_end - cw_start).total_seconds()))
   print('Using period of {} secondsn'.format(period)) cloudwatch_ready = False
   # Keep polling CloudWatch metrics until datapoints are available
   while not cloudwatch_ready: time.sleep(30) print('Waiting 30 seconds ...') # Must use default units of microseconds model_latency_metrics = cloudwatch.get_metric_statistics(MetricName='ModelLatency', Dimensions=[{'Name': 'EndpointName', 'Value': endpoint_name}, {'Name': 'VariantName', 'Value': "AllTraffic"}], Namespace="AWS/SageMaker", StartTime=cw_start, EndTime=cw_end, Period=period, Statistics=statistics, ExtendedStatistics=extended ) # Should be 1000 if len(model_latency_metrics['Datapoints']) > 0: print('{} latency datapoints ready'.format(model_latency_metrics['Datapoints'][0]['SampleCount'])) print('Side-car latency percentiles:') side_avg = model_latency_metrics['Datapoints'][0]['Average'] / 1000 side_p50 = model_latency_metrics['Datapoints'][0]['ExtendedStatistics']['p50'] / 1000 side_p90 = model_latency_metrics['Datapoints'][0]['ExtendedStatistics']['p90'] / 1000 side_p95 = model_latency_metrics['Datapoints'][0]['ExtendedStatistics']['p95'] / 1000 side_p100 = model_latency_metrics['Datapoints'][0]['ExtendedStatistics']['p100'] / 1000 print('Avg | P50 | P90 | P95 | P100') print('{:.4f} | {:.4f} | {:.4f} | {:.4f}n'.format(side_avg, side_p50, side_p90, side_p95, side_p100)) cloudwatch_ready = True

   이 스크립트는 1 x 3 x 224 x 224 크기의 텐서를 사용합니다 (이미지 분류의 표준). 먼저 일련의 워밍업 추론을 실행 한 다음 100 개의 추론을 실행합니다. 지연 백분위 수는 이러한 1000 개의 추론에서만보고됩니다.

   이 게시물은 대기 시간 측정 항목을 사용합니다 ModelLatency. 이 지표는 Amazon CloudWatch로 전송되며 Amazon SageMaker 시스템 내에서 유추 대기 시간을 캡처합니다. 자세한 내용은 Amazon CloudWatch로 Amazon SageMaker 모니터링.

   TorchScript로 모델을 컴파일하고 다른 이름으로 저장해야합니다. model.pt 타르볼에서.

   호스팅 인스턴스에 가속기가 연결된 엔드 포인트를 호출하면 Amazon SageMaker가 기본값을 호출합니다. model_fn 및 predict_fn 기본적으로. 가속기가없는 Amazon SageMaker에서 PyTorch를 사용하는 경우 자체 구현을 제공해야합니다. model_fn 진입 점 스크립트를 통해.

   기본값은 model_fn 사용 torch.jit.load('model.pt') 이전에 TorchScript로 모델을 직렬화하고 파일 이름 규칙을 준수한다고 가정하기 때문에 모델 가중치를로드합니다. 액셀러레이터가 연결되면 기본값 predict_fn 를 사용하여 torch.jit.optimized_execution 블록-연결된 Elastic Inference 가속기에서 모델을 실행하도록 최적화해야 함을 지정합니다. 그렇지 않으면, predict_fn 표준 PyTorch 방식으로 추론합니다. 이 글을 쓰는 시점에서 Amazon SageMaker에는 다중 첨부가 지원되지 않습니다. 따라서 장치 서수는 항상 0.

   직접 구현하기로 결정한 경우 predict_fn Elastic Inference를 사용하는 동안 torch.jit.optimized_execution 컨텍스트 또는 추론은 전적으로 호스팅 인스턴스에서 실행되며 연결된 가속기를 사용하지 않습니다. 자세한 내용은 SageMaker Python SDK와 함께 PyTorch 사용.

   기본 핸들러는 GitHub의.

10. 다음 명령으로 벤치 마크 스크립트를 실행하십시오.

    python benchmark_sm_endpoint.py

다음과 유사한 출력이 표시되어야합니다.

Doing warmup round of 100 inferences (not counted)
Running 1000 inferences for pt-ei-densenet121-traced-c5large-eia2medium:
Client end-to-end latency percentiles:
Avg | P50 | P90 | P95 | P100
64.7758 | 61.7952 | 73.7203 | 77.3841 Getting Cloudwatch:
Time elapsed: 364.777493 seconds
Using period of 420 seconds Waiting 30 seconds ...
1000.0 latency datapoints ready
Side-car latency percentiles:
Avg | P50 | P90 | P95 | P100
47.8507 | 46.1647 | 51.7429 | 56.7705

올바른 인스턴스 선택

새로운 추론 워크로드를 배포 할 때 선택할 수있는 인스턴스 유형이 많습니다. 다음과 같은 주요 매개 변수를 고려해야합니다.

• 메모리 – 응용 프로그램에 충분한 CPU 및 가속기 메모리를 제공하는 호스트 인스턴스 및 가속기 조합을 선택해야합니다. 입력 텐서 크기와 모델 크기의 합으로 런타임 메모리 요구 사항을 낮출 수 있습니다. 그러나 런타임 메모리 사용량은 일반적으로 모든 모델에서이 하한보다 훨씬 높으며 프레임 워크에 따라 다릅니다. 이 가이드 라인 만 사용하여 선택한 CPU 인스턴스 및 Elastic Inference Accelerator를 대략적으로 안내 할 수 있습니다.
• 숨어 있음 기타 요건 – 충분한 메모리가있는 호스트 인스턴스 및 액셀러레이터 세트를 확보 한 후 응용 프로그램의 대기 시간 요구 사항을 충족하는 것으로 선택 범위를 좁힐 수 있습니다. 이 게시물에서는 추론 당 대기 시간을 성능을 평가하는 핵심 지표로 간주합니다. 단위 시간당 처리 된 이미지 또는 단어의 추론 처리량은 일반적으로 사용되는 또 다른 지표입니다.
• 비용 – 메모리 및 대기 시간 요구 사항을 모두 만족하는 하드웨어 조합 세트를 보유한 후 가장 낮은 유추 당 가격을 제공하는 조합을 선택하여 비용 효율성을 최적화 할 수 있습니다. 이 지표를 (가격 / 초 * 추론 통화 당 평균 대기 시간)으로 계산할 수 있습니다. 숫자를 더 구체적으로 만들기 위해이 게시물은 100,000 개의 추론 당 비용을 제공합니다. 각 하드웨어 조합에 대해이를 수행하여 워크로드의 비용 효율성을 비교하고 최적의 하드웨어를 선택할 수 있습니다. 이 게시물은 미국 서부 (오레곤) 리전의 시간당 가격을 사용합니다.

이제이 프로세스를 적용하여 DenseNet-121을 실행하기위한 최적의 인스턴스를 선택할 수 있습니다. 먼저 애플리케이션의 메모리 및 CPU 요구 사항을 평가하고 해당 요구 사항을 충족하는 호스트 인스턴스 및 가속기의 하위 집합을 정리하십시오.

다음으로 대기 시간 성능을 살펴보십시오. 이 포스트는 각 인스턴스에서 DenseNet-121에 대해 동일한 텐서 입력과 TorchVision ImageNet 사전 훈련 가중치를 사용했습니다. 이 입력을 사용하여 모델에 대해 1,000 개의 추론을 실행하고 실행 당 대기 시간을 수집했으며 평균 대기 시간과 90 번째 백분위 수 대기 시간 (P90 대기 시간)을보고했습니다. 이 게시물에서는 P90 대기 시간이 80 밀리 초 미만이어야합니다. 모든 추론 통화의 90 %는 대기 시간이 80ms보다 작아야합니다.

Amazon Elastic Inference 액셀러레이터를 100,000 가지 유형의 CPU 호스트 인스턴스에 연결하고 각각에 대해 이전 성능 테스트를 실행했습니다. 다음 표에는 시간당 가격, 추론 통화 당 평균 대기 시간 및 XNUMX 추론 당 비용이 나와 있습니다. 아래의 모든 조합은 대기 시간 임계 값을 충족합니다.

대기 시간에 대한 다른 호스트 인스턴스의 영향을 볼 수 있습니다. 동일한 액셀러레이터 유형의 경우 더 강력한 호스트 인스턴스를 사용해도 대기 시간이 크게 향상되지는 않습니다. 그러나 액셀러레이터가 커지면 모델이 액셀러레이터에서 실행되므로 액셀러레이터가 클수록 대기 시간이 줄어 듭니다. 애플리케이션에 충분한 CPU 메모리를 제공하는 가장 저렴한 호스트 인스턴스 유형을 선택해야합니다. ml.m5.large 또는 ml.c5.large는 많은 사용 사례에 충분하지만 전부는 아닙니다.

앞의 기준에 따라이 게시물에서는 대기 시간 요구 사항을 충족하는 가장 저렴한 두 가지 옵션 인 ml.c5.large (ml.eia2.medium) 및 ml.m5.large (ml.eia2.medium)를 선택했습니다. 둘 다이 사용 사례에 적합합니다.

SageMaker에서 추론에 대한 다른 인스턴스 비교

이 게시물은 독립형 CPU 및 GPU 호스트 인스턴스에 대한 대기 시간 및 비용 성능 데이터를 수집하고 이전 Elastic Inference 벤치 마크와 비교했습니다. 사용 된 독립형 CPU 인스턴스는 ml.c5.xl, ml.c5.4xl, ml.m5.xl 및 ml.m5.4xl입니다. 사용 된 독립형 GPU 인스턴스는 ml.p3.2xl, ml.g4dn.xl, ml.g4dn.2xl 및 ml.g4dn.4xl입니다.

다음 집계 표는 Elastic Inference 지원 옵션에 대한 비용 성능 데이터와 독립형 인스턴스 옵션을 보여줍니다.

Elastic Inference가 독립형 CPU 및 GPU 인스턴스를 통해 제공하는 가치 제안을보다 잘 이해하기 위해 각 하드웨어 유형별로이 지연 시간과 비용 효율성 데이터를 나란히 시각화 할 수 있습니다. 다음 막대 차트는 100,000 추론 당 비용을 표시하고 선 그래프는 P90 추론 대기 시간을 밀리 초 단위로 표시합니다. 진한 회색 막대는 Elastic Inference 가속기가있는 인스턴스이고 녹색 막대는 독립형 GPU 인스턴스이며 파란색 막대는 독립형 CPU 인스턴스입니다.

지연 시간 분석

예상대로 CPU 인스턴스는 GPU 인스턴스와 비교할 때 성능이 저하됩니다. ml.g4dn.xl 인스턴스는 CPU 인스턴스보다 약 90 배 빠릅니다. 독립형 CPU 인스턴스는 P80 대기 시간 임계 값 인 XNUMXms를 만족시키지 않습니다.

그러나 이러한 CPU 인스턴스는 GPU 가속의 혜택을 받기 때문에 Elastic Inference가 연결된 경우 훨씬 더 성능이 좋습니다. ml.eia5.medium이 포함 된 ml.c2.large 인스턴스는 독립형 CPU 인스턴스보다 거의 4 배 빠른 추론 속도를 제공합니다. 그러나 독립형 GPU 인스턴스는 Elastic Inference가 연결된 CPU 인스턴스보다 여전히 우수합니다. ml.g5dn.xl은 ml.eia2.medium으로 ml.c4.large보다 두 배 빠릅니다. ml.g4dn.xl, ml.g2dn.4xl 및 ml.g4dn.4xl 인스턴스는 무시할 수있는 변동으로 대체로 동일한 대기 시간을 갖습니다. ml.g4dn 인스턴스 121 개 모두 동일한 GPU를 사용하지만 더 큰 ml.gXNUMXdn 인스턴스에는 더 많은 vCPU 및 메모리 리소스가 있습니다. DenseNet-XNUMX의 경우 vCPU 및 메모리 리소스를 늘려도 추론 대기 시간이 향상되지 않습니다.

Elastic Inference 및 독립형 GPU 인스턴스는 모두 지연 시간 요구 사항을 충족합니다.

비용 분석

비용면에서는 ml.eia5.medium이있는 ml.c2.large가 두드러집니다. ml.eia5.medium이있는 ml.c2.large는 시간당 가격이 가장 낮지는 않지만 추론 100,000 회당 비용이 가장 낮습니다. 시간당 가격에 대한 자세한 내용은 Amazon SageMaker 요금.

시간당 비용이 저렴한 인스턴스가 반드시 추론 당 비용이 더 낮을 필요는 없다는 결론을 내릴 수 있습니다. 추론 당 대기 시간이 더 길 수 있기 때문입니다. 마찬가지로 추론 당 대기 시간이 짧은 인스턴스는 추론 당 비용이 낮지 않을 수 있습니다. ml.m5.xlarge 및 ml.c5.xlarge CPU 인스턴스는 시간당 가격이 가장 낮지 만 대부분의 Elastic Inference 및 독립형 GPU 옵션보다 추론 당 비용이 더 높습니다. ml.m5.4xlarge 및 ml.c5.4xlarge 인스턴스가 클수록 대기 시간이 길고 시간당 비용이 더 높으므로 모든 Elastic Inference 옵션보다 추론 당 비용이 더 높습니다. 독립형 GPU 인스턴스는 CUDA 작업이 악용하는 높은 컴퓨팅 병렬 처리로 인해 전체 보드에서 최상의 대기 시간을 달성합니다. 그러나 Elastic Inference는 추론 당 비용이 가장 낮습니다.

Amazon Elastic Inference를 사용하면 두 가지 이점을 모두 누릴 수 있습니다. GPU가 제공하는 대부분의 병렬화 및 추론 속도 향상을 얻을 수 있으며 CPU 및 GPU 독립 실행 형 인스턴스보다 비용 효율성이 높습니다. 또한 호스트 인스턴스와 추론 가속 하드웨어를 분리 할 수있는 유연성이있어 vCPU, 메모리 및 애플리케이션에 필요한 기타 모든 리소스에 맞게 하드웨어를 유연하게 최적화 할 수 있습니다.

위의 테스트에서는 ml.eia5.medium이 포함 된 ml.c2.large가 DenseNet-121을 실행하기위한 대기 시간 기준 및 메모리 사용 요구 사항을 충족하는 가장 저렴한 옵션임을 보여줍니다.

이 게시물에 사용 된 지연 시간 측정 항목 (ModelLatency CloudWatch Metrics에서 생성)은 Amazon SageMaker의 대기 시간을 측정합니다. 이 지연 시간 지표는 애플리케이션에서 Amazon SageMaker까지의 지연 시간을 고려하지 않습니다. 응용 프로그램을 벤치마킹 할 때 이러한 대기 시간을 고려해야합니다.

요약

Amazon Elastic Inference는 Amazon SageMaker의 PyTorch 추론 워크로드를위한 저렴하고 유연한 솔루션입니다. Elastic Inference 액셀러레이터를 Amazon SageMaker 인스턴스에 연결하여 독립형 Amazon SageMaker GPU 및 CPU 인스턴스보다 GPU와 유사한 추론 가속화를 달성하고 비용 효율성을 유지할 수 있습니다. 자세한 내용은 Amazon Elastic Inference 란 무엇입니까? 

저자에 관하여

David Fan은 AWS AI의 소프트웨어 엔지니어입니다. 그는 컴퓨터 비전 및 딥 러닝 연구 분야의 최첨단 기술을 발전시키고 AI 연구의 대규모 생산 사용을 방해하는 계산 및 도메인 지식 장벽을 줄이는 데 열정적입니다. 여가 시간에는 카 글레 경쟁을하고 arXiv 신문을 따라 가기를 좋아합니다.

Srinivas Hanabe는 AWS AI for Elastic Inference의 주요 제품 관리자입니다. 이 직책을 맡기 전에는 Amazon VPC의 PM 책임자였습니다. Srinivas는 장거리 달리기를 좋아하고 다양한 주제의 책을 읽고 가족과 함께 시간을 보내고 경력 멘토입니다.

출처 : https://aws.amazon.com/blogs/machine-learning/reduce-ml-inference-costs-on-amazon-sagemaker-for-pytorch-models-using-amazon-elastic-inference/