משתמשי LiteRT

משתמשים שקיבלו הרשאה מאפשרים האצת חומרה של דגמי LiteRT באמצעות שימוש מאיצים במכשיר כמו ה-GPU ומעבד האותות הדיגיטליים (DSP).

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

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

לכל אחד מהמאיצים האלה יש ממשקי API שמאפשרים חישובים מותאמים אישית, כמו OpenCL או OpenGL ES ל-GPU בנייד. בדרך כלל, כדי לכתוב הרבה קוד מותאם אישית כדי להריץ רשת נוירונים דרך הממשקים האלה. העניין מסתבך עוד יותר כשחושבים שלכל מאיץ יש יתרונות ו חסרונות ולא יכולים לבצע כל פעולה ברשת נוירונים. TensorFlow הענקת API של Lite פותרת את הבעיה הזו על ידי שימוש כגשר בין TFLite זמן הריצה וממשקי ה-API האלה ברמה נמוכה יותר.

בחירת נציג מורשה

ב-LiteRT יש תמיכה במספר צירים, שכל אחד מהם מותאם פלטפורמות מסוימות וסוגים מסוימים של מודלים. בדרך כלל יש כמה נציגים רלוונטיים לתרחיש לדוגמה שלכם, בהתאם לשני קריטריונים עיקריים: הפלטפורמה (Android או iOS?) שאליה מטרגטים, וסוג המודל (נקודה צפה או כמותית?) שאתם מנסים להאיץ.

משתמשים עם הרשאות גישה לפי פלטפורמה

בפלטפורמות שונות (Android ו-iOS)

• מקבל הגישה ל-GPU - אפשר להשתמש במקבל ההרשאה ל-GPU גם ב-Android וגם ב-iOS. הוא מותאמת להפעלת מודלים מבוססי-צף של 32 סיביות ו-16 סיביות שבהם ה-GPU זמינים. הוא תומך גם במודלים כמותיים של 8 ביט ומספק GPU ביצועים בהשוואה לגרסאות הצפות שלהן. פרטים על ה-GPU ראו את המאמר LiteRT ב-GPU.

iOS

• נציג ליבה ללמידת מכונה (Core ML) במכשירי iPhone ו-iPad חדשים יותר – במכשירי iPhone ו-iPad חדשים יותר במכשירי iPad שבהם הנוירונים זמין, אפשר להשתמש בהרשאת הגישה של Core ML לזרז את ההסקת מסקנות לגבי מודלים של נקודה צפה (floating-point) של 32 ביט או 16 ביט. Neural המנוע זמין למכשירים ניידים של Apple עם A12 SoC ומעלה. עבור בסקירה הכללית על תהליך העברת ההרשאות של Core ML והוראות מפורטות, ראו בעל הרשאה ל-LiteRT Core ML.

משתמשים עם הרשאות גישה לפי סוג מודל

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

מתבצע אימות של הביצועים

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

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

כלים להערכה

זמן אחזור טביעת הרגל הפחמנית

אפשר להשתמש בכלי ההשוואה לשוק של LiteRT עם פרמטרים מתאימים להערכת ביצועי המודל, כולל אומדן ממוצע זמן אחזור, תקורת אתחול, טביעת רגל של זיכרון וכו'. כלי זה תומך כדי להבין מהי התצורה הטובה ביותר להענקת גישה למודל שלכם, עבור את המופע, אפשר לציין את --gpu_backend=gl באמצעות --use_gpu כדי למדוד GPU הפעלה באמצעות OpenGL. הרשימה המלאה של הפרמטרים הנתמכים להענקת גישה מוגדרות בשלב המפורט תיעוד.

הנה דוגמה להרצה של מודל כמותי עם GPU דרך adb:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

אפשר להוריד גרסה מוכנה מראש של הכלי הזה ל-Android, בגרסת 64 ביט ARM אדריכלות כאן (עוד פרטים).

דיוק ו תיקון

משתמשים עם הרשאות גישה לערוץ מבצעים בדרך כלל חישובים ברמת דיוק שונה מזו של המעבד (CPU) שלהם המקבילים להם. כתוצאה מכך, יש השוואה (בדרך כלל משנית) של רמת הדיוק המשויך לשימוש בהאצלת חומרה לצורך האצת חומרה. לתשומת ליבכם: לא נכון תמיד, למשל, כי ה-GPU משתמש ברמת דיוק בנקודה צפה (floating-point) במודלים כמותיים, עשוי להיות שיפור קל ברמת הדיוק (למשל, יש שיפור של פחות מ-1% בסיווג התמונות של ILSVRC – 5% המובילים).

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

הערכה מבוססת-משימה

ב-LiteRT יש כלים להערכת הנכונות של שתי משימות מבוססות-תמונה:

• ILSVRC 2012 (תמונה) סיווג) עם Top-K דיוק

• זיהוי אובייקטים של COCO (עם תיבות תוחמות) עם דיוק ממוצע ממוצע (mAP)

קבצים בינאריים מוכנים מראש של הכלים האלה (Android, ארכיטקטורת ARM בגרסת 64 ביט), יחד עם התיעוד זמין כאן:

• סיווג תמונות של ImageNet (עוד פרטים) * אובייקט COCO זיהוי (עוד פרטים)

הדוגמה הבאה מציגה סיווג תמונות הערכה עם GPU ב-Pixel 4:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

הפלט הצפוי הוא רשימה של המדדים המובילים מ-1 עד 10:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

הערכה אגנוסטית של המשימה

למשימות שבהן אין כלי הערכה במכשיר, או מתנסים במודלים מותאמים אישית, ב-LiteRT יש את הפונקציה הבדלים של Google. (Android, ארכיטקטורה בינארית של ARM 64 סיביות כאן)

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

• מסקנות מעבד (CPU) עם שרשור יחיד
• מסקנות בהגדרת המשתמש – מוגדרת על ידי הפרמטרים האלה

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

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

במודל עם משתנה פלט יחיד, הפלט עשוי להיראות כך:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

כלומר, בשביל tensor פלט באינדקס 0, הרכיבים מ- הפלט של המעבד (CPU) שונה מהפלט של בעל הגישה ב-1.96e-05 בממוצע.

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