Gerente de NPU

O Android 17 e versões mais recentes são compatíveis com o gerenciador da unidade de processamento neural (NPU, na sigla em inglês) (com.android.npumanager), que coordena a alocação e o agendamento de recursos da NPU em serviços do sistema e cargas de trabalho de aplicativos. Ao mover a arbitragem de recursos de daemons personalizados do fornecedor para a plataforma Android, o NPU Manager aumenta a previsibilidade, evita a falta de recursos, gerencia limites térmicos e melhora o desempenho geral do dispositivo.

Contexto e motivação

Antes do NPU Manager, os apps e módulos do sistema enviavam cargas de trabalho diretamente para drivers do fornecedor ou serviços proprietários. Essa abordagem tinha várias desvantagens:

• Competição ineficiente de recursos:cargas de trabalho pesadas de machine learning (como mecanismos de inferência de modelos de linguagem grandes [LLMs] ou sistemas de visão no dispositivo) competiam diretamente com outros sistemas de alta prioridade por recursos finitos de NPU (como SRAM, memória de pesos e canais de execução).
• Instabilidade do sistema:cargas de trabalho não coordenadas podem acionar limitação térmica, falhas de página de memória ou daemon de eliminação de memória baixa (LMKD, na sigla em inglês) se as demandas excederem a capacidade do hardware.
• Priorização ineficiente:o servidor do sistema não consegue ajustar a prioridade da NPU em resposta a mudanças de contexto, como uma tarefa em segundo plano carregando um modelo grande enquanto um pipeline de câmera sensível à latência ou um assistente de usuário está ativo em primeiro plano.

O Gerenciador de NPU resolve esses desafios atuando como um árbitro no nível do sistema que controla o carregamento do modelo e ajusta dinamicamente as prioridades de execução com base na integridade do dispositivo atual e nos estados do app.

Arquitetura do sistema

O NPU Manager é implementado como um serviço do sistema chamado npu em execução no framework do Android. O NPU Manager isola a coordenação de alto nível das políticas de programação da implementação do driver do fornecedor de baixo nível.

O diagrama a seguir ilustra as camadas do ambiente do NPU Manager:

Figura 1. Camadas de ambiente do NPU Manager.

Principais componentes

• Cliente da API do framework (android.npumanager.NpuManager): o ponto de entrada usado pelos clientes para solicitar reservas de carga de modelo.
• Serviço do sistema (npu): um serviço do sistema que controla as aprovações de carga do modelo e gerencia comandos de substituição com base em regras de prioridade de programação.
• HAL de programação da NPU (android.hardware.npu): uma interface baseada em AIDL que transmite callbacks de prioridades de apps Android entre o framework e o driver.
• Driver do fornecedor:um driver de baixo nível que controla os blocos de execução de hardware e implementa mecanismos de priorização de baixo nível.

API de SDK e framework

Antes de chamar bibliotecas de rede neural de baixo nível ou carregar arquivos de modelo, os clientes da estrutura precisam interagir com o serviço NpuManager. Para isso, os clientes primeiro definem uma solicitação de carga de modelo e depois executam o fluxo de solicitação e aprovação.

Solicitação de carregamento do modelo

Uma solicitação de carregamento de modelo é representada por ModelLoadRequest. Esse objeto contém:

• ID exclusivo da solicitação
• Classe de tamanho estimado do modelo, como NPU_MODEL_SIZE_LESS_THAN_1GB ou NPU_MODEL_SIZE_GREATER_THAN_2G
• Prioridade pretendida, como NPU_MODEL_PRIORITY_BACKGROUND, NPU_MODEL_PRIORITY_NORMAL ou NPU_MODEL_PRIORITY_OPPORTUNISTIC

O exemplo de código a seguir cria um ModelLoadRequest com um limite de tamanho maior que 2 GB e prioridade de execução normal:

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

Fluxo de solicitação e aprovação

Os clientes invocam requestCanLoadModel de forma assíncrona:

npuManager.requestCanLoadModel(request, callback, executor);

Quando os recursos de NPU estão disponíveis, o framework responde usando ModelLoadRequestCallback com os seguintes eventos:

• onCanLoadModel(request, status, listener): disparado quando a solicitação é aprovada. O cliente recebe um token NpuManager.ModelLoadStatusListener. Depois que o cliente carregar totalmente o modelo na memória do driver, ele precisa chamar listener.notifyModelLoaded(request).
• onRequestUnloadModel(request) ou onRequestUnloadModel(request, reason): acionado quando o sistema sofre pressão de recursos (como uma solicitação em primeiro plano ou um pico térmico) e exige que o cliente libere o modelo. Depois de recuperar os recursos da NPU, o cliente chama listener.notifyModelUnloaded(request).
• onModelLoadRequestComplete(request, status): informa ao cliente sobre as mudanças finais no ciclo de vida da solicitação, como cancelamento.

Os clientes podem cancelar convites pendentes usando cancelModelLoad(request).

Integração de HAL e fornecedor

Para oferecer suporte ao NPU Manager, as implementações específicas do fornecedor precisam estar em conformidade com as interfaces de serviço AIDL android.hardware.npu.

Configuração de programação

O sistema transmite a prioridade do app usando a AIDL SchedulingConfig a estrutura AIDL SchedulingConfig definida em IScheduling.aidl:

package android.hardware.npu;

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

Usando essa estrutura, o NPU Manager coordena os alinhamentos de prioridade. Por exemplo, se um app em segundo plano enviar um job de alta prioridade, a prioridade será ajustada para baixo para evitar interferência com gráficos em primeiro plano.

Status e criação de perfil da tarefa

Os drivers do fornecedor precisam informar o status do ciclo de vida dos grupos de execução da NPU ao gerenciador. WorkInfo rastreia as tarefas (definidas em 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;
}

Debouncing de eventos

A estrutura de programação oferece suporte à remoção de duplicação de eventos usando o parâmetro debounce_duration_ms no registro de callback de programação. Isso evita o excesso de registros e suprime notificações rápidas, por exemplo, eventos consecutivos de início e fim para modelos repetidos.

Os estados do ciclo de vida de callback são informados da seguinte maneira:

• onWorkRequested: a carga de trabalho é enfileirada pelo serviço do fornecedor.
• onWorkStarted: a execução da carga de trabalho começa.
  • NPU_START_REASON_INITIAL: primeira execução.
  • NPU_START_REASON_RESUMED: a execução foi retomada após a substituição.
• onWorkEnded: a execução da carga de trabalho foi concluída.
  • NPU_END_REASON_COMPLETED: conclusão bem-sucedida da execução.
  • NPU_END_REASON_CANCELLED_USER: cancelado pelo cliente.
  • NPU_END_REASON_CANCELLED_SYSTEM: substituído por uma política do sistema.
  • NPU_END_REASON_FAILED: erro de execução ou falha do driver.
  • NPU_END_REASON_PAUSED: temporariamente suspenso para tarefas de maior prioridade.

Preparação e teste de dispositivos

Verifique se essas configurações estão em vigor antes de verificar a integridade do dispositivo.

Declarações de aplicativos

Os clientes que buscam a priorização do agendamento de NPU precisam declarar o recurso de hardware de NPU no AndroidManifest.xml:

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

Para modelos implantados em gerações mais recentes de hardware de parceiros, essa declaração pode ser necessária para a criação ideal do mecanismo.

Teste de integração do VTS

As implementações de HAL de NPU podem ser validadas com testes funcionais do VTS, por exemplo, VtsHalNpuSchedulingTargetTest.