What is new

AWS has published an updated reference pattern for running computer vision inspection models across a large fleet of cameras on a factory floor, rebuilt for version 3 of the Amazon SageMaker Python SDK. The earlier version of this pattern, from 2023, relied on SageMaker Edge Manager, a service AWS has since deprecated. The new version replaces it with SageMaker Neo, AWS's model compilation service for edge hardware, and reorganizes the whole pipeline around the restructured SDK v3, which splits what used to be one monolithic library into separate packages for training, serving and workflow orchestration.

The full sample, including a working AWS Cloud Development Kit (CDK) deployment, is published in AWS's GitHub samples repository. According to the post, a complete pipeline run using synthetic data costs about seven cents in compute and takes roughly 15 minutes.

The problem it addresses

Quality-inspection computer vision tends to work well as a single-camera proof of concept and then breaks down at scale. A plant with 40 production lines, each with several cameras, does not see the same image twice: lighting, glare and camera angle differ line by line. AWS says that in production deployments it has worked on, a single model trained on pooled footage from many cameras consistently underperforms a set of models each fine-tuned on one camera's own footage. That solves the accuracy problem but creates a logistics problem instead: instead of training and shipping one model, a plant now has to train, evaluate, version and deploy a model per camera, potentially thousands of them, without a person checking each one by hand.

How the pipeline works

The architecture has two halves. The training half is a single SageMaker Pipeline, parameterized by camera ID, that runs 13 steps per execution. For each camera it trains two models in parallel branches: a small convolutional autoencoder that learns what a normal product looks like and flags deviations by how badly it reconstructs an image (an anomaly detector), and a ResNet18 image classifier fine-tuned to confirm whether a flagged item is actually defective. Both start from that camera's own most recent approved model rather than from scratch, so repeated re-training is cheap and incremental.

Each branch exports its trained model to ONNX, a portable model format, and evaluates that exported artifact — not the original in-memory model — against held-out data. AWS flags this as a deliberate design choice: evaluating the exact file you plan to ship means an export bug cannot let a broken model through on the strength of a training run that looked fine. Only a model that passes its quality gate moves on to be compiled by SageMaker Neo for the target edge device and then registered in the SageMaker Model Registry. A model that fails its gate is marked failed, never registered, and the camera keeps running its previous approved model.

The quality thresholds are chosen to fit how defect data actually behaves. In the sample, roughly 90 percent of images show a good part, so plain accuracy is close to useless — a model that always predicts "good" would score about 0.9 while catching no defects at all. The anomaly branch instead gates on AUROC (a measure of how well the model ranks normal versus abnormal images) of at least 0.8. The classifier branch requires two conditions to both hold: balanced accuracy — the average of the model's recall on each class — of at least 0.6, and recall on the defect class specifically of at least 0.5. Balanced accuracy alone can still hide a model that is excellent on good parts and poor on defects, so pairing it with a minimum defect-recall threshold closes that gap. Both thresholds are configurable pipeline parameters.

  • Two models trained per camera: a convolutional autoencoder for anomaly detection and a fine-tuned ResNet18 classifier for defect confirmation
  • Both models exported to ONNX and evaluated on that exported artifact before anything is approved
  • Anomaly gate: AUROC ≥ 0.8; classifier gate: balanced accuracy ≥ 0.6 AND defect recall ≥ 0.5
  • Approved models are compiled with SageMaker Neo for a chosen edge target (for example Jetson Xavier or Raspberry Pi 4B) before registration
  • Fleet training requests are queued and throttled through Step Functions, SQS and a DynamoDB-based concurrency limiter, capped at five simultaneous pipeline runs by default
  • A full synthetic-data pipeline run costs about $0.07 and takes about 15 minutes, according to AWS

Keeping the fleet within account limits

Training jobs consume SageMaker's concurrent-job quota, and a sudden backlog of hundreds of cameras needing re-training could otherwise try to launch hundreds of pipelines at once. The orchestration layer sits on top: re-training requests land in an Amazon SQS queue, a Lambda function starts a Step Functions execution for each one, and each execution must first acquire a slot from a counter stored in DynamoDB before it is allowed to start its pipeline. The counter uses an atomic, conditional update so that a burst of requests drains at a steady rate rather than racing past the cap. The default cap is five concurrent pipelines, deliberately set low so the sample runs without requesting a quota increase, but it is adjustable. Failures, whether from a quality gate or an operational error, are routed to Amazon SNS through EventBridge rather than disappearing silently.

Why it matters

The specific combination here — gating on the exported, ship-ready artifact rather than the training-time model; compiling for the edge before registration so nothing is approved that the fleet's hardware can't actually run; and using per-camera metadata to turn one shared model registry into a searchable per-camera history — is a template that generalizes beyond vision inspection to any fleet of edge devices producing per-unit models. AWS also notes the design principle behind the classifier's two-part gate: for heavily imbalanced data, plain accuracy and even balanced accuracy alone can mask poor performance on the class that actually matters.

Limits and open questions

This is a reference sample, not a managed product: it requires the account to set up IAM roles, an S3 bucket, an ECR repository and several other services, and the post notes some SDK v3 quirks that affect anyone deploying it through CDK, such as IAM role validation happening at pipeline-synthesis time rather than at execution time. AWS points out that teams whose needs fit a fully managed option such as Amazon Lookout for Vision have a simpler path; this pattern is aimed specifically at the fleet-scale, per-camera constraint that managed services don't cover. Scaling past a single AWS account's training-job quotas is left as an open design problem, with AWS suggesting levers like requesting higher quotas, spreading jobs across instance types, regions or accounts, and holding a backlog in SQS.

How to try it

The code is available at aws-samples/sample-sagemaker-fleet-cv-pipeline on GitHub, with a two-phase CDK deployment (first creating roles, bucket and ECR repository, then deploying the pipeline and orchestration stack). By default the sample generates synthetic production-line images so it can be run end to end without any real dataset. For testing against real images, the repository includes a downloader for the BCCD dataset, a small, MIT-licensed collection of 364 annotated blood-smear microscopy images, with platelet presence mapped to a stand-in "defect" class purely as an illustrative exercise, not a clinical claim.

Sources