AWS SageMaker endpoint调用额外延迟原因排查及优化咨询

1. 推理脚本全链路耗时排查 #

• 优先统计inference.py中input_fn、output_fn两个函数的耗时，你当前仅统计了predict_fn的75ms推理耗时，绝大多数场景下序列化/反序列化的开销都被遗漏了，尤其是处理大文本、多模态等格式的请求/响应时，这部分开销很容易超过100ms。
• 可以在input_fn第一行、output_fn最后一行埋点计时，确认脚本层总耗时是否和你之前统计的75ms一致。

2. SageMaker平台层耗时排查 #

• 查看CloudWatch中Endpoint的ModelLatency指标，该指标是SageMaker从收到请求到完成响应发送的总内部耗时，减去你统计的脚本总耗时，差值就是SageMaker容器框架层的额外开销。
• 如果你使用的是官方HuggingFace DLC容器，检查是否开启了默认的请求校验、自动格式转换等额外中间件逻辑，这部分内置逻辑也会产生额外耗时。
• 查看OverheadLatency指标，该指标反映了请求在SageMaker队列中的等待耗时，如果指标过高说明当前实例负载不足，请求出现排队。

3. 实例与负载相关耗时排查 #

• 检查实例CPU/GPU利用率，若平均利用率超过70%，会直接导致请求排队、调度延迟升高，可升级实例规格或调低自动扩缩容触发阈值。
• 排除冷启动干扰：长时间无流量后收到的第一个请求会触发模型重新加载到显存/内存，耗时会大幅升高，测试时建议连续发送10次以上请求，取后5次的平均值作为基准数据。
• 检查单实例模型并发配置，如果当前并发请求数超过设置的并发上限，请求会进入排队队列产生额外耗时。

4. 调用链路与网络耗时排查 #

• 同区域VPC内直接调用Endpoint测试，排除API Gateway、Lambda等中间转发层的额外开销，这类中间服务本身的处理耗时很容易达到几十到上百ms。
• 用curl -w命令统计完整请求的各阶段耗时：curl -w "@curl-format.txt" -o /dev/null -s <Endpoint调用地址>，明确DNS解析、TCP握手、TLS握手、请求上传、响应下载各阶段的实际耗时，确认网络开销是否符合预期。
• 确认调用侧和SageMaker Endpoint是否在同一AWS区域，跨区域调用本身就会产生几十到上百ms的网络延迟。

5. 通用优化方向 #

• 用ujson替代默认json库处理序列化/反序列化，大体积请求/响应用msgpack等二进制格式传输，同时开启传输压缩。
• GPU实例可开启TensorRT/ONNX Runtime优化，或用SageMaker Neo编译模型，进一步降低推理耗时。
• 调整批量推理配置，允许小批量请求合并处理，提升吞吐的同时降低平均请求耗时。

内容的提问来源于stack exchange，提问作者AndrewL