Pengelola NPU

Android 17 dan yang lebih tinggi mendukung Pengelola Unit Pemrosesan Neural (NPU) (com.android.npumanager), yang mengoordinasikan alokasi dan penjadwalan resource NPU di seluruh layanan sistem dan workload aplikasi. Dengan memindahkan arbitrase resource dari daemon vendor kustom ke platform Android, NPU Manager meningkatkan prediktabilitas, mencegah kekurangan resource, mengelola batas termal, dan meningkatkan performa perangkat secara keseluruhan.

Latar belakang dan motivasi

Sebelum NPU Manager, aplikasi dan modul sistem mengirimkan workload langsung ke driver vendor atau layanan eksklusif. Pendekatan ini memiliki beberapa kelemahan:

  • Persaingan resource yang tidak efisien: Workload machine learning yang berat (seperti mesin inferensi Model Bahasa Besar (LLM) atau sistem visi di perangkat) bersaing secara langsung dengan sistem prioritas tinggi lainnya untuk mendapatkan resource NPU terbatas (seperti SRAM, memori bobot, dan saluran eksekusi).
  • Ketidakstabilan sistem: Workload yang tidak terkoordinasi dapat memicu pembatasan termal, kesalahan halaman memori, atau daemon penghentian proses memori rendah (LMKD) jika permintaan melebihi kapasitas hardware.
  • Prioritas yang tidak efisien: Server sistem tidak dapat menyesuaikan prioritas NPU sebagai respons terhadap perubahan konteks, seperti tugas latar belakang yang memuat model besar saat pipeline kamera atau asisten pengguna yang sensitif terhadap latensi aktif di latar depan.

Pengelola NPU mengatasi tantangan ini dengan bertindak sebagai penentu di tingkat sistem yang membatasi pemuatan model dan menyesuaikan prioritas eksekusi secara dinamis berdasarkan kesehatan perangkat dan status aplikasi saat ini.

Arsitektur sistem

NPU Manager diimplementasikan sebagai layanan sistem bernama npu yang berjalan dalam framework Android. NPU Manager mengisolasi koordinasi tingkat tinggi dari kebijakan penjadwalan dari penerapan driver vendor tingkat rendah.

Diagram berikut menggambarkan lapisan lingkungan NPU Manager:

Lapisan lingkungan NPU Manager

Gambar 1. Lapisan lingkungan NPU Manager.

Komponen penting

  • Klien Framework API (android.npumanager.NpuManager): Titik entri yang digunakan oleh klien untuk meminta reservasi pemuatan model
  • Layanan Sistem (npu): Layanan sistem yang membatasi persetujuan pemuatan model dan mengelola perintah pengalihan berdasarkan aturan prioritas penjadwalan
  • HAL Penjadwalan NPU (android.hardware.npu): Antarmuka berbasis AIDL yang meneruskan callback prioritas aplikasi Android antara framework dan driver
  • Driver vendor: Driver tingkat rendah yang mengontrol blok eksekusi hardware dan menerapkan mekanisme prioritas tingkat rendah

SDK dan API framework

Sebelum memanggil library jaringan neural tingkat rendah atau memuat file model, klien framework harus berinteraksi dengan layanan NpuManager. Untuk melakukannya, klien terlebih dahulu menentukan permintaan pemuatan model, lalu menjalankan permintaan dan alur persetujuan.

Permintaan pemuatan model

Permintaan pemuatan model diwakili oleh ModelLoadRequest. Objek ini berisi:

  • ID permintaan unik
  • Perkiraan class ukuran model, seperti NPU_MODEL_SIZE_LESS_THAN_1GB atau NPU_MODEL_SIZE_GREATER_THAN_2G
  • Prioritas yang diinginkan, seperti NPU_MODEL_PRIORITY_BACKGROUND, NPU_MODEL_PRIORITY_NORMAL, atau NPU_MODEL_PRIORITY_OPPORTUNISTIC

Contoh kode berikut membangun ModelLoadRequest dengan batas ukuran lebih besar dari 2 GB dan prioritas eksekusi normal:

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

Alur permintaan dan persetujuan

Klien memanggil requestCanLoadModel secara asinkron:

npuManager.requestCanLoadModel(request, callback, executor);

Saat resource NPU tersedia, framework akan merespons menggunakan ModelLoadRequestCallback dengan peristiwa berikut:

  • onCanLoadModel(request, status, listener): Diaktifkan saat permintaan disetujui. Klien menerima token NpuManager.ModelLoadStatusListener. Setelah klien memuat model sepenuhnya dalam memori driver, klien harus memanggil listener.notifyModelLoaded(request).
  • onRequestUnloadModel(request) atau onRequestUnloadModel(request, reason): Diaktifkan saat sistem mengalami tekanan resource (seperti permintaan latar depan yang masuk atau lonjakan suhu) dan mengharuskan klien melepaskan modelnya. Setelah merebut kembali resource NPU, klien memanggil listener.notifyModelUnloaded(request).
  • onModelLoadRequestComplete(request, status): Memberi tahu klien tentang perubahan siklus proses permintaan akhir, seperti pembatalan.

Klien dapat membatalkan undangan yang menunggu persetujuan menggunakan cancelModelLoad(request).

Integrasi HAL dan vendor

Untuk mendukung Pengelola NPU, implementasi vendor khusus perangkat harus sesuai dengan antarmuka layanan AIDL android.hardware.npu.

Konfigurasi penjadwalan

Sistem meneruskan prioritas aplikasi menggunakan AIDL SchedulingConfig struktur AIDL SchedulingConfig yang ditentukan dalam IScheduling.aidl:

package android.hardware.npu;

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

Dengan menggunakan struktur ini, Pengelola NPU mengoordinasikan penyelarasan prioritas. Misalnya, jika aplikasi latar belakang mengirimkan tugas prioritas tinggi, prioritas akan disesuaikan ke bawah untuk mencegah interferensi pada grafis latar depan.

Status dan pembuatan profil tugas

Driver vendor harus melaporkan status siklus proses grup eksekusi NPU ke pengelola. WorkInfo melacak tugas (ditetapkan di 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;
}

Penghilangan getaran peristiwa

Framework penjadwalan mendukung penghilangan derau peristiwa menggunakan parameter debounce_duration_ms dalam pendaftaran callback penjadwalan. Hal ini menghindari banjir log dan menekan notifikasi cepat, misalnya, peristiwa mulai dan akhir berturut-turut untuk model berulang.

Status siklus proses callback dilaporkan sebagai berikut:

  • onWorkRequested: Workload diantrekan oleh layanan vendor.
  • onWorkStarted: Eksekusi workload dimulai.
    • NPU_START_REASON_INITIAL: Menjalankan eksekusi pertama.
    • NPU_START_REASON_RESUMED: Eksekusi dilanjutkan setelah penghentian sementara.
  • onWorkEnded: Eksekusi workload berakhir.
    • NPU_END_REASON_COMPLETED: Penyelesaian operasi yang berhasil.
    • NPU_END_REASON_CANCELLED_USER: Dibatalkan oleh klien.
    • NPU_END_REASON_CANCELLED_SYSTEM: Digantikan oleh kebijakan sistem.
    • NPU_END_REASON_FAILED: Error eksekusi atau kegagalan driver.
    • NPU_END_REASON_PAUSED: Ditangguhkan sementara untuk tugas dengan prioritas lebih tinggi.

Kesiapan dan pengujian perangkat

Pastikan konfigurasi ini sudah diterapkan sebelum memverifikasi kesehatan perangkat.

Pernyataan aplikasi

Klien yang mencari prioritas penjadwalan NPU harus mendeklarasikan fitur hardware NPU di AndroidManifest.xml mereka:

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

Untuk model yang di-deploy di hardware partner generasi yang lebih baru, pernyataan ini mungkin diperlukan untuk pembuatan mesin yang optimal.

Pengujian integrasi VTS

Implementasi NPU HAL dapat divalidasi dengan pengujian fungsional VTS, misalnya, VtsHalNpuSchedulingTargetTest.