المفوِّضون LiteRT

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

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

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

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

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

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

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

متوافق مع عدّة أنظمة تشغيل (Android وiOS)

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

iOS

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

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

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

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

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

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

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

وقت الاستجابة واستهلاك الذاكرة

يمكن استخدام أداة قياس الأداء في LiteRT مع المَعلمات المناسبة لتقدير أداء النموذج، بما في ذلك متوسط وقت الاستدلال، وعبء الإعداد الأوّلي، ومساحة الذاكرة، وما إلى ذلك. وتتيح هذه الأداة استخدام علامات متعدّدة لمعرفة أفضل إعدادات المفوّض لنموذجك. على سبيل المثال، يمكن تحديد --gpu_backend=gl مع --use_gpu لقياس تنفيذ وحدة معالجة الرسومات (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 بت هنا (مزيد من التفاصيل).

الدقة والصحة

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

تتضمّن LiteRT نوعَين من الأدوات لقياس مدى دقة سلوك الوكيل بالنسبة إلى نموذج معيّن، وهما: الأدوات المستندة إلى المهام والأدوات غير المستندة إلى المهام. تتيح جميع الأدوات الموضّحة في هذا القسم مَعلمات التفويض المتقدّم التي تستخدمها أداة قياس الأداء من القسم السابق. يُرجى العِلم أنّ الأقسام الفرعية أدناه تركّز على تقييم الأداء باستخدام وكيل (هل يحقّق الوكيل الأداء نفسه الذي تحقّقه وحدة المعالجة المركزية؟) بدلاً من تقييم النموذج (هل النموذج نفسه مناسب للمهمة؟).

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

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

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

• COCO Object Detection (w/ bounding boxes) مع متوسط الدقة

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

• ImageNet Image Classification (مزيد من التفاصيل) * COCO Object Detection (مزيد من التفاصيل)

يوضّح المثال أدناه تقييم تصنيف الصور باستخدام وحدة معالجة الرسومات على هاتف 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

الناتج المتوقّع هو قائمة بمقاييس Top-K من 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 الأداة Inference Diff. (‫Android، ملف ثنائي لبنية ARM‏ 64 بت هنا)

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

• الاستدلال باستخدام وحدة معالجة مركزية (CPU) ذات سلسلة تعليمات واحدة
• الاستدلال من تحديد المستخدم: يتم تحديده من خلال هذه المَعلمات

ولإجراء ذلك، تنشئ الأداة بيانات عشوائية وفقًا للتوزيع الطبيعي (Gaussian) وتمرّرها عبر برنامجَين لتفسير TFLite، أحدهما ينفّذ نواة وحدة المعالجة المركزية (CPU) ذات السلسلة الواحدة، والآخر يتم تحديد مَعلماته بواسطة وسيطات المستخدم.

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

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

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، تختلف العناصر من ناتج وحدة المعالجة المركزية عن ناتج المفوّض بمتوسط 1.96e-05.

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