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