Calidad de servicio

A partir de Android 11, NNAPI ofrece una mejor calidad de servicio (QoS), ya que permite que una app indique las prioridades relativas de sus modelos, el tiempo de espera máximo para que se prepare un modelo determinado y el tiempo de espera máximo para que se complete una ejecución en particular. Además, Android 11 presenta valores de error de NNAPI adicionales que permiten que un servicio indique con mayor precisión qué salió mal cuando se produce una falla, de modo que la app cliente pueda reaccionar y recuperarse mejor.

Prioridad

En Android 11 o versiones posteriores, los modelos se preparan con una prioridad en el NN HAL 1.3. Esta prioridad es relativa a otros modelos preparados que pertenecen a la misma app. Las ejecuciones de mayor prioridad pueden usar más recursos de procesamiento que las de menor prioridad, y pueden anular o dejar sin recursos a las ejecuciones de menor prioridad.

La llamada a NN HAL 1.3 que incluye Priority como argumento explícito es IDevice::prepareModel_1_3. Ten en cuenta que IDevice::prepareModelFromCache_1_3 incluye implícitamente Priority en los argumentos de la caché.

Existen muchas estrategias posibles para admitir prioridades según las capacidades del controlador y el acelerador. Estas son algunas estrategias:

  • En el caso de los controladores que tienen compatibilidad con prioridades integrada, propaga directamente el campo Priority al acelerador.
  • Usa una cola de prioridad por app para admitir diferentes prioridades incluso antes de que una ejecución llegue al acelerador.

  • Pausar o cancelar los modelos de prioridad baja que se están ejecutando para liberar el acelerador y ejecutar modelos de prioridad alta Para ello, inserta puntos de control en modelos de baja prioridad que, cuando se alcancen, consulten una marca para determinar si se debe detener la ejecución actual antes de tiempo o particiona el modelo en submodelos y consulta la marca entre ejecuciones de submodelos. Ten en cuenta que el uso de puntos de control o submodelos en modelos preparados con una prioridad puede generar una sobrecarga adicional que no está presente en los modelos sin una prioridad en versiones anteriores a NN HAL 1.3.

    • Para admitir la usurpación, conserva el contexto de ejecución, incluida la siguiente operación o submodelo que se ejecutará y cualquier dato de operando intermedio relevante. Usa este contexto de ejecución para reanudar la ejecución más adelante.
    • No es necesario admitir la preempción completa, por lo que no se necesita preservar el contexto de ejecución. Debido a que las ejecuciones de modelos de NNAPI son deterministas, las ejecuciones se pueden reiniciar desde cero más adelante.

Android permite que los servicios diferencien entre diferentes apps de llamadas a través del uso de un AID (UID de Android). HIDL tiene mecanismos integrados para recuperar el UID de la app que realiza la llamada a través del método ::android::hardware::IPCThreadState::getCallingUid. Puedes encontrar una lista de AIDs en libcutils/include/cutils/android_filesystem_config.h.

Fechas límite

A partir de Android 11, la preparación y las ejecuciones de modelos se pueden iniciar con un argumento de fecha límite OptionalTimePoint. Para los conductores que pueden estimar cuánto tiempo lleva una tarea, esta fecha límite les permite abortar la tarea antes de que comience si estiman que no se puede completar antes de la fecha límite. De manera similar, el plazo permite que el controlador aborte una tarea en curso que estima que no se completará antes de la fecha límite. El argumento de fecha límite no obliga a un controlador a abortar una tarea si esta no se completa antes de la fecha límite o si ya pasó. El argumento de fecha límite se puede usar para liberar recursos de procesamiento dentro del controlador y devolver el control a la app más rápido de lo que es posible sin la fecha límite.

Las llamadas a NN HAL 1.3 que incluyen plazos de OptionalTimePoint como argumento son las siguientes:

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

Para ver una implementación de referencia de la función de fecha límite para cada uno de los métodos anteriores, consulta el controlador de muestra de NNAPI en frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Códigos de error

Android 11 incluye cuatro valores de código de error en NN HAL 1.3 para mejorar los informes de errores, lo que permite que los controladores comuniquen mejor su estado y que las apps se recuperen con mayor facilidad. Estos son los valores de código de error en ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

En Android 10 o versiones anteriores, un controlador solo podía indicar una falla a través del código de error GENERAL_FAILURE. A partir de Android 11, se pueden usar los dos códigos de error MISSED_DEADLINE para indicar que la carga de trabajo se abortó porque se alcanzó la fecha límite o porque el controlador predijo que la carga de trabajo no se completaría antes de la fecha límite. Los dos códigos de error RESOURCE_EXHAUSTED se pueden usar para indicar que la tarea falló debido a una limitación de recursos dentro del controlador, por ejemplo, que el controlador no tiene suficiente memoria para la llamada.

La versión TRANSIENT de ambos errores indica que el problema es temporal y que las llamadas futuras a la misma tarea podrían tener éxito después de una breve demora. Por ejemplo, este código de error se debe mostrar cuando el controlador está ocupado con un trabajo anterior de larga duración o intensivo en recursos, pero la tarea nueva se completaría correctamente si el controlador no estuviera ocupado con el trabajo anterior. La versión PERSISTENT de ambos errores indica que se espera que las llamadas futuras a la misma tarea siempre fallen. Por ejemplo, este código de error se debe mostrar cuando el controlador estima que la tarea no se completará antes de la fecha límite, incluso en condiciones perfectas, o que el modelo es inherentemente demasiado grande y supera los recursos del controlador.

Validación

La funcionalidad de calidad de servicio se prueba en las pruebas de VTS de NNAPI (VtsHalNeuralnetworksV1_3Target). Esto incluye un conjunto de pruebas de validación (TestGenerated/ValidationTest#Test/) para garantizar que el controlador rechace las prioridades no válidas y un conjunto de pruebas llamadas DeadlineTest (TestGenerated/DeadlineTest#Test/) para garantizar que el controlador controle las fechas límite correctamente.