如何解决我的 Amazon SageMaker 端点的延迟问题？

简短描述

您可以使用 Amazon CloudWatch 监控为单一模型提供服务的 SageMaker 端点的延迟指标 ModelLatency 和 OverheadLatency。

• ModelLatency 是 SageMaker 所查看的模型响应推理请求所用的时间。此持续时间包括模型发送请求和获取响应的本地通信时间。它还包括模型容器内推理的完成时间。
• OverheadLatency 是使用 SageMaker 开销响应调用请求所用的时间。此时间的计算方式是：从 SageMaker 收到请求到返回响应的时间中减去 ModelLatency。

当您使用 SageMaker 多模型终端节点时，CloudWatch 中提供了以下额外指标：

• **ModelLoadingWaitTime：**调用请求在执行推理之前等待目标模型下载或加载的时间。
• **ModelDownloadingTime：**从 Amazon Simple Storage Service（Amazon S3）下载模型所用的时间。
• **ModelLoadingTime：**从容器加载模型所用的时间。
• **ModelCacheHit：**发送到已加载模型的端点的 InvokeEndpoint 请求数量。

多模型终端节点会在模型的整个生命周期内加载和卸载模型。您可以使用 LoadedModelCount CloudWatch 指标来查看端点的已加载模型数量。

解决方法

高 ModelLatency

您可以通过采取以下措施来减少这种延迟：

• 在 SageMaker 端点之外对模型进行基准测试以测试性能。
• 如果您的模型受 SageMaker Neo 的支持，可以对模型进行编译。SageMaker Neo 可将模型的运行速度优化到两倍，同时所占用的内存不到十分之一，也不会对准确性造成任何影响。
• 如果 AWS Inferentia 支持您的模型，则您可以为 Inferentia 编译模型。与基于 AWS GPU 的实例相比，该模型可提供多三倍的吞吐量，并将每次推理的成本降低多达 45%。
• 如果您使用的是 CPU 实例，并且该模型支持 GPU 加速，则可以使用 GPU 实例为实例添加 GPU 加速。
  **注意：**推理代码可能会影响模型延迟，具体取决于代码处理推理的方式。代码中的任何延迟都会增加延迟。
• 如果端点被过度使用，可能会导致更高的模型延迟。您可以向端点添加自动扩缩，以动态增加和减少可用于端点的实例数量。

高 OverheadLatency

多种因素可能会增加 OverheadLatency。这些因素包括请求和响应的有效负载大小、请求频率，以及请求的身份验证或授权。

由于冷启动，端点的首次调用可能会增加延迟。第一次调用请求会遇到这种情况。为避免此问题，您可以向端点发送测试请求，对其进行预热。请注意，不频繁的请求也可能会导致 OverheadLatency 增加。