менеджер НПУ

Android 17 и более поздние версии поддерживают менеджер нейронных процессоров (NPU Manager) ( com.android.npumanager ), который координирует распределение и планирование ресурсов NPU между системными службами и рабочими нагрузками приложений. Перенося арбитраж ресурсов с пользовательских демонов сторонних производителей на платформу Android, менеджер NPU повышает предсказуемость, предотвращает нехватку ресурсов, управляет температурными ограничениями и улучшает общую производительность устройства.

Предыстория и мотивация

До появления NPU Manager приложения и системные модули отправляли рабочие нагрузки напрямую драйверам поставщиков или проприетарным сервисам. Такой подход имел ряд недостатков:

  • Неэффективная конкуренция за ресурсы: ресурсоемкие задачи машинного обучения (такие как механизмы вывода больших языковых моделей (LLM) или системы машинного зрения на устройствах) напрямую конкурируют с другими системами с высоким приоритетом за ограниченные ресурсы NPU (такие как SRAM, память для весов и каналы выполнения).
  • Нестабильность системы: Нескоординированные рабочие нагрузки могут привести к перегреву, ошибкам страничного доступа к памяти или срабатыванию демона LMKD (low memory killer daemon), если требования превышают возможности оборудования.
  • Неэффективная приоритезация: системный сервер не может корректировать приоритет NPU в ответ на изменения контекста, например, когда фоновая задача загружает большую модель, в то время как в фоновом режиме активен чувствительный к задержкам конвейер обработки изображений с камеры или пользовательский помощник.

Менеджер NPU решает эти проблемы, выступая в качестве системного арбитра, который регулирует загрузку моделей и динамически корректирует приоритеты выполнения в зависимости от текущего состояния устройства и приложения.

Архитектура системы

Менеджер NPU реализован как системная служба с именем npu , работающая в рамках Android. Менеджер NPU изолирует высокоуровневую координацию политик планирования от низкоуровневой реализации драйверов поставщика.

На следующей диаграмме показаны уровни среды NPU Manager:

Слои среды NPU Manager

Рисунок 1. Слои среды NPU Manager.

Ключевые компоненты

  • Клиент API фреймворка ( android.npumanager.NpuManager ): точка входа, используемая клиентами для запроса резервирования загрузки моделей.
  • Системная служба ( npu ): Системная служба, которая контролирует утверждение загрузки моделей и управляет командами вытеснения на основе правил приоритета планирования.
  • NPU Scheduling HAL ( android.hardware.npu ): интерфейс на основе AIDL, который передает обратные вызовы приоритетов приложений Android между фреймворком и драйвером.
  • Драйвер поставщика: низкоуровневый драйвер, управляющий блоками выполнения аппаратных средств и реализующий низкоуровневые механизмы приоритезации.

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 ГБ и обычным приоритетом выполнения:

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 реализации от конкретных производителей устройств должны соответствовать интерфейсам службы AIDL android.hardware.npu .

Настройка планирования

Система передает приоритеты приложений, используя структуру AIDL SchedulingConfig , определенную в 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 .