Die Verwaltung des Lebenszyklus des Computer-Vision-Modells auf Flottenebene ist ein Problem, das auftritt, sobald die Konzeptprüfung der Qualitätsinspektion erfolgreich ist. Eine Kamera und ein Modell funktionieren gut. Dann verlangt die Anlage dasselbe Ergebnis bei 40 Linien, jede mit mehreren Kameras, und jede Kamera sieht die Welt anders. Jede hat einen anderen Winkel, unterschiedliche Reflexionen auf der gleichen Stahloberfläche und unterschiedliches Umgebungslicht je nachdem, welche Tür geöffnet ist. In den Produktionsdeploys, an denen wir gearbeitet haben, unterwirft ein einzelnes Modell, das auf zusammengefassten Bildern trainiert wurde, die Leistung von einigen einzelnen Kameras, sodass jede Kamera ihr eigenes feinjustiertes Modell erhält. Das eigentliche Problem ist nun nicht mehr, ein Modell gut zu trainieren. Es geht darum, Tausende von Modellen zu trainieren, zu bewerten, zu versionieren und zu versenden, ohne dass ein Mensch für jedes Modell involviert ist.
Dieser Beitrag aktualisiert das Muster, das in der 2023er-Serie Ein End-to-End-MLOps-Pipeline für die visuelle Qualitätsprüfung an der Edge eingeführt wurde, für das aktuelle Amazon SageMaker Python SDK v3. Es ersetzt den seitdem deklassierten Amazon SageMaker Edge Manager durch Amazon SageMaker Neo zur Optimierung an der Edge. Ich zeige einen Amazon SageMaker Pipeline mit zweifacher Verzweigung, der einen Anomaliedetektor und einen Defektklassifikator pro Kamera trainiert, mit Qualitätsprüfstellen, die unterleistungsfähige Modelle blockieren. Ein in der Pipeline enthaltener Compilierungsschritt von SageMaker Neo sorgt dafür, dass jedes registrierte Modell mit einem für Geräte optimierten Produkt ausgeliefert wird, und eine AWS Step Functions-Orchestrierungsschicht steuert das Training der Flotten. Alles wird mit dem AWS Cloud Development Kit (AWS CDK) deployed, und eine vollständige Pipeline-Run auf synthetischen Daten kostet etwa $0,07 in Rechenkapazität.
Der vollständige Beispielcode ist im aws-samples GitHub-Repository verfügbar.
Lösungsüberblick
Das folgende Diagramm zeigt den Lebenszyklus des Modells über die gesamte Flotte des Beispiels. Eine Orchestrierungsschicht wartet auf Anfragen zur Neuerstellung und begrenzt die konkurrierende Arbeit. Ein Trainingsprozess pro Kamera bereitet Daten vor, trainiert und bewertet einen Anomaliedetektor sowie einen Klassifikator und erzeugt versionierte Modelartefakte für Edge-Geräte.
Abbildung 1: Lösungsarchitektur
Die Trainingshälfte ist ein einzelner SageMaker-Pipeline, der durch die Kamera parametriert wird und bei jeder Ausführung 13 Schritte ausführt. Drei Eingangs-Schritte laufen parallel: Präprozessierung, Abruf des neuesten Anomalien-Objekts und Abruf des neuesten Klassifikators. Der Pipeline prüft die Bilder der Kamera und holt das neueste genehmigte Modell der Kamera für jede Abteilung ab, anschließend trainieren zwei Modelle. Das erste Modell ist ein kleiner konvolutiver Autoencoder, der lernt, wie ein normales Produkt aussieht, und Anomalien durch Rekonstruktionsfehler erkennt. Das zweite ist ein ResNet18-Klassifikator, der angepasst wurde, um den Defekt zu bestätigen. Jede Branch exportiert sein Modell in ONNX, evaluiert das exportierte Artefakt gegen verbleibende Daten und durchläuft eine Qualitätsprüfung. Nach der Prüfung wird das Modell mit SageMaker Neo für den konfigurierten Edge-Zielbereich kompiliert und erst dann im SageMaker Model Registry registriert. Dadurch hat jedes genehmigte Paket ein kompiliertes Artefakt, das für den Einsatz auf Geräten geeignet ist. Die Pakete enthalten die Kamerennummer als Metadaten, und die Wärme-Start-Fetch-Filter jeder Branch berücksichtigen diese, sodass das Neulernen immer von der eigenen Geschichte dieser Kamera fortgesetzt wird.
Die Orchestrierung bewegt die Flotte in Halbschritten. Die Neulernungsanfragen landen in einer Amazon Simple Queue Service (Amazon SQS) FIFO-Kette, und eine AWS Lambda-Funktion startet eine Step Functions- Ausführung pro Anfrage. Jede Ausführung erhält eine Slot durch ein DynamoDB-Semaphore, bevor sie ihren Prozess beginnt. Dadurch wird eine Welle an Anfragen in einer konstanten Rate abgeführt, anstatt alle gleichzeitig gestartet zu werden. Die Ergebnisse werden über das Amazon Simple Notification Service (Amazon SNS) veröffentlicht, und operative Fehler erreichen denselben Thema durch eine Amazon EventBridge-Regel mit der ursprünglichen Fehlermeldung erhalten.
Die Ausgabe des Systems ist verschlüsselt und wird nach Qualitätskriterien für jedes Kameramodell erstellt. Das Model Registry enthält das portable ONNX, und S3 enthält die von Neo kompilierte Version des Modells, eine auf Geräte optimierte gemeinsame Bibliothek, die vom DLR-Runtime geladen wird anstatt ONNX. Beides ist bereit für jeden Versandmechanismus, den Ihr Unternehmen verwendet.
Voraussetzungen
Um das Beispiel zu verlegen, benötigen Sie Folgendes:
- Ein AWS-Konto mit Berechtigungen zur Erstellung von AWS Identity und Access Management (IAM)-Rollen.
- Ein Amazon Simple Storage Service (Amazon S3)-Bucket.
- Ein Repository des Amazon Elastic Container Registries (Amazon ECR).
- Die SageMaker AI-, AWS Step Functions-, AWS Lambda-, Amazon Simple Queue Service (Amazon SQS)--, Amazon Simple Notification Service (Amazon SNS)--, Amazon EventBridge- und Amazon DynamoDB-Ressourcen in den Stacks.
- Python 3.10, 3.11 oder 3.12, Docker.
- AWS CDK CLI Version 2.1131.0 oder neuer.
Vorherige CLI-Versionen versagen wegen eines Unterschieds im Cloud-Assemblieschemata gegenüber den neuesten Versionen von aws-cdk-lib. Es ist keine Erhöhung der Servicequoten erforderlich. Die Orchestrierungsschicht akzeptiert standardmäßig maximal fünf Pipeline-Exekutionen gleichzeitig, wodurch die konkurrierenden SageMaker-Trainingjobs innerhalb des Standard-Kontoequatsums bleiben.
Wenn Sie eine Region von AWS außerhalb der Standard-Region Ihres CLI ausführen, setzen Sie alle drei Werte AWS_REGION, AWS_DEFAULT_REGION und CDK_DEFAULT_REGION direkt in der Deployskripte, anstatt im Shell-Profil, z. B.: AWS_REGION=us-east-2 AWS_DEFAULT_REGION=us-east-2 CDK_DEFAULT_REGION=us-east-2 cdk deploy --all. Die CDK-KLIC, Boto3 und die AWS Command Line Interface (AWS CLI) lösen die Region aus überschneienden, aber nicht identischen Variablen sets ab, und ein Unterschied führt zu verwirrenden Teildeployments. Das Präfixieren der Befehl steuert alle drei Werte nur für diese Ausführung, sodass Ihre eigene Standard-Region unverändert bleibt.
Definieren des Trainingspfades mit SDK v3
Der Code in diesem Abschnitt stammt aus der CDK-Anwendung im Repository und nicht aus einem eigenständigen Skript. Er wird während des cdk-Deploy-Prozesses ausgeführt, wenn die Stack-Definition des Pipelines erstellt wird. Die Umgebungsanpassung und die Deploy-Befehle erfolgen später, unter „Deploying and running the sample“. Das SDK v3 hat das SageMaker Python SDK in modulare Pakete umgewandelt, und die Imports zeigen die neue Struktur der Bibliothek:
from sagemaker.train import ModelTrainer
from sagemaker.train.configs import InputData, Compute, OutputDataConfig
from sagemaker.core.training.configs import MetricDefinition
from sagemaker.serve.model_builder import ModelBuilder
from sagemaker.mlops.workflow.pipeline import Pipeline
from sagemaker.mlops.workflow.steps import ProcessingStep, TrainingStep
from sagemaker.mlops.workflow.model_step import ModelStep
from sagemaker.mlops.workflow.condition_step import ConditionStep
from sagemaker.core.workflow.conditions import ConditionGreaterThanOrEqualTo
from sagemaker.core.workflow.functions import JsonGetDie Installation von sagemaker>=3.0.0,<4 führt die sagemaker-core, sagemaker-train, sagemaker-serve und sagemaker-mlops als separate Pakete ein. Die Trainingskonfiguration, die in v2 über die Argumente des Estimator-Konstruktors verbreitet war, befindet sich nun in typisierten Config-Objekten, die an ModelTrainer übergeben werden. Dies ist der Trainer der Anomalie-Abfolge, wortwörtlich aus dem Beispiel:
anomalib_trainer = ModelTrainer(
training_image=custom_training_image_uri,
compute=Compute(
instance_type=training_instance_type.to_string(),
instance_count=1,
),
base_job_name="cv-pipeline-anomalib-train",
sagemaker_session=pipeline_session,
role=role_arn,
hyperparameters={
"program": "train_anomalib.py",
"model_name": "autoencoder",
"image_size": "256",
"num_epochs": "3",
"batch_size": "16",
"learning_rate": "0.001",
},
input_data_config=anomalib_input_data,
output_data_config=OutputDataConfig(
s3_output_path=run_prefix("anomalib-training")
),
).with_metric_definitions(
[
MetricDefinition(
name="image_auroc",
regex=r"validation:image_auroc=([0-9]*\.?[0-9]+)",
),
]
)anomalib_input_data verbindet vier Kanäle (train, validation, test, pretrained_model) mit den Eigenschaften des Upstream-Schritts, und run_prefix definiert jeden S3-Pfad im Zusammenhang mit dem Pipeline-Execution-ID, sodass konkurrierende Betriebsvorgänge nie aufeinander treffen. Beides befindet sich im Repository.
Zwei v3-Verhalten sind relevant, wenn der Pipeline innerhalb einer CDK-Anwendung existiert, und keines davon wird im Changelog als störende Änderung angegeben. Erstens validiert das SDK v3 die Ausführungsrolle des Pipelines gegenüber dem Live-IAM während der Erstellung der Pipeline-Definition. Diese Validierung erfolgt während der Synthesezeit, nicht während der Ausführungszeit. Eine CDK-Anwendung kann die Rolle und den Pipeline in einer einzigen Deployment nicht erstellen, da die Rolle noch nicht existiert, als das SDK sie validiert. Dies ist getrennt von cdk-bootstrap, das die Ressourcen des CDK-Toolsets einmal pro Konto und Region bereitstellt und möglicherweise bereits in Ihrem Konto erledigt ist. Die eigene zweiphasige Deployment-Methode des Beispiels wird durch ein Kontextzeichen gesteuert, das denselben Namen trägt. Eine erste Durchgabe mit -c bootstrap=true erstellt die Rolle, den Bucket und das ECR-Repository, und die zweite Durchgabe synthetisiert den Pipeline gegenüber der nun existierenden Rolle. Der Amazon Resource Name (ARN), der in der Pipeline-Definition eingebettet ist, muss ebenfalls eine konkrete Zeichenfolge sein, nicht ein ungelöster CDK-Token.
Zweitens simuliert der v3-Rolvalider die ECR-Pull-Rechte ohne einen Ressourcen-ARN, sodass eine Ausführungsrolle, die auf ein einzelnes ECR-Repository beschränkt ist, die Validierung scheitert, obwohl sie im Laufzeitmodus funktionieren würde. Aus diesem Grund trägt die Rolle des Beispiels eine breitere ECR-Grundlage.
Zum Schluss: Ein V3-Verhalten, das das Beispiel verwendet: Die Pipeline wird mit PipelineSession(default_bucket=your_bucket) aufgebaut, um die von der SDK verwalteten Uploads, wie beispielsweise Schritt-Code, in den eigenen Bucket der Pipeline zu legen. Dadurch befindet sich jeder Artifact an einem Ort und die Berechtigungen des Ausführungs-Roles umfassen einen einzigen Bucket. (Es funktioniert auch, wenn dem Role Zugriff auf den Standard-Bucket der SDK gewährt wird. Diese Methode ist ordentlicher.)
Qualitätsprüfungen, die dem Verhalten der Defektdaten entsprechen
Jeder trainierte Modell wird vor der Registrierung bewertet, und die Bewertung erfolgt gegenüber dem exportierten ONNX-Artefakt, nicht gegenüber dem in-Einrichtung befindlichen PyTorch-Modell. Diese Unterscheidung ist wichtig: Das Artefakt, das Sie verwenden, ist auch das Artefakt, das Sie versenden. Daher kann ein Exportproblem niemals ein kaputtes Modell durch eine scheinbar gesunde Trainingsrunde hindurchlassen.
Die Anomalie-Branche-Gates auf AUROC betragen mindestens 0,8. Die Klassifizierungs-Branche-Gates erfolgen gleichzeitig bei zwei Metriken, und die Auswahl der Metriken wird durch die charakteristische Eigenschaft der Defektdaten bestimmt: eine hohe Klassenungleichheit. In diesem Beispiel sind etwa 90 Prozent der Bilder gut – was für eine Produktionslinie realistisch ist. Gegen diese Verteilung ist die einfache Genauigkeit bedeutungslos, denn ein Modell, das für jedes Bild „gut“ vorhersagt, erzielt einen Wert von etwa 0,9, während es keine Defekte erkennt. Gerechte Genauigkeit – das Mittelwert der Klassen-Recall-Werte – korrigiert dies, aber es hat seine eigene Schwachstelle. Ein Modell mit perfekter Recall auf guten Bereichen und nur 20 Prozent Recall auf Defekten erzielt immer noch (1,0 + 0,2) / 2 = 0,6. Somit erfordert die Prüfung eine gerechte Genauigkeit von mindestens 0,6 und eine Recall-Wert für Defekte von mindestens 0,5 zusammen.
step_check_classifier = ConditionStep(
name="CheckClassifierQuality",
conditions=[
ConditionGreaterThanOrEqualTo(
left=JsonGet(
step_name=step_eval_classifier.name,
property_file="evaluation",
json_path="balanced_accuracy",
),
right=min_accuracy,
),
ConditionGreaterThanOrEqualTo(
left=JsonGet(
step_name=step_eval_classifier.name,
property_file="evaluation",
json_path="defect_recall",
),
right=min_defect_recall,
),
],
if_steps=[step_compile_classifier, step_register_classifier],
else_steps=[step_fail_classifier],
depends_on=[step_eval_classifier],
)Ein ConditionStep verbindet seine Bedingungen miteinander, sodass beide erfüllt sein müssen. Die Schwellenwerte sind Pipeline-Parameter, die bei jeder Ausführung anpassbar sind, ohne Neudefinition. Wenn ein Gate fehlt, markiert ein FailStep die fehlgeschlagene Ausführung und das Modell des jeweiligen Zweigstrecken ist nie im Register gespeichert (die beiden Zweigstrecken funktionieren unabhängig voneinander, sodass das Modell des anderen Zweigstrecken noch im Register gespeichert sein kann). Die Flotte versorgt weiterhin die vorher genehmigte Modellversion für diese Kamera.
Der Trainingscode löst das gleiche Ungleichgewicht auf der anderen Seite aus. Der Klassifizierer ist ein feinjustierter resnet18 mit ImageNet-Werten und einer zweigeschlechtigen Kopfstruktur. Bei Datenmengen pro Kamera verhindert das Feinjustieren der vortrainierten Gewichte, dass das Modell auf die majoritäre Klasse zusammenfällt. Der Trainingscode balanciert die Trainingsbatches mit einem WeightedRandomSampler unter Verwendung der umgekehrten Klassenfrequenz, während der Verlust ungewichtet bleibt. Die Kombination von einem gewichteten Verlust und gewichtigem Sampling führt zu einer übermäßigen Abweichung in Richtung der minoritären Klasse.
Kompilieren für die Grenze mit SageMaker Neo, innerhalb des Pipelines
Beachten Sie den if_steps-Feldwert im vorherigen Code: Nach dem Überschreiten des Tores läuft zunächst die Kompilierung ab und die Registrierung hängt davon ab. Beide Trainingsskripte exportieren ONNX mit dynamischen Batch-Axissen. Die Qualitätsgate bewerten diese exportierten Ergebnisse unter ONNX Runtime, anschließend übermittelt ein CompileAnomalibNeo oder CompileClassifierNeo-Schritt das gateierte Ergebnis an SageMaker Neo. Die Reihenfolge ist: Gate, dann Kompilierung, dann Registrierung. Ein Modell wird nur zu einem Approved-Paket, wenn es auch für das Edge-Ziel des Flotts kompiliert werden kann; daher wird das Register nie ein Modell anzeigen, das die Geräte nicht ausführen können.
Die Komprimierungsstufe umfasst drei problematische Aspekte. Neo erfordert, dass die Eingabetarball nur die Modelldatei enthält, aber während des Trainingsvorgangs wird ein model.tar.gz mit dem Checkpoint und den Metriken zusammen mit dem ONNX-Modell ausgegeben. Zuerst wird eine Tarball, die ausschließlich ONNX enthält, neu komprimiert. Neo erfordert außerdem konkrete Eingabshauptformen, während die Exports einen dynamischen Batch-Axis angeben; daher ist der Batchgröße 1 in der Komprimierungsanfrage festgelegt. Da die Pipeline-Stufen wiederholt versuchen können, entsteht der Name des Komprimierungsjobs deterministisch aus dem Ausführungs-ID, sodass eine Wiederholung des Polling-Vorgangs mit dem bereits gestarteten Job stattfindet und nicht zu einem unbekannten Job wird.
Das Ziel ist ein Pipeline-Parameter: NeoTargetDevice wählt einen benannten Gerät, wie jetson_xavier oder rasp4b, und seine Standardkonfiguration basiert auf der NeoTargetOs/NeoTargetArch-Plattform, LINUX/X86_64. Das kompilierte Paket enthält den optimierten compiled.so sowie die DLR-Runtime, um es zu nutzen. Die Standardausgabe funktioniert auf jedem x86_64 Linux-Host, sodass Sie sie vor der Verwendung für spezifische Geräte validieren können. Die Kompilation selbst ist kostenlos. Sie zahlen für die Verarbeitungsinstanz und den S3-Speicher der Ausgaben. Für die Kompilation eines bereits registrierten Modells für weitere Gerätetypen, ohne Neuerlernen, enthält das Repository ein ad-hoc Skript, das denselben Prozess gegenüber dem Model-Registry ausführt.
Modellregistern der Per-Kamera-Modelle
Jede Branch registriert sich in einer eigenen Modellpaketgruppe, und jedes Paket enthält die Kamera-ID sowie seine Bewertungsmetriken. Aus dem Beispiel werden die Metriken weggelassen:
classifier_model_builder = ModelBuilder(
s3_model_data_url=classifier_model_data,
image_uri=custom_training_image_uri,
sagemaker_session=pipeline_session,
role_arn=role_arn,
)
step_register_classifier = ModelStep(
name="RegisterClassifierModel",
depends_on=[step_compile_classifier],
step_args=classifier_model_builder.register(
model_package_group_name="sm1k-classifier-model-group",
approval_status="Approved",
model_metrics=classifier_metrics,
customer_metadata_properties={"CameraId": camera_id},
),
)Die Kamera-Identität in customer_metadata_properties ist es, die zwei gemeinsame Paketgruppen in einen Flottenkatalog zu verwandeln. Die Pakete aller Kameras befinden sich in denselben Gruppen, und das historische Verhalten jeder einzelnen Kamera wird durch Filterung der Metadaten wiederhergestellt. Jede Abteilung hat einen Fetch-Schritt, der die genehmigten Pakete neuesten zuerst durchgeht, bis das neueste Modell der angeforderten Kamera gefunden wird, da ListModelPackages nicht auf Serverseite auf Kundmetadaten filtern kann. Bei der ersten Ausführung der Kamera findet der Fetch nichts, und die Trainierung verlässt sich auf die kalte-Start-Initialisierung (ImageNet-Werte für den Klassifikator, zufällige Initialisierung für den Autoencoder). Jede spätere Ausführung beginnt mit dem eigenen vorherigen Modell der Kamera, was eine häufige, kostengünstige und kontinuierliche Neutraining-Fähigkeit im gesamten Flottenumfang ermöglicht.
Beachten Sie, welche Einträge in diesen Registry-Dateien vorhanden sind und welche nicht: Sie katalogisieren versionierte, qualitätskontrollierte Artefakte, doch der Containerreferenz ist die Trainingsbilddatei, die keine Inferenzendeckten dient. Sie existieren für einen Flottenworkflow, bei dem ein Abwärtssystem die Artefakte abruft und sie an Geräte sendet, nicht für CreateEndpoint.
Organisieren von Trainingsanfragen für Flotten
Jeder AWS-Konto hat Servicequoten für gleichzeitige SageMaker-Training-Jobs, und jede Pipeline- Ausführung startet mehrere Jobs. Deshalb muss das wiederholte Training im Team geplant werden. Es muss verhindert werden, dass eine Auslastung von 500 Anfragen in 500 gleichzeitige Pipeline-Ausführungen wird. Das Beispiel verwendet ein Semaphore, einen Zähler für verfügbare Plätze, der wie ein Parkplatz mit fünf Plätzen funktioniert. Bevor die State-Machine von Step Functions einen Pipeline startet, nimmt sie einen Slot, indem sie den Counter in DynamoDB atomar erhöht, unter der Bedingung, dass die Erhöhung unterbrochen wird, sobald die Grenze erreicht ist:
acquire_semaphore = tasks.DynamoUpdateItem(
self, "AcquireSemaphore",
table=semaphore_table,
key={"LockName": tasks.DynamoAttributeValue.from_string("pipeline-concurrency")},
update_expression="SET ActiveCount = if_not_exists(ActiveCount, :zero) + :one",
condition_expression="attribute_not_exists(ActiveCount) OR ActiveCount < :limit",
)Wenn alle Slots belegt sind, wartet die Ausführung und versucht es erneut. Wenn sein Pipeline abgeschlossen ist, reduziert es den Zähler, um das Slot freizugeben. Ein Detail ist wertvoll für Ihre eigenen Designs: Die Bedingungsausdrücke von DynamoDB setzen die Grenze in einer einzigen atomaren Operation fest, anstatt dass die State-Machine den Zähler liest und entscheidet – was einen Wettlauf zwischen dem Lesen und dem Schreiben lässt. Das Repository implementiert den Rest der Betriebs-Hardening-Maßnahmen, einschließlich der Freischaltung von Slots auf jeder Fehlerstrecke und der Weitergabe fehlgeschlagener Ausführungen an Amazon SNS über Amazon EventBridge. Das README beschreibt die Bestimmung der Wartezeiten.
Der Wert von fünf ist ein Stack-Parameter, der niedrig eingestellt werden muss, damit das Sample in jedem Standard-Konto ausgeführt werden kann, ohne dass eine Erhöhung des Quotenlimits erforderlich ist. Anpassen Sie ihn entsprechend den Quoten für das Trainingstraining Ihres Kontos. Über die Quoten eines einzelnen Kontos hinaus ist die Skalierung des Flottentrainings ein eigenes Thema. Die Standard-Methoden sind das Erhöhen der Dienstquoten, die Verteilung des Trainings auf verschiedene Instanztypen oder Regionen sowie die Verteilung der Flotte auf mehrere Konten. Sie können auch den Überbau in SQS speichern und Arbeit nur dann übernehmen, wenn die Kapazität frei wird. Diese Entscheidungen hängen von der Größe und Struktur Ihres Flotts ab. Das Beispiel gibt Ihnen das funktionierende Skelett, auf das Sie sich erweitern können.
Aufsetzen und Betrieb des Beispiels
Die Beschreibung im README des Repositoriums ist die autoritative Version. Die folgende kurze Anleitung beginnt mit einer sauberen Download- und Installation und stellt die Umgebung vor dem ersten Deployment bereit:
git clone https://github.com/aws-samples/sample-sagemaker-fleet-cv-pipeline
cd sample-sagemaker-fleet-cv-pipeline && python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk bootstrap # once per account/region
cdk deploy SageMakerCVPipelineStack -c bootstrap=true # roles, bucket, ECR
cdk deploy --all # pipeline + orchestration
./scripts/push_ecr_image.sh # build and push training imageStandardmäßig erzeugt der Pipeline synthetische Produktionslinienbilder, sodass Sie das gesamte System end-to-end ohne Datensatz und ohne Datenfreigaben validieren können. Eine vollständige Ausführung führt alle 13 Schritte durch, einschließlich der Neo-Kompilierungen, in etwa 15 Minuten und kostet rund $0,07 für eine ml.m5.xlarge-Kapazität (US East (Ohio) Region (us-east-2), Juli 2026, auf Anfrage). Die Orchestrierungsressourcen kosten zusammen weniger als $0,10 pro Monat bei einer Sample-Größe.
Um den Pipeline-Prozess auf echten Bildern durchzuführen, enthält das Repository einen Downloader für den BCCD-Datensatz. Der Datensatz ist eine Sammlung von 364 annotierten Blutmikroskopbildern, die ursprünglich auf GitHub frei zugänglich waren und unter einer MIT-Lizenz in Pascal VOC-Format geordnet wurden. Derselbe Datensatz wird auch von Roboflow als öffentliches Eigentum verbreitet. Der Skript führt die Präsenz der Thrombozellen in die Defektklasse ein, teilt die Bilder optional nach Kameraen auf, um eine Flotte zu simulieren, und lädt die Trainings-Tarballen in den Pipeline-Bucket hoch. Das begleitende Notebook führt den gesamten Pipeline-Prozess auf echten Daten durch und führt zusätzlich die ONNX-Inferenz für ein normales und ein anomales Beispiel aus. Die Betrachtung der Thrombozellen als Defekte dient nur als exemplarische Darstellung einer Herstellungsdefektverteilung und ist keine klinische Aussage.
Reinigung
Modell-Pakete werden während des Pipeline-Runtimes erstellt, daher kann AWS CloudFormation sie nicht löschen. Entfernen Sie sie zunächst mit der AWS CLI, dann zerstören Sie die Stacks mit cdk destroy --all -c bootstrap=true --force. Die README listet die genauen Befehle auf.
Schlussfolgerung
In diesem Artikel habe ich eine funktionierende SageMaker SDK v3-Referenzarchitektur für das Flottenscale-Computer-Vision-Lebenszyklus gezeigt. Die Architektur umfasst einen doppelten Trainingspfad, bei dem jeder Modell erheblich überprüft wird, bevor er als Export auf ONNX-Format erstellt und mit SageMaker Neo kompiliert wird, und erst dann registriert wird. Das Model-Registry-System verwendet Kamera-Metadaten, um gemeinsame Paketgruppen in eine für jede Kamera verfügbare warmstartbare Historie zu machen, und ein Step-Functions-Orchestrierungsschicht steuert das Training der Flotte innerhalb der Quoten des Accounts. Für Teams, deren Anforderungen durch verwaltete Optionen wie Amazon Lookout for Vision erfüllt werden, ist dies der einfachere Weg. Dieses Muster adressiert die Einschränkung auf pro-Kamera-Ebene und auf Flotten-Ebene, die verwaltete Optionen nicht abdecken. Die Designregeln überschreiten das Computervision: Es geht um eine Balance zwischen Genauigkeit und Recall für kleine Klassen, anstatt nur Genauigkeit; das Produkt muss evaluiert und kompiliert werden, und operative Fehler sollten benachrichtigt werden, anstatt still zu enden.
Das Beispiel wird innerhalb weniger Minuten ausgeführt, und eine vollständige Validierungsrunde kostet etwa sieben Cent Rechenleistung. Ein kostengünstiger nächster Schritt ist es, das Repository zu klonen und es auszuführen. Danach muss der BCCD-Downloader auf einen echten Käfig gerichtet werden, NeoTargetDevice für das Hardware festlegen oder die Orchestrierungsgrenzen an das Flottenkonzept anpassen. Für die Migration des SDK v3 selbst sind die SageMaker Python SDK-Dokumentation sowie die zweiteilige Serie, in der die neue SDK veröffentlicht wird, die Referenzen, die ich stets offen hielten.
Wenn Sie Unterstützung benötigen, um dieses Muster an Ihre Produktionsumgebung anzupassen, wenden Sie sich an das Team Ihres AWS-Kontos.