如何在AWS SageMaker中分离预处理与推理至不同实例部署？

核心结论 #

SageMaker单个端点无法实现预处理和推理在不同实例运行——多容器端点的设计逻辑是让多个容器共享同一组实例的资源，用于在单实例内完成多阶段任务处理，而非跨实例拆分工作负载。

最优实现方案 #

方案1：API Gateway + Lambda（CPU）+ SageMaker GPU推理端点

• 执行流程：前端请求通过API Gateway触发CPU环境的Lambda函数，完成图像解码、缩放、归一化等预处理操作；预处理完成后，Lambda直接调用SageMaker GPU推理端点执行模型预测，最终将结果返回至前端。
• 核心优势：Lambda采用按需计费模式，闲置时无成本，CPU资源成本远低于GPU实例；SageMaker GPU端点仅需专注于推理任务，资源利用率更高；预处理与推理环节独立扩缩容，可根据各自负载灵活调整配置。
• 注意事项：若预处理逻辑复杂或单请求数据量较大，可替换Lambda为ECS Fargate（同样使用CPU实例）运行预处理服务，规避Lambda的执行时间与内存限制。

方案2：SageMaker Processing + 批量推理（非实时场景）

• 执行流程：针对批量图像处理任务，先通过配置CPU实例的SageMaker Processing Job完成全量图像预处理，将处理后的数据存储至S3；再使用SageMaker批量转换或异步推理（GPU实例）读取S3中的预处理数据执行推理。
• 核心优势：批量场景下CPU预处理与GPU推理完全解耦，可分别调度最优实例类型，大幅降低整体成本；Processing Job支持自动扩缩容，适配大规模数据处理需求。

方案3：ECS/EKS微服务架构（高灵活度场景）

• 执行流程：将预处理服务（CPU实例部署）与推理服务（GPU实例部署）分别打包为Docker镜像，部署至ECS或EKS集群；通过内部负载均衡或服务发现实现服务间调用，前端请求先发送至预处理服务，处理完成后转发至推理服务，最终返回结果。
• 核心优势：可完全独立控制预处理与推理的实例类型、数量及扩缩容策略；支持复杂业务逻辑扩展（如预处理结果缓存、请求排队等）；适配高并发、低延迟的实时业务场景。

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