共计 14176 个字符，预计需要花费 36 分钟才能阅读完成。
PyTorch 是一种应用动静计算图形的常见深度学习框架，借助它，咱们能够应用命令语言和罕用的 Python 代码轻松开发深度学习模型。推理是应用训练模型进行预测的过程。对于应用 PyTorch 等框架的深度学习应用程序，推理老本占计算成本的 90%。因为深度学习模型须要不同数量的 GPU、CPU 和内存资源，为推理抉择适当的实例有难度。在一个独立的 GPU 实例上对其中一个资源进行优化通常会导致其余资源利用有余。因而，咱们可能要为未应用的资源付费。
Amazon Elastic Inference 通过反对将适量 GPU 反对推理减速附加到任何 Amazon SageMaker 或 EC2 实例或 Amazon ECS 工作中来解决此问题。咱们能够在 AWS 中抉择最适宜应用程序整体计算和内存需要的 CPU 实例，并独自附加所需的适量 GPU 反对推理减速，以满足应用程序提早要求。如此一来，就能够更加高效地应用资源并升高推理老本。明天，PyTorch 退出 TensorFlow 和 Apache MXNet 作为 Elastic Inference 反对的深度学习框架。撰写本文时发行的版本为 1.3.1。
Amazon SageMaker 是一项齐全托管的服务，为每个开发人员和数据科学家提供在 TensorFlow、Apache MXNet 和 PyTorch 等深度学习框架上疾速构建、训练和部署机器学习（ML）模型的能力。Amazon SageMaker 通过提供在生产环境中部署机器学习模型和监控模型品质所需的所有来轻松生成预测。
下文将介绍如何应用 Elastic Inference 降低成本及改善 PyTorch 模型在 Amazon SageMaker 上的提早。
TorchScript：弥合钻研与生产之间的差距
咱们当初探讨 TorchScript，它是从 PyTorch 代码中创立可序列化及可优化模型的一种形式。咱们必须将模型转换为 TorchScript 能力将 Elastic Inference 与 PyTorch 联合应用。
PyTorch 应用动静计算图形大大简化了模型开发过程。然而，此模式为生产模型部署带来独特的挑战。在生产环境中，较好的办法是对模型进行动态图形示意。这不仅能让咱们在应用 Python 较少的环境中应用该模型，还容许对性能和内存进行优化。
TorchScript 通过提供将模型编译并导出至没有应用 Python 的图形示意中的能力来弥合这一差距。咱们能够通过将 PyTorch 模型转换为 TorchScript 来在任何生产环境中运行您的模型。TorchScript 还能够执行适时的图形级优化，从而提供比规范 PyTorch 更高的性能。
要将 Elastic Inference 与 PyTorch 联合应用，必须将模型转换为 TorchScript 格局，并将推理 API 用于 Elastic Inference。本文通过示例阐明了如何将模型编译到 TorchScript 及如何应用反对 Elastic Inference 的 PyTorch 掂量端到端推理提早的基准。最初，本文比拟了各种不同的实例和加速器组合与独立 CPU 和 GPU 实例的性能和老本指标。
应用 TorchScript 编译和序列化模型
咱们能够应用 tracing 或 scripting 将 PyTorch 模型编译到 TorchScript 中。它们都会生成计算图形，但形式不同。
编写模型脚本的举荐办法通常是编译到 TorchScript，因为它会保留所有模型逻辑。然而在撰写本文时，可应用 PyTorch 1.3.1 编写脚本的模型集比可跟踪的模型集小。模型或者能够跟踪，但不能编写脚本，或者依据无奈跟踪。咱们可能须要批改您的模型代码，以使其与 TorchScript 兼容。
因为 Elastic Inference 目前在 PyTorch 1.3.1 中解决控制流操作的形式，对于蕴含很多条件分支的脚本模型而言，推理提早可能不是最优的。同时尝试跟踪和脚本，理解模型在应用 Elastic Inference 时的体现。随着 1.3.1 版本的公布，跟踪模型的体现可能比其脚本版本好。
无关更多信息，请参阅 PyTorch 网站上的 TorchScript 介绍教程。
脚本
脚本通过间接剖析元代码来构建计算图形和保留控制流。上面的示例显示了如何应用脚本编译模型。它应用 TorchVision 为 ResNet-18 预训练的权重。咱们能够将生成的脚本模型保留到一个文件中，而后应用反对 Elastic Inference 的 PyTorch 将它与 torch.jit.load 一起加载。请参阅以下代码：
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 输出。产生这种状况是因为在应用特定输出进行跟踪时，并不会执行所有的代码门路。
上面的示例显示如何应用跟踪与随机化张量输出编译模型。它还应用 TorchVision 为 ResNet-18 预训练的权重。咱们必须将 torch.jit.optimized_execution 上下文块与第二个参数用户设施序号，以将跟踪模型与 Elastic Inference 联合应用。这个批改的函数定义承受两个参数，仅可通过反对 Elastic Inference 的 PyTorch 框架提供。
如果应用规范的 PyTorch 框架跟踪模型，请疏忽 torch.jit.optimized_execution 数据块。咱们依然能够将生成的脚本模型保留到一个文件中，而后应用反对 Elastic Inference 的 PyTorch 将它与 torch.jit.load 一起加载。请参阅以下代码：
# 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)保留并加载编译的模型
跟踪和脚本的输入为 ScriptModule，它是规范 PyTorch 的 nn.Module 的 TorchScript 模仿。对 TorchScript 模块进行序列化和反序列化别离与调用 torch.jit.save() 和 torch.jit.load() 一样。它是应用 torch.save () 和 torch.load () 保留和加载规范 PyTorch 模型的 JIT 模仿。请参阅以下代码：
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')不同于保留的规范 PyTorch 模型，保留的 TorchScript 模型不会绑定到特定的类和代码目录。咱们能够间接加载保留的 TorchScript 模型，无需先实例化模型类。如此一来，就能够在没有 Python 的环境中应用 TorchScript 模型。
带有 Elastic Inference PyTorch 的 Amazon SageMaker 中的端对端推理基准
下文将逐渐介绍应用 Amazon SageMaker 托管终端节点掂量 DenseNet-121 的反对 Elastic Inference 的 PyTorch 推理提早基准的过程。
DenseNet-121 是一种卷积神经网络（CNN），已在各种数据集的图像分类中获得一流后果。它的架构松散地建设在 ResNet（另一个常见的图像分类 CNN）的根底上。
Amazon SageMaker 托管能力使得将模型部署到 HTTPS 终端节点变成可能，从而使模型可用于通过 HTTP 申请执行推理。
先决条件
此演示将 EC2 实例用作客户端，以启动并与 Amazon SageMaker 托管的终端节点交互。此客户端实例没有附加加速器；咱们将启动终端节点，该终端节点可预置附加了加速器的托管实例。若要实现此演练，必须先实现以下先决条件：
Ø 创立 IAM 角色并增加 Amazon SageMaker FullAccess，此策略可授予应用 Amazon Elastic Inference 和 Amazon SageMaker 的权限。
- 确保 sagemaker.amazonaws.com 是“信赖关系”下的受信赖实体。
- 无关更多信息，请参阅为实例角色配置一个 Elastic Inference 策略和 Amazon SageMaker 角色。
Ø 启动 m5.large CPU EC2 实例。
- 应用 Linux 或 Ubuntu Deep Learning AMI (DLAMI) v27。
本文应用 DLAMI 中内置的 Elastic Inference 反对的 PyTorch Conda 环境，只拜访 Amazon SageMaker 开发工具包，并应用 PyTorch 1.3.1 保留 DenseNet-121 权重。当 Amazon SageMaker Notebook 反对公布时，咱们能够应用 Notebook 内核代替之。
托管的实例和加速器通过 AWS DL Container 应用 Elastic Inference 反对的 PyTorch。为客户端实例抉择的环境只能简化 Amazon SageMaker 开发工具包的应用，及应用 PyTorch 1.3.1 保留模型权重。
演示
请实现以下步骤：
- 登录创立的实例。
- 应用以下命令激活 Elastic Inference 反对的 PyTorch Conda 环境：
source activate amazonei_pytorch_p36- 创立一个名为 script.py 的空文件。此文件将用作托管容器的入口点。此文件为空，是为了触发默认的 model_fn 和 predict_fn。默认 predict_fn 同时实用于规范 PyTorch 和 Elastic Inference 反对的 PyTorch。但默认 model_fn 只能为 Elastic Inference 反对的 PyTorch 施行。如果要衡量标准 PyTorch 的基准，则须要像以前一样施行本人的 model_fn。
- 在同一个目录中，应用以下代码创立名为 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 中提取。无关更多信息，请参阅将 PyTorch 与 SageMaker Python 开发工具包联合应用。
- 运行脚本以应用下列命令创立原始码：
python create_sm_tarball.py- 应用以下代码创立名为 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 角色。该脚本应用咱们以前创立的原始码和空白入口点脚本来预置 Amazon SageMaker 托管的终端节点。此示例代码可掂量附加了 ml.eia2.medium 加速器的 ml.c5.large 托管实例的基准。
咱们不用间接提供映像来创立终端节点，但为了分明起见，此文会提供。无关其余框架的可用 Docker 容器的更多信息，请参阅深度学习容器镜像。
- 应用以下命令运行脚本，以创立附加了 ml.c5.large 和 ml.eia2.medium 的托管终端节点：
python create_sm_endpoint.py- 转至 SageMaker 控制台并期待终端节点实现部署。此过程应该须要破费 10 分钟左右。当初已准备就绪，能够调用终端节点进行推理。
- 应用以下代码创立名为 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 {} seconds\n'.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 个推理。提早百分位数仅应用这 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。
如果决定在应用 Elastic Inference 时施行本人的 predict_fn，必须记得应用 torch.jit.optimized_execution 上下文，否则推理将齐全运行在托管实例上，且不会应用附加的加速器。无关更多信息请参阅将 PyTorch 与 SageMaker Python 开发工具包联合应用。
默认处理程序提供在 GitHub 上。
- 应用以下命令运行基准脚本：
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 加速器抉择。
- 提早要求 – 当领有一组具备足够内存的托管实例和加速器后，能够将抉择范畴进一步放大到满足应用程序提早要求的那些实例和加速器。本文将每次推理的提早视为评估性能的要害指标。按单位工夫解决的图像或单词的推理吞吐量是另一个罕用指标。
- 老本 – 当领有一组同时满足内存和提早要求的硬件组合后，能够通过抉择为每次推理提供最低价格的组合来优化老本效率。能够将此指标计算为（价格 / 秒 * 每次推理调用的均匀提早）。为了使数字更加具体，本文提供每 100000 次推理的费用。咱们能够比拟工作负载的老本效率，并通过这样做来为每个硬件组合抉择最佳硬件。本文应用美国西部（俄勒冈）区域的每小时价格。
现已准备就绪，可利用此过程来抉择最佳实例以运行 DenseNet-121。首先，评估应用程序的内存和 CPU 要求，并将符合要求的托管实例和加速器子集列入候选名单。
接下来，理解一下提早性能。本文对每个实例都应用雷同的张量输出和 DenseNet-121 的 TorchVision ImageNet 预训练权重。咱们应用此输出在模型上运行 1000 次推理，收集每次运行的提早，并报告均匀提早和第 90 个百分位的提早（P90 提早）。本文要求 P90 提早低于 80 毫秒，也就是说所有推理调用中 90% 的调用提早应低于 80ms。
咱们将 Amazon Elastic Inference 加速器附加在三种类型的 CPU 托管实例上，并为其各自运行前述性能测试。上面列出了每小时价格、每次推理调用的均匀提早和每 100000 次推理的费用。上面的所有组合均满足提早预置。
能够看到不同托管实例对提早的影响。对于雷同加速器类型，应用更弱小的托管实例不会显著改善提早。然而，附加较大的加速器可升高提早，因为模型运行在加速器上，且较大的加速器领有更多的资源，如 GPU 计算和内存。咱们应该抉择可为应用程序提供足够 CPU 内存的最便宜的托管实例类型。ml.m5.large 或 ml.c5.large 足够用于很多应用案例，但并非全副应用案例。
基于前述规范，本文抉择满足提早要求的两个老本最低的选项，即带有 ml.eia2.medium 的 ml.c5.large 和带有 ml.eia2.medium 的 ml.m5.large。对于此应用案例，两者都是可行的。
比拟不同实例在 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 实例上带来的性价比，咱们能够针对每种硬件类型应用图形显示此提早和老本数据。上面的条形图绘制了每 100000 次推理的费用，线形图绘制了 P90 推理提早（以毫秒为单位）。深灰色条形指的是带有 Elastic Inference 加速器的实例，绿色条形指的是独立的 GPU 实例，蓝色条形指的是独立的 CPU 实例。
提早剖析
跟预期的一样，CPU 实例的性能不如 GPU 实例的性能。ml.g4dn.xl 实例的速度约比 CPU 实例快 7 倍。所有的独立 CPU 实例都不满足 80ms 的 P90 提早阈值。
然而这些 CPU 实例在附加了 Elastic Inference 的状况下性能更好，因为它们受害于 GPU 减速。带有 ml.eia2.medium 的 ml.c5.large 实例将推理速度进步到独立 CPU 实例的靠近 3 倍。然而独立的 GPU 实例依然比附加了 Elastic Inference 的 CPU 实例好；ml.g4dn.xl 的速度比带有 ml.eia2.medium 的 ml.c5.large 的速度快两倍多一点。请留神，ml.g4dn.xl、ml.g4dn.2xl 和 ml.g4dn.4xl 实例的提早大抵相等，差别可忽略不计。全副三个 ml.g4dn 实例都具备雷同的 GPU，但较大的 ml.g4dn 实例领有更多的 vCPU 和内存资源。对于 DenseNet-121 而言，减少 vCPU 和内存资源不会改善推理提早。
Elastic Inference 和独立的 GPU 实例都满足提早要求。
老本剖析
在老本方面，带有 ml.eia2.medium 的 ml.c5.large 体现比较突出。尽管带有 ml.eia2.medium 的 ml.c5.large 不具备最低的每小时价格，但它每 100000 次推理的费用是最低的。无关每小时定价的更多信息，请参阅 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.eia2.medium 的 ml.c5.large 是费用最低的选项，它满足运行 DenseNet-121 的提早规范和内存应用要求。
本文应用的提早指标（CloudWatch Metrics 中公布的 ModelLatency）可掂量 Amazon SageMaker 内的提早。此提早指标未思考到从应用程序到 Amazon SageMaker 的提早。确保在掂量应用程序的基准时思考到这些提早。
小结
Amazon Elastic Inference 是一项灵便的低成本解决方案，实用于 Amazon SageMaker 上的 PyTorch 推理工作负载。通过将 Elastic Inference 加速器附加到 Amazon SageMaker 实例，咱们能够取得相似于 GPU 的推理减速并放弃比独立的 Amazon SageMaker GPU 和 CPU 实例更高的老本效益。更多信息请参阅什么是 Amazon Elastic Inference？
