NPU manager

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

רקע ומוטיבציה

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

• תחרות לא יעילה על משאבים: עומסי עבודה כבדים של למידת מכונה (כמו מנועי הסקה של מודלים גדולים של שפה (LLM) או מערכות ראייה במכשיר) התחרו ישירות עם מערכות אחרות בעדיפות גבוהה על משאבי NPU מוגבלים (כמו SRAM, זיכרון משקלים וערוצי ביצוע).
• חוסר יציבות במערכת: עומסי עבודה לא מתואמים עלולים להפעיל הגבלת מהירות (throttling) תרמית, שגיאות בדפי זיכרון או דמון (daemon) של מנגנון להפסקת תהליכים במקרה של מחסור בזיכרון (LMKD), אם הדרישות חורגות מיכולת החומרה.
• תעדוף לא יעיל: שרת המערכת לא יכול לשנות את העדיפות של ה-NPU בתגובה לשינויים בהקשר, כמו טעינה של מודל גדול על ידי משימת רקע בזמן שצינור מצלמה או עוזר משתמש רגיש לזמן אחזור פעיל בחזית.

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

ארכיטקטורת המערכת

ה-NPU Manager מיושם כשירות מערכת בשם npu שפועל במסגרת Android. ה-NPU Manager מבודד את התיאום ברמה הגבוהה של מדיניות התזמון מההטמעה ברמה הנמוכה של מנהל ההתקן של הספק.

התרשים הבא ממחיש את השכבות של סביבת NPU Manager:

איור 1. שכבות סביבה ב-NPU Manager.

רכיבים מרכזיים

• Framework API Client (android.npumanager.NpuManager): נקודת הכניסה שמשמשת את הלקוחות לבקשת הזמנות לטעינת מודלים
• שירות מערכת (npu): שירות מערכת שמונע אישורים לטעינת מודלים ומנהל פקודות קדימה על סמך כללי עדיפות בתזמון
• ‫NPU Scheduling HAL (android.hardware.npu): ממשק מבוסס AIDL שמעביר קריאות חוזרות של עדיפויות אפליקציות Android בין המסגרת לבין מנהל ההתקן
• Vendor driver: מנהל התקן ברמה נמוכה ששולט בבלוקים של ביצוע החומרה ומטמיע מנגנוני תעדוף ברמה נמוכה

‫SDK ו-API של מסגרת

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

בקשה לטעינת מודל

בקשה לטעינת מודל מיוצגת על ידי ModelLoadRequest. האובייקט הזה מכיל:

• מזהה בקשה ייחודי
• גודל משוער של המודל, למשל NPU_MODEL_SIZE_LESS_THAN_1GB או NPU_MODEL_SIZE_GREATER_THAN_2G
• העדיפות המיועדת, כמו NPU_MODEL_PRIORITY_BACKGROUND,‏ NPU_MODEL_PRIORITY_NORMAL או NPU_MODEL_PRIORITY_OPPORTUNISTIC

בדוגמת הקוד הבאה נוצר ModelLoadRequest עם מגבלת גודל של יותר מ-2 GB ועדיפות ביצוע רגילה:

ModelLoadRequest request = new ModelLoadRequest.Builder(requestId)
        .setSize(NPU_MODEL_SIZE_GREATER_THAN_2G)
        .setPriority(NPU_MODEL_PRIORITY_NORMAL)
        .build();

תהליך הבקשה והאישור

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

npuManager.requestCanLoadModel(request, callback, executor);

כשמשאבי NPU זמינים, המסגרת מגיבה באמצעות ModelLoadRequestCallback עם האירועים הבאים:

• ‫onCanLoadModel(request, status, listener): מופעל כשהבקשה מאושרת. הלקוח מקבל טוקן NpuManager.ModelLoadStatusListener אחרי שהלקוח טוען את המודל באופן מלא בזיכרון של מנהל ההתקן, הוא חייב לקרוא ל-listener.notifyModelLoaded(request).
• ‫onRequestUnloadModel(request) או onRequestUnloadModel(request, reason): האירוע מופעל כשיש עומס על משאבי המערכת (למשל, בקשה להפעלה ברקע או עלייה חדה בטמפרטורה) והמערכת דורשת מהלקוח לשחרר את המודל. אחרי שמשחררים את משאבי ה-NPU, הלקוח קורא ל-listener.notifyModelUnloaded(request).
• ‫onModelLoadRequestComplete(request, status): מודיע ללקוח על שינויים סופיים במחזור החיים של הבקשה, כמו ביטול.

לקוחות יכולים לבטל הזמנות בהמתנה באמצעות cancelModelLoad(request).

שילוב של HAL וספקים

כדי לתמוך ב-NPU Manager, הטמעות ספציפיות למכשיר של ספקים צריכות להיות תואמות לממשקי השירות של android.hardware.npu AIDL.

הגדרת התזמון

המערכת מעבירה את העדיפות של האפליקציה באמצעות SchedulingConfig AIDL,‏ SchedulingConfig מבנה AIDL שמוגדר ב-IScheduling.aidl:

package android.hardware.npu;

@VintfStability
parcelable SchedulingConfig {
    int minPriority;
    int maxPriority;
    int uid;
    int appPriority;
    boolean hasDirectAccess;
    boolean canAttributeOtherUid;
}

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

סטטוס המשימה ופרופיל

מנהלי התקנים של ספקים צריכים לדווח למנהל על סטטוס מחזור החיים של קבוצות ביצוע של NPU. ‫WorkInfo עוקב אחרי המשימות (מוגדרות ב-WorkInfo.aidl):

package android.hardware.npu;

import android.hardware.npu.NpuUuid;

@VintfStability
parcelable WorkInfo {
    int id;
    @nullable NpuUuid groupId;
    int uid;
    int debugPid;
    int originalUid;
    @nullable String debugFeatureId;
    int jobPriority;
    int effectivePriority;
    long timestampMs;
    int deviceNumber;
}

ביטול כפילויות של אירועים

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

מצבי מחזור החיים של הקריאה החוזרת מדווחים באופן הבא:

• ‫onWorkRequested: עומס העבודה מתווסף לתור על ידי שירות הספק.
• ‫onWorkStarted: הביצוע של עומס העבודה מתחיל.
  • ‫NPU_START_REASON_INITIAL: הפעלת הביצוע הראשונה.
  • ‫NPU_START_REASON_RESUMED: ההפעלה חודשה אחרי שהייתה קדימות.
• ‫onWorkEnded: הביצוע של עומס העבודה הסתיים.
  • ‫NPU_END_REASON_COMPLETED: השלמת ההרצה בהצלחה.
  • ‫NPU_END_REASON_CANCELLED_USER: בוטל על ידי הלקוח.
  • NPU_END_REASON_CANCELLED_SYSTEM: נדחית על ידי מדיניות המערכת.
  • ‫NPU_END_REASON_FAILED: שגיאת הפעלה או כשל בדרייבר.
  • NPU_END_REASON_PAUSED: מושעה באופן זמני לטובת משימות בעדיפות גבוהה יותר.

מוכנות המכשיר ובדיקות

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

הצהרות לגבי אפליקציות

לקוחות שרוצים לתת עדיפות לתזמון של NPU צריכים להצהיר על תכונת החומרה של NPU בקובץ AndroidManifest.xml שלהם:

<uses-feature android:name="android.hardware.npu" android:required="false" />

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

בדיקות שילוב של VTS

אפשר לאמת הטמעות של NPU HAL באמצעות בדיקות פונקציונליות של VTS, לדוגמה, VtsHalNpuSchedulingTargetTest.