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

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

למידע נוסף על ה-API של רשתות עצביות, ראה API של רשתות עצביות .

רשתות עצביות HAL

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

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

רשתות עצביות זורמות

איור 1. זרימת רשתות עצביות

אִתחוּל

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

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

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

באנדרואיד 9 ומטה, מבנה Capabilities כולל מידע על ביצועי דרייבר רק עבור נקודה צפה וטנזורים כמותיים ואינו כולל סוגי נתונים סקלרים.

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

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

הַהדָרָה

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

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

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

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

צורת פלט

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

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

תִזמוּן

באנדרואיד 10, אפליקציה יכולה לבקש את זמן הביצוע אם האפליקציה ציינה מכשיר בודד לשימוש במהלך תהליך ההידור. לפרטים, ראה MeasureTiming וגילוי והקצאת התקנים . במקרה זה, מנהל התקן NN HAL 1.2 חייב למדוד את משך הביצוע או לדווח על UINT64_MAX (כדי לציין כי משך הזמן אינו זמין) בעת ביצוע בקשה. על הנהג למזער כל עונש ביצוע הנובע ממדידת משך הביצוע.

הנהג מדווח על משכי הזמן הבאים במיקרו-שניות במבנה Timing :

  • זמן ביצוע במכשיר: לא כולל זמן ביצוע במנהל ההתקן, שפועל על המעבד המארח.
  • זמן ביצוע במנהל ההתקן: כולל זמן ביצוע במכשיר.

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

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

הוצאה להורג מגודרת

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

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

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

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

בקרת זרימה

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

איכות השירות

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

לנקות

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

שימוש במעבד

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

המסגרת מספקת מימוש CPU עבור כל פעולות NNAPI למעט פעולות המוגדרות על ידי הספק. למידע נוסף, ראה הרחבות ספקים .

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

פונקציות שירות

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

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

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

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

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

מַתַן תוֹקֵף

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

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

  • נקודה צפה: abs(expected - actual) <= atol + rtol * abs(expected); איפה:

    • עבור fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
    • עבור fp16, atol = rtol = 5.0f * 0.0009765625f

  • Quantized: off-by-one (למעט mobilenet_quantized , שהוא off-by-three)

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

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

בדיקת פאז

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

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

מפתחי פלטפורמת אנדרואיד משתמשים גם ב-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 Machine Learning Test Suite כוללת סדרה של מבחני ריסוק כדי לאמת את החוסן של נהגים בתנאי שימוש כבדים או במקרים פינתיים של התנהגות לקוחות.

כל מבחני הריסוק מספקים את התכונות הבאות:

  • זיהוי תליה: אם לקוח 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 לתוך ספריית המקור ברמה העליונה של אנדרואיד.

    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 של Neural Networks

סעיף זה מתאר את השינויים שהוכנסו בגרסאות Android ו- Neural Networks HAL.

אנדרואיד 11

אנדרואיד 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

אנדרואיד 10 מציגה את NN HAL 1.2, הכולל את השינויים הבולטים הבאים.

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

אנדרואיד 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

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

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

הרשימה למטה מציגה את הפעולות ששונו באנדרואיד 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

NN HAL 1.1 הוצג באנדרואיד 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 הראשוני של Neural Networks (1.0) שוחרר באנדרואיד 8.1. למידע נוסף, ראה /neuralnetworks/1.0/ .