Cómo gestionar una flota de modelos de visión por computadora en el edge con SageMaker SDK v3

El desafío en producción

Un prototipo de inspección de calidad suele funcionar bien con una cámara y un modelo. El problema aparece cuando la planta pide el mismo resultado en 40 líneas, cada una con varias cámaras. Cada cámara ve el mundo de forma distinta: ángulo, reflejos sobre el mismo acero inoxidable y variaciones de luz según la puerta del bay que esté abierta. En muchos despliegues productivos, un único modelo entrenado con metraje agregado rinde peor que modelos finos ajustados por cámara.

Entonces la dificultad deja de ser solo entrenar un buen modelo y pasa a ser cómo entrenar, evaluar, versionar y desplegar miles de modelos sin intervención humana por cada cámara. El patrón que presentamos actualiza una solución previa para que funcione con Amazon SageMaker Python SDK v3 y reemplaza el obsoleto SageMaker Edge Manager por SageMaker Neo para la optimización en el edge.

Arquitectura y flujo general

La solución divide responsabilidades en dos capas principales: el pipeline de entrenamiento por cámara y una capa de orquestación que regula el trabajo en toda la flota.

• Por cada cámara se ejecuta un pipeline parametrizado que prepara datos, entrena dos modelos (un detector de anomalías y un clasificador de defectos), evalúa, pasa por puertas de calidad y produce artefactos versionados listos para el dispositivo.
• La orquestación usa una cola FIFO (Amazon SQS) donde llegan pedidos de re-entrenamiento; un Lambda inicia una ejecución de AWS Step Functions por solicitud. Antes de comenzar, cada ejecución adquiere un “slot” mediante un semáforo en DynamoDB, de modo que los re-entrenamientos se espacen y no saturen las cuotas de entrenamiento concurrente.

Las notificaciones de éxito y errores operativos se publican en Amazon SNS; EventBridge mantiene el rastro de fallas preservando el error original.

El pipeline por cámara: dos ramas y 13 pasos

El pipeline de SageMaker es único pero bifurcado: por cámara corre 13 pasos en total. Tres pasos de entrada que se ejecutan en paralelo son Preprocess, Fetch Latest Anomaly y Fetch Latest Classifier. En resumen:

• Preprocess: prepara las imágenes específicas de la cámara.
• Fetch Latest: recupera el modelo aprobado más reciente para cada rama (calentamiento/warm-start), filtrando por el ID de la cámara como metadato, de modo que cada re-entrenamiento retome su propia historia.
• Rama de anomalías: entrena un pequeño autoencoder convolucional que aprende la apariencia normal del producto y marca anomalías por error de reconstrucción.
• Rama de clasificación: fine-tunea un ResNet18 para confirmar y clasificar defectos.
• Exportación: cada modelo se exporta a ONNX y se evalúa el artefacto exportado contra datos reservados (held-out) antes de pasar una puerta de calidad.
• Compilación: solo los modelos que superan la puerta pasan por SageMaker Neo para compilarse hacia el objetivo de edge configurado.
• Registro: finalmente, los modelos aprobados se registran en SageMaker Model Registry. Cada paquete registrado incluye el ONNX portátil y, en S3, la build compilada por Neo, que es una biblioteca optimizada cargada por el runtime DLR en el dispositivo.

Como resultado, cada versión aprobada es una unidad lista para entrega al dispositivo, incluyendo una artefacto optimizado por hardware.

Orquestación de la flota

La orquestación protege recursos y garantiza un flujo controlado de trabajo:

• Amazon SQS FIFO recibe solicitudes de re-entrenamiento.
• Un AWS Lambda inicia una ejecución de Step Functions por cada solicitud.
• Cada ejecución adquiere un slot en DynamoDB para limitar la concurrencia (por defecto el patrón admite hasta cinco ejecuciones simultáneas), evitando picos que excedan las cuotas de entrenamiento.
• Salidas y fallas informan a través de SNS y EventBridge.

Este diseño permite escalar desde pruebas con una o pocas cámaras hasta operaciones en flotas grandes sin intervención manual por modelo.

Optimización para dispositivos y registro

Una diferencia clave en la actualización a SDK v3 es el reemplazo de SageMaker Edge Manager por SageMaker Neo para la compilación de modelos hacia dispositivos. La solución asegura que lo que se registra en el Model Registry no sea solo el ONNX portable, sino también la build compilada por Neo almacenada en S3. Esa build no es ONNX en ejecución: es una biblioteca optimizada, cargada por el runtime DLR en el dispositivo, y lista para el mecanismo de entrega que use su planta.

Además, las versiones cargan metadatos con el ID de la cámara, permitiendo que el pipeline haga warm-start desde el historial propio de cada cámara en re-entrenamientos sucesivos.

Cambios relevantes en SageMaker SDK v3

El SDK v3 reorganizó la librería Python de SageMaker en paquetes modulares, lo que implica diferencias en imports y organización del código. El ejemplo disponible en el repositorio de muestras funciona dentro de una aplicación AWS CDK que sintetiza la definición del pipeline durante el despliegue.

Requisitos y notas de despliegue

Para desplegar la muestra se necesitan:

• Cuenta AWS con permisos para crear roles IAM.
• Un bucket en S3 y un repositorio en Amazon ECR.
• Recursos configurados por las stacks: SageMaker, Step Functions, Lambda, SQS, SNS, EventBridge y DynamoDB.
• Python 3.10, 3.11 o 3.12, y Docker.
• AWS CDK CLI versión 2.1131.0 o posterior (versiones anteriores fallan por incompatibilidad de esquema de ensamblado cloud).

No es necesario solicitar aumentos de cuota en la mayoría de despliegues: la orquestación por defecto limita a cinco ejecuciones de pipeline simultáneas, manteniendo los trabajos de entrenamiento dentro de la cuota estándar.

Un detalle operativo importante: si despliegan a una región distinta de la configurada por defecto del CLI, ajusten las tres variables de entorno de región en la línea de despliegue (AWS_REGION, AWS_DEFAULT_REGION y CDK_DEFAULT_REGION) para evitar despliegues parciales y confusos.

Costo de referencia: una ejecución completa del pipeline con datos sintéticos cuesta cerca de $0.07 en cómputo, según la muestra original.

Implicaciones para industrias en América Latina

En plantas latinoamericanas las condiciones de iluminación, diversidad de equipos y limitaciones de conectividad hacen crítico contar con artefactos optimizados y procesos automáticos de entrenamiento por cámara. Este patrón ayuda a:

• Reducir intervención manual al escalar soluciones de inspección visual.
• Entregar modelos compilados que funcionan en dispositivos con conectividad intermitente o con recursos limitados.
• Mantener trazabilidad por cámara usando el Model Registry y metadatos.

Al adoptar un enfoque automatizado y parametrizado por cámara, equipos técnicos y líderes de planta pueden priorizar despliegues y planes de mantenimiento sin multiplicar el trabajo operativo.

Conclusión

Gestionar el ciclo de vida de modelos de visión por cámara en el edge exige automatización sólida: pipelines per-cámara, puertas de calidad, compilación para dispositivo y una capa de orquestación que controle la concurrencia. La actualización a SageMaker SDK v3 y el uso de SageMaker Neo para compilación ofrecen un patrón reproducible que facilita poner en producción soluciones de inspección visual a escala, con artefactos listos para ejecutar en el edge y registrar por versión y cámara.

El repositorio de muestra en GitHub contiene la implementación completa y los recursos CDK necesarios para desplegar el patrón y adaptarlo a las particularidades de cada planta.