إدارة دورة حياة نموذج الرؤية الحاسوبية على مستوى القطيع هو مشكلة تظهر في اللحظة التي ينجح فيها مفهوم التفتيش الجودة. كاميرا واحدة ونموذج واحد يعملان بشكل جيد. ثم يطلب المصنع نفس النتائج على 40 خطًا، كل منها يحتوي على عدة كاميرات، وكل كاميرا ترى العالم بطريقة مختلفة. كل كاميرا لها زاوية مختلفة، وضوء مختلف من نفس السطح الفولاذي، وضوء بيئي مختلف حسب باب الغرفة المفتوح. في عمليات النشر التجارية التي عملنا عليها، كان النموذج الواحد الذي تم تدريبه على مجموعة من الصور يتقاوم بشكل كافٍ مقارنةً بالكاميرات الفردية، بحيث يحصل كل كاميرا على نموذجها الخاص المعدل بدقة. الآن، لم يعد المشكلة الحقيقية تتمثل في تدريب نموذج واحد بشكل جيد، بل في تدريب وتقييم وتحديث وتوزيع آلاف النماذج دون وجود شخص بشرى يتحكم في كل منها.
هذا المنشور يحدّث النمط الذي تم تقديمه في السلسلة لعام 2023 بناء سلسلة عملية MLOps كاملة لفحص الجودة البصرية على الحافة للإصدار الحالي لمنصة Amazon SageMaker SDK Python v3. وهو يستبدل مدير Amazon SageMaker Edge الذي تم إيقافه منذ فترة بـ Amazon SageMaker Neo لتحسين الأداء على الحافة. أعرض سلسلة عملية Amazon SageMaker ذات الفروع المزدوجة التي تدرب فيها جهاز كاميرا واحد على جهاز كاميرا أخرى، مع بوابات جودة تمنع النماذج التي لا تعمل بشكل جيد. خطوة تجميع SageMaker Neo داخل السلسلة تضمن أن كل نموذج مسجل يصدر برمجية مُحسّنة للجهاز، وطبقة تنظيم AWS Step Functions تساعد على تنظيم تدريب القوات. يمكنك نشر كل شيء باستخدام أداة تطوير السحابة AWS (AWS CDK)، وتكلفة تشغيل سلسلة العملية الكاملة على البيانات الاصطناعية حوالي 0.07 دولار في الحساب.
العينة الكاملة متاحة في ملف مستودع GitHub aws-samples.
نظرة عامة على الحل
يُظهر الرسم البياني التالي دورة حياة النموذج على مستوى الأسطول للمثال. تكدس طبقة التنظيم الطلبات لإعادة التدريب وتحد من العمل المتزامن. يتم تحضير البيانات وتدريب وتقييم أداة اكتشاف الأنماط وأداة التصنيف لكل كاميرا، ويتم إنتاج ملفات النموذج المرتبطة بالإصدار للأجهزة الحدية.
الشكل 1: هيكل الحل
الجزء التدريبي هو سيرفر واحد من SageMaker، يتم تخصيصه حسب الكاميرا، ويقوم بتنفيذ 13 خطوة في كل تنفيذ. ثلاث خطوات دخول تتم بشكل متوازي: التحضير المسبق، استرجاع الأخطاء الأحدث، واسترجاع الفئة المُحسِّنة الأحدث. يقوم السيرفر بتحضير الصور الخاصة بالكاميرا والتعرف على النموذج الأحدث الموافق لكل فرع، ثم يقوم بتدريب نموذجين. النموذج الأول هو مخزن صورة تكراري صغير يتعلم كيف يبدو المنتج الطبيعي ويعترف بالأخطاء من خلال خطأ إعادة البناء. الثاني هو مصنف ResNet18 تم تعديله بدقة للتأكد من العيب. كل فرع يقوم بنقل نموذجه إلى ONNX، ويقيّم النموذج المنقول مقابل البيانات المخزنة، ويمر عبر بوابة الجودة. بعد المرور بالبوابة، يتم تجميع النموذج باستخدام SageMaker Neo للهدف المحيط، ثم يسجل فقط في سجل نماذج SageMaker. ونتيجة لذلك، يحتوي كل حزمة مصادق عليها على نموذج مُجمع جاهز للاستخدام على الأجهزة. تحمل الحزم معرف الكاميرا كبيانات تحتوي (metadata)، ويتم استخدام فلاتر استرداد البداية الدافئة لكل فرع عليها، بحيث يبدأ إعادة التدريب دائمًا من تاريخ الكاميرا نفسها.
تقوم عملية التنظيم بتحريك الأسطول على خطوات متوسطة. تُرسل طلبات إعادة التدريب إلى مزود الخدمة البسيط لقوائم Amazon (Amazon SQS) من نوع FIFO، وتبدأ دالة AWS Lambda تنفيذ عمليات Step Functions لكل طلب. يشغل كل تنفيذ مقعدًا من خلال حامل التوقيت في DynamoDB قبل بدء سير العملية، بحيث يتم شحن الطلبات بشكل مستقر بدلاً من إطلاقها جميعًا في نفس الوقت. تُنشر الإكمالات عبر خدمة إشعارات أمازون البسيطة (Amazon SNS)، وتصل الأعطال التشغيلية إلى نفس الموضوع من خلال قاعدة أمازون EventBridge مع الحفاظ على الخطأ الأصلي.
ناتج النظام يتم تحديده حسب الإصدار، ويخضع لرقابة الجودة، ويتضمن الشوائب الخاصة بكل نموذج كاميرا على حدة. يحتوي مجلد التسجيلات النموذجية على ملف ONNX القابل للنقل، بينما يحتوي S3 على النسخة المكتملة من النموذج المصدر المنشأة باستخدام Neo، وهي مكتبة مشتركة مُحسّنة للأجهزة يتم تحميلها من قبل وقت التنفيذ DLR بدلاً من ملف ONNX. كلا النوعين جاهزان لطريقة التسليم التي تستخدمها محطة الإنتاج.
الشروط المسبقة
لتنفيذ العينة، تحتاج إلى ما يلي:
- حساب AWS يمتلك الصلاحيات لإنشاء أدوار إدارة الهوية والوصول في AWS (IAM).
- حاوية خدمة التخزين البسيط لأمازون (Amazon S3).
- مستودع لوحة تخزين الحاويات المرنة لأمازون (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 في الأكواد.
- بايثون 3.10، 3.11، أو 3.12، دابروكس.
- إصدار أداة CLI لـ AWS CDK 2.1131.0 أو أحدث.
فشل الإصدارات السابقة من CLI بسبب عدم تطابق نموذج التجميع الخاص بالسحابة مع الإصدارات الحديثة من aws-cdk-lib. لا حاجة لزيادة حد الميزانية الخاصة بالخدمة. يسمح طبقة التنظيم بحد أقصى خمسة تنفيذات للخطوط في كل مرة بشكل افتراضي، مما يحافظ على وظائف التدريب داخل SageMaker المتزامنة ضمن حد الميزانية القياسية للحساب.
إذا قمت بنشر المشروع في منطقة AWS غير المنطقة الافتراضية لطبقة التحكم (CLI) الخاصة بك، فقم بتعيين الثلاثة من 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. تقوم طبقة التحكم (CLI) لـ CDK، Boto3، وواجهة سطر الأوامر الخاصة بـ AWS (AWS CLI) بتحديد المنطقة من بين مجموعات المتغيرات المتداخلة ولكن غير المتطابقة، ويؤدي الاختلاف إلى نشر جزئي مربك. يضع البادئة على الأمر كل هذه المتغيرات فقط لهذا الاستخدام، لذا تظل المنطقة الافتراضية الخاصة بك دون تغيير.
تحديد خط الطلب التدريبي باستخدام SDK v3
الكود في هذا القسم مأخوذ من تطبيق CDK في المستودع، وليس من برنامج مستقل، ويتم تشغيله أثناء عملية التثبيت cdk، عندما يقوم الـ stack بتوليد تعريف خط الأنابيب. يتم إعداد البيئة والأوامر التثبيت لاحقًا، ضمن خصائص التثبيت وتشغيل العينة. قام SDK v3 بإعادة تنظيم SDK Python لـ SageMaker إلى حزم منطقية، وتُظهر الإدخالات الشكل الجديد للملف.
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. هذه هي تدريب المشغل لفرع الاضطراب، كما هو مكتوب بدقة من العينة:
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 يقوم بربط أربعة قنوات (train, validation, test, pretrained_model) مع خصائص الخطوة العلوية، بينما يُطبق run_prefix كل مسار S3 على معرف تنفيذ خط الحزمة بحيث لا تتعارض عمليات التشغيل المتزامنة. كلا العنصرين موجودان في المستودع.
اثنان من سلوكيات v3 مهمة عندما يعيش الممرر داخل تطبيق CDK، ولا يظهر أي منهما في سجل التغييرات كتغيير قاطع. أولاً، يقوم SDK v3 بتحقق من دور تنفيذ الممرر ضد IAM الحي أثناء بناء تعريف الممرر. يحدث هذا التحقق في وقت التركيب بدلاً من وقت التنفيذ. لا يمكن لتطبيق CDK إنشاء الدور والممرر في نشر واحد، لأن الدور غير موجود بعد عندما يقوم SDK بتحقق منه. هذا منفصل عن cdk bootstrap، الذي يوفر موارد أداة CDK مرة واحدة لكل حساب ومنطقة، وقد يكون قد تم ذلك بالفعل في حسابك. النشر ذو المرحلتين الخاص بالمثال يتم توجيهه بواسطة علامة تبويب السياق التي تشارك ذلك الاسم. المرحلة الأولية مع -c bootstrap=true تخلق الدور والصندوق ومستودع ECR، والمرحلة الثانية تركب الممرر ضد الدور الموجود الآن. يجب أن يكون اسم الموارد Amazon للدور المدمج في تعريف الممرر أيضًا سلسلة نصية ملموسة، وليس رمز CDK غير محلول.
ثانيًا، يقوم مُصمم التحقق من دور v3 بتشبيه صلاحيات سحب ECR دون ARN للموارد، لذلك فإن دور التنفيذ المحدود لمستودع ECR واحد يفشل في التحقق، على الرغم من أنه سيُعمل أثناء التشغيل. ولهذا السبب، يحمل دور العينة منحًا أوسع لـ ECR.
أخيرًا، عادة v3 التي يستخدمها المثال: بناء المسار باستخدام PipelineSession(default_bucket=your_bucket) لإرسال عمليات التحميل التي يديرها SDK إلى حاوية المسار الخاصة به، بحيث يعيش كل المنتج في مكان واحد، وتغطي صلاحيات دور التنفيذ حاوية واحدة. (كذلك، يمكن منح الدور إمكانية الوصول إلى الحاوية الافتراضية لـ SDK. هذه الطريقة أكثر تنظيمًا.)
بوابات الجودة التي تتوافق مع سلوك بيانات العيوب
يتم تقييم كل نموذج مدرب قبل التسجيل، ويتم التقييم استنادًا إلى الملف ONNX المصدري بدلاً من النموذج الخاص ببرنامج PyTorch الموجود في الذاكرة. وهذا الفرق مهم: الملف الذي تُشحنه هو الملف الذي تُرسله، لذا فإن أي مشكلة في التصدير قد لا تسمح بنقل نموذج مكسور خلال عملية التدريب التي تبدو سليمة.
تكون درجات الفرع الغريب على AUROC لا تقل عن 0.8. تكون درجات فرع المفسر على معيارين في نفس الوقت، ويتم اختيار المعايير بناءً على الخاصية المميزة لبيانات العيوب: التمادل الكبير في الفئات. في هذا العينة، حوالي 90 بالمئة من الصور جيدة، وهو أمر واقعي للخط الإنتاجي. بالنسبة لهذا التوزيع، فإن الدقة البسيطة عديمة الفائدة، لأن النموذج الذي يتنبأ بـ"الجودة" لكل صورة يحصل على نتيجة حوالي 0.9 بينما لا يكتشف أي عيوب. الدقة المتوازنة، أي متوسط معدل استرداد كل فئة، تعمل على تصحيح ذلك، لكن لها نقطة ضعف خاصة بها. النموذج الذي يحقق استردادًا مثاليًا في الأجزاء الجيدة و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 يجمع شروطه مع بعض، لذا يجب أن تمر كلها. العتبات هي معلمات خط التصنيع، ويمكن تعديلها أثناء التنفيذ دون الحاجة إلى إعادة توزيعها. إذا فشل البوابة، يُعلق FailStep على فشل التنفيذ، ولا يصل نموذج الفرع الآخر إلى السجل (الفروعتان تعملان بشكل مستقل، لذا قد يظل نموذج الفرع الآخر مُسجّلًا). تستمر الفصيلة في تقديم النموذج الموافق السابق للكاميرا.
كود التدريب يعالج نفس عدم التوازن من الجانب الآخر. الفئة التعليمية هي resnet18 المعدل بدقة مع أوزان ImageNet وقاعدة ذات فئتين. عند أحجام مجموعات البيانات لكل كاميرا، يعمل التعديل الدقيق للأوزان المدربة مسبقًا على منع النموذج من الانهيار نحو الفئة الأكبر عددية. يقوم كود التدريب بتوازن دفعات التدريب باستخدام WeightedRandomSampler باستخدام تكرارات الترتيب المعاكسة، بينما يظل الخسارة غير مُعيّرة. الجمع بين خسارة معيّرة وتجربة عشوائية معيّرة يؤدي إلى تصحيح زائد نحو الفئة الأقل عددية.
تجميع البيانات للحافة باستخدام SageMaker Neo، داخل مسار العملية
لاحظ if_steps في البوابة في الكود السابق: بعد المرور بالبوابة، يتم التجميع أولاً، وتعتمد التسجيل على ذلك. تقوم برامج التدريب بتصدير البيانات إلى صيغة ONNX مع محاور الدفعة الديناميكية. تقيّم بوابات الجودة هذه المنتجات المصدرة تحت تشغيل ONNX، ثم يقوم خطوة CompileAnomalibNeo أو CompileClassifierNeo بتحويل المنتج المُحتفظ به إلى SageMaker Neo. العملية الثابتة هي: البوابة، ثم التجميع، ثم التسجيل. لا يصبح النموذج حزمة معتمدة إلا إذا تم تجميعه أيضًا للهدف الحدودي للسفينة، لذلك لا يتم الإعلان عن النموذج في السجلات الذي لا يمكن للأجهزة تشغيله.
تحتوي خطوة التجميع على ثلاثة عناصر عرضة للخطأ. يتطلب نيو أن يحتوي ملف التحميل tarball على ملف النموذج فقط، لكن مهام التدريب تنتج ملف model.tar.gz الذي يحتوي على نقاط التحقق والمؤشرات جنبًا إلى جنب مع نموذج ONNX. تقوم الخطوة بتجميع ملف tarball يحتوي فقط على ONNX أولاً. يتطلب نيو أيضًا أشكالًا محددة للمدخلات، بينما تعلن المخرجات عن محور الدفعة الديناميكي، لذا يتم تثبيت حجم الدفعة عند 1 في طلب التجميع. وبما أن خطوات المجرى يمكنها إعادة المحاولة، فإن اسم مهمة التجميع ينتج بشكل حتمي من معرف التنفيذ، بحيث تعود عملية المحاولة إلى استطلاع المهمة التي بدأها بالفعل بدلاً من تفريغها.
الهدف هو معلمة خط الأنابيب: NeoTargetDevice يختار جهازًا مسمى مثل jetson_xavier أو rasp4b، ويتم تجميعه بشكل افتراضي للمنصة NeoTargetOs/NeoTargetArch، وذلك بشكل افتراضي على لينكس/X86_64. يحتوي الحزمة المجمعة على الملف compiled.so المُحسّن بالإضافة إلى تشغيل DLR لفتحه. الناتج الافتراضي يعمل على أي جهاز Linux X86_64، لذا يمكنك التحقق منه قبل تحديد أهداف خاصة بالجهاز. التجميع نفسه لا يتطلب رسومًا. أنت تدفع مقابل حالة المعالجة التي يقوم بها والمستودع S3 للبيانات الناتجة. للتجميع لنموذج مسجل مسبقًا لأنواع أجهزة إضافية لاحقًا، دون إعادة التدريب، يحتوي المستودع على سكريبت خاص يعمل بنفس الدورة ضد سجل النماذج.
نماذج كل كاميرا في سجل النماذج
تسجل كل فرع في مجموعة حزم النموذج الخاصة به، وكل حزمة تحمل معرف الكاميرا ومؤشرات تقييمها. من العينة، تم تجاهل توصيل مؤشرات التقييم:
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},
),
)
هوية الكاميرا في customer_metadata_properties هي ما يجعل مجموعتين مشتركتين من الحزم تتحول إلى فلاتة قائمة. توجد الحزم من جميع الكاميرات في نفس المجموعات، ويتم استرجاع التاريخ الخاص بكل كاميرا عن طريق التصفية على البيانات الوصفية. لكل فرع هناك خطوة استرجاع تمر عبر الحزم الموافق عليها من أحدث إلى أقدم حتى تجد النموذج الأحدث للكاميرا المطلوبة، لأن ListModelPackages لا يمكنه التصفية على بيانات العملاء على جانب الخادم. في أول تشغيل للكاميرا، لا يتم العثور على شيء، فيُعود التدريب إلى تهيئة البداية الباردة (أوزان ImageNet للمعالج التصنيفي، تهيئة عشوائية للمنشئ الآلي). في كل تشغيل لاحق، يبدأ التدريب من النموذج السابق الخاص بالكاميرا نفسها، وهذا ما يجعل إعادة التدريب المتكرر والاقتصادي والتدريب التدريجي ممكنًا على مستوى الفلاتة بأكملها.
لاحظ ما هي قوائم السجلات هذه وما هي ليست: فهي تصف العناصر المتغيرة النسخ، والمنتجات التي تحظى بجودة محددة، لكن مرجع الحاوية الخاصة بها هو الصورة التدريبية، التي لا تخدم أي نقاط نهاية استدلالية. توجد هذه القوائم السجلات في عملية التشغيل للأسطول، حيث يستخرج النظام العلوي العناصر ويُرسلها إلى الأجهزة، وليس للاستخدام في CreateEndpoint.
تنظيم طلبات تدريب الأسطول
لكل حساب في AWS حدود خدمة للعمليات التدريبية المتزامنة لـ SageMaker، ويقوم تنفيذ كل خط أنابيب بإطلاق عدة عمليات، لذلك يحتاج إعادة التدريب الجماعي إلى توقيت مناسب. يجب أن يتم ضبط الوضع بحيث لا تتجاوز طلبات الـ 500 طلبًا نقطة تزامن عمليات الخط الأنابيب الـ 500. يستخدم المثال هذا نوعًا من العداد، وهو عداد للأماكن المتاحة التي تعمل كموقف سيارات بخمسة أماكن. قبل أن تبدأ آلة الحالة في خطوات العملية ببدء تدفق، فإنها تأخذ حجزًا عن طريق زيادة عدد ثابت في قاعدة بيانات 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 SNS من خلال Amazon EventBridge. يغطي ملف README تحديد حدود الانتظار.
حد الخمسة هو معامل تراكب، يجب ضبطه منخفضًا حتى يتم تنفيذ العينة و실행ها في أي حساب قياسي دون الحاجة إلى زيادة الحصص. يمكنك تعديله حسب ما يسمح به حصص العمل التدريبي لحسابك. بعد حد حصص حساب واحد، يعتبر توسيع تدريب القوات موضوع منفصل. الأدوات القياسية تشمل رفع حصص الخدمة، توزيع التدريب على أنواع المثيلات أو المناطق، وتوزيع القوات بين عدة حسابات. يمكنك أيضًا الاحتفاظ بالمهام المتراكمة في 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
بشكل افتراضي، يقوم الممر الطبيعي بتوليد صور لخط الإنتاج الاصطناعي، بحيث يمكنك التحقق من النظام بأكمله من البداية إلى النهاية دون الحاجة إلى مجموعة بيانات أو موافقات بيانات. يُنفذ التشغيل الكامل جميع الخطوات الـ 13، بما في ذلك تجميعات Neo، في حوالي 15 دقيقة، وتكلف حوالي 0.07 دولار عند استخدام خدمة ml.m5.xlarge (منطقة US East (Ohio) (us-east-2)، يوليو 2026، على الطلب الفوري). تكلفة موارد التنظيم معًا أقل من 0.10 دولار شهريًا عند حجم العينات.
لتنفيذ الخطوة التدريبية على الصور الحقيقية، يحتوي المخزن المؤقت على برنامج تنزيل لـ مجموعة بي سي سي دي. تتمثل مجموعة البيانات في مجموعة من 364 صورة للدم تحت المجهر، تم نشرها أصلاً على GitHub، وتم إعادة تنظيمها إلى صيغة باسكال فيوك تحت ترخيص ميتش. كما يتم توزيع نفس المجموعة من البيانات من قبل روبوفلو كمجموعة عامة. يقوم البرنامج بتبديل وجود الصفائح الدموية إلى فئة العيوب، ويقوم تلقائيًا بتقسيم الصور حسب الكاميرا لتمثيل أسطول من الكاميرات، ويقوم بنشر ملفات التدريب على الباكيت الخاص بالخطوة التدريبية. يقوم دفتر الملاحظات المصاحب بتنفيذ الخطوة التدريبية بالكامل على البيانات الحقيقية، ويقوم بتحليل ONNX جنبًا إلى جنب على عينة طبيعية وعينة غير طبيعية. يعتبر اعتبار الصفائح الدموية كعيوب مجرد تمثيل توضحي لتوزيع العيوب في التصنيع، وليس ادعاءً سريريًا.
تنظيف
تُنشأ حزم النموذج أثناء تشغيل خط الأنابيب، لذلك لا يمكن لـ AWS CloudFormation أن تزيلها. يجب إزالتها أولاً باستخدام AWS CLI، ثم تدمير الرفوف باستخدام cdk destroy --all -c bootstrap=true --force. يذكر الملخص المرفق الأوامر الدقيقة.
الخلاصة
في هذه المقالة، عرضت هيكلاً مرجعياً لـ SageMaker SDK v3 يعمل بشكل جيد للدورة حياة الرؤية الحاسوبية على مستوى الفرق الكبيرة. يتضمن الهيكل خط إنتاج تدريب مزدوج الفروع، حيث يتم فحص كل نموذج من حيث الجودة بناءً على ملف ONNX المنشور به، ويتم تجميعه باستخدام SageMaker Neo، ثم يسجل فقط. يستخدم نظام التسجيل الخاص بالنماذج البيانات التحتية للكاميرا لتحويل مجموعات الحزم المشتركة إلى سجلات يمكن بدء التدريب عليها لكل كاميرا، كما يقوم طبقة تنظيمية من Step Functions بتنظيم تدريب الفرق ضمن حدود الحسابات المتاحة. بالنسبة للفرق التي تحتاج إلى خيارات مُدارة مثل Amazon Lookout for Vision، فهذه هي الطريقة الأبسط. يستهدف هذا النموذج القيود المتعلقة بكل كاميرا على مستوى الفيلق، وهو ما لا تغطيه الخيارات المُدارة. قواعد التصميم تنتقل إلى ما وراء الرؤية الحاسوبية: يجب أن يكون الهدف هو الدقة المتوازنة مع استرداد الأصوات من الفئات الأقلية بدلاً من الدقة، ويجب تقييم وتجميع المنتج الذي يتم شحنه، كما يجب إبلاغ الفشل التشغيلي بدلاً من إنهاء العملية بهدوء.
يتم تنفيذ العينة في دقائق، وتكلفة التحقق الكامل حوالي سبعة سنتات من المعالجة، لذا الخطوة التالية ذات التكلفة المنخفضة تتمثل في استنساخ المستودع وتشغيله. من هنا، يجب توجيه برنامج التحميل الخاص بـ BCCD إلى صندوق حقيقي، وتحديد NeoTargetDevice لجهازك، أو تعديل حدود التنظيمية لأسطولك. بالنسبة للانتقال إلى SDK v3 نفسه، فإن وثائق SDK Python لـ SageMaker والسلسلة المكونة من جزأين التي تعلن عن SDK الجديد هي المراجع التي ظللت أفتحها طوال الوقت.
إذا كنت ترغب في الحصول على مساعدة في تكييف هذا النموذج مع بيئة الإنتاج الخاصة بك، يرجى الاتصال بفريق حساب AWS الخاص بك.