المفوِّضون LiteRT

يعمل المفوَّضون على تفعيل تسريع الأجهزة لنماذج LiteRT من خلال الاستفادة من مسرِّعات العمل على الجهاز مثل وحدة معالجة الرسومات ومعالج الإشارات الرقمية (DSP).

يستخدم LiteRT بشكل تلقائي نواة وحدة المعالجة المركزية (CPU) التي تم تحسينها للعمل على ARM. نيون مجموعة التعليمات. إلا أن وحدة المعالجة المركزية (CPU) تعد معالجًا متعدد الأغراض لا محسَّنة بالضرورة للعمليات الحسابية الثقيلة الموجودة عادةً في الآلة نماذج التعلّم (على سبيل المثال، معاملات المصفوفة التي ينطوي عليها الالتفاف والكثافة طبقات).

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

يحتوي كل من هذه المسرِّعات على واجهات برمجة تطبيقات مرتبطة تتيح عمليات حوسبة مخصصة، مثل OpenCL أو OpenGL ES لوحدة معالجة الرسومات للأجهزة الجوّالة. عادةً، سيكون لديك لكتابة الكثير من الرموز المخصصة لتشغيل شبكة عصبية من خلال هذه الواجهات. تزداد الأمور تعقيدًا عندما تفكر في أن كل مسرّع له الإيجابيات سلبيات ولا يمكنها تنفيذ كل عملية في الشبكة العصبية. TensorFlow تحل واجهة برمجة التطبيقات Delegate API في Lite هذه المشكلة من خلال العمل كجسر بين TFLite. وواجهة برمجة التطبيقات ذات المستوى الأدنى هذه.

اختيار المفوَّض

يدعم LiteRT مفوَّضين متعددين، ويتم تحسين كل منهم بعض المنصات وأنواع معيّنة من النماذج. عادةً، سيكون هناك هناك عدة مفوَّضين تنطبق على حالة استخدامك، بناءً على معيارين رئيسيين: والنظام الأساسي (Android أو iOS؟) الذي تستهدفه، ونوع النموذج (نقطة عائمة أم الكمية؟) التي تحاول تسريعها.

المفوِّضون حسب النظام الأساسي

على عدّة أنظمة أساسية (Android وiOS)

• تفويض وحدة معالجة الرسومات: يمكن استخدام تفويض وحدة معالجة الرسومات على كل من نظامَي التشغيل Android وiOS. أُنشأها جون هنتر، الذي كان متخصصًا لتشغيل نماذج عائمة بنظام 32 بت و16 بت حيث تكون وحدة معالجة الرسومات المتوفرة. ويتوافق أيضًا مع النماذج الكَمية بنظام 8 بت ويوفر وحدة معالجة رسومات. الأداء على قدم المساواة مع إصداراتها العائمة. للحصول على تفاصيل حول وحدة معالجة الرسومات يُرجى الاطّلاع على LiteRT على وحدة معالجة الرسومات.

iOS

• تفويض أساسي لتعلُّم الآلة لأجهزة iPhone وiPad الأحدث: لأجهزة iPhone وiPad الأحدث أجهزة iPad التي يتوفّر فيها المحرّك العصبي، يمكنك استخدام تفويض Core ML تسريع الاستنتاج لنماذج النقاط العائمة بحجم 32 بت أو 16 بت Neural يتوفّر محرّك البحث على أجهزة Apple الجوّالة التي تتضمّن المنظومة على الرقاقة A12 أو إصدار أحدث. بالنسبة إلى للحصول على نظرة عامة حول المفوَّض الأساسي لتكنولوجيا تعلُّم الآلة والتعليمات المفصّلة مفوَّض LiteRT Core ML:

المفوَّضون حسب نوع النموذج

يتم تصميم كل مسرِّع مع وضع عرض بت معين من البيانات في الاعتبار. إذا كنت توفير نموذج النقطة العائمة للمفوّض الذي يتوافق فقط مع تنسيق 8 بت العمليات، فإنه سيتم رفض جميع عملياته وسيتم تشغيل النموذج بالكامل على وحدة المعالجة المركزية (CPU). لتجنب هذه المفاجآت، يقدم الجدول أدناه نظرة عامة على تفويض الدعم استنادًا إلى نوع النموذج:

التحقّق من الأداء

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

تتميز LiteRT بأدوات شاملة لتقييم الأداء والدقة تمكين المطورين من الثقة في استخدام المفوَّضين في تطبيقاتهم. وتتم مناقشة هذه الأدوات في القسم التالي.

أدوات التقييم

بطيء تأثير الذاكرة

يمكن استخدام أداة قياس الأداء في LiteRT مع المعاملات المناسبة لتقدير أداء النموذج، بما في ذلك متوسط الاستنتاج وقت الاستجابة وأعباء الإعداد وبصمة الذاكرة وما إلى ذلك، وتتيح هذه الأداة علامات متعددة لمعرفة أفضل تهيئة تفويض لنموذجك. بالنسبة مثيل، يمكن تحديد --gpu_backend=gl باستخدام --use_gpu لقياس وحدة معالجة الرسومات. باستخدام OpenGL. في ما يلي القائمة الكاملة بمعلَمات التفويض المتوافقة المحدد في قسم ذات الصلة.

في ما يلي مثال على تشغيل نموذج كمي باستخدام وحدة معالجة رسومات من خلال adb:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

يمكنك تنزيل إصدار مُعَدّ مسبقًا من هذه الأداة لنظام Android، معالج ARM بالإصدار 64 بت. الهندسة المعمارية هنا (المزيد التفاصيل).

الدقة الصحّة

عادةً ما يُجري المفوَّضون عمليات حسابية بدقة مختلفة عن وحدة المعالجة المركزية (CPU). نظرائها. نتيجةً لذلك، هناك مفاضلة في الدقة (عادةً ما تكون طفيفة). بالاستعانة بمفوّض لتسريع الأجهزة. لاحظ أن هذا ليس دائمًا صحيحًا؛ على سبيل المثال، نظرًا لأن وحدة معالجة الرسومات تستخدم دقة النقطة العائمة وبتشغيل نماذج كَمية، قد يكون هناك تحسن طفيف في الدقة (على سبيل المثال، <أفضل 5 تحسين بنسبة% 1 في تصنيف صور ILSVRC).

يتضمن LiteRT نوعين من الأدوات لقياس مدى دقة الشخص المفوَّض نموذج محدد: Task-based وTask-Agnostic. جميع الأدوات الموضحة في هذا القسم على التفويض المتقدم المَعلمات استخدام أداة قياس الأداء من القسم السابق. لاحظ أن تركّز الأقسام الفرعية أدناه على تقييم التفويض (هل يؤدي المفوَّض نفس مستوى وحدة المعالجة المركزية (CPU)؟) بدلاً من تقييم النموذج (هل النموذج نفسه جيد مهمة؟).

التقييم المستند إلى المهمة

يحتوي LiteRT على أدوات لتقييم الصحة في مهمتين تعتمدان على الصور:

• ILSVRC 2012 (صورة التصنيف) مع أعلى درجة ألف الدقة

• رصد كائنات COCO (مع المربعات الإحاطة) مع متوسط الدقة (mAP)

برامج ثنائية مصممة مسبقًا لهذه الأدوات (Android وبنية ARM 64 بت)، إلى جانب يمكن العثور على الوثائق هنا:

• تصنيف الصور في ImageNet (المزيد التفاصيل) * كائن COCO الرصد (المزيد التفاصيل)

يوضح المثال التالي تصنيف الصور التقييم مع وحدة معالجة الرسومات على هاتف Pixel 4:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

الناتج المتوقّع هو قائمة بالمقاييس "الأكثر رواجًا" من 1 إلى 10:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

تقييم اللاأدرية للمهام

المهام التي لا توجد فيها أداة تقييم على الجهاز فقط، أو إذا كانت تختبر نماذج مخصصة، فإن LiteRT لديه الاستنتاج الفارق . (برنامج ثنائي لهندسة ARM ثنائية الإصدار 64 بت من Android) هنا)

يقارن اختلاف الاستنتاج بين تنفيذ LiteRT (من حيث وقت الاستجابة انحراف قيمة المخرجات) في إعدادين:

• استنتاج وحدة المعالجة المركزية (CPU) يتضمّن سلسلة تعليمات واحدة
• استنتاج من تحديد المستخدم - تحدّده هذه المعلمات

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

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

بالنسبة إلى نموذج يحتوي على موتر إخراج واحد، قد يبدو الناتج على النحو التالي:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

وهذا يعني أنه بالنسبة لمتنس الإخراج في الفهرس 0، لا يتم احتساب العناصر من يختلف مخرج وحدة المعالجة المركزية (CPU) عن ناتج المفوّض بمتوسط 1.96e-05.

لاحظ أن تفسير هذه الأرقام يتطلب معرفة أعمق بالنموذج، ما الذي يشير إليه كل متوتر الناتج. إذا كان الانحدار البسيط الذي يحدد نوعًا ما من النقاط أو التضمين، فينبغي أن يكون الفرق منخفضًا (وإلا قد خطأ مع المفوَّض). ومع ذلك، فإن مخرجات مثل "فئة الكشف" واحد من يصعب تفسير نماذج محرك الأقراص ذات الحالة الصلبة قليلاً. على سبيل المثال، قد تعرض اختلافًا في استخدام هذه الأداة، ولكن ذلك لا يعني بالضرورة حدوث مشكلة الشخص المفوَّض: ضع في اعتبارك فئتين (مزيفتين): "التلفزيون (رقم التعريف: 10)" و"مراقب (رقم التعريف:20)" - إذا لا يمانع مندوب من الحكومة الحقيقة الذهبية، ويعرض مراقبًا بدلاً من التلفزيون، قد يكون فارق المُخرج لهذا المُعَرِّف ما يصل إلى 20-10 = 10.