מנהלי התקנים של Neural Networks API

בדף הזה מובאת סקירה כללית לגבי אופן ההטמעה של ממשק API של רשתות נוירונים (NNAPI) לנהגים. לקבלת מידע נוסף, אפשר לעיין בתיעוד שנמצא בהגדרת HAL קבצים ב- hardware/interfaces/neuralnetworks הטמעה של מנהל התקן לדוגמה נמצאת ב- frameworks/ml/nn/driver/sample

למידע נוסף על Neural Networks API, ראו Neural Networks API.

HAL של רשתות נוירונים

HAL של רשתות הנוירונים (NN) מגדיר הפשטה של המכשירים השונים, כמו יחידות עיבוד גרפיות (GPU) ומעבדי אותות דיגיטליים (DSP), שהם חלק ממוצר מסוים (לדוגמה, טלפון או טאבלט). הגורמים המניעים את המודעות מכשירים חייבים לעמוד בדרישות תקן NN HAL. הממשק מצוין ב-HAL קובצי הגדרה hardware/interfaces/neuralnetworks

הזרימה הכללית של הממשק בין המסגרת לנהג מתוארת בתרשים 1.

איור 1. זרימה של רשתות נוירונים

אתחול

בזמן האתחול, ה-framework שולח שאילתה לנהג לגבי היכולות שלו באמצעות IDevice::getCapabilities_1_3 המבנה של @1.3::Capabilities כולל את כל סוגי הנתונים, מייצג ביצועים לא קשורים באמצעות וקטור.

כדי לקבוע איך להקצות חישובים למכשירים הזמינים, משתמשת ביכולות כדי להבין באיזו מהירות ובאיזו מהירות אנרגיה כל נהג יכול לבצע פעולה בצורה יעילה יותר. כדי לספק את המידע הזה, הנהג צריך לספק מספרי ביצועים סטנדרטיים שמבוססים על הביצוע של עומסי עבודה (workloads) של הפניות.

כדי לקבוע את הערכים שהנהג מחזיר בתגובה IDevice::getCapabilities_1_3, צריך להשתמש באפליקציית בנצ'מרק של NNAPI כדי למדוד את את הביצועים של סוגי הנתונים המתאימים. The MobileNet v1 ו-v2, asr_float, ו-tts_float מומלץ להשתמש במודלים למדידת ביצועים של 32 סיביות ומודלים כמותיים של MobileNet v1 ו-v2 מומלץ לערכי קומות ב-8 ביט. מידע נוסף זמין במאמר הבא: חבילת בדיקת למידת מכונה של Android.

ב-Android 9 ומטה, המבנה Capabilities כולל ביצועים של הנהגים רק עבור נקודה צפה (floating-point) וטנצ'רים כמותיים, ולא כולל סוגי נתונים סקלריים.

כחלק מתהליך האתחול, המערכת עשויה לשלוח שאילתות לגבי מידע נוסף, באמצעות IDevice::getType IDevice::getVersionString, IDevice:getSupportedExtensions, וגם IDevice::getNumberOfCacheFilesNeeded.

בין ההפעלות מחדש של המוצר, ה-framework מצפה לכל השאילתות שמתוארות כדי לדווח תמיד על אותם הערכים עבור נהג נתון. אחרת, אפליקציה שימוש במנהל התקן הזה עלול להוביל לירידה בביצועים או להתנהגות שגויה.

קומפילציה

ה-framework קובע באילו מכשירים להשתמש כאשר היא מקבלת בקשה אפליקציה. ב-Android 10, אפליקציות יכולות לגלות ולציין את המכשירים שה-framework בוחר לפיה. מידע נוסף זמין במאמר הבא: גילוי והקצאה של מכשירים.

בזמן האיסוף של המודל, ה-framework שולח את המודל לכל מועמד נהג/ת בהתקשרות IDevice::getSupportedOperations_1_3 כל נהג מחזיר מערך של בוליאניים המציינים בפעולות של המודל. נהג יכול לקבוע שהוא לא יכול תומכים בפעולה נתונה מכמה סיבות. לדוגמה:

• הנהג לא תומך בסוג הנתונים הזה.
• מנהל ההתקן תומך רק בפעולות עם פרמטרים ספציפיים של קלט. עבור לדוגמה, מנהל התקן עשוי לתמוך בקונבולוציות 3x3 ו-5x5, אבל לא 7x7 ב-AI.
• לנהג יש מגבלות זיכרון שמונעות ממנו לטפל גרפים או קלטים.

במהלך ההידור, הקלט, הפלט והאופרנדים הפנימיים של המודל, מתואר ב: OperandLifeTime יכול להיות שהמאפיינים או הדירוג לא ידועים. מידע נוסף זמין במאמר הבא: צורת הפלט.

ה-framework מורה לכל נהג/ת שנבחר להתכונן לבצע קבוצת משנה של את המודל באמצעות הפעלה IDevice::prepareModel_1_3 לאחר מכן, כל מנהל התקן הרכב את קבוצת המשנה שלו. לדוגמה, נהג יכול ליצור קוד או ליצור עותק של המשקולות עם סדר שונה. בגלל שיכול להיות פרק זמן משמעותי בין ההידור של המודל לבין ביצוע בקשות, משאבים כמו מקטעים גדולים של זיכרון המכשיר יוקצו במהלך ההידור.

אם הפעולה מצליחה, הנהג יחזיר @1.3::IPreparedModel כינוי. אם הנהג מחזיר קוד כשל במהלך הכנת קבוצת המשנה של ה-framework מפעיל את כל המודל במעבד.

כדי לקצר את משך הזמן שנדרש לאיסוף כשהאפליקציה מופעלת, הנהג/ת יכול/ה ארטיפקטים של הידור במטמון. למידע נוסף אפשר לראות את האוסף שמירה במטמון.

ביצוע

כשאפליקציה מבקשת מה-framework לבצע בקשה, ה-framework קורא ה IPreparedModel::executeSynchronously_1_3 שיטת HAL כברירת מחדל לביצוע הפעלה סינכרונית במודל מוכן. אפשר גם לבצע בקשה באופן אסינכרוני באמצעות execute_1_3 את ה-method executeFenced method (למידע נוסף, ניתן לעיין בקטע Fencedexe), או מבוצעת באמצעות ביצוע רצף.

קריאות ביצוע סינכרוניות משפרות את הביצועים ומצמצמות את ניהול השרשורים לעומת קריאות אסינכרוניות מכיוון שהשליטה מוחזרת את עיבוד האפליקציה רק לאחר שהביצוע הושלם. המשמעות היא לנהג/ת לא נדרש מנגנון נפרד כדי לשלוח הודעה לתהליך האפליקציה הושלם.

באמצעות השיטה execute_1_3 האסינכרונית, הבקרה חוזרת אל של האפליקציה אחרי שהביצוע התחיל, והנהג צריך להודיע על כך את ה-framework אחרי הביצוע, באמצעות @1.3::IExecutionCallback.

הפרמטר Request שמועבר לשיטת ההרצה מפרט את הקלט והפלט אופרנדים שמשמשים לביצוע. הזיכרון שמאחסן את נתוני האופרנד חייב משתמשים בסדר עולה. המאפיין הראשון הוא שחוזר על עצמו את הזמן האיטי ביותר, מרווח פנימי בסוף כל שורה. למידע נוסף על סוגי האופרנדים, לראות Operands.

עבור מנהלי התקנים NN HAL 1.2 ואילך, כאשר הבקשה הושלם, את סטטוס השגיאה, צורת הפלט, וגם מוחזר פרטי תזמון ל-framework. במהלך הביצוע, פלט או אופרנדים פנימיים של המודל עשויים להיות בעלי מאפיין אחד או יותר לא ידועים או דירוג לא ידוע. כאשר לפחות פלט אחד לאופרנד יש מאפיין או דירוג לא ידועים, הנהג צריך לחזור פרטי פלט בגודל דינמי.

לנהגים עם NN HAL 1.1 ומטה, מוחזר רק סטטוס השגיאה הבקשה הושלמה. המימדים של אופרנדים של קלט ופלט חייבים להיות מלאים שצוין כדי שההפעלה תסתיים בהצלחה. אופרנדים פנימיים יכולים יש מאפיין אחד או יותר שאינם ידועים, אבל צריך לציין דירוג.

בבקשות ממשתמשים שכוללות מספר נהגים, ה-framework אחראי על לשמור זיכרון ביניים ולסדר את הקריאות לכל נהג.

אפשר לשלוח מספר בקשות במקביל באותו זמן @1.3::IPreparedModel הנהג יכול לבצע בקשות במקביל או לבצע סריאליזציה של הפעולות.

המסגרת יכולה לבקש מנהג לשמור יותר ממודל מוכן אחד. עבור דוגמה, הכנת מודל m1, הכנה m2, ביצוע בקשה r1 ב-m1, ביצוע r2 ב-m2, הפעלה של r3 ב-m1, הפעלה r4 בתאריך m2, גרסה (מתוארת ב ניקוי) m1, ומשחררים את m2.

כדי להימנע מהפעלה ראשונה איטית שעלולה לפגוע בחוויית המשתמש (במקרה של רעד בפריים ראשון), הנהג צריך לבצע את רוב האתחולים בשלב ההידור. האתחול בהפעלה הראשונה צריך להיות מוגבל ל- פעולות שמשפיעות לרעה על תקינות המערכת כשמבצעים אותן בשלב מוקדם, כמו שמירת מאגרי נתונים זמניים גדולים או הגברת קצב השעון של מכשיר. נהגים שיכולים להכין רק מספר מוגבל של מודלים בו-זמנית יכולים לבצע לבצע את האתחול בהפעלה הראשונה.

ב-Android מגרסה 10 ואילך, במקרים שבהם מספר הפעלות עם אותו מודל מוכן מבוצעת ברצף במהירות, הלקוח יכול לבחור להשתמש בביצוע אובייקט פרץ (bursts) לצורך תקשורת בין האפליקציה לתהליכי מנהל ההתקנים. לקבלת מידע נוסף מידע נוסף, ראה פעולות של רצף הודעות ותורים של הודעות מהירות.

כדי לשפר את הביצועים של כמה הפעלות ברצף במהירות, הנהג/ת יכול לשמור על מאגרי נתונים זמניים או להגדיל את שיעורי השעון. יצירת טיימר מפקח (watchdog) מומלץ שהשרשור ישוחרר משאבים אם לא נוצרות בקשות חדשות אחרי פרק זמן קבוע מראש.

צורת הפלט

לבקשות שבהן אופרנד פלט אחד או יותר אין את כל המאפיינים מנהל התקן צריך לספק רשימה של צורות פלט שמכילות את של כל אופרנד פלט לאחר הביצוע. לקבלת מידע נוסף מידע על מימדים, 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 זמין במאמר מסגרת סנכרון.

בביצוע מוגדר, ה-framework קורא IPreparedModel::executeFenced להפעלת הפעלה מגודרת ואסינכרונית במודל מוכן עם של גדרות סנכרון שצריך להמתין לו. אם המשימה האסינכרונית הסתיימה לפני הקריאה חוזרת, ניתן להחזיר כינוי ריק עבור sync_fence. כדי לאפשר את ה-framework צריך גם להחזיר אובייקט IFencedExecutionCallback כדי לשלוח שאילתה על מידע על סטטוס שגיאה ועל משך הזמן.

לאחר השלמת הביצוע, ערכים של תזמון למדידת משך הביצוע, אפשר לשלוח שאילתות IFencedExecutionCallback::getExecutionInfo.

• timingLaunched: משך הזמן מההפעלה של executeFenced ועד executeFenced מציין את ה-syncFence שהוחזר.
• timingFenced: משך הזמן מהרגע שבו כל גדרות הסנכרון שההפעלה בהמתנה מסומנת כאשר האותות של executeFenced syncFence שהוחזר.

זרימת בקרה

במכשירים עם Android מגרסה 11 ואילך, ה-NNAPI כוללת שתי פעולות בקרה, IF ו-WHILE, שמשתמשות במודלים אחרים כארגומנטים ולבצע אותם באופן מותנה (IF) או שוב ושוב (WHILE). עבור כדי לקבל מידע נוסף בנושא: תהליך בקרה.

איכות השירות

ב-Android 11, ה-NNAPI כולל איכות משופרת של (QoS) באמצעות מתן אפשרות לאפליקציה לציין את סדר העדיפויות היחסי שלה משך הזמן המקסימלי הצפוי להכנה של מודל, משך הזמן המקסימלי הצפוי להשלמת הביצוע. עבור מידע נוסף: איכות השירות.

ניקוי

כשאפליקציה מסיימת להשתמש במודל מוכן, ה-framework נשלח ההתייחסות שלו @1.3::IPreparedModel לאובייקט. כשאין יותר הפניה לאובייקט IPreparedModel, הוא האפליקציה תושמד באופן אוטומטי בשירות הנהג שיצר אותה. ספציפי לדגם זמינים כרגע לנהג במסגרת היישום של והשמדת בינה מלאכותית. אם שירות הנהג רוצה שהאובייקט IPreparedModel יהיה הוא יושמד אוטומטית כשהלקוח לא צריך אותו יותר, אסור לו להחזיק כל הפניה לאובייקט IPreparedModel אחרי האובייקט IPreparedeModel הוחזרה דרך IPreparedModelCallback::notify_1_3.

שימוש במעבד

על מנהלי ההתקנים להשתמש במעבד (CPU) כדי להגדיר חישובים. אסור לנהגים להשתמש במעבד (CPU) כדי לבצע חישובי תרשימים כי זה מפריע את היכולת של ה-framework להקצות עבודה בצורה נכונה. הנהג/ת צריך/ה לדווח על כך את החלקים שהיא לא יכולה לטפל בהם ב-framework, והם מאפשרים ל-framework לטפל מנוחה.

ה-framework מספק הטמעה של מעבד (CPU) לכל הפעולות של NNAPI, מלבד והפעולות שהוגדרו על ידי הספק. מידע נוסף זמין במאמר הבא: תוספי ספקים.

פעולות שנוספו ב-Android 10 (רמת API 29) יש יישום של המעבד (CPU) המקורי רק כדי לאמת שבדיקות ה-CTS ו-VTS. הם נכונים. ההטמעות האופטימליות שכלולות בלמידת מכונה לנייד frameworks עדיפויות על פני הטמעת מעבד (CPU) של NNAPI.

פונקציות עזר

בסיס הקוד של NNAPI כולל פונקציות שימושיות שבהן מנהל ההתקן יכול להשתמש שירותים שונים.

frameworks/ml/nn/common/include/Utils.h מכיל פונקציות שונות של כלי שירות, כמו פונקציות המשמשות לרישום ביומן להמרה בין גרסאות NN HAL שונות.

• VLogging: VLOG הוא מאקרו wrapper מסביב ל-LOG של Android, שרק רושם את ההודעה אם התג המתאים מוגדר ב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 הקובץ מכיל פקודות מאקרו כדי להוסיף בקלות systracing של מידע לקוד של רשתות נוירונים. לדוגמה, אפשר לראות את הפעלות המאקרו NNTRACE_* מנהל התקן לדוגמה.

frameworks/ml/nn/common/include/GraphDump.h מכיל פונקציית שירות להעלאת התוכן של Model בתרשים למטרות ניפוי באגים.

• graphDump: כתיבת ייצוג של המודל ב-Gerviz (.dot) לפורמט של השידור שצוין (אם צוין) או ל-Logcat (אם לא סופק שידור).

אימות

כדי לבדוק את ההטמעה של ה-NNAPI, צריך להשתמש בבדיקות VTS ו-CTS שכלולות ב- המסגרת של Android. VTS מפעיל את הנהגים ישירות (בלי להשתמש CTS), ואילו CTS מיישם אותם באופן עקיף דרך המסגרת. האלה לבדוק כל method של API ולוודא שכל הפעולות הנתמכות על ידי פועלים בצורה תקינה ומספקים תוצאות שעומדות בדרישות הדיוק.

אלה דרישות הדיוק ב-CTS וב-VTS עבור NNAPI:

• נקודה צפה (floating-point): AB(CPV - Actual) <= atol + rtol * AB(expected); איפה:

  • ל-fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
  • ל-fp16, atol = rtol = 5.0f * 0.0009765625f

• כמותית: כל אחד בנפרד (חוץ מאשר mobilenet_quantized, כלומר עד 3 פעמים)

• בוליאני: התאמה מדויקת

אחת הדרכים שבהן CTS בודק NNAPI היא באמצעות יצירת גרפים פסאודונימים קבועים שמשמש לבדיקה ולהשוואה של תוצאות הביצוע של כל נהג הטמעת קובצי עזר של NNAPI. לנהגים עם NN HAL 1.2 ואילך, אם התוצאות לא עומדות בקריטריונים לדיוק, CTS מדווח על שגיאה וטוען קובץ מפרט למודל שנכשל במסגרת /data/local/tmp לניפוי באגים. לפרטים נוספים על הקריטריונים לקביעת דיוק, ראו TestRandomGraph.cpp וגם TestHarness.h

בדיקת Fuzz

המטרה של בדיקת fuzz היא למצוא קריסות, טענות נכונות (assertions), הפרות זיכרון, או התנהגות לא מוגדרת כללית בקוד הנבדק, בגלל גורמים כמו שאינם צפויים. לבדיקת fuzz של NNAPI, מערכת Android משתמשת בבדיקות שמבוססות על libFuzzer, יעיל ב-fuzzing כי הם משתמשים בכיסוי שורות של מקרי בדיקה קודמים כדי ליצור קלט אקראי חדש. לדוגמה, ב-libFuzzer יש העדפה למקרי בדיקה שרצים בשורות קוד חדשות. כך אפשר לצמצם משמעותית את משך הזמן שנדרש כדי למצוא קוד בעייתי.

כדי לבצע בדיקת fuzz (בדיקת fuzz) כדי לאמת את ההטמעה של מנהל ההתקן, משנים את frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp בכלי הבדיקה libneuralnetworks_driver_fuzzer שנמצא ב-AOSP כדי לכלול את קוד הנהג/ת. למידע נוסף על בדיקת fuzz של NNAPI, ראו frameworks/ml/nn/runtime/test/android_fuzzing/README.md

אבטחה

האפליקציה מעבדת תקשורת ישירות עם התהליך של הנהג, מנהלי התקנים חייבים לאמת את הארגומנטים של השיחות שהם מקבלים. האימות הזה מאומת על ידי VTS. קוד האימות נמצא ב- frameworks/ml/nn/common/include/ValidateHal.h

הנהגים צריכים גם לוודא שאפליקציות לא יוכלו להפריע בזמן השימוש באותו מכשיר.

חבילת הכלים לבדיקת למידת מכונה ב-Android

חבילת Android Machine Learning Test Suite (MLTS) היא נקודת השוואה ל-NNAPI שכלולה ב- CTS ו-VTS לאימות הדיוק של מודלים אמיתיים במכשירים של ספקים. מידע על זמן האחזור והדיוק, והשוואה בין הנהגים תוצאות עם את התוצאות בעזרת TF Lite שרץ במעבד. בשביל אותו מודל ומערכי נתונים. כך אפשר לוודא שהנהג לא מדויק יותר גרועה מהטמעה של הפניה למעבד (CPU).

מפתחים של פלטפורמת Android משתמשים גם ב-MLTS כדי להעריך את זמן האחזור והדיוק של נהגים.

נקודת ההשוואה של NNAPI נמצאת בשני פרויקטים ב-AOSP:

• platform/test/mlts/benchmark (אפליקציית השוואה)
• platform/test/mlts/models (מודלים ומערכי נתונים)

מודלים ומערכי נתונים

נקודת ההשוואה של NNAPI משתמשת במודלים ובמערכי הנתונים הבאים.

• MobileNetV1 צף ו-u8 כמותו בגדלים שונים, פועלים מול קבוצת משנה קטנה (1,500 תמונות) של מערך הנתונים של תמונות פתוחות בגרסה 4.
• MobileNetV2 צף ו-u8 כמותו בגדלים שונים, פועלים מול קבוצת משנה קטנה (1,500 תמונות) של מערך הנתונים של תמונות פתוחות בגרסה 4.
• מודל אקוסטי מבוסס-זיכרון לטווח קצר (LSTM) להמרת טקסט לדיבור, פועלים מול קבוצת משנה קטנה של הקבוצה הארקטי של CMU.
• מודל אקוסטי מבוסס 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 של רשתות נוירונים

בקטע הזה מתוארים השינויים שבוצעו ב-Android ובנוירונים גרסאות 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 לא תומכת באופרנדים חתומים ארבע הפעולות האחרות תומכות בקוונטיזציה חתומה אבל לא דורשות יהיו זהות.
• תמיכה בפעולות מגודרות שבהן ה-framework קורא IPreparedModel::executeFenced להפעלת הפעלה מגודרת ואסינכרונית במודל מוכן עם של גדרות סנכרון שצריך להמתין לו. מידע נוסף זמין במאמר הבא: הרצה מגודרת.
• תמיכה בתהליך הבקרה. הוספה של הפעולות IF ו-WHILE, שלוקחתות מודלים אחרים כארגומנטים והפעלה שלהם באופן מותנה (IF) או שוב ושוב (WHILE). מידע נוסף זמין במאמר הבא: תהליך בקרה.
• איכות שירות משופרת (QoS) כי אפליקציות יכולות לציין את סדר העדיפויות של המודלים, ומשך הזמן המקסימלי הצפוי להיות מוכן, וכמות הזמן המקסימלית הצפויה שצריך לבצע. מידע נוסף זמין במאמר הבא: איכות השירות.
• תמיכה בדומיינים של זיכרון שמספקים ממשקים של מקצים עבור חוצצים בניהול הנהג. הפעולה הזו מאפשרת להעביר זיכרונות מקומיים במכשיר ביצוע תהליכים שונים, תוך מניעת העתקה וטרנספורמציה לא נחוצות של נתונים בין הפעלות רצופות לאותו מנהל התקן. לקבלת מידע נוסף, ראו דומיינים של זיכרון.

10 Android

ב-Android 10 אנחנו משיקים את NN HAL 1.2, שכולל את בעקבות שינויים חשובים.

• המבנה Capabilities כולל את כל סוגי הנתונים, כולל סקלריות ומייצג ביצועים לא קשורים באמצעות וקטור מאשר שדות בעלי שם.
• ה-methods getVersionString ו-getType מאפשרות ל-framework אחזור סוג המכשיר (DeviceType) ופרטי הגרסה. צפייה גילוי והקצאה של מכשירים.
• השיטה executeSynchronously נקראת כברירת מחדל כדי לבצע באופן סינכרוני. ה-method execute_1_2 מנחה את המסגרת תבצעו הפעלה באופן אסינכרוני. פרטים נוספים מופיעים בקטע ביצוע.
• הפרמטר MeasureTiming ל-executeSynchronously, execute_1_2, וביצוע רצף נתונים מציין אם הנהג נועד למדוד את הביצוע משך הזמן. התוצאות מדווחות במבנה Timing. צפייה תזמון.
• תמיכה בפעולות שבהן אופרנד פלט אחד או יותר הוא לא ידוע מאפיין או דירוג. ראו צורת פלט.
• תמיכה בתוספי ספקים, שהם אוספים של פרמטרים שהוגדרו על ידי הספק פעולות וסוגי נתונים. הנהג מדווח על תוספים נתמכים דרך השיטה IDevice::getSupportedExtensions. צפייה תוספי ספקים.
• היכולת של אובייקט רצף (bursts) לשלוט בקבוצה של הפעלות רצפים באמצעות תורי הודעות מהירים (FMQ) לתקשורת בין האפליקציה לנהג תהליכים וכך לקצר את זמן האחזור. צפייה פעולות של רצף הודעות ותורים של הודעות מהירות.
• תמיכה ב-AHardwareBuffer כדי לאפשר לנהג לבצע הפעלות מבלי להעתיק נתונים. צפייה AHardwareBuffer
• תמיכה משופרת בשמירה במטמון של ארטיפקטים של הידור (compilation) כדי לקצר את משך הזמן שמשמש להידור כשאפליקציה מופעלת. צפייה שמירה במטמון של הידור במטמון.

ב-Android 10 מוצגים סוגי האופרנד הבאים וגם ב-AI.

• סוגי אופציות

  • 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 מופיעים עדכונים להרבה אפליקציות קיימות ב-AI. העדכונים הם קשורים בעיקר לנושאים הבאים:

• תמיכה בפריסת הזיכרון של NCHW
• תמיכה בטנזטורים עם דירוג שונה מ-4 ב-softmax פעולות נירמול
• תמיכה בקיפולים מורחבים
• תמיכה בקלט עם קוונטיזציה מעורבת ANEURALNETWORKS_CONCATENATION

הרשימה הבאה מציגה את הפעולות שהשתנו ב- Android 10. לתוכנית מלאה מפרטים של השינויים, OperationCode במשאבי העזרה של 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 Android

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 STR כולל את השדה הנוסף relaxedFloat32toFloat16Performance, כדי שהנהג יוכל לדווח למסגרת על הביצועים הרגועים שלה.

Android מגרסה 8.1

הגרסה הראשונית של Neural Networks HAL (1.0) הושקה ב-Android 8.1. לקבלת מידע נוסף מידע נוסף, ראה /neuralnetworks/1.0/