# AWS beschreibt kamerabezogene Sichtprüfung mit SageMaker SDK v3

- Source: MechNext — https://mechnext.eu/de/article/54-aws-outlines-per-camera-visual-inspection-lifecycle-with-sagemaker-sdk-v3
- Published: 2026-10-27
- Updated: 2026-10-27
- Category: Industry News
- Language: de (Markdown in other languages: ?lang=en, ?lang=sk, ?lang=pl, ?lang=zh, ?lang=ru)

> Eine AWS-Referenzarchitektur verbindet Training je Kamera, Qualitätsprüfungen für ONNX und Neo-Kompilierung. Sie regelt paralleles Nachtrainieren und grenzt die Gerätebereitstellung ab.

AWS stellt eine Referenzarchitektur für visuelle Prüfung mit SageMaker Python SDK v3 vor. Sie aktualisiert ein Pipeline-Muster von 2023, ersetzt den veralteten SageMaker Edge Manager durch SageMaker Neo zur Optimierung für Edge-Geräte und stellt die Infrastruktur über AWS CDK bereit. Der Beitrag beschreibt eine Beispielimplementierung; die Ergebnisse sind keine unabhängige Bestätigung für den Betrieb einer Produktionsflotte.

### Eine Pipeline für einzelne Kameras

Das Beispiel nutzt eine über Kameraparameter gesteuerte SageMaker Pipeline mit 13 Schritten. Sie verarbeitet Bilder vor, lädt die neuesten freigegebenen Modelle der jeweiligen Kamera und trainiert zwei Zweige: einen konvolutionalen Autoencoder zur Anomalieerkennung und einen angepassten ResNet18 zur Fehlerklassifikation. Der Klassifikator verwendet auf ImageNet vortrainierte Gewichte und einen Kopf für zwei Klassen. Ein WeightedRandomSampler gleicht Trainingsbatches durch inverse Klassenhäufigkeiten aus; die Verlustfunktion bleibt ungewichtet.

Jeder Zweig verwendet eine gemeinsame Modellpaketgruppe. Die Pakete enthalten Kamera-IDs und Bewertungsmetriken. Da ListModelPackages kundenspezifische Metadaten nicht serverseitig filtern kann, durchsucht der Abruf freigegebene Pakete vom neuesten aus nach der gewünschten Kamera. Beim ersten Lauf startet der Klassifikator mit ImageNet-Gewichten und der Autoencoder mit zufälliger Initialisierung. Spätere Läufe setzen beim bisherigen Kameramodell an.

### Qualität vor Kompilierung und Registrierung

Die Bewertung erfolgt an exportierten ONNX-Artefakten. Der Anomaliezweig benötigt eine AUROC von mindestens 0,8. Der Klassifikator muss sowohl eine ausgewogene Genauigkeit von mindestens 0,6 als auch einen Recall für Fehler von mindestens 0,5 erreichen. Die Schwellen lassen sich je Ausführung anpassen. Ein gescheiterter Zweig registriert sein Modell nicht; der andere kann unabhängig davon erfolgreich sein. Die Kamera nutzt weiterhin ihr bisheriges freigegebenes Modell.

Beide Zweige folgen der Reihenfolge Qualitätsprüfung, Neo-Kompilierung und Registrierung. Für die Kompilierung wird der Export in ein ausschließlich ONNX enthaltendes Tar-Archiv verpackt und die Batchgröße auf 1 festgelegt. Der Auftragsname wird aus der Pipeline-Ausführungs-ID abgeleitet. Wiederholungsversuche können dadurch die Statusabfrage des bestehenden Kompilierungsauftrags fortsetzen.

Neo-Ziele sind Pipeline-Parameter. Die Standardplattform ist LINUX/X86_64; benannte Geräteoptionen umfassen jetson_xavier und rasp4b. Das kompilierte Paket enthält compiled.so und die DLR-Laufzeit. Ein Skript im Repository kompiliert registrierte Modelle auch für weitere Gerätetypen, ohne sie erneut zu trainieren.

Die Model Registry katalogisiert portable ONNX-Artefakte, während S3 die von DLR geladenen Neo-Builds speichert. Die Registereinträge verweisen auf das Trainingsimage und sind für eine nachgelagerte Artefaktlieferung an Geräte vorgesehen, nicht für CreateEndpoint. Die Beispielimplementierung enthält weder diese Gerätebelieferung noch Inferenzendpunkte.

### Nachtraining und Umstellung auf SDK v3

Anfragen zum Nachtraining gelangen in eine SQS-FIFO-Warteschlange. Lambda startet je Anfrage eine Step-Functions-Ausführung. Ein DynamoDB-Semaphor begrenzt parallele Pipeline-Ausführungen atomar, standardmäßig auf fünf. Bei voller Kapazität warten Ausführungen und versuchen es erneut. Plätze werden bei Abschluss und auf Fehlerpfaden freigegeben. SNS meldet Abschlüsse und Betriebsfehler; Fehler werden über EventBridge weitergeleitet.

SDK v3 teilt Funktionen in modulare Pakete auf und übergibt die Trainingskonfiguration als typisierte Objekte an ModelTrainer. Die Live-Prüfung der IAM-Rolle bei der CDK-Synthese erfordert in diesem Beispiel eine zweiphasige Bereitstellung und eine konkrete Rollen-ARN. Laut AWS benötigt die ECR-Berechtigungssimulation des v3-Validators zudem eine breitere Freigabe als eine Laufzeitrichtlinie für nur ein Repository.

### Messwerte und Beispieldaten

Standardmäßig erzeugt die Lösung synthetische Bilder einer Produktionslinie. AWS nennt rund 15 Minuten für alle 13 Schritte einschließlich beider Neo-Kompilierungen sowie etwa 0,07 US-Dollar an abgerechneter ml.m5.xlarge-Zeit zu On-Demand-Preisen vom Juli 2026 in US East (Ohio). Die Orchestrierung koste im Beispielumfang deutlich unter 0,10 US-Dollar monatlich. Neo berechnet die Kompilierung selbst nicht; Verarbeitung und S3-Speicherung verursachen Kosten. Diese Angaben lassen sich nicht auf Produktionsflotten, andere Regionen, Hardware oder Preiszeiträume übertragen.

Ein Downloader lädt außerdem 364 annotierte BCCD-Blutausstrichbilder, kann sie nach Kamera aufteilen und Trainingsarchive hochladen. Das Vorhandensein von Blutplättchen wird der Fehlerklasse zugeordnet. Ein Notebook führt die Pipeline aus und vergleicht ONNX-Inferenz an normalen und anomalen Beispielen. Der Beitrag bezeichnet die Zuordnung ausdrücklich als Fertigungsillustration, nicht als klinische Aussage.