استدلال ML الفعال من حيث التكلفة مع نماذج متعددة الأطر على Amazon SageMaker PlatoBlockchain Data Intelligence. البحث العمودي. عاي.

استدلال تعلم الآلة الموفر من حيث التكلفة مع نماذج متعددة الأطر على Amazon SageMaker 

أثبت التعلم الآلي (ML) أنه أحد أكثر تطبيقات التكنولوجيا نجاحًا وانتشارًا ، حيث يؤثر على مجموعة واسعة من الصناعات ويؤثر على مليارات المستخدمين كل يوم. مع هذا التبني السريع لتعلم الآلة في كل صناعة ، تواجه الشركات تحديات في دعم تنبؤات زمن الوصول المنخفض وتوافر عالي مع تعظيم استخدام الموارد وتقليل التكاليف المرتبطة بها. نظرًا لأن كل إطار عمل ML له تبعياته الخاصة ، وخطوات النشر لكل إطار مختلفة ، فإن نشر النماذج المضمنة في أطر عمل مختلفة في الإنتاج وإدارة كل نقطة نهاية يصبح أكثر وأكثر تعقيدًا.

الأمازون SageMaker تمكننا نقاط النهاية متعددة الحاويات (MCEs) من تجميع النماذج في أطر عمل مختلفة ونشرها على نفس المضيف ، مما يؤدي إلى إنشاء نقطة نهاية واحدة. يمكنك توفير حاويات لأطر العمل المختلفة التي تستخدمها لبناء النماذج ، وسيأخذ SageMaker كل هذه الحاويات ويضعها خلف نقطة نهاية واحدة. على سبيل المثال ، يمكن أن يكون لديك نموذج PyTorch و TensorFlow تم تحميلهما على نقطتي نهاية مخصصتين تخدمان نفس حالات الاستخدام أو حالات استخدام مختلفة تمامًا ، وكلا هذين النموذجين لهما حركة مرور واردة متقطعة لا تستخدم الموارد إلى أقصى حد. في مثل هذا السيناريو ، يمكنك تجميعهم معًا باستخدام الحاويات في نقطة نهاية واحدة باستخدام MCE ، مما يؤدي إلى تحسين استخدام الموارد مع تقليل التكاليف المتكبدة في تقديم كلا النموذجين من نقاط نهاية مختلفة.

توفر نقاط النهاية متعددة الحاويات حلاً قابلاً للتطوير وفعالًا من حيث التكلفة لنشر ما يصل إلى 15 نموذجًا مبنيًا على أطر ML مختلفة وخوادم نموذجية وخوارزميات تخدم نفس حالة الاستخدام أو حالة استخدام مختلفة ، مما يعني أنه يمكنك الحصول على نماذج مبنية على أطر عمل تعلم متعددة أو وسيطة متنوعة خطوات عبر كل هذه الحاويات والنماذج. يمكن الوصول إلى كل هذه النماذج بشكل فردي عن طريق الاستدعاء المباشر أو مخيطها في خط أنابيب باستخدام الاستدعاء التسلسلي ، حيث يكون ناتج أحد النماذج هو المدخلات للنموذج التالي.

في هذا المنشور ، نناقش كيفية إجراء استدلال ML الفعال من حيث التكلفة مع نماذج متعددة الأطر على SageMaker.

أنماط استدعاء MCE

يعتبر الاستدعاء المباشر لـ SageMaker MCE مفيدًا في الحالات التي تقوم فيها بجمع نماذج غير مرتبطة بنقطة نهاية MCE أو تقوم بإجراء اختبار A / B بين النماذج الموجودة خلف نقطة نهاية MCE لقياس أدائها. يمكنك استدعاء الحاوية المحددة مباشرة في استدعاء API والحصول على التنبؤ من هذا النموذج.

باستخدام الاستدعاء التسلسلي ، يمكنك تجميع 2-15 حاوية معًا ، ويصبح إخراج إحداها مدخلات الحاوية التالية بالتسلسل. هذه حالة استخدام مثالية إذا كان لديك ، على سبيل المثال ، خط أنابيب تنبؤ متعدد الخطوات حيث يتم استخدام نموذج Scikit-Learn للتنبؤ المتوسط ​​ويتم تغذية النتيجة إلى نموذج TensorFlow للاستدلال النهائي. بدلاً من نشرها كنقاط نهاية مختلفة وتطبيق آخر أو وظيفة أخرى تنظمها وإجراء مكالمات متعددة لواجهة برمجة التطبيقات ، يمكنك نشرها كـ SageMaker MCE ، واستخلاص المنطق وإعدادها للاستدعاء التسلسلي ، حيث يدير SageMaker نقل البيانات بين حاوية واحدة إلى أخرى تلقائيًا وتنبعث إخراج الحاوية النهائية إلى العميل الذي يقوم بطلب واجهة برمجة التطبيقات.

يختلف الاستدعاء التسلسلي لـ SageMaker MCE اختلافًا جوهريًا عن خط أنابيب الاستدلال التسلسلي SageMaker (مزيد من التفاصيل في الأقسام أدناه). يتم استهداف خط أنابيب الاستدلال التسلسلي بشكل أكبر لتنظيم تدفقات عمل ML المعقدة مثل المعالجة المسبقة للبيانات ، أو بناء مجموعة نموذجية ، أو تنفيذ فحوصات شرطية لتحديد النموذج المطلوب استدعاءه ، أو المعالجة اللاحقة للتنبؤ ، بما في ذلك منطق الأعمال قبل إرسال التنبؤ إلى تطبيقات المصب . في المقابل ، تم تصميم الاستدعاء التسلسلي MCE لربط نماذج 2-14 في خط أنابيب للاستدلال ، حيث يأخذ كل نموذج التنبؤ بالنموذج السابق كمدخل.

تكون جميع الحاويات الموجودة في MCE دائمًا في الخدمة وفي الذاكرة ، لذلك لا توجد بداية باردة أثناء استدعاء نقطة النهاية. تعمل MCEs أيضًا على تحسين استخدام نقطة النهاية وتحسين التكاليف نظرًا لنشر النماذج خلف نقطة نهاية واحدة ومشاركة مثيل الحوسبة الأساسي ، بدلاً من احتلال كل نموذج لموارد الحوسبة الفردية.

دعنا نلقي نظرة على بعض حالات الاستخدام ونرى كيف يمكنك استخدام SageMaker MCEs لتحسين استنتاج تعلم الآلة.

حالات الاستخدام لـ SageMaker MCEs

لنفترض أن لديك نموذجين لتصنيف المشاعر ، أحدهما للغة الإنجليزية والآخر للغة الألمانية ، وهذه النماذج تخدم مناطق جغرافية مختلفة مع حركة المرور القادمة في أوقات مختلفة في اليوم. بدلاً من تشغيل نقطتي نهاية على مدار الساعة طوال أيام الأسبوع ، يمكنك نشر كل منهما في نقطة نهاية واحدة باستخدام MCE والوصول إليها باستخدام الاستدعاء المباشر ، وبالتالي تحسين استخدام الموارد والتكاليف. انظر الكود التالي:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

في هذا المثال ، لدينا نموذجان (englishModel و germanModel) ، ونحدد الحاويات في SageMaker create_model بناء وتعريف InferenceExecutionConfig باسم "مباشر". الآن يمكننا استدعاء نقطة النهاية للاستدلال وتحديد TargetContainerHostname إما englishModel or germanModel اعتمادًا على العميل الذي يقوم باستدعاء API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

يمكنك أيضًا استخدام الاستدعاء المباشر داخل MCE لإجراء اختبارات A / B لمقارنة الأداء بين النماذج.

الرسم البياني التالي يوضح هندستنا.

وبالمثل ، في حالات استخدام ML الأخرى ، عند استخدام النموذج المدرب لمعالجة طلب ما ، يتلقى النموذج البيانات بتنسيق يحتاج إلى معالجة مسبقة (على سبيل المثال ، تمييزها) قبل أن يتم تمريرها إلى الخوارزمية للاستدلال. عندما يتم ربط خوارزميات ML معًا ، فإن إخراج أحد النماذج يعمل كمدخل للنموذج التالي قبل الوصول إلى النتيجة النهائية. في هذه الحالة ، يمكنك إنشاء خط أنابيب تسلسلي SageMaker MCE ، حيث تتحدث الحاويات مع بعضها البعض في التسلسل المحدد في create_model أنشئ بدلاً من نشر كل نموذج في نقاط نهاية مختلفة وكتابة منطق مستقل لتسهيل تدفق البيانات بين جميع هذه النماذج واستدعاءات واجهة برمجة التطبيقات. الرسم البياني التالي يوضح هذه العمارة.

استدلال ML الفعال من حيث التكلفة مع نماذج متعددة الأطر على Amazon SageMaker PlatoBlockchain Data Intelligence. البحث العمودي. عاي.

في حالة الاستخدام هذه ، نستخدم الكود التالي:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

في هذا المثال ، لدينا حاويتان للمعالجة (Processing-1 و Processing-2) لمعالجة المعالم وتحويلات البيانات ، وحاويتا للاستدلال (Inference-1 و Inference-2) لتشغيل تنبؤات نموذج ML على البيانات المعالجة مسبقًا. ال PipelineModel يتيح لك المثيل تحديد مسار الاستدلال المكون من تسلسل خطي من أربع حاويات تعالج طلبات الاستدلال على البيانات. توجد الحاويات في نفس المكان ، مما يتيح لك تشغيل الاستدلال بزمن انتقال منخفض.

مقياس نقاط النهاية متعددة النماذج لأعداد كبيرة من النماذج

تزداد فوائد نقاط النهاية متعددة النماذج من SageMaker بناءً على مقياس توحيد النموذج. يمكنك أن ترى وفورات في التكلفة عند استضافة نموذجين بنقطة نهاية واحدة ، وبالنسبة لحالات الاستخدام مع مئات أو آلاف النماذج ، فإن المدخرات أكبر بكثير.

يعد تحجيم نقاط نهاية MCE أمرًا سهلاً أيضًا باستخدام SageMakerVariantInvocationsPerInstance مقياس محدد مسبقًا ، والذي يعطي متوسط ​​عدد المرات في الدقيقة التي يتم فيها استدعاء كل مثيل لنقطة نهاية النموذج لتحديد TargetScaling سياسات. يقوم SageMaker بضبط عدد المثيلات التي يتم توفيرها لنموذج بشكل ديناميكي استجابةً للتغييرات في عبء العمل لديك. عندما يزداد عبء العمل ، يجلب القياس التلقائي المزيد من المثيلات عبر الإنترنت والأحمال مع النماذج والحاويات المستهدفة لمواكبة خدمة الطلبات. عندما ينخفض ​​عبء العمل ، يزيل القياس التلقائي المثيلات غير الضرورية ويفريغ حاويات النموذج بحيث لا تلتهم الحاويات الموارد ، ولا تدفع مقابل الحالات التي لا تستخدمها. يواجه الوقت اللازم لإكمال الطلب الأول مقابل نموذج معين زمن انتقال إضافي (يسمى البداية الباردة) لتنزيل النموذج منه خدمة تخزين أمازون البسيطة (Amazon S3) وقم بتحميله في الذاكرة. تنتهي الاستدعاءات اللاحقة بدون أي حمل إضافي لأنه تم تحميل النموذج بالفعل. انظر الكود التالي:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

باتباع المثال السابق لتكوين السياسة ، نستخدم ملحق SageMakerVariantInvocationsPerInstance مقياس محدد مسبقًا لضبط عدد مثيلات المتغير بحيث يكون لكل مثيل ملف InvocationsPerInstance متري 70.

يمكننا أيضًا توسيع نطاق SageMaker MCEs استنادًا إلى مقياسنا المخصص ، مثل CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationالطرق أو DiskUtilization، لتوسيع أو تقليل عدد المثيلات بناءً على استخدام مورد معين. لمزيد من المعلومات ، يرجى الرجوع إلى مقياس نماذج الأمازون SageMaker تلقائيًا.

يوصى بأن يعرض النموذج الموجود في كل حاوية متطلبات حساب ووقت استجابة متشابهة في كل طلب استنتاج ، لأنه إذا تحولت حركة المرور إلى MCE من نموذج استخدام وحدة المعالجة المركزية عاليًا إلى نموذج استخدام منخفض لوحدة المعالجة المركزية ، ولكن يظل حجم الاستدعاء الإجمالي كما هو ، نقطة النهاية لا يتوسع وقد لا تكون هناك مثيلات كافية للتعامل مع جميع الطلبات لنموذج استخدام وحدة المعالجة المركزية عاليًا.

تأمين MCEs

بالنسبة إلى MCEs ذات الاستدعاء المباشر ، يتم استضافة عدة حاويات في مثيل واحد عن طريق مشاركة الذاكرة ووحدة تخزين. من المهم تأمين الحاويات ، والحفاظ على التعيين الصحيح للطلبات لاستهداف الحاويات ، وتزويد المستخدمين بالوصول الصحيح إلى الحاويات المستهدفة. يمكنك تقييد invoke_endpoint الوصول إلى مجموعة محدودة من الحاويات داخل MCE باستخدام sagemaker:TargetContainerHostname إدارة الهوية والوصول AWS مفتاح شرط (IAM). يستخدم SageMaker أدوار IAM لتوفير السياسات القائمة على الهوية IAM التي تستخدمها لتحديد الإجراءات والموارد المسموح بها أو المرفوضة والشروط التي بموجبها يُسمح بالإجراءات أو يتم رفضها. توضح السياسات التالية كيفية قصر المكالمات على حاويات معينة داخل نقطة نهاية:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

راقب نقاط النهاية متعددة النماذج باستخدام مقاييس Amazon CloudWatch

لإجراء مقايضات السعر والأداء ، ستحتاج إلى اختبار نقاط النهاية متعددة النماذج باستخدام النماذج وحركة المرور التمثيلية من تطبيقك الخاص. يوفر SageMaker مقاييس إضافية بتنسيق الأمازون CloudWatch لنقاط النهاية متعددة النماذج حتى تتمكن من تحديد استخدام نقطة النهاية ومعدل دخول ذاكرة التخزين المؤقت وتحسين نقطة النهاية الخاصة بك. المقاييس هي كما يلي:

  • ModelLoadingWaitTime - الفترة الزمنية التي ينتظرها طلب الاحتجاج حتى يتم تنزيل النموذج الهدف أو تحميله لإجراء الاستنتاج.
  • ModelUnloadingTime - الفترة الزمنية التي يستغرقها تفريغ النموذج من خلال الحاوية UnloadModel استدعاء API.
  • وقت تنزيل النموذج - الفترة الزمنية التي يستغرقها تنزيل النموذج من Amazon S3.
  • ModelLoadingTime - الفترة الزمنية التي يستغرقها تحميل النموذج من خلال الحاوية LoadModel استدعاء API.
  • ModelCacheHit - عدد ال InvokeEndpoint الطلبات المرسلة إلى نقطة النهاية حيث تم تحميل النموذج بالفعل. أخذ Average الإحصاء يوضح نسبة الطلبات التي تم تحميل النموذج فيها بالفعل.
  • LoadedModelCount - عدد النماذج التي تم تحميلها في الحاويات في نقطة النهاية. يتم إصدار هذا المقياس لكل حالة. ال Average تخبرك الإحصائية بفترة دقيقة واحدة بمتوسط ​​عدد النماذج المحملة لكل مثيل ، و Sum تخبرك الإحصائية بالعدد الإجمالي للنماذج التي تم تحميلها عبر جميع المثيلات في نقطة النهاية. النماذج التي يتتبعها هذا المقياس ليست فريدة بالضرورة لأنه يمكنك تحميل نموذج في عدة حاويات في نقطة النهاية.

هناك أيضًا العديد من المقاييس الأخرى التي تستخدمها كل حاوية تعمل على مثيل ، مثل Invocations مشيرا إلى عدد InvokeEndpoint الطلبات المرسلة إلى حاوية داخل نقطة نهاية ، ContainerLatency إعطاء الوقت الذي استغرقته نقطة النهاية للحاوية المستهدفة أو جميع الحاويات في استدعاء تسلسلي للرد كما هو معروض من SageMaker ، و CPUUtilization و MemoryUtilizaton تشير إلى وحدات CPU ونسبة الذاكرة.

وفي الختام

في المنشور ، ناقشنا كيف يمكن أن تكون نقاط النهاية متعددة الحاويات من SageMaker مفيدة في تحسين التكاليف واستخدام الموارد. تشمل الأمثلة على وقت استخدام MCEs ، على سبيل المثال لا الحصر ، ما يلي:

  • نماذج الاستضافة عبر أطر عمل مختلفة (مثل TensorFlow و PyTorch و Scikit-Learn) التي لا تحتوي على حركة مرور كافية لإشباع السعة الكاملة لمثيل
  • نماذج الاستضافة من نفس الإطار باستخدام خوارزميات تعلم الآلة المختلفة (مثل التوصيات أو التنبؤ أو التصنيف) ووظائف المعالج
  • مقارنات بين بنى متشابهة تعمل على إصدارات إطار عمل مختلفة (مثل TensorFlow 1.x مقابل TensorFlow 2.x) لسيناريوهات مثل اختبار A / B

تدعم SageMaker MCEs نشر ما يصل إلى 15 حاوية على نقاط النهاية في الوقت الفعلي واستدعاءها بشكل مستقل للاستدلال بزمن انتقال منخفض وتوفير التكاليف. يمكن أن تكون النماذج غير متجانسة تمامًا ، مع مكدس تقديم مستقل خاص بها. يمكنك إما استدعاء هذه الحاويات بشكل تسلسلي أو مستقل لكل طلب. يمكن أن توفر لك الاستضافة الآمنة لنماذج متعددة ، من أطر عمل مختلفة ، على مثيل واحد ما يصل إلى 90٪ من التكلفة مقارنةً باستضافة النماذج في نقاط نهاية مخصصة أحادية المثيل.


عن المؤلفين

استدلال ML الفعال من حيث التكلفة مع نماذج متعددة الأطر على Amazon SageMaker PlatoBlockchain Data Intelligence. البحث العمودي. عاي.ضوال باتل هو مهندس رئيسي لتعلم الآلة في AWS. لقد عمل مع مؤسسات تتراوح من الشركات الكبيرة إلى الشركات الناشئة متوسطة الحجم في المشكلات المتعلقة بالحوسبة الموزعة والذكاء الاصطناعي. يركز على التعلم العميق ، بما في ذلك مجالات البرمجة اللغوية العصبية ورؤية الكمبيوتر. يساعد العملاء على تحقيق استدلال نموذج عالي الأداء على Amazon SageMaker.

استدلال ML الفعال من حيث التكلفة مع نماذج متعددة الأطر على Amazon SageMaker PlatoBlockchain Data Intelligence. البحث العمودي. عاي.فيكرام إيلانجو هو مهندس حلول متخصص في الذكاء الاصطناعي / التعلم الآلي في Amazon Web Services ، ومقرها في فرجينيا ، الولايات المتحدة. يساعد Vikram عملاء الصناعة المالية والتأمينية العالمية من خلال التصميم والقيادة الفكرية لبناء ونشر تطبيقات التعلم الآلي على نطاق واسع. يركز حاليًا على معالجة اللغة الطبيعية ، والذكاء الاصطناعي المسؤول ، وتحسين الاستدلال ، وتوسيع ML عبر المؤسسة. في أوقات فراغه ، يستمتع بالسفر والتنزه والطهي والتخييم مع عائلته.

استدلال ML الفعال من حيث التكلفة مع نماذج متعددة الأطر على Amazon SageMaker PlatoBlockchain Data Intelligence. البحث العمودي. عاي.سوراب تريكاندي هو مدير أول للمنتجات في Amazon SageMaker Inference. إنه متحمس للعمل مع العملاء وتحفزه هدف إضفاء الطابع الديمقراطي على التعلم الآلي. يركز على التحديات الأساسية المتعلقة بنشر تطبيقات ML المعقدة ، ونماذج ML متعددة المستأجرين ، وتحسين التكلفة ، وجعل نشر نماذج التعلم العميق أكثر سهولة. في أوقات فراغه ، يستمتع سوراب بالمشي لمسافات طويلة والتعرف على التقنيات المبتكرة واتباع TechCrunch وقضاء الوقت مع أسرته.

الطابع الزمني:

اكثر من التعلم الآلي من AWS