مدیر NPU

Android 17 و نسخه‌های بالاتر از «مدیر واحد پردازش عصبی» (NPU) (com.android.npumanager) پشتیبانی می‌کند که تخصیص و زمان‌بندی منابع NPU را در سراسر سرویس‌های سیستم و حجم کاری برنامه‌ها هماهنگ می‌کند. با انتقال داوری منابع از دیمون‌های فروشنده سفارشی به پلاتفرم Android، «مدیر NPU» پیش‌بینی‌پذیری را افزایش می‌دهد، از کمبود منابع جلوگیری می‌کند، مرزهای حرارتی را مدیریت می‌کند، و عملکرد کلی دستگاه را بهبود می‌بخشد.

پیشینه و انگیزه

قبل‌از «مدیر NPU»، برنامه‌ها و واحدهای سیستم مستقیماً حجم‌های کاری را به درایورهای فروشنده یا خدمات اختصاصی ارسال می‌کردند. این رویکرد چندین اشکال داشت:

• رقابت ناکارآمد برای منابع: حجم‌های کاری سنگین یادگیری ماشین (مانند موتورهای استنتاج مدل زبانی بزرگ (LLM) یا سیستم‌های بینایی درون‌دستگاهی) مستقیماً با دیگر سیستم‌های دارای اولویت بالا برای منابع محدود NPU (مانند SRAM، حافظه وزن‌ها، و کانال‌های اجرا) رقابت می‌کردند.
• بی‌ثباتی سیستم: اگر بار کاری هماهنگ نباشد و تقاضا از ظرفیت سخت‌افزار فراتر رود، ممکن است باعث محدود شدن حرارتی، خطاهای صفحه حافظه، یا فعال شدن «دیو بستن ناشی از کمبود حافظه» (LMKD) شود.
• اولویت‌بندی ناکارآمد: سرور سیستم نمی‌تواند اولویت NPU را در پاسخ به تغییرات بافت تنظیم کند، مثلاً وقتی یک تکلیف پس‌زمینه درحال بار کردن یک مدل عظیم است و هم‌زمان یک خط لوله دوربین حساس به تأخیر یا دستیار کاربر در پیش‌زمینه فعال است.

«مدیر NPU» با ایفای نقش به‌عنوان داور سطح سیستم، این چالش‌ها را برطرف می‌کند که بارگذاری مدل را کنترل می‌کند و اولویت‌های اجرا را براساس وضعیت سلامت فعلی دستگاه و وضعیت برنامه‌ها به‌صورت پویا تنظیم می‌کند.

معماری سیستم

«مدیر NPU» به‌عنوان سرویس سیستمی به‌نام npu که در چارچوب Android اجرا می‌شود پیاده‌سازی شده است. «مدیر NPU» هماهنگی سطح بالای خط‌مشی‌های زمان‌بندی را از پیاده‌سازی درایور فروشنده سطح پایین جدا می‌کند.

نمودار زیر لایه‌های محیط «مدیر NPU» را نشان می‌دهد:

شکل ۱. لایه‌های محیط «مدیر NPU».

عناصر اصلی

• کارخواه میانای برنامه‌سازی کاربردی چارچوب (android.npumanager.NpuManager): نقطه ورودی مورد استفاده کارخواهان برای درخواست رزرو بار مدل
• خدمات سیستم (npu): خدمات سیستمی که تأییدیه‌های بار مدل را دروازه‌بانی می‌کند و براساس قوانین اولویت زمان‌بندی، دستورات پیش‌گیری را مدیریت می‌کند
• ‫NPU Scheduling HAL (android.hardware.npu): میانای مبتنی بر AIDL که بازخوان اولویت‌های برنامه Android و تماس‌های برگشتی بین چارچوب و درایور است
• گرداننده فروشنده: گرداننده سطح پایینی که اجرای سخت‌افزار را کنترل می‌کند و سازوکارهای اولویت‌بندی سطح پایین را پیاده‌سازی می‌کند

کیت توسعه نرم‌افزار و میانای برنامه‌سازی کاربردی چارچوب

پیش‌از فراخوانی کتابخانه‌های شبکه عصبی سطح پایین یا بار کردن فایل‌های مدل، کاربران چارچوب باید با سرویس 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 را با حد مجاز اندازه بزرگ‌تر از ۲ گیگابایت و اولویت اجرای عادی می‌سازد:

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»، پیاده‌سازی‌های فروشنده مختص دستگاه باید با میاناهای سرویس 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» هماهنگی‌های اولویت را هماهنگ می‌کند. برای مثال، اگر برنامه پس‌زمینه‌ای کار با اولویت بالا ارسال کند، اولویت آن به پایین‌تر تنظیم می‌شود تا با گرافیک پیش‌زمینه تداخل نداشته باشد.

وضعیت تکلیف و نمایه‌سازی

گردانندگان فروشنده باید وضعیت چرخه عمر گروه‌های اجرای 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، اعتبارسنجی کرد.