حقق أداءً فائق النطاق لخدمة النموذج باستخدام NVIDIA Triton Inference Server على Amazon SageMaker

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

يتمثل النمط الشائع لتقليل أوقات الاستجابة دون المساومة على الإنتاجية الإجمالية في استضافة هذه النماذج على نفس المثيل جنبًا إلى جنب مع منطق الأعمال الخفيف المضمن فيه. يمكن أيضًا تغليف هذه النماذج داخل حاويات فردية أو متعددة في نفس الحالة من أجل توفير عزل للعمليات الجارية والحفاظ على زمن الوصول منخفضًا. بالإضافة إلى ذلك ، يعتمد وقت الاستجابة الكلي أيضًا على منطق تطبيق الاستدلال وتحسينات النموذج والبنية التحتية الأساسية (بما في ذلك الحوسبة والتخزين والشبكات) وخادم الويب الأساسي الذي يتلقى طلبات الاستدلال. خادم الاستدلال NVIDIA Triton هو برنامج مفتوح المصدر يقدم الاستدلال مع ميزات لزيادة الإنتاجية واستخدام الأجهزة مع زمن انتقال منخفض للغاية (ملي ثانية من رقم واحد). لديه دعم واسع لأطر عمل تعلم الآلة (بما في ذلك TensorFlow و PyTorch و ONNX و XGBoost و NVIDIA TensorRT) وخلفيات البنية التحتية ، بما في ذلك وحدات معالجة الرسومات ووحدات المعالجة المركزية و استدلال AWS. بالإضافة إلى ذلك ، تم دمج Triton Inference Server مع الأمازون SageMaker، خدمة تعلّم آلي شاملة مُدارة بالكامل ، توفر خيارات استدلال في الوقت الفعلي بما في ذلك عزباء و متعدد النماذج الاستضافة. تتضمن خيارات الاستدلال هذه استضافة نماذج متعددة داخل نفس الحاوية خلف ملف نقطة نهاية واحدةو الاستضافة نماذج متعددة مع حاويات متعددة خلف نقطة نهاية واحدة.

في تشرين الثاني (نوفمبر) 2021 ، أعلنا تكامل خادم الاستدلال Triton على SageMaker. عملت AWS بشكل وثيق مع NVIDIA لتمكينك من الحصول على أفضل ما في العالمين وجعل نشر النموذج مع Triton على AWS أسهل.

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

يمكنك مراجعة ملف مفكرة اعتدنا على نشر النماذج وإجراء اختبارات التحميل بنفسك باستخدام الكود الموجود على GitHub جيثب:.

ضبط الأداء وتحسينه للنموذج الذي يخدم على SageMaker

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

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

الاستدلال في الوقت الفعلي ووقت الاستجابة في SageMaker

الاستدلال في الوقت الحقيقي من SageMaker مثالي لاستدلال أعباء العمل حيث يكون لديك متطلبات في الوقت الفعلي وتفاعلية وزمن انتقال منخفض. هناك أربعة مقاييس شائعة الاستخدام لمراقبة زمن انتقال طلب الاستدلال لنقاط نهاية استدلال SageMaker

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

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

يعتمد زمن انتقال الحاوية على عدة عوامل ؛ فيما يلي أهمها:

• البروتوكول الأساسي (HTTP (s) / gRPC) المستخدم للتواصل مع خادم الاستدلال
• النفقات العامة المتعلقة بإنشاء اتصالات TLS جديدة
• وقت إلغاء تسلسل حمولة الطلب / الاستجابة
• طلب ميزات قائمة الانتظار والتجميع التي يوفرها خادم الاستدلال الأساسي
• طلب قدرات الجدولة التي يوفرها خادم الاستدلال الأساسي
• أداء وقت التشغيل الأساسي لخادم الاستدلال
• أداء مكتبات ما قبل المعالجة والمعالجة اللاحقة قبل استدعاء وظيفة التنبؤ النموذجية
• أساس أداء الواجهة الخلفية لإطار تعلم الآلة
• التحسينات الخاصة بالطراز والأجهزة الخاصة

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

نظرة عامة على حالة الاستخدام

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

في هذا المنشور ، نقيس حالة استخدام البرمجة اللغوية العصبية باستخدام نقطة نهاية في الوقت الفعلي لـ SageMaker استنادًا إلى حاوية Triton Inference Server ونوصي بتحسينات ضبط الأداء لحالة استخدام ML الخاصة بنا. نحن نستخدم وجه معانق كبير ومدرب مسبقًا على المحولات بيرت كبير غير محدد النموذج ، الذي يحتوي على حوالي 336 مليون معلمة نموذجية. جملة الإدخال المستخدمة في نموذج التصنيف الثنائي مبطن ومقطع إلى أقصى طول لتسلسل إدخال يبلغ 512 رمزًا مميزًا. يحاكي اختبار حمل الاستدلال 500 طلب في الثانية (30,000 دعوة كحد أقصى في الدقيقة) و ModelLatency أقل من 0.5 ثانية (500 مللي ثانية).

يلخص الجدول التالي تكويننا المعياري.

خادم الاستدلال NVIDIA Triton

تم تصميم Triton Inference Server خصيصًا لتمكين النشر القابل للتطوير والسريع والسهل للنماذج في الإنتاج. يدعم Triton مجموعة متنوعة من أطر عمل الذكاء الاصطناعي الرئيسية ، بما في ذلك TensorFlow و TensorRT و PyTorch و XGBoost و ONNX. باستخدام الواجهة الخلفية المخصصة لـ Python و C ++ ، يمكنك أيضًا تنفيذ عبء عمل الاستدلال لمزيد من حالات الاستخدام المخصصة.

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

يزيد Triton من أداء الاستدلال من خلال تعظيم استخدام الأجهزة باستخدام تقنيات تحسين مختلفة (تعد عمليات تشغيل النماذج المتزامنة والجمع الديناميكي هي الأكثر استخدامًا). يعد العثور على تكوينات النموذج المثلى من مجموعات مختلفة من أحجام الدُفعات الديناميكية وعدد مثيلات النموذج المتزامنة أمرًا أساسيًا لتحقيق الاستدلال في الوقت الفعلي ضمن الخدمة منخفضة التكلفة باستخدام Triton.

الخلط الديناميكي

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

في البنية السابقة ، تصل جميع الطلبات إلى جهاز التجميع الديناميكي أولاً قبل الدخول إلى قوائم انتظار جدولة النموذج الفعلية لانتظار الاستدلال. يمكنك تعيين أحجام الدُفعات المفضلة لديك للجمع الديناميكي باستخدام ملف المفضل_حجم_الدفعة الإعدادات في تكوين النموذج. (لاحظ أن حجم الدُفعة المشكلة يجب أن يكون أقل من max_batch_size يدعم النموذج.) يمكنك أيضًا تكوين max_queue_delay_microthans لتحديد الحد الأقصى لوقت التأخير في المُجمع لانتظار الطلبات الأخرى للانضمام إلى الدُفعة بناءً على متطلبات زمن الوصول.

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

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

نماذج قيد التشغيل بشكل متزامن

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

يوضح الشكل التالي كيف يمكنك بسهولة تكوين سياسات نشر نموذج مختلفة ببضعة سطور فقط من تغييرات التعليمات البرمجية. على سبيل المثال ، يُظهر التكوين A (على اليسار) أنه يمكنك بث نفس التكوين لمثيلين من نموذج bert-large-uncased لجميع وحدات معالجة الرسومات المتاحة. في المقابل ، يُظهر التكوين B (الأوسط) تكوينًا مختلفًا لـ GPU 0 فقط ، دون تغيير السياسات على وحدات معالجة الرسومات الأخرى. يمكنك أيضًا نشر مثيلات لنماذج مختلفة على وحدة معالجة رسومات واحدة ، كما هو موضح في التكوين C (يمين).

في التكوين C ، يمكن لمثيل الحوسبة معالجة طلبين متزامنين لنموذج DistilGPT-2 وسبعة طلبات متزامنة لـ bert-large-uncased نموذج بالتوازي. من خلال هذه التحسينات ، يمكن استخدام موارد الأجهزة بشكل أفضل في عملية التقديم ، وبالتالي تحسين الإنتاجية وتوفير كفاءة أفضل من حيث التكلفة لأعباء عملك.

TensorRT

نفيديا تينسوررت عبارة عن SDK لاستدلال التعلم العميق عالي الأداء الذي يعمل بسلاسة مع Triton. يتضمن TensorRT ، الذي يدعم كل إطار عمل رئيسي للتعلم العميق ، مُحسِّنًا للاستدلال ووقت تشغيل يوفر زمن انتقال منخفض وإنتاجية عالية لتشغيل الاستنتاجات بأحجام هائلة من البيانات عبر تحسينات قوية.

تعمل TensorRT على تحسين الرسم البياني لتقليل أثر الذاكرة عن طريق تحرير الذاكرة غير الضرورية وإعادة استخدامها بكفاءة. بالإضافة إلى ذلك ، يقوم تجميع TensorRT بدمج العمليات المتفرقة داخل الرسم البياني للنموذج لتشكيل نواة أكبر لتجنب الحمل الزائد لعمليات إطلاق نواة صغيرة متعددة. يساعدك الضبط التلقائي لـ Kernel على الاستفادة الكاملة من الأجهزة عن طريق تحديد أفضل خوارزمية على وحدة معالجة الرسومات المستهدفة. تعمل تدفقات CUDA على تمكين النماذج من العمل بالتوازي لزيادة استخدام وحدة معالجة الرسومات الخاصة بك للحصول على أفضل أداء. أخيرًا وليس آخرًا ، يمكن لتقنية التكميم أن تستخدم بشكل كامل تسريع مختلط الدقة لأنوية Tensor لتشغيل النموذج في FP32 و TF32 و FP16 و INT8 لتحقيق أفضل أداء للاستدلال.

Triton على استضافة SageMaker

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

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

إن اتساع الخيارات والنمطية وسهولة استخدام أطر عمل مختلفة تجعل SageMaker و Triton تطابقًا قويًا.

مُوصي الاستدلال من SageMaker لقياس نتائج الاختبار

نستخدم SageMaker Inference Proper لإجراء تجاربنا. يقدم SageMaker Inference الموصى به نوعين من الوظائف: الافتراضية والمتقدمة ، كما هو موضح في الرسم التخطيطي التالي.

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

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

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

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

إعداد التجربة

نحن نستخدم ميزة اختبار الحمل المخصص لبرنامج SageMaker Inference Proper لتقييم ملف تعريف البرمجة اللغوية العصبية (NLP) الموضح في حالة الاستخدام الخاصة بنا. نحدد أولاً المتطلبات الأساسية التالية المتعلقة بنموذج البرمجة اللغوية العصبية ومهمة ML. يستخدم SageMaker Inference التوصية هذه المعلومات لسحب صورة Docker للاستدلال منها سجل الأمازون المرنة للحاويات (Amazon ECR) وقم بتسجيل النموذج في سجل نموذج SageMaker.

تسمح لنا تكوينات نمط حركة المرور في SageMaker Inference Proper بتحديد مراحل مختلفة لاختبار الحمل المخصص. يبدأ اختبار التحميل بمستخدمين أوليين وينتج مستخدمين جديدين كل دقيقة ، لمدة إجمالية تبلغ 25 دقيقة (1500 ثانية) ، كما هو موضح في الكود التالي:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

نجرب الحمل باختبار نفس النموذج في حالتين مختلفتين. تستخدم التجارب المستندة إلى PyTorch نموذج PyTorch القياسي غير المعدل. بالنسبة للتجارب المستندة إلى TensorRT ، نقوم بتحويل نموذج PyTorch إلى محرك TensorRT مسبقًا.

نطبق مجموعات مختلفة من ميزات تحسين الأداء على هذين النموذجين ، ملخصة في الجدول التالي.

نتائج الاختبار والملاحظات

أجرينا اختبارات تحميل لثلاثة أنواع من المثيلات ضمن عائلة g4dn نفسها: ml.g4dn.xlarge و ml.g4dn.2xlarge و ml.g4dn.12xlarge. تتمتع جميع أنواع مثيلات g4dn بإمكانية الوصول إلى وحدات معالجة الرسومات NVIDIA T4 Tensor Core والجيل الثاني من معالجات Intel Cascade Lake. كان المنطق وراء اختيار أنواع المثيلات هو الحصول على مثيل به وحدة معالجة رسومات واحدة فقط متاحة ، بالإضافة إلى مثيل له إمكانية الوصول إلى وحدات معالجة رسومات متعددة — أربعة في حالة ml.g2dn.4xlarge. بالإضافة إلى ذلك ، أردنا اختبار ما إذا كانت زيادة سعة وحدة المعالجة المركزية الافتراضية على المثيل باستخدام وحدة معالجة رسومات واحدة متاحة ستؤدي إلى تحسين نسبة أداء التكلفة.

دعنا ننتقل إلى تسريع التحسين الفردي أولاً. يوضح الرسم البياني التالي أن تحسين TensorRT يوفر تخفيضًا بنسبة 50٪ في زمن انتقال النموذج مقارنةً بالنسخة الأصلية في PyTorch على مثيل ml.g4dn.xlarge. ينمو تقليل زمن الوصول هذا إلى أكثر من ثلاث مرات في مثيلات وحدات معالجة الرسومات المتعددة لـ ml.g4dn.12xlarge. وفي الوقت نفسه ، فإن تحسين الإنتاجية بنسبة 30٪ ثابت في كلتا الحالتين ، مما يؤدي إلى فعالية أفضل من حيث التكلفة بعد تطبيق تحسينات TensorRT.

من خلال التجميع الديناميكي ، يمكننا الاقتراب من تحسين الإنتاجية بمقدار الضعفين باستخدام نفس بنية الأجهزة في جميع تجارب مثيل ml.g2dn.xlarge و ml.g4dn.4xlarge و ml.g2dn.4xlarge بدون زيادة ملحوظة في زمن الانتقال.

وبالمثل ، يمكّننا تنفيذ النموذج المتزامن من الحصول على حوالي 3-4x تحسين في الإنتاجية عن طريق تعظيم استخدام GPU على مثيل ml.g4dn.xlarge وحوالي 2x على كل من مثيل ml.g4dn.2xlarge ومثيل متعدد GPU لـ ml. g4dn.12xlarge .. تأتي هذه الزيادة في الإنتاجية بدون أي زيادة في زمن الانتقال.

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

[1] عدد المثيلات الأولي في الجدول أعلاه هو العدد الموصى به من المثيلات لاستخدامها مع سياسة القياس التلقائي للحفاظ على متطلبات الإنتاجية ووقت الاستجابة لأعباء العمل الخاصة بك.

[2] يتم حساب التكلفة لكل ساعة في الجدول أعلاه بناءً على عدد المثيل الأولي والسعر لنوع المثيل.

تتحقق النتائج في الغالب من التأثير المتوقع لميزات تحسين الأداء المختلفة:

• تجميع TensorRT له التأثير الأكثر موثوقية عبر جميع أنواع المثيلات. زادت المعاملات في الدقيقة لكل مثيل بنسبة 30-35٪ ، مع خفض ثابت للتكلفة بنسبة 25٪ تقريبًا مقارنة بأداء محرك TensorRT إلى PyTorch BERT الافتراضي (pt-base). يتم تعزيز الأداء المتزايد لمحرك TensorRT واستغلاله بواسطة ميزات ضبط الأداء الأخرى التي تم اختبارها.
• أدى تحميل نموذجين على كل وحدة معالجة رسومات (مجموعة مثيلات) إلى مضاعفة جميع المقاييس المقاسة تقريبًا. زادت الدعوات في الدقيقة لكل مثيل بنسبة 80-90٪ تقريبًا ، مما أدى إلى خفض التكلفة في نطاق 50٪ ، كما لو كنا نستخدم وحدتي معالجة رسومات. حقيقة، الأمازون CloudWatch تؤكد مقاييس تجاربنا على g4dn.2xlarge (كمثال) أن استخدام وحدة المعالجة المركزية ووحدة معالجة الرسومات يتضاعف عندما نقوم بتكوين مجموعة مثيل من نموذجين.

مزيد من النصائح حول الأداء وتحسين التكلفة

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

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

نتوقع اختبار هذه التقنيات والميزات وقياس أدائها في منشور مستقبلي ، لذلك ترقبوا ذلك!

وفي الختام

في هذا المنشور ، اكتشفنا بعض المعلمات التي يمكنك استخدامها لتعظيم أداء نقطة النهاية في الوقت الفعلي من SageMaker لخدمة نماذج PyTorch BERT مع خادم الاستدلال Triton. استخدمنا SageMaker Inference Proper لإجراء اختبارات قياس الأداء لضبط هذه المعلمات. ترتبط هذه المعلمات في جوهرها بتحسين النموذج المستند إلى TensorRT ، مما يؤدي إلى تحسن بنسبة 50٪ تقريبًا في أوقات الاستجابة مقارنة بالإصدار غير المحسّن. بالإضافة إلى ذلك ، أدى تشغيل النماذج بشكل متزامن واستخدام الدُفعات الديناميكية لـ Triton إلى زيادة الإنتاجية بنسبة 70٪ تقريبًا. أدى الضبط الدقيق لهذه المعلمات إلى تقليل إجمالي لتكلفة الاستدلال أيضًا.

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

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

يمكنك العثور على الكمبيوتر الدفتري المستخدم لاختبار التحميل والنشر عليه GitHub جيثب:. يمكنك تحديث تكوينات Triton وإعدادات SageMaker Inference Proper لتلائم حالة الاستخدام الخاصة بك لتحقيق أحمال عمل الاستدلال الأفضل من حيث التكلفة والأداء.

حول المؤلف

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

جواو مورا هو مهندس حلول متخصص في AI / ML في Amazon Web Services. يركز في الغالب على حالات استخدام البرمجة اللغوية العصبية ومساعدة العملاء على تحسين تدريب ونشر نموذج التعلم العميق. وهو أيضًا مؤيد نشط لحلول ML ذات التعليمات البرمجية المنخفضة والأجهزة المتخصصة في ML.

موهان غاندي هو مهندس برمجيات أول في AWS. لقد عمل مع AWS على مدار السنوات التسع الماضية وعمل على العديد من خدمات AWS مثل EMR و EFA و RDS على Outposts. يركز حاليًا على تحسين تجربة الاستدلال SageMaker. في أوقات فراغه ، يستمتع برياضة المشي لمسافات طويلة وتشغيل الماراثون.

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

سانتوش بهافاني هو مدير منتج تقني أقدم مع فريق Amazon SageMaker Elastic Inference. إنه يركز على مساعدة عملاء SageMaker على تسريع الاستدلال بالنموذج ونشره. في أوقات فراغه ، يستمتع بالسفر ولعب التنس وشرب الكثير من شاي بوير.

جياهونغ ليو هو مهندس حلول في فريق مزود الخدمة السحابية في NVIDIA. يساعد العملاء في تبني حلول التعلم الآلي والذكاء الاصطناعي التي تستفيد من حوسبة NVIDIA المتسارعة لمواجهة تحديات التدريب والاستدلال. في أوقات فراغه ، يستمتع بالأوريغامي ومشاريع DIY ولعب كرة السلة.

• كوينسمارت. أفضل بورصة للبيتكوين والعملات المشفرة في أوروبا.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. دخول مجاني.
• كريبتوهوك. الرادار. تجربة مجانية.
• المصدر: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/