برامج تشغيل API للشبكات العصبية

توفر هذه الصفحة نظرة عامة حول كيفية تنفيذ برنامج تشغيل واجهة برمجة تطبيقات الشبكات العصبية (NNAPI). لمزيد من التفاصيل ، راجع الوثائق الموجودة في ملفات تعريف HAL ​​في hardware/interfaces/neuralnetworks . يوجد تطبيق برنامج تشغيل نموذجي في frameworks/ml/nn/driver/sample .

لمزيد من المعلومات حول واجهة برمجة تطبيقات الشبكات العصبية ، راجع واجهة برمجة تطبيقات الشبكات العصبية .

الشبكات العصبية HAL

تحدد الشبكات العصبية (NN) HAL تجريدًا لمختلف الأجهزة ، مثل وحدات معالجة الرسومات (GPU) ومعالجات الإشارات الرقمية (DSP) ، الموجودة في منتج (على سبيل المثال ، الهاتف أو الكمبيوتر اللوحي). يجب أن تتوافق برامج تشغيل هذه الأجهزة مع NN HAL. الواجهة محددة في ملفات تعريف HAL ​​في hardware/interfaces/neuralnetworks .

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

تدفق الشبكات العصبية

الشكل 1. تدفق الشبكات العصبية

التهيئة

عند التهيئة ، يستعلم إطار العمل السائق عن قدراته باستخدام IDevice::getCapabilities_1_3 . @1.3::Capabilities يشمل جميع أنواع البيانات ويمثل أداء غير مرخّص باستخدام متجه.

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

لتحديد القيم التي يُرجعها برنامج التشغيل استجابةً لـ IDevice::getCapabilities_1_3 ، استخدم تطبيق قياس الأداء NNAPI لقياس أداء أنواع البيانات المقابلة. يوصى بنماذج MobileNet v1 و v2 و asr_float و tts_float لقياس الأداء لقيم النقطة العائمة 32 بت ويوصى بنماذج MobileNet v1 و v2 للقيم الكمية 8 بت. لمزيد من المعلومات ، راجع Android Machine Learning Test Suite .

في Android 9 والإصدارات الأقدم ، تتضمن بنية Capabilities معلومات أداء السائق فقط للنقطة العائمة والموترات الكمية ولا تتضمن أنواع البيانات العددية.

كجزء من عملية التهيئة ، قد يستعلم إطار العمل عن مزيد من المعلومات ، باستخدام IDevice::getType و IDevice::getVersionString و IDevice:getSupportedExtensions و IDevice::getNumberOfCacheFilesNeeded .

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

التحويل البرمجي

يحدد إطار العمل الأجهزة التي يجب استخدامها عند تلقي طلب من أحد التطبيقات. في Android 10 ، يمكن للتطبيقات اكتشاف وتحديد الأجهزة التي يختار منها إطار العمل. لمزيد من المعلومات ، راجع اكتشاف الجهاز والتعيين .

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

  • برنامج التشغيل لا يدعم نوع البيانات.
  • برنامج التشغيل يدعم فقط العمليات مع معلمات إدخال محددة. على سبيل المثال ، قد يدعم برنامج التشغيل عمليات الالتفاف 3x3 و 5x5 ، لكن ليس 7x7.
  • السائق لديه قيود في الذاكرة تمنعه ​​من التعامل مع الرسوم البيانية الكبيرة أو المدخلات.

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

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

عند النجاح ، يقوم برنامج التشغيل بإرجاع مقبض @1.3::IPreparedModel . إذا قام برنامج التشغيل بإرجاع رمز فشل عند إعداد مجموعته الفرعية من النموذج ، يقوم إطار العمل بتشغيل النموذج بأكمله على وحدة المعالجة المركزية.

لتقليل الوقت المستخدم في التجميع عند بدء تشغيل التطبيق ، يمكن للسائق تخزين عناصر الترجمة مؤقتًا. لمزيد من المعلومات ، راجع التخزين المؤقت للترجمة .

تنفيذ

عندما يطلب تطبيق من إطار العمل تنفيذ طلب ما ، يستدعي إطار العمل IPreparedModel::executeSynchronously_1_3 HAL لإجراء تنفيذ متزامن على نموذج معد. يمكن أيضًا تنفيذ الطلب بشكل غير متزامن باستخدام طريقة execute_1_3 ، أو طريقة executeFenced (انظر التنفيذ المُسيّر) ، أو تنفيذه باستخدام تنفيذ الاندفاع .

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

باستخدام طريقة execute_1_3 غير المتزامنة ، يعود عنصر التحكم إلى عملية التطبيق بعد بدء التنفيذ ، ويجب على السائق إخطار إطار العمل عند اكتمال التنفيذ ، باستخدام @1.3::IExecutionCallback .

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

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

بالنسبة للسائقين مع NN HAL 1.1 أو أقل ، يتم إرجاع حالة الخطأ فقط عند اكتمال الطلب. يجب تحديد أبعاد معاملات الإدخال والإخراج بالكامل حتى يكتمل التنفيذ بنجاح. يمكن أن تحتوي المعاملات الداخلية على بُعد واحد أو أكثر من الأبعاد غير المعروفة ، ولكن يجب أن يكون لها ترتيب محدد.

بالنسبة لطلبات المستخدم التي تمتد عبر برامج تشغيل متعددة ، يكون إطار العمل مسؤولاً عن حجز الذاكرة الوسيطة وتسلسل المكالمات لكل محرك.

يمكن بدء طلبات متعددة بالتوازي على نفس @1.3::IPreparedModel . يمكن للسائق تنفيذ الطلبات بالتوازي أو إجراء تسلسل لعمليات التنفيذ.

يمكن أن يطلب إطار العمل من السائق الاحتفاظ بأكثر من نموذج جاهز. على سبيل المثال ، قم بإعداد النموذج m1 ، وإعداد m2 ، وتنفيذ الطلب r1 على m1 ، وتنفيذ r2 على m2 ، وتنفيذ r3 على m1 ، وتنفيذ r4 على m2 ، والإفراج (الموصوف في التنظيف ) m1 ، والإفراج عن m2 .

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

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

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

شكل الإخراج

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

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

توقيت

في Android 10 ، يمكن للتطبيق أن يطلب وقت التنفيذ إذا حدد التطبيق جهازًا واحدًا لاستخدامه أثناء عملية التجميع. للحصول على تفاصيل ، راجع MeasureTiming الجهاز والتعيين. في هذه الحالة ، يجب على برنامج تشغيل NN HAL 1.2 قياس مدة التنفيذ أو تقرير UINT64_MAX (للإشارة إلى أن المدة غير متوفرة) عند تنفيذ الطلب. يجب على السائق تقليل أي عقوبة أداء ناتجة عن قياس مدة التنفيذ.

يقوم السائق بالإبلاغ عن المدد التالية بالميكروثانية في هيكل Timing :

  • وقت التنفيذ على الجهاز: لا يشمل وقت التنفيذ في برنامج التشغيل ، والذي يعمل على المعالج المضيف.
  • وقت التنفيذ في برنامج التشغيل: يشمل وقت التنفيذ على الجهاز.

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

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

إعدام بسياج

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

في التنفيذ المُسوَّج ، يستدعي إطار العمل طريقة IPreparedModel::executeFenced لإطلاق تنفيذ مُحاط وغير متزامن على نموذج مُعد مع متجه لأسوار التزامن تنتظره. إذا تم الانتهاء من المهمة غير المتزامنة قبل عودة الاستدعاء ، يمكن إرجاع مؤشر فارغ لـ sync_fence . يجب أيضًا إرجاع كائن IFencedExecutionCallback للسماح لإطار العمل بالاستعلام عن حالة الخطأ ومعلومات المدة.

بعد اكتمال التنفيذ ، يمكن الاستعلام عن قيمتي التوقيت التاليتين اللتين تقيسان مدة التنفيذ من خلال IFencedExecutionCallback::getExecutionInfo .

  • timingLaunched : المدة من وقت executeFenced ، يتم استدعاءها عند executeFenced ، والإشارات المُحكمة ، syncFence .
  • timingFenced : المدة من وقت الإشارة إلى جميع أسوار المزامنة التي ينتظرها التنفيذ عند التنفيذ ، وإشارات executeFenced إلى syncFence .

تدفق التحكم

بالنسبة للأجهزة التي تعمل بنظام Android 11 أو أعلى ، يتضمن NNAPI عمليتي تحكم في التدفق ، IF و WHILE ، والتي تأخذ نماذج أخرى كوسيطات وتنفذها بشكل مشروط ( IF ) أو بشكل متكرر ( WHILE ). لمزيد من المعلومات حول كيفية تنفيذ ذلك ، راجع التحكم في التدفق .

جودة الخدمة

في Android 11 ، يتضمن NNAPI تحسين جودة الخدمة (QoS) من خلال السماح للتطبيق بالإشارة إلى الأولويات النسبية لنماذجها ، والحد الأقصى للوقت المتوقع لإعداد نموذج ، والحد الأقصى من الوقت المتوقع للتنفيذ أن يكتمل. لمزيد من المعلومات ، راجع جودة الخدمة .

تنظيف

عندما ينتهي تطبيق ما من استخدام نموذج مُعد ، يُطلق إطار العمل مرجعه إلى كائن @1.3::IPreparedModel . عندما لا تتم الإشارة إلى كائن IPreparedModel ، يتم إتلافه تلقائيًا في خدمة برنامج التشغيل التي أنشأته. يمكن استعادة الموارد الخاصة بالطراز في هذا الوقت في تنفيذ السائق للمدمِّر. إذا كانت خدمة برنامج التشغيل تريد تدمير كائن IPreparedModel تلقائيًا عند عدم الحاجة إليه من قبل العميل ، فيجب ألا يحتفظ بأي مراجع لكائن IPreparedModel بعد إرجاع كائن IPreparedeModel من خلال IPreparedModelCallback::notify_1_3 .

استخدام المعالج

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

يوفر إطار العمل تطبيق CPU لجميع عمليات NNAPI باستثناء العمليات التي يحددها البائع. لمزيد من المعلومات ، راجع ملحقات البائع .

العمليات المقدمة في Android 10 (المستوى 29 من API) لها فقط تطبيق مرجعي لوحدة المعالجة المركزية للتحقق من صحة اختبارات CTS و VTS. تُفضل عمليات التنفيذ المُحسَّنة المضمنة في أطر التعلم الآلي للجوّال على تنفيذ NNAPI CPU.

وظائف المرافق

تتضمن قاعدة بيانات NNAPI وظائف الأداة المساعدة التي يمكن استخدامها بواسطة خدمات برنامج التشغيل.

يحتوي ملف frameworks/ml/nn/common/include/Utils.h على وظائف أدوات مساعدة متنوعة ، مثل تلك المستخدمة للتسجيل وللتحويل بين إصدارات NN HAL المختلفة.

  • تسجيل VLog: VLOG عبارة عن ماكرو مجمّع حول Android's LOG يسجل الرسالة فقط إذا تم تعيين العلامة المناسبة في خاصية debug.nn.vlog . يجب استدعاء initVLogMask() قبل أي مكالمات إلى VLOG . يمكن استخدام الماكرو VLOG_IS_ON للتحقق مما إذا كان VLOG ممكّنًا حاليًا ، مما يتيح تخطي رمز التسجيل المعقد إذا لم تكن هناك حاجة إليه. يجب أن تكون قيمة العقار مما يلي:

    • سلسلة فارغة ، تشير إلى عدم إجراء أي تسجيل.
    • الرمز 1 أو all ، مشيرًا إلى أن جميع عمليات التسجيل يجب أن تتم.
    • قائمة بالعلامات ، محددة بمسافات أو فاصلات أو نقطتين ، تشير إلى التسجيل الذي يجب القيام به. العلامات هي compilation و cpuexe و driver execution manager model .
  • compliantWithV1_* : إرجاع true إذا كان من الممكن تحويل كائن NN HAL إلى نفس النوع من إصدار HAL مختلف دون فقد المعلومات. على سبيل المثال ، يؤدي استدعاء compliantWithV1_0 على V1_2::Model إلى إرجاع false إذا كان النموذج يتضمن أنواع عمليات مقدمة في NN HAL 1.1 أو NN HAL 1.2.

  • convertToV1_* : يحول كائن NN HAL من إصدار إلى آخر. يتم تسجيل تحذير إذا أدى التحويل إلى فقدان المعلومات (أي إذا كان الإصدار الجديد من النوع لا يمكن أن يمثل القيمة بالكامل).

  • القدرات: يمكن استخدام دالات nonExtensionOperandPerformance update للمساعدة في بناء حقل Capabilities::operandPerformance .

  • الاستعلام عن خصائص الأنواع: isExtensionOperandType ، isExtensionOperationType ، nonExtensionSizeOfData ، nonExtensionOperandSizeOfData ، nonExtensionOperandTypeIsScalar ، tensorHasUnspecifiedDimensions .

يحتوي ملف frameworks/ml/nn/common/include/ValidateHal.h على وظائف مساعدة للتحقق من صلاحية كائن NN HAL وفقًا لمواصفات إصدار HAL الخاص به.

  • validate* : إرجاع true إذا كان كائن NN HAL صالحًا وفقًا لمواصفات إصدار HAL الخاص به. لم يتم التحقق من أنواع OEM وأنواع الملحقات. على سبيل المثال ، يُرجع validateModel false إذا كان النموذج يحتوي على عملية تشير إلى فهرس معامل غير موجود ، أو عملية غير مدعومة في إصدار HAL هذا.

يحتوي ملف frameworks/ml/nn/common/include/Tracing.h على وحدات ماكرو لتبسيط إضافة معلومات النظام إلى كود الشبكات العصبية. على سبيل المثال ، راجع استدعاءات الماكرو NNTRACE_* في برنامج التشغيل النموذجي.

يحتوي ملف frameworks/ml/nn/common/include/GraphDump.h على وظيفة مساعدة لتفريغ محتوى Model في شكل رسومي لأغراض التصحيح.

  • graphDump : يكتب تمثيل النموذج بتنسيق Graphviz ( .dot ) إلى التدفق المحدد (إذا تم توفيره) أو إلى logcat (إذا لم يتم توفير دفق).

تصديق

لاختبار تنفيذك لـ NNAPI ، استخدم اختبارات VTS و CTS المضمنة في إطار عمل Android. تقوم VTS بتمرين برامج التشغيل الخاصة بك بشكل مباشر (دون استخدام إطار العمل) ، بينما تقوم CTS بتمرينها بشكل غير مباشر من خلال إطار العمل. يختبر هؤلاء كل طريقة من طرق API ويتحققون من أن جميع العمليات التي يدعمها السائقون تعمل بشكل صحيح وتوفر نتائج تلبي متطلبات الدقة.

متطلبات الدقة في CTS و VTS لـ NNAPI هي كما يلي:

  • النقطة العائمة: القيمة المطلقة (المتوقع - الفعلي) <= atol + rtol * abs (متوقع) ؛ أين:

    • بالنسبة إلى fp32 ، atol = 1e-5f ، rtol = 5.0f * 1.1920928955078125e-7
    • بالنسبة إلى fp16 ، atol = rtol = 5.0f * 0.0009765625f
  • الكمية: متقطعة تلو الأخرى (باستثناء mobilenet_quantized ، والتي تكون متقطعة بمقدار ثلاثة)

  • قيمة منطقية: مطابقة تامة

تتمثل إحدى طرق اختبار CTS في NNAPI في إنشاء رسوم بيانية شبه عشوائية ثابتة تستخدم لاختبار ومقارنة نتائج التنفيذ من كل محرك مع تنفيذ مرجع NNAPI. بالنسبة للسائقين مع NN HAL 1.2 أو أعلى ، إذا كانت النتائج لا تفي بمعايير الدقة ، فإن CTS تبلغ عن خطأ وتفريغ ملف المواصفات للنموذج الفاشل تحت /data/local/tmp لتصحيح الأخطاء. لمزيد من التفاصيل حول معايير الدقة ، راجع TestRandomGraph.cpp و TestHarness.h .

اختبار الزغب

الغرض من اختبار الزغب هو العثور على الأعطال أو التأكيدات أو انتهاكات الذاكرة أو السلوك العام غير المحدد في الكود قيد الاختبار بسبب عوامل مثل المدخلات غير المتوقعة. بالنسبة لاختبار NNAPI fuzz ، يستخدم Android اختبارات تعتمد على libFuzzer ، وهي فعالة في التشويش لأنها تستخدم تغطية خطية لحالات الاختبار السابقة لتوليد مدخلات عشوائية جديدة. على سبيل المثال ، يفضل libFuzzer حالات الاختبار التي تعمل على سطور جديدة من التعليمات البرمجية. هذا يقلل بشكل كبير من مقدار الوقت الذي تستغرقه الاختبارات للعثور على التعليمات البرمجية ذات المشكلات.

لإجراء اختبار الزغب للتحقق من صحة تنفيذ برنامج التشغيل الخاص بك ، قم بتعديل frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp في أداة اختبار libneuralnetworks_driver_fuzzer الموجودة في AOSP لتضمين رمز برنامج التشغيل الخاص بك. لمزيد من المعلومات حول اختبار NNAPI fuzz ، راجع frameworks/ml/nn/runtime/test/android_fuzzing/README.md .

حماية

نظرًا لأن عمليات التطبيق تتواصل مباشرة مع عملية السائق ، يجب على السائقين التحقق من صحة وسيطات المكالمات التي يتلقونها. تم التحقق من هذا التحقق من قبل VTS. كود التحقق موجود في frameworks/ml/nn/common/include/ValidateHal.h .

يجب أن يتأكد السائقون أيضًا من أن التطبيقات لا يمكن أن تتداخل مع التطبيقات الأخرى عند استخدام نفس الجهاز.

مجموعة اختبار تعلم الآلة في Android

تعد مجموعة اختبار تعلم الآلة في Android (MLTS) أحد معايير NNAPI المضمنة في CTS و VTS للتحقق من دقة النماذج الحقيقية على أجهزة البائعين. يقوم المعيار بتقييم زمن الوصول والدقة ، ويقارن نتائج برامج التشغيل بالنتائج باستخدام TF Lite الذي يعمل على وحدة المعالجة المركزية ، لنفس الطراز ومجموعات البيانات. هذا يضمن أن دقة برنامج التشغيل ليست أسوأ من التنفيذ المرجعي لوحدة المعالجة المركزية.

يستخدم مطورو منصة Android أيضًا MLTS لتقييم زمن انتقال ودقة برامج التشغيل.

يمكن العثور على معيار NNAPI في مشروعين في AOSP:

النماذج ومجموعات البيانات

يستخدم معيار NNAPI النماذج ومجموعات البيانات التالية.

  • MobileNetV1 float و u8 كميًا بأحجام مختلفة ، يعمل مقابل مجموعة فرعية صغيرة (1500 صورة) من Open Images Dataset v4.
  • MobileNetV2 float و u8 كميًا بأحجام مختلفة ، يعمل مقابل مجموعة فرعية صغيرة (1500 صورة) من Open Images Dataset v4.
  • نموذج صوتي قائم على الذاكرة طويلة المدى (LSTM) لتحويل النص إلى كلام ، يعمل مقابل مجموعة فرعية صغيرة من مجموعة CMU Arctic.
  • نموذج صوتي قائم على LSTM للتعرف التلقائي على الكلام ، يعمل مقابل مجموعة فرعية صغيرة من مجموعة بيانات LibriSpeech.

لمزيد من المعلومات ، راجع platform/test/mlts/models .

اختبار الإجهاد

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

توفر جميع اختبارات التصادم الميزات التالية:

  • اكتشاف تعليق: إذا توقف عميل NNAPI أثناء الاختبار ، يفشل الاختبار بسبب سبب الفشل HANG وتتحرك مجموعة الاختبار إلى الاختبار التالي.
  • اكتشاف تعطل عميل NNAPI: تنجو الاختبارات من أعطال العميل وتفشل الاختبارات بسبب سبب الفشل CRASH .
  • اكتشاف تعطل برنامج التشغيل: يمكن للاختبارات اكتشاف تعطل برنامج التشغيل الذي يتسبب في حدوث فشل في مكالمة NNAPI. لاحظ أنه قد تكون هناك أعطال في عمليات برنامج التشغيل لا تسبب فشل NNAPI ولا تتسبب في فشل الاختبار. لتغطية هذا النوع من الفشل ، يوصى بتشغيل الأمر tail في سجل النظام للأخطاء أو الأعطال المتعلقة ببرنامج التشغيل.
  • استهداف جميع المسرّعات المتاحة: يتم إجراء الاختبارات على جميع برامج التشغيل المتاحة.

جميع اختبارات التصادم لها النتائج الأربعة المحتملة التالية:

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

لمزيد من المعلومات حول اختبار الإجهاد والقائمة الكاملة لاختبارات الأعطال ، راجع platform/test/mlts/benchmark/README.txt .

باستخدام MLTS

لاستخدام MLTS:

  1. قم بتوصيل جهاز مستهدف بمحطة العمل الخاصة بك وتأكد من إمكانية الوصول إليه من خلال adb . تصدير متغير بيئة ANDROID_SERIAL للجهاز المستهدف إذا تم توصيل أكثر من جهاز واحد.
  2. cd في دليل مصدر المستوى الأعلى لنظام Android.

    source build/envsetup.sh
    lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
    ./test/mlts/benchmark/build_and_run_benchmark.sh
    

    في نهاية تشغيل الاختبار ، يتم تقديم النتائج كصفحة HTML وتمريرها إلى xdg-open .

لمزيد من المعلومات ، راجع platform/test/mlts/benchmark/README.txt .

إصدارات HAL للشبكات العصبية

يصف هذا القسم التغييرات التي تم إدخالها في إصدارات HAL من Android والشبكات العصبية.

أندرويد 11

يقدم Android 11 NN HAL 1.3 ، والذي يتضمن التغييرات الملحوظة التالية.

  • دعم تكميم 8 بت الموقع في NNAPI. يضيف نوع المعامل TENSOR_QUANT8_ASYMM_SIGNED . يجب أيضًا أن تدعم برامج التشغيل التي تحتوي على NN HAL 1.3 التي تدعم العمليات ذات التكمية غير الموقعة المتغيرات الموقعة لتلك العمليات. عند تشغيل إصدارات موقعة وغير موقعة من معظم العمليات الكمية ، يجب أن تنتج برامج التشغيل نفس النتائج حتى إزاحة 128. هناك خمسة استثناءات لهذا المطلب: CAST و HASHTABLE_LOOKUP و LSH_PROJECTION و PAD_V2 و QUANTIZED_16BIT_LSTM . لا تدعم عملية QUANTIZED_16BIT_LSTM المعاملات الموقعة والعمليات الأربعة الأخرى تدعم التكميم الموقع ولكنها لا تتطلب أن تكون النتائج متطابقة.
  • دعم عمليات التنفيذ المُحددة حيث يستدعي إطار العمل طريقة IPreparedModel::executeFenced لإطلاق تنفيذ مُحاط وغير متزامن على نموذج مُعد مع متجه لأسوار المزامنة تنتظر. لمزيد من المعلومات ، راجع التنفيذ بسياج .
  • دعم للتحكم في التدفق. يضيف عمليتي IF و WHILE ، اللتين تأخذان نماذج أخرى كوسيطات وتنفذها بشروط ( IF ) أو بشكل متكرر ( WHILE ). لمزيد من المعلومات ، راجع التحكم في التدفق .
  • تحسين جودة الخدمة (QoS) حيث يمكن للتطبيقات أن تشير إلى الأولويات النسبية لنماذجها ، والحد الأقصى للوقت المتوقع لإعداد نموذج ، والحد الأقصى للوقت المتوقع لإكمال التنفيذ. لمزيد من المعلومات ، راجع جودة الخدمة .
  • دعم مجالات الذاكرة التي توفر واجهات مخصصة للمخازن المؤقتة التي يديرها برنامج التشغيل. يسمح ذلك بتمرير الذكريات الأصلية للجهاز عبر عمليات التنفيذ ، ومنع نسخ البيانات غير الضرورية والتحويل بين عمليات الإعدام المتتالية على نفس برنامج التشغيل. لمزيد من المعلومات ، راجع مجالات الذاكرة .

أندرويد 10

يقدم Android 10 NN HAL 1.2 ، والذي يتضمن التغييرات الملحوظة التالية.

  • تتضمن بنية Capabilities جميع أنواع البيانات بما في ذلك أنواع البيانات العددية ، وتمثل أداءً غير مرتبط باستخدام متجه بدلاً من الحقول المسماة.
  • تسمح أساليب getVersionString و getType لإطار العمل باسترداد نوع الجهاز (نوع الجهاز) DeviceType الإصدار. انظر اكتشاف الجهاز والتعيين .
  • يتم استدعاء الأسلوب executeSynchronously بشكل افتراضي لإجراء التنفيذ بشكل متزامن. تخبر طريقة execute_1_2 إطار العمل بتنفيذ تنفيذ غير متزامن. انظر التنفيذ .
  • تحدد معلمة MeasureTiming executeSynchronously execute_1_2 وتنفيذ الاندفاع ما إذا كان السائق سيقيس مدة التنفيذ. يتم الإبلاغ عن النتائج في هيكل Timing . انظر التوقيت .
  • دعم عمليات التنفيذ حيث يكون لواحد أو أكثر من معاملات الإخراج بُعد أو رتبة غير معروفة. انظر شكل الإخراج .
  • دعم ملحقات البائع ، وهي مجموعات من العمليات وأنواع البيانات التي يحددها البائع. يقوم برنامج التشغيل بالإبلاغ عن الامتدادات المدعومة من خلال طريقة IDevice::getSupportedExtensions . انظر ملحقات البائع .
  • القدرة على التحكم في مجموعة من عمليات تنفيذ الاندفاع باستخدام قوائم انتظار الرسائل السريعة (FMQs) للتواصل بين عمليات التطبيق والسائق ، مما يقلل من زمن الوصول. راجع عمليات التنفيذ المتتالية وقوائم انتظار الرسائل السريعة .
  • دعم برنامج AHardwareBuffer للسماح للسائق بتنفيذ عمليات التنفيذ دون نسخ البيانات. انظر AHardwareBuffer .
  • دعم محسّن للتخزين المؤقت لعناصر الترجمة لتقليل الوقت المستخدم في التجميع عند بدء تشغيل التطبيق. انظر التخزين المؤقت للترجمة .

يقدم Android 10 أنواع المعاملات والعمليات التالية.

  • أنواع المعامل

    • ANEURALNETWORKS_BOOL
    • ANEURALNETWORKS_FLOAT16
    • ANEURALNETWORKS_TENSOR_BOOL8
    • ANEURALNETWORKS_TENSOR_FLOAT16
    • ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
    • ANEURALNETWORKS_TENSOR_QUANT16_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL
  • عمليات

    • ANEURALNETWORKS_ABS
    • ANEURALNETWORKS_ARGMAX
    • ANEURALNETWORKS_ARGMIN
    • ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
    • ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
    • ANEURALNETWORKS_CAST
    • ANEURALNETWORKS_CHANNEL_SHUFFLE
    • ANEURALNETWORKS_DETECTION_POSTPROCESSING
    • ANEURALNETWORKS_EQUAL
    • ANEURALNETWORKS_EXP
    • ANEURALNETWORKS_EXPAND_DIMS
    • ANEURALNETWORKS_GATHER
    • ANEURALNETWORKS_GENERATE_PROPOSALS
    • ANEURALNETWORKS_GREATER
    • ANEURALNETWORKS_GREATER_EQUAL
    • ANEURALNETWORKS_GROUPED_CONV_2D
    • ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
    • ANEURALNETWORKS_INSTANCE_NORMALIZATION
    • ANEURALNETWORKS_LESS
    • ANEURALNETWORKS_LESS_EQUAL
    • ANEURALNETWORKS_LOG
    • ANEURALNETWORKS_LOGICAL_AND
    • ANEURALNETWORKS_LOGICAL_NOT
    • ANEURALNETWORKS_LOGICAL_OR
    • ANEURALNETWORKS_LOG_SOFTMAX
    • ANEURALNETWORKS_MAXIMUM
    • ANEURALNETWORKS_MINIMUM
    • ANEURALNETWORKS_NEG
    • ANEURALNETWORKS_NOT_EQUAL
    • ANEURALNETWORKS_PAD_V2
    • ANEURALNETWORKS_POW
    • ANEURALNETWORKS_PRELU
    • ANEURALNETWORKS_QUANTIZE
    • ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
    • ANEURALNETWORKS_RANDOM_MULTINOMIAL
    • ANEURALNETWORKS_REDUCE_ALL
    • ANEURALNETWORKS_REDUCE_ANY
    • ANEURALNETWORKS_REDUCE_MAX
    • ANEURALNETWORKS_REDUCE_MIN
    • ANEURALNETWORKS_REDUCE_PROD
    • ANEURALNETWORKS_REDUCE_SUM
    • ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
    • ANEURALNETWORKS_ROI_ALIGN
    • ANEURALNETWORKS_ROI_POOLING
    • ANEURALNETWORKS_RSQRT
    • ANEURALNETWORKS_SELECT
    • ANEURALNETWORKS_SIN
    • ANEURALNETWORKS_SLICE
    • ANEURALNETWORKS_SPLIT
    • ANEURALNETWORKS_SQRT
    • ANEURALNETWORKS_TILE
    • ANEURALNETWORKS_TOPK_V2
    • ANEURALNETWORKS_TRANSPOSE_CONV_2D
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

يقدم Android 10 تحديثات للعديد من العمليات الحالية. تتعلق التحديثات بشكل أساسي بما يلي:

  • دعم تخطيط الذاكرة NCHW
  • دعم الموترات من رتبة مختلفة عن 4 في softmax وعمليات التطبيع
  • دعم التلافيف المتوسعة
  • دعم المدخلات مع التقسيم المختلط في ANEURALNETWORKS_CONCATENATION

توضح القائمة أدناه العمليات التي تم تعديلها في Android 10. للحصول على تفاصيل كاملة عن التغييرات ، راجع رمز العملية في الوثائق المرجعية لـ NNAPI.

  • ANEURALNETWORKS_ADD
  • ANEURALNETWORKS_AVERAGE_POOL_2D
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_CONCATENATION
  • ANEURALNETWORKS_CONV_2D
  • ANEURALNETWORKS_DEPTHWISE_CONV_2D
  • ANEURALNETWORKS_DEPTH_TO_SPACE
  • ANEURALNETWORKS_DEQUANTIZE
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_FLOOR
  • ANEURALNETWORKS_FULLY_CONNECTED
  • ANEURALNETWORKS_L2_NORMALIZATION
  • ANEURALNETWORKS_L2_POOL_2D
  • ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
  • ANEURALNETWORKS_LOGISTIC
  • ANEURALNETWORKS_LSH_PROJECTION
  • ANEURALNETWORKS_LSTM
  • ANEURALNETWORKS_MAX_POOL_2D
  • ANEURALNETWORKS_MEAN
  • ANEURALNETWORKS_MUL
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_RELU
  • ANEURALNETWORKS_RELU1
  • ANEURALNETWORKS_RELU6
  • ANEURALNETWORKS_RESHAPE
  • ANEURALNETWORKS_RESIZE_BILINEAR
  • ANEURALNETWORKS_RNN
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_SOFTMAX
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SPACE_TO_DEPTH
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_SUB
  • ANEURALNETWORKS_SVDF
  • ANEURALNETWORKS_TANH
  • ANEURALNETWORKS_TRANSPOSE

أندرويد 9

تم تقديم NN HAL 1.1 في Android 9 ويتضمن التغييرات الملحوظة التالية.

  • IDevice::prepareModel_1_1 يتضمن معلمة ExecutionPreference . يمكن للسائق استخدام هذا لضبط إعداده ، مع العلم أن التطبيق يفضل الحفاظ على البطارية أو أنه سيتم تنفيذ النموذج في مكالمات متتالية سريعة.
  • تمت إضافة تسع عمليات جديدة: BATCH_TO_SPACE_ND ، DIV ، MEAN ، PAD ، SPACE_TO_BATCH_ND ، SQUEEZE ، STRIDED_SLICE ، SUB ، TRANSPOSE .
  • يمكن للتطبيق تحديد إمكانية تشغيل حسابات تعويم 32 بت باستخدام نطاق عائم 16 بت و / أو دقة من خلال تعيين Model.relaxComputationFloat32toFloat16 إلى true . يحتوي هيكل Capabilities على المجال الإضافي المريح من أداء relaxedFloat32toFloat16Performance بحيث يمكن للسائق الإبلاغ عن أدائه المريح إلى إطار العمل.

أندرويد 8.1

تم إصدار HAL (1.0) للشبكات العصبية في Android 8.1. لمزيد من المعلومات ، راجع /neuralnetworks/1.0/ .