تقديم مجموعة أدوات قياس الاستدلال المعياري للاستدلال بدون خادم من Amazon SageMaker

استدلال Amazon SageMaker Serverless هو خيار استدلال مبني لغرض معين يجعل من السهل عليك نشر نماذج التعلم الآلي (ML) وتوسيع نطاقها. يوفر نموذج الدفع لكل استخدام ، وهو مثالي للخدمات حيث تكون استدعاءات نقطة النهاية غير متكررة ولا يمكن التنبؤ بها. على عكس نقطة نهاية الاستضافة في الوقت الفعلي ، والمدعومة بمثيل طويل التشغيل ، يتم توفير موارد الحوسبة لنقاط النهاية التي لا تحتوي على خادم عند الطلب ، مما يلغي الحاجة إلى اختيار أنواع المثيلات أو إدارة سياسات التوسع.

توضح البنية عالية المستوى التالية كيفية عمل نقطة نهاية بدون خادم. يستدعي العميل نقطة نهاية ، مدعومة ببنية تحتية مُدارة من AWS.

ومع ذلك ، فإن نقاط النهاية التي لا تحتوي على خادم تكون عرضة للبدايات الباردة في حدود الثواني ، وبالتالي فهي أكثر ملاءمة لأحمال العمل المتقطعة أو غير المتوقعة.

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

في هذا المنشور ، نقدم مجموعة الأدوات ونقدم نظرة عامة على تكوينها ومخرجاتها.

حل نظرة عامة

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

قم بتثبيت مجموعة الأدوات

قم أولاً بتثبيت مكتبة قياس الأداء في بيئة Python الخاصة بك باستخدام النقطة:

pip install sm-serverless-benchmarking

يمكنك تشغيل الكود التالي من ملف أمازون ساجميكر ستوديو نموذج، مثيل دفتر SageMaker، أو أي مثيل به الوصول الآلي إلى AWS والمناسب إدارة الهوية والوصول AWS (IAM) أذونات. تم توثيق أذونات IAM المطلوبة في ملف جيثب ريبو. للحصول على إرشادات إضافية وأمثلة لسياسات IAM ، يرجى الرجوع إلى كيف يعمل Amazon SageMaker مع IAM. يقوم هذا الرمز بتشغيل معيار مع مجموعة افتراضية من المعلمات على نموذج يتوقع إدخال CSV مع مثالين للسجلات. من الممارسات الجيدة تقديم مجموعة تمثيلية من الأمثلة لتحليل كيفية أداء نقطة النهاية مع أحمال الإدخال المختلفة.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

بالإضافة إلى ذلك ، يمكنك تشغيل المعيار كمهمة معالجة SageMaker ، والتي قد تكون خيارًا أكثر موثوقية لمعايير التشغيل الأطول مع عدد كبير من الدعوات. انظر الكود التالي:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

لاحظ أن هذا سيتكبد تكلفة إضافية لتشغيل مثيل معالجة SageMaker من ml.m5.large طوال مدة المعيار.

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

تكوين قياس الأداء

قبل الخوض في ما يفعله المعيار والمخرجات التي ينتجها ، من المهم فهم بعض المفاهيم الأساسية عندما يتعلق الأمر بتكوين نقاط نهاية بدون خادم.

هناك اثنين من خيارات التكوين الرئيسية: MemorySizeInMB و MaxConcurrency. MemorySizeInMB يكوّن حجم الذاكرة المخصص للمثيل ، ويمكن أن يكون 1024 ميجابايت أو 2048 ميجابايت أو 3072 ميجابايت أو 4096 ميجابايت أو 5120 ميجابايت أو 6144 ميجابايت. يتناسب عدد وحدات المعالجة المركزية الافتراضية أيضًا مع مقدار الذاكرة المخصصة. ال MaxConcurrency تقوم المعلمة بضبط عدد الطلبات المتزامنة التي تستطيع نقطة النهاية خدمتها. مع MaxConcurrency من 1 ، يمكن لنقطة نهاية بدون خادم معالجة طلب واحد فقط في كل مرة.

لتلخيص ، و MemorySizeInMB توفر المعلمة آلية للتوسع الرأسي ، مما يسمح لك بضبط الذاكرة وحساب الموارد لخدمة نماذج أكبر ، بينما MaxConcurrency يوفر آلية لقابلية التوسع الأفقي ، مما يسمح لنقطة النهاية الخاصة بك بمعالجة المزيد من الطلبات المتزامنة.

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

نواتج المقارنة المعيارية

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

بشكل افتراضي ، تقوم الأداة بتشغيل مقياسين. الأول هو معيار قياس الاستقرار ، والذي ينشر نقطة نهاية لكل من تكوينات الذاكرة المحددة ويستدعي كل نقطة نهاية مع حمولات العينة المتوفرة. الهدف من هذا المعيار هو تحديد إعداد MemorySizeInMB الأكثر فاعلية واستقرارًا. يسجل المعيار فترات انتقال الاستدعاء ويحسب التكلفة المتوقعة لكل استدعاء لكل نقطة نهاية. ثم يقارن التكلفة مقابل مثيل استضافة مماثل في الوقت الفعلي.

عند اكتمال القياس ، تولد الأداة عدة مخرجات في المحدد result_save_path الدليل بهيكل الدليل التالي:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

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

دعونا نفحص بعض نواتج قياس الأداء الفعلية لنقطة نهاية تخدم نموذج MobileNetV2 TensorFlow لرؤية الكمبيوتر. إذا كنت ترغب في إعادة إنتاج هذا المثال ، فراجع ملف مثال دفاتر الملاحظات الدليل في مستودع جيثب.

الناتج الأول في التقرير الموحد هو جدول ملخص يوفر الحد الأدنى والمتوسط ​​والمتوسط ​​والحد الأقصى من وقت الاستجابة لكل MemorySizeInMB تكوين حجم الذاكرة بنجاح. كما هو مبين في الجدول التالي ، متوسط ​​زمن انتقال الاحتجاج (invocation_latency_mean) في التحسن مع زيادة تكوين الذاكرة إلى 3072 ميجابايت ، لكنها توقفت عن التحسن بعد ذلك.

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

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

يعرض الجدول التالي المقاييس التي تم التقاطها بواسطة CloudWatch لكل تكوين ذاكرة.

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

الناتج النهائي لمعيار التكلفة والاستقرار هو تكوين ذاكرة موصى به ، جنبًا إلى جنب مع جدول يقارن تكلفة تشغيل نقطة نهاية بدون خادم مقابل مثيل استضافة SageMaker قابل للمقارنة. بناءً على البيانات التي تم جمعها ، حددت الأداة أن تكوين 2048 ميجابايت هو أفضل تكوين لهذا النموذج. على الرغم من أن التكوين 3072 يوفر وقت استجابة أفضل بنحو 10 مللي ثانية ، إلا أن ذلك يأتي مع زيادة في التكلفة بنسبة 30٪ ، من 4.55 دولارًا أمريكيًا إلى 5.95 دولارًا أمريكيًا لكل مليون طلب. بالإضافة إلى ذلك ، يُظهر الناتج أن نقطة النهاية التي لا تحتوي على خادم ستوفر وفورات تصل إلى 1٪ مقابل مثيل استضافة في الوقت الفعلي قابل للمقارنة عندما يكون هناك أقل من مليون طلب استدعاء شهريًا ، وتقطع حتى مع نقطة نهاية في الوقت الفعلي بعد 88.72 مليون طلب.

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

على سبيل المثال ، من خلال ضبط ملف concurrency_benchmark_max_conc parameter إلى [4 ، 8] و concurrency_num_clients_multiplier إلى [1 ، 1.5 ، 2] ، يتم إطلاق نقطتي نهاية: واحدة بها MaxConcurency من 4 والنقطة الأخرى 8. ثم يتم قياس كل نقطة نهاية باستخدام (MaxConcurency x المضاعف) عدد العملاء المتزامنين المحاكين ، والذي يترجم لنقطة النهاية مع التزامن 4 لتحميل معايير الاختبار مع 4 و 6 و 8 عملاء متزامنين.

الناتج الأول لهذا المعيار هو جدول يعرض مقاييس زمن الوصول واستثناءات الخنق والمعاملات في المقاييس الثانية (TPS) المرتبطة بكل منها MaxConcurrency التكوين بأعداد مختلفة من العملاء المتزامنين. تساعد هذه المقاييس في تحديد المناسب MaxConcurrency الإعداد للتعامل مع الحمل المروري المتوقع. في الجدول التالي ، يمكننا أن نرى أن نقطة النهاية التي تم تكوينها باستخدام حد أقصى للتزامن 8 كانت قادرة على التعامل مع ما يصل إلى 16 عميلًا متزامنًا مع استثناءين فقط من الاختناق من بين 2,500 استدعاء تم إجراؤها بمتوسط ​​24 معاملة في الثانية.

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

يوفر الناتج النهائي جدولًا بمقاييس CloudWatch لكل منها MaxConcurrency ترتيب. بخلاف الجدول السابق الذي يوضح توزيع زمن الوصول لكل تكوين ذاكرة ، والذي قد لا يعرض دائمًا البداية الباردة ModelSetupTime المقياس ، فمن المرجح أن يظهر هذا المقياس في هذا الجدول نظرًا لوجود عدد أكبر من طلبات الاستدعاء وعدد أكبر MaxConcurrency.

وفي الختام

في هذا المنشور ، قدمنا ​​SageMaker Serverless Inference Benchmarking Toolkit وقدمنا ​​نظرة عامة على التكوين والمخرجات. يمكن أن تساعدك الأداة في اتخاذ قرار أكثر استنارة فيما يتعلق بالاستدلال بدون خادم عن طريق تحميل اختبار التكوينات المختلفة باستخدام أنماط حركة مرور واقعية. جرب مجموعة أدوات قياس الأداء مع النماذج الخاصة بك لترى بنفسك الأداء والتوفير في التكاليف الذي يمكنك توقعه من خلال نشر نقطة نهاية بدون خادم. يرجى الرجوع إلى جيثب ريبو للحصول على وثائق إضافية وأمثلة على أجهزة الكمبيوتر المحمولة.

موارد إضافية

عن المؤلفين

سيمون زامارين هو مهندس حلول AI / ML الذي ينصب تركيزه الرئيسي على مساعدة العملاء على استخراج القيمة من أصول البيانات الخاصة بهم. في أوقات فراغه ، يستمتع Simon بقضاء الوقت مع العائلة ، وقراءة الخيال العلمي ، والعمل على العديد من مشاريع DIY المنزلية.

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

ريشابه راي شودري هو مدير أول للمنتجات في Amazon SageMaker ، ويركز على استدلال التعلم الآلي. إنه متحمس للابتكار وبناء تجارب جديدة لعملاء التعلم الآلي على AWS للمساعدة في توسيع أعباء العمل لديهم. في أوقات فراغه ، يستمتع بالسفر والطهي. يمكنك أن تجده على لينكدين:.