用 SageMaker SDK v3 管理边缘端全车队计算机视觉模型生命周期

当视觉质检的概念验证在一台摄像头、一个模型上跑通后，工厂往往很快提出在数十条产线上复制同样效果的需求。但每台摄像头的角度、不锈钢表面反光和环境光都不同，用汇总素材训练的单一模型常常达不到单台摄像头的效果，最终每台摄像头都需要自己的微调模型。真正的难题随之变成如何在没有人工逐台介入的情况下，完成数千个模型的训练、评估、版本管理和下发。

AWS 在博客中给出了面向当前 Amazon SageMaker Python SDK v3 的更新方案，替代 2023 年那套端到端视觉质检 MLOps 流水线，并用 Amazon SageMaker Neo 取代已弃用的 SageMaker Edge Manager 做边缘优化。

方案结构

训练侧是一条按摄像头参数化的 SageMaker Pipeline，每次执行运行 13 个步骤。预处理、拉取最新异常检测模型、拉取最新分类器三个入口步骤并行执行，随后训练两个模型：一个学习正常产品外观、以重建误差标记异常的小型卷积自编码器，以及一个用于确认缺陷的 ResNet18 微调分类器。

每个分支都会把模型导出为 ONNX，在留出数据上评估导出产物，并通过质量门控。通过门控后，模型经 SageMaker Neo 针对配置的边缘目标编译，之后才注册进 SageMaker Model Registry。因此每个获批的模型包都带有可直接部署到设备的编译产物。模型包以摄像头 ID 作为元数据，热启动拉取按该 ID 过滤，重训练总是从这台摄像头自己的历史继续。

编排侧负责控制车队节奏。重训练请求进入 Amazon SQS FIFO 队列，由 Lambda 为每个请求启动一次 Step Functions 执行；每次执行先通过 DynamoDB 信号量获取槽位再启动流水线，使突发请求以稳定速率消化而不是同时开跑。完成事件发布到 Amazon SNS，运行故障经 EventBridge 规则进入同一主题并保留原始错误。

输出结果是按摄像头版本化、经过质量门控的模型产物：Model Registry 保存可移植的 ONNX，S3 保存该模型的 Neo 编译版本——后者是由 DLR 运行时加载的设备优化共享库，而非 ONNX。

部署条件

示例通过 AWS CDK 部署，需要具备创建 IAM 角色权限的 AWS 账户、一个 S3 桶、一个 Amazon ECR 仓库，以及 SageMaker AI、Step Functions、Lambda、SQS、SNS、EventBridge、DynamoDB 相关资源。环境需 Python 3.10、3.11 或 3.12 及 Docker，AWS CDK CLI 版本不低于 2.1131.0，旧版本会因 cloud assembly schema 与新版 aws-cdk-lib 不匹配而失败。

方案不需要申请服务配额提升：编排层默认最多同时放行五次流水线执行，使并发 SageMaker 训练作业保持在标准账户配额内。若部署到非 CLI 默认区域，需在部署命令上同时设置 AWS_REGION、AWS_DEFAULT_REGION 和 CDK_DEFAULT_REGION，因为 CDK CLI、Boto3 与 AWS CLI 解析区域所用的变量集合并不完全一致，不一致会导致部分部署失败。

编辑部观察

这套方案的价值不在单个模型的精度，而在把“每台摄像头一个模型”的规模化成本压下来：质量门控阻止不达标模型进入注册表，Neo 编译前置到流水线内保证注册即带设备产物，信号量则把车队级并发控制在账户配额之内。博客给出的约 0.07 美元是合成数据上单次完整流水线的计算成本，真实产线数据量、摄像头数量和重训练频率会显著改变总成本，读者应以此为基础自行测算。

实践上可先在小范围摄像头验证质量门控阈值是否适配自身缺陷类型，再逐步扩大车队规模；同时确认边缘设备运行时与 Neo 编译目标的匹配关系，避免注册表里的产物与实际设备不兼容。