플릿 전체 컴퓨터 비전 모델 라이프사이클 관리는 품질 검사 개념 증명이 성공하는 순간 나타나는 문제입니다. 카메라 한 대와 모델 하나로는 잘 작동합니다. 그런데 공장이 같은 결과를 40개 라인, 각 라인에 여러 대의 카메라에 적용해 달라고 요청하면, 모든 카메라는 세상을 각기 다르게 봅니다. 각 카메라는 서로 다른 각도, 동일한 스테인리스 표면에서의 서로 다른 반사광, 그리고 어느 베이 도어가 열려 있는지에 따른 서로 다른 주변광을 가집니다. 우리가 작업한 프로덕션 배포에서는 풀링된 영상으로 학습된 단일 모델이 개별 카메라 대비 충분히 성능이 낮아서 결국 각 카메라가 자체 파인튜닝된 모델을 갖게 되었습니다. 이제 진짜 문제는 하나의 모델을 잘 학습시키는 것이 아닙니다. 사람이 각 단계마다 개입하지 않고 수천 개의 모델을 학습, 평가, 버전 관리, 배포하는 것입니다.
이 게시물은 2023년 시리즈에서 소개된 패턴을 업데이트합니다 엣지에서 시각 품질 검사를 위한 엔드투엔드 MLOps 파이프라인 구축 현재 Amazon SageMaker Python SDK v3용으로. 이 글은 지원이 중단된 Amazon SageMaker Edge Manager를 엣지 최적화용 Amazon SageMaker Neo로 대체합니다. 저는 카메라별로 이상 탐지기와 결함 분류기를 학습시키는 이중 분기 Amazon SageMaker Pipeline, 성능이 낮은 모델을 차단하는 품질 게이트, 등록된 모든 모델이 디바이스 최적화 아티팩트와 함께 출고되도록 보장하는 파이프라인 내 SageMaker Neo 컴파일 단계, 그리고 플릿 학습의 속도를 조절하는 AWS Step Functions 오케스트레이션 계층을 살펴봅니다. 모든 것을 AWS Cloud Development Kit(AWS CDK)으로 배포하며, 합성 데이터에 대한 전체 파이프라인 실행은 약 $0.07의 컴퓨팅 비용이 듭니다.
전체 샘플은 다음에서 이용할 수 있습니다 aws-samples GitHub 저장소.
솔루션 개요
다음 다이어그램은 샘플의 플릿 전체 모델 라이프사이클을 보여줍니다. 오케스트레이션 계층은 재학습 요청을 큐에 넣고 동시 작업 수를 제한합니다. 카메라별 학습 파이프라인은 데이터를 준비하고, 이상 탐지기와 분류기를 학습 및 평가하며, 엣지 디바이스용 버전 관리된 모델 아티팩트를 생성합니다.
그림 1: 솔루션 아키텍처
학습 측면은 카메라로 파라미터화된 단일 SageMaker Pipeline으로, 실행당 13개 단계를 수행합니다. 세 개의 진입 단계가 병렬로 실행됩니다: Preprocess, Fetch Latest Anomaly, Fetch Latest Classifier. 파이프라인은 해당 카메라의 이미지를 전처리하고 각 분기에 대해 해당 카메라의 가장 최근 승인된 모델을 가져온 다음 두 개의 모델을 학습시킵니다. 첫 번째는 정상 제품의 모습을 학습하고 재구성 오류로 이상을 표시하는 작은 합성곱 오토인코더입니다. 두 번째는 결함을 확인하도록 파인튜닝된 ResNet18 분류기입니다. 각 분기는 모델을 ONNX로 내보내고, 내보낸 아티팩트를 홀드아웃 데이터로 평가하며, 품질 게이트를 통과합니다. 게이트를 통과하면 모델은 구성된 엣지 대상에 대해 SageMaker Neo로 컴파일되고, 그 후에야 SageMaker Model Registry에 등록됩니다. 그 결과 모든 승인된 패키지는 디바이스 준비가 완료된 컴파일 아티팩트를 갖게 됩니다. 패키지는 카메라 ID를 메타데이터로 포함하며, 각 분기의 웜스타트 가져오기가 이를 기준으로 필터링하므로 재학습은 항상 해당 카메라 자신의 이력에서 재개됩니다.
오케스트레이션 측면은 플릿의 속도를 조절합니다. 재학습 요청은 Amazon Simple Queue Service(Amazon SQS) FIFO 큐에 도착하고, AWS Lambda 함수가 요청별로 Step Functions 실행을 시작합니다. 각 실행은 파이프라인을 시작하기 전에 DynamoDB 세마포어를 통해 슬롯을 획득하므로, 요청이 폭증해도 모두 동시에 시작되는 대신 꾸준한 속도로 처리됩니다. 완료는 Amazon Simple Notification Service(Amazon SNS)로 게시되고, 운영상의 실패는 원래 오류가 보존된 채 Amazon EventBridge 규칙을 통해 동일한 토픽에 전달됩니다.
시스템의 출력은 버전 관리되고 품질 게이트를 통과한 카메라별 모델 아티팩트입니다. Model Registry는 이식 가능한 ONNX를 보관하고, S3는 해당 모델의 Neo 컴파일 빌드를 보관하는데, 이는 ONNX가 아니라 DLR 런타임이 로드하는 디바이스 최적화 공유 라이브러리입니다. 둘 모두 공장에서 사용하는 어떤 전달 메커니즘에도 바로 사용할 수 있습니다.
사전 조건
샘플을 배포하려면 다음이 필요합니다:
- AWS Identity and Access Management(IAM) 역할을 생성할 수 있는 권한이 있는 AWS 계정.
- Amazon Simple Storage Service(Amazon S3) 버킷.
- Amazon Elastic Container Registry(Amazon ECR) 리포지토리.
- 스택에 포함된 SageMaker AI, AWS Step Functions, AWS Lambda, Amazon Simple Queue Service(Amazon SQS), Amazon Simple Notification Service(Amazon SNS), Amazon EventBridge 및 Amazon DynamoDB 리소스.
- Python 3.10, 3.11 또는 3.12, Docker.
- AWS CDK CLI 버전 2.1131.0 이상.
이전 CLI 버전은 최신 버전의 aws-cdk-lib과(와) 클라우드 어셈블리 스키마 불일치로 실패합니다. 서비스 할당량 증가는 필요하지 않습니다. 오케스트레이션 계층은 기본적으로 한 번에 최대 5개의 파이프라인 실행을 허용하여, 동시 SageMaker 학습 작업이 표준 계정 할당량 내에 머물도록 합니다.
CLI 기본 리전이 아닌 다른 AWS 리전에 배포하는 경우, 다음 세 가지를 모두 설정하세요. AWS_REGION, AWS_DEFAULT_REGION, 그리고 CDK_DEFAULT_REGION 배포 명령 자체에, 셸 프로필이 아닌 곳에 설정하세요. 예를 들어, AWS_REGION=us-east-2 AWS_DEFAULT_REGION=us-east-2 CDK_DEFAULT_REGION=us-east-2 cdk deploy --all. CDK CLI, Boto3, AWS Command Line Interface(AWS CLI)는 겹치기는 하지만 동일하지 않은 변수 집합에서 리전을 확인하며, 불일치가 발생하면 혼란스러운 부분 배포가 생깁니다. 명령 앞에 접두사를 붙이면 해당 호출에 한해 세 도구 모두에 적용되므로, 사용자 자신의 기본 리전은 변경되지 않습니다.
SDK v3로 학습 파이프라인 정의하기
이 섹션의 코드는 독립 실행형 스크립트가 아니라 리포지토리의 CDK 애플리케이션에서 발췌한 것이며, 스택이 파이프라인 정의를 합성할 때 cdk deploy 중에 실행됩니다. 환경 설정 및 배포 명령은 뒤의 Deploying and running the sample 섹션에서 다룹니다. SDK v3는 SageMaker Python SDK를 모듈식 패키지로 재편했으며, 임포트 구문에서 라이브러리의 새로운 구조를 확인할 수 있습니다:
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 JsonGet설치 sagemaker>=3.0.0,<4 끌어들인다 sagemaker-core, sagemaker-train, sagemaker-serve, 그리고 sagemaker-mlops 별도의 패키지로. v2가 여러 곳에 분산시켰던 훈련 설정은 Estimator 생성자 인수는 이제 다음에 전달되는 타입이 지정된 구성 객체에 들어갑니다 ModelTrainer다음은 샘플에서 그대로 가져온 이상 탐지(anomaly) 브랜치의 트레이너입니다:
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 4개 채널을 연결하며(train, validation, test, pretrained_model) 상위 단계 속성으로부터 가져오며, run_prefix 모든 S3 경로를 파이프라인 실행 ID로 범위를 한정하여 동시에 실행되는 여러 플릿 실행이 서로 충돌하지 않도록 합니다. 둘 다 리포지토리에 포함되어 있습니다.
파이프라인이 CDK 애플리케이션 내부에 존재할 때 중요한 v3 동작이 두 가지 있으며, 어느 것도 변경 로그에서 주요 변경(breaking change)으로 표시되지 않았습니다. 첫째, SDK v3는 파이프라인 정의를 빌드하는 동안 파이프라인의 실행 역할을 실제 IAM을 대상으로 검증합니다. 이 검증은 실행 시점이 아니라 합성(synthesis) 시점에 발생합니다. CDK 앱은 역할과 파이프라인을 하나의 배포에서 생성할 수 없는데, SDK가 역할을 검증할 때 해당 역할이 아직 존재하지 않기 때문입니다. 이는 계정과 리전당 한 번 CDK 툴킷 리소스를 프로비저닝하며 이미 귀하의 계정에서 완료되었을 수 있는 cdk bootstrap과는 별개입니다. 샘플 자체의 2단계 배포는 우연히 그 이름과 동일한 컨텍스트 플래그에 의해 구동됩니다. 첫 번째 단계를 -c bootstrap=true 실행하면 역할, 버킷, ECR 리포지토리가 생성되고, 두 번째 단계에서는 이제 존재하는 역할을 대상으로 파이프라인을 합성합니다. 파이프라인 정의에 포함되는 역할 Amazon Resource Name (ARN)도 구체적인 문자열이어야 하며, 해석되지 않은 CDK 토큰이어서는 안 됩니다.
둘째, v3 역할 검증기는 리소스 ARN 없이 ECR 풀 권한을 시뮬레이션하므로, 단일 ECR 리포지토리로 범위가 한정된 실행 역할은 런타임에는 정상 작동하더라도 검증에 실패합니다. 이러한 이유로 샘플의 역할에는 더 넓은 범위의 ECR 권한이 부여되어 있습니다.
마지막으로, 샘플이 사용하는 v3 습관이 하나 있습니다. 파이프라인을 다음과 같이 생성하면 PipelineSession(default_bucket=your_bucket) 단계 코드와 같은 SDK가 관리하는 업로드가 파이프라인 자체의 버킷으로 라우팅되어 모든 아티팩트가 한 곳에 모이고 실행 역할의 권한이 단일 버킷을 커버하게 됩니다. (역할에 SDK의 기본 버킷 접근 권한을 부여하는 방법도 동작하지만, 이 방식이 더 깔끔합니다.)
결함 데이터의 특성에 맞춘 품질 게이트
훈련된 모든 모델은 등록 전에 평가되며, 평가는 메모리 내 PyTorch 모델이 아니라 내보낸 ONNX 아티팩트를 대상으로 수행됩니다. 이 구분이 중요합니다. 게이트를 통과하는 아티팩트가 실제 출시되는 아티팩트이므로, 내보내기 문제가 있어도 겉보기에 건강해 보이는 훈련 실행을 통해 깨진 모델이 통과할 수 없습니다.
이상 탐지(anomaly) 브랜치는 AUROC 0.8 이상을 게이트 조건으로 합니다. 분류기(classifier) 브랜치는 두 지표를 동시에 게이트 조건으로 하며, 지표의 선택은 결함 데이터의 본질적 특성인 심한 클래스 불균형에 의해 결정됩니다. 이 샘플에서는 대략 90퍼센트의 이미지가 양품인데, 이는 생산 라인에서 현실적인 수치입니다. 이러한 분포에서는 단순 정확도(accuracy)는 무의미합니다. 모든 이미지를 “양품”으로 예측하는 모델이 결함을 하나도 잡지 못하면서도 약 0.9의 점수를 얻기 때문입니다. 클래스별 재현율(recall)의 평균인 균형 정확도(balanced accuracy)는 이를 보정하지만, 그 자체의 맹점이 있습니다. 양품 부품에 대한 재현율이 완벽하고 결함에 대한 재현율이 20퍼센트에 불과한 모델도 여전히 (1.0 + 0.2) / 2 = 0.6의 점수를 얻습니다. 따라서 게이트는 균형 정확도 0.6 이상과 결함 재현율 0.5 이상을 함께 요구합니다:
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],
)은(는) ConditionStep 조건들을 AND로 결합하므로 두 조건 모두 통과해야 합니다. 임계값은 파이프라인 파라미터이며, 재배포 없이 실행별로 조정할 수 있습니다. 게이트가 실패하면 FailStep 이(가) 해당 실행을 실패로 표시하고 그 브랜치의 모델은 레지스트리에 도달하지 못합니다 (두 브랜치는 독립적으로 게이트를 수행하므로 다른 브랜치의 모델은 여전히 등록될 수 있습니다). 플릿은 해당 카메라에 대해 이전에 승인된 모델을 계속 서빙합니다.
훈련 코드는 동일한 불균형을 다른 쪽에서도 다룹니다. 분류기는 ImageNet 가중치와 2클래스 헤드를 갖춘 파인튜닝된 resnet18 입니다. 카메라별 데이터셋 크기에서는 사전 훈련된 가중치를 파인튜닝하는 것이 모델이 다수 클래스에 붕괴되는 것을 방지하는 핵심입니다. 훈련 코드는 역 클래스 빈도를 사용하는 WeightedRandomSampler 으로 훈련 배치의 균형을 맞추는 반면, 손실(loss)은 가중치를 두지 않습니다. 가중 손실과 가중 샘플링을 결합하면 소수 클래스 쪽으로 과도하게 보정됩니다.
파이프라인 내부에서 SageMaker Neo로 엣지용 컴파일하기
앞선 코드에서 게이트의 if_steps 부분에 주목하십시오. 게이트를 통과하면 컴파일이 먼저 실행되고 등록은 그에 의존합니다. 두 학습 스크립트 모두 동적 배치 축(dynamic batch axes)으로 ONNX를 내보냅니다. 품질 게이트는 ONNX Runtime에서 이렇게 내보낸 아티팩트를 채점하고, 그 다음 CompileAnomalibNeo 또는 CompileClassifierNeo 단계가 게이트를 통과한 아티팩트를 SageMaker Neo로 넘깁니다. 불변식(invariant)은 게이트, 그 다음 컴파일, 그 다음 등록입니다. 모델은 플릿의 엣지 타겟에 대해 컴파일에 성공해야만 Approved 패키지가 되므로, 레지스트리는 기기들이 실행할 수 없는 모델을 절대 광고하지 않습니다.
컴파일 단계는 오류가 발생하기 쉬운 세 가지 세부 사항을 캡슐화합니다. Neo는 입력 tarball에 모델 파일만 포함되기를 요구하지만, 학습 작업은 ONNX 모델과 함께 체크포인트와 메트릭을 model.tar.gz 로 내보냅니다. 이 단계는 먼저 ONNX 전용 tarball로 재패키징합니다. Neo는 또한 구체적인 입력 형상을 요구하는 반면 내보내기는 동적 배치 축을 선언하므로, 컴파일 요청에서 배치 크기 1이 고정됩니다. 그리고 파이프라인 단계는 재시도할 수 있으므로, 컴파일 작업 이름은 실행 ID로부터 결정론적으로 도출되어 재시도 시 새 작업을 만들어 버리는 대신 이미 시작한 작업의 폴링을 재개합니다.
타겟은 파이프라인 파라미터입니다: NeoTargetDevice 은(는) jetson_xavier 또는 rasp4b같은 이름이 지정된 기기를 선택하며, 기본값은 NeoTargetOs/NeoTargetArch 플랫폼, 기본적으로 LINUX/X86_64에 대해 컴파일합니다. 컴파일된 패키지에는 최적화된 compiled.so 과(와) 이를 로드하기 위한 DLR 런타임 이(가) 포함됩니다. 기본 출력은 모든 x86_64 Linux 호스트에서 실행되므로, 기기별 타겟에 커밋하기 전에 검증할 수 있습니다. 컴파일 자체에는 비용이 발생하지 않습니다. 이를 구동하는 처리 인스턴스와 출력물의 S3 스토리지에 대해 지불합니다. 재학습 없이 나중에 이미 등록된 모델을 추가 기기 유형으로 컴파일하기 위해, 저장소에는 Model Registry에 대해 동일한 흐름을 실행하는 ad-hoc 스크립트가 포함되어 있습니다.
Model Registry의 카메라별 모델
각 브랜치는 자체 모델 패키지 그룹에 등록하고, 모든 패키지는 카메라 ID와 평가 메트릭을 담고 있습니다. 메트릭 연결 부분을 생략한 샘플 예시:
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},
),
)에서 카메라 식별성은 두 개의 공유 패키지 그룹을 플릿 카탈로그로 바꾸는 요소입니다. 모든 카메라의 패키지가 동일한 그룹에 존재하며, 카메라별 이력은 메타데이터로 필터링하여 복원할 수 있습니다. 각 브랜치에는 승인된 패키지를 최신순으로 페이징하며 요청한 카메라의 최신 모델을 찾을 때까지 진행하는 fetch 단계가 있는데, 이는 customer_metadata_properties 이(가) 서버 측에서 고객 메타데이터로 필터링할 수 없기 때문입니다. 카메라의 첫 실행 시 fetch는 아무것도 찾지 못하고 학습은 콜드 스타트 초기화(분류기는 ImageNet 가중치, 오토인코더는 무작위 초기화)로 폴백합니다. 이후 모든 실행은 해당 카메라의 이전 모델에서 재개되며, 이것이 플릿 전반에서 빈번하고 저렴한 증분 재학습을 가능하게 하는 핵심입니다. ListModelPackages 이러한 레지스트리 항목이 무엇이고 무엇이 아닌지 주목하십시오. 이 항목들은 버전 관리되고 품질 게이트를 통과한 아티팩트를 카탈로그화하지만, 그 컨테이너 참조는 학습 이미지이며 추론 엔드포인트에는 쓸모가 없습니다. 이들은 하위 시스템이 아티팩트를 가져와 기기로 전송하는 플릿 워크플로우를 위한 것이지,
이러한 레지스트리 항목이 무엇이고 무엇이 아닌지 유의하십시오. 이 항목들은 버전이 관리되고 품질 게이트를 통과한 아티팩트를 목록화하지만, 그 컨테이너 참조는 추론 엔드포인트를 전혀 제공하지 않는 학습 이미지입니다. 이 항목들은 후속 시스템이 아티팩트를 가져와 기기에 배포하는 플릿 워크플로우를 위한 것이지, 다음을 위한 것이 아닙니다. CreateEndpoint.
플릿 학습 요청 오케스트레이션
모든 AWS 계정에는 동시 SageMaker 학습 작업에 대한 서비스 쿼터가 있으며, 여기서 각 파이프라인 실행은 여러 작업을 시작하므로 플릿 재학습에는 속도 조절이 필요합니다. 500개 요청의 버스트가 500개의 동시 파이프라인 실행이 되지 않도록 무언가가 막아야 합니다. 샘플은 세마포어, 즉 다섯 개의 주차 공간이 있는 주차장처럼 작동하는 사용 가능한 슬롯의 카운터를 사용합니다. Step Functions 상태 머신이 파이프라인을 시작하기 전에, DynamoDB의 카운터를 원자적으로 증가시켜 슬롯을 확보하되, 상한에 도달하면 증가를 거부하는 조건을 둡니다:
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",
)모든 슬롯이 차 있으면 실행은 대기 후 재시도합니다. 파이프라인이 끝나면 카운터를 감소시켜 슬롯을 해제합니다. 여러분의 설계에 가져갈 만한 한 가지 세부 사항이 있습니다. DynamoDB 조건식은 단일 원자적 연산으로 상한을 강제하며, 상태 머신이 카운터를 읽고 결정하는 방식(읽기와 쓰기 사이에 경쟁 상태 창이 생김)을 피합니다. 저장소는 모든 실패 경로에서 슬롯을 해제하는 것과 Amazon EventBridge를 통해 실패한 실행을 Amazon SNS로 전달하는 것을 포함한 나머지 운영 강화를 구현합니다. README에서 대기 바운드 크기 조정을 다룹니다.
상한 5는 스택 파라미터로, 쿼터 증가를 요청하지 않고도 어떤 표준 계정에서든 샘플이 배포되고 실행될 수 있도록 낮게 설정되어 있습니다. 계정의 학습 작업 쿼터가 지원하는 값으로 조정하십시오. 단일 계정의 쿼터를 넘어서는 플릿 학습 확장은 별도의 주제입니다. 표준적인 수단은 서비스 쿼터 상향, 인스턴스 유형 또는 리전에 걸친 학습 분산, 여러 계정에 걸친 플릿 분산입니다. 백로그를 SQS에 보관하고 용량이 확보될 때만 작업을 수용할 수도 있습니다. 이러한 선택은 플릿의 규모와 형태에 따라 달라집니다. 샘플은 이를 확장할 수 있는 실동작 스켈레톤을 제공합니다.
샘플 배포 및 실행
저장소 README의 워크스루가 권위 있는 버전입니다. 다음 요약 형식은 깨끗한 체크아웃에서 시작하여 첫 배포 전에 환경을 설정합니다:
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 image기본적으로 파이프라인은 합성 생산 라인 이미지를 생성하므로, 데이터셋이나 데이터 승인 없이도 전체 시스템을 엔드 투 엔드로 검증할 수 있습니다. 전체 실행은 두 번의 Neo 컴파일을 포함한 13단계를 모두 약 15분 만에 수행하며, 비용은 청구 기준으로 약 $0.07이 소요됩니다. ml.m5.xlarge 시간 기준 약 $0.07의 비용이 듭니다(US East (Ohio) Region (us-east-2), 2026년 7월, 온디맨드 기준). 오케스트레이션 리소스는 샘플 규모에서 한 달에 합쳐서 $0.10 이하로 매우 저렴합니다.
실제 이미지로 파이프라인을 시험해 볼 수 있도록, 리포지토리에는 다음을 위한 다운로더가 포함되어 있습니다: BCCD 데이터셋. 이 데이터셋은 GitHub에서 최초로 오픈 소스화되어 MIT 라이선스로 Pascal VOC 형식으로 재구성된, 364개의 주석이 달린 혈액 도말 현미경 이미지 모음입니다. 동일한 데이터셋은 Roboflow 에서 퍼블릭 도메인으로도 배포됩니다. 이 스크립트는 혈소판 존재 여부를 결함 클래스에 매핑하고, 선택적으로 이미지를 카메라별로 분할하여 플릿을 시뮬레이션하며, 학습 타르볼을 파이프라인 버킷에 업로드합니다. 함께 제공되는 노트북은 실제 데이터로 전체 파이프라인을 실행하고 정상 샘플과 이상 샘플에 대해 나란히 ONNX 추론을 수행합니다. 혈소판을 결함으로 취급하는 것은 제조 결함 분포를 나타내기 위한 예시적 대체물일 뿐, 임상적 주장이 아닙니다.
정리
모델 패키지는 파이프라인 런타임에 생성되므로, AWS CloudFormation이 이를 삭제할 수 없습니다. 먼저 AWS CLI로 패키지를 제거한 후, 다음으로 스택을 삭제하십시오: cdk destroy --all -c bootstrap=true --force. 정확한 명령은 README 에 나와 있습니다.
결론
이 게시물에서 저는 플릿 규모 컴퓨터 비전 라이프사이클을 위한, 작동하는 SageMaker SDK v3 참조 아키텍처를 소개했습니다. 이 아키텍처는 모든 모델이 내보낸 ONNX 아티팩트에 대해 품질 게이트를 거치고, SageMaker Neo로 컴파일된 후에만 등록되는 이중 분기 학습 파이프라인을 포함합니다. Model Registry 레이아웃은 카메라 메타데이터를 활용하여 공유 패키지 그룹을 카메라별 웜 스타트 가능한 이력으로 전환하며, Step Functions 오케스트레이션 계층은 계정 할당량 내에서 플릿 학습의 속도를 조절합니다. Amazon Lookout for Vision과 같은 관리형 옵션으로 요구 사항이 충족되는 팀이라면 그것이 더 간단한 경로입니다. 이 패턴은 관리형 옵션이 다루지 않는 카메라별, 플릿 규모 제약을 대상으로 합니다. 설계 규칙은 컴퓨터 비전을 넘어 적용됩니다: 정확도가 아닌 균형 정확도와 소수 클래스 재현율로 게이트를 설정하고, 실제 배포하는 아티팩트를 평가하고 컴파일하며, 운영 장애가 조용히 종료되는 것이 아니라 알림을 보내도록 하십시오.
샘플은 몇 분 만에 배포되며 전체 검증 실행에 약 7센트의 컴퓨팅 비용이 들므로, 저비용의 다음 단계는 리포지토리 를 복제하여 실행해 보는 것입니다. 그 후, BCCD 다운로더가 실제 버킷을 가리키도록 설정하고, 사용자 하드웨어에 맞게 NeoTargetDevice 설정하거나, 오케스트레이션 범위를 플릿에 맞게 조정하십시오. SDK v3 마이그레이션 자체에 대해서는 SageMaker Python SDK 문서 와 새 SDK 발표 2부작 시리즈가 제가 내내 열어두었던 참고 자료입니다.
이 패턴을 프로덕션 환경에 적용하는 데 도움이 필요하시면 AWS 어카운트 팀에 문의하십시오.