مدیر NPU

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

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

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

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

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

معماری سیستم

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

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

شکل 1. لایه‌های محیط مدیریت NPU.

اجزای کلیدی

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

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 با محدودیت اندازه بیش از ۲ گیگابایت و اولویت اجرای معمولی می‌سازد:

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 در ثبت فراخوانی زمان‌بندی، از حذف رویداد (event debouncing) پشتیبانی می‌کند. این کار از سیل لاگ‌ها (log flooding) جلوگیری می‌کند و اعلان‌های سریع، مانند رویدادهای شروع و پایان متوالی برای مدل‌های تکراری را سرکوب می‌کند.

وضعیت چرخه حیات فراخوانی به صورت زیر گزارش می‌شود:

• 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 ، اعتبارسنجی کرد.