Qualidade de serviço

A partir do Android 11, a NNAPI oferece uma melhor qualidade de serviço (QoS) ao permitir que um app indique as prioridades relativas dos modelos, o tempo máximo esperado para um modelo ser preparado e o tempo máximo esperado para uma execução ser concluída. Além disso, o Android 11 apresenta outros valores de erro da NNAPI, permitindo que um serviço indique com mais precisão o que deu errado quando ocorre uma falha. Assim, o app cliente pode reagir e se recuperar melhor.

Prioridade

No Android 11 ou versões mais recentes, os modelos são preparados com uma prioridade na NN HAL 1.3. Essa prioridade é relativa a outros modelos preparados pertencentes ao mesmo app. Execuções de maior prioridade podem usar mais recursos de computação do que as de menor prioridade, além de interromper ou impedir a execução de tarefas de menor prioridade.

A chamada da HAL 1.3 de rede neural que inclui Priority como um argumento explícito é IDevice::prepareModel_1_3. Observe que IDevice::prepareModelFromCache_1_3 inclui implicitamente Priority nos argumentos de cache.

Há muitas estratégias possíveis para oferecer suporte a prioridades, dependendo das capacidades do driver e do acelerador. Confira algumas estratégias:

  • Para drivers com suporte prioritário integrado, propague diretamente o campo Priority para o acelerador.
  • Use uma fila de prioridade por app para oferecer suporte a diferentes prioridades mesmo antes de uma execução chegar ao acelerador.

  • Pause ou cancele os modelos de baixa prioridade que estão sendo executados para liberar o acelerador e executar modelos de alta prioridade. Para isso, insira checkpoints em modelos de baixa prioridade que, quando alcançados, consultam uma flag para determinar se a execução atual deve ser interrompida prematuramente ou particione o modelo em submodelos e consulte a flag entre as execuções de submodelos. O uso de pontos de verificação ou submodelos em modelos preparados com uma prioridade pode introduzir uma sobrecarga adicional que não está presente em modelos sem uma prioridade em versões anteriores ao NN HAL 1.3.

    • Para oferecer suporte à substituição, preserve o contexto de execução, incluindo a próxima operação ou submodelo a ser executado e todos os dados de operando intermediários relevantes. Use esse contexto de execução para retomar a execução mais tarde.
    • Não é necessário suporte completo à substituição. Portanto, o contexto de execução não precisa ser preservado. Como as execuções de modelo da NNAPI são deterministas, elas podem ser reiniciadas do zero em um momento posterior.

O Android permite que os serviços diferenciem os apps de chamada usando um AID (UID do Android). O HIDL tem mecanismos integrados para recuperar o UID do app de chamada pelo método ::android::hardware::IPCThreadState::getCallingUid. Uma lista de AIDs pode ser encontrada em libcutils/include/cutils/android_filesystem_config.h.

Prazos

A partir do Android 11, a preparação e as execuções de modelos podem ser iniciadas com um argumento de prazo OptionalTimePoint. Para motoristas que podem estimar quanto tempo uma tarefa leva, esse prazo permite que o motorista interrompa a tarefa antes de começar se ele estimar que ela não pode ser concluída antes do prazo. Da mesma forma, o prazo permite que o driver interrompa uma tarefa em andamento que ele estima que não será concluída antes do prazo. O argumento de prazo não força um driver a interromper uma tarefa se ela não for concluída até o prazo ou se o prazo já tiver passado. O argumento de prazo pode ser usado para liberar recursos de computação no driver e retornar o controle ao app mais rápido do que seria possível sem o prazo.

As chamadas da HAL de NN 1.3 que incluem prazos OptionalTimePoint como argumento são:

  • IDevice::prepareModel_1_3
  • IDevice::prepareModelFromCache_1_3
  • IPreparedModel::execute_1_3
  • IPreparedModel::executeSynchronously_1_3
  • IPreparedModel::executeFenced

Para conferir uma implementação de referência do recurso de prazo para cada um dos métodos acima, consulte o driver de exemplo da NNAPI em frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Códigos de erro

O Android 11 inclui quatro valores de código de erro na NN HAL 1.3 para melhorar a geração de relatórios de erros, permitindo que os drivers comuniquem melhor o estado deles e que os apps se recuperem de maneira mais adequada. Estes são os valores de código de erro em ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

No Android 10 ou versões anteriores, um driver só podia indicar uma falha usando o código de erro GENERAL_FAILURE. No Android 11, os dois códigos de erro MISSED_DEADLINE podem ser usados para indicar que a carga de trabalho foi interrompida porque o prazo foi atingido ou porque o driver previu que a carga de trabalho não seria concluída até o prazo. Os dois códigos de erro RESOURCE_EXHAUSTED podem ser usados para indicar que a tarefa falhou devido a uma limitação de recursos no driver, como falta de memória para a chamada.

A versão TRANSIENT dos dois erros indica que o problema é temporário e que as próximas chamadas para a mesma tarefa podem ser bem-sucedidas após um pequeno atraso. Por exemplo, esse código de erro deve ser retornado quando o motorista estiver ocupado com um trabalho anterior de longa duração ou que exija muitos recursos, mas a nova tarefa seria concluída com êxito se o motorista não estivesse ocupado com o trabalho anterior. A versão PERSISTENT dos dois erros indica que as chamadas futuras para a mesma tarefa sempre vão falhar. Por exemplo, esse código de erro deve ser retornado quando o motorista estima que a tarefa não será concluída até o prazo, mesmo em condições perfeitas, ou que o modelo é muito grande e excede os recursos do motorista.

Validação

A funcionalidade de qualidade de serviço é testada nos testes VTS da NNAPI (VtsHalNeuralnetworksV1_3Target). Isso inclui um conjunto de testes para validação (TestGenerated/ValidationTest#Test/) para garantir que o driver rejeite prioridades inválidas e um conjunto de testes chamado DeadlineTest (TestGenerated/DeadlineTest#Test/) para garantir que o driver processe prazos corretamente.