NPU 管理員

Android 17 以上版本支援神經處理單元 (NPU) 管理工具 (com.android.npumanager)，可協調系統服務和應用程式工作負載之間的 NPU 資源分配和排程。NPU 管理器將資源仲裁從自訂供應商精靈移至 Android 平台，可提高可預測性、防止資源不足、管理熱邊界，並提升整體裝置效能。

背景和動機

在 NPU Manager 推出前，應用程式和系統模組會直接將工作負載提交給供應商驅動程式或專屬服務。這種做法有幾個缺點：

  • 資源競爭效率不彰：大型語言模型 (LLM) 推論引擎或裝置端視覺系統等機器學習工作負載繁重，會直接與其他高優先順序系統爭奪有限的 NPU 資源 (例如 SRAM、權重記憶體和執行通道)。
  • 系統不穩定：如果需求超出硬體容量，未協調的工作負載可能會觸發熱節流、記憶體頁面錯誤或低記憶體終止精靈 (LMKD)。
  • 優先順序設定效率不彰：系統伺服器無法因應情境變化調整 NPU 優先順序，例如在背景工作載入大型模型時，延遲敏感型攝影機管道或使用者助理正在前景中運作。

NPU 管理工具會做為系統層級的仲裁者，控管模型載入作業，並根據目前的裝置健康狀態和應用程式狀態，動態調整執行優先順序，藉此解決這些挑戰。

系統架構

NPU 管理工具會以系統服務的形式實作，名稱為 npu，在 Android 架構中執行。NPU 管理工具會將排程政策的高層級協調作業，與低層級供應商驅動程式實作作業隔開。

下圖說明 NPU 管理員環境層：

NPU Manager 環境層

圖 1. NPU 管理工具環境層。

重要元件

  • 架構 API 用戶端 (android.npumanager.NpuManager)：用戶端用來要求模型載入預訂的進入點
  • 系統服務 (npu)：根據排程優先順序規則，控管模型載入核准程序及管理搶占指令的系統服務
  • NPU 排程 HAL (android.hardware.npu)：以 AIDL 為基礎的介面，可在架構和驅動程式之間轉送 Android 應用程式優先順序回呼。
  • 供應商驅動程式：控制硬體執行區塊並實作低階優先順序機制的低階驅動程式

SDK 和架構 API

呼叫低階神經網路程式庫或載入模型檔案前，架構用戶端必須與 NpuManager 服務互動。如要執行這項操作，用戶端必須先定義模型載入要求，然後執行要求和核准流程。

模型載入要求

模型載入要求以 ModelLoadRequest 表示。這個物件包含：

  • 不重複的要求 ID
  • 預估模型大小類別，例如 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 管理工具，特定裝置的供應商實作項目必須符合 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 執行作業，用戶端必須在 AndroidManifest.xml 中宣告 NPU 硬體功能：

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

如果模型部署在較新一代的合作夥伴硬體上，可能需要這項聲明才能建立最佳引擎。

VTS 整合測試

您可以使用 VTS 功能測試驗證 NPU HAL 實作項目，例如 VtsHalNpuSchedulingTargetTest。