Calidad de servicio

A partir de Android 11, la 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 determinada. Además, Android 11 introduce valores de error adicionales de la NNAPI 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 y versiones posteriores, los modelos se preparan con una prioridad en 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 interrumpir o privar de 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 de forma implícita 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 integrada con la prioridad, 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.

  • Pausa o cancela los modelos de baja prioridad que se están ejecutando para liberar el acelerador y ejecutar modelos de alta prioridad. Para ello, inserta puntos de control en modelos de baja prioridad que, cuando se alcanzan, consultan una marca para determinar si la ejecución actual debe detenerse de forma prematura, o bien particiona el modelo en submodelos y consulta la marca entre las ejecuciones de los 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 prioridad en versiones anteriores a NN HAL 1.3.

    • Para admitir la interrupción, conserva el contexto de ejecución, incluida la próxima operación o submodelo que se ejecutará y los datos de operandos intermedios pertinentes. Usa este contexto de ejecución para reanudar la ejecución más adelante.
    • No es necesario que se admita la preferencia total, por lo que no es necesario conservar el contexto de ejecución. Dado que las ejecuciones de modelos de la NNAPI son determinísticas, se pueden reiniciar desde cero en un momento posterior.

Android permite que los servicios diferencien entre las distintas 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 llama a través del método ::android::hardware::IPCThreadState::getCallingUid. Puedes encontrar una lista de los 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. En el caso de 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. Del mismo modo, el plazo permite que el controlador anule una tarea en curso que estima que no se completará antes del plazo. El argumento de fecha límite no obliga a un conductor a anular una tarea si esta no se completa antes de la fecha límite o si esta 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 sería posible sin la fecha límite.

Las llamadas a HAL de NN 1.3 que incluyen plazos 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ódigos 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 fluidez. Estos son los valores de los códigos de error en ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

En Android 10 y 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, los dos códigos de error MISSED_DEADLINE se pueden usar para indicar que se anuló la carga de trabajo 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, como 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 devolver cuando el controlador está ocupado con un trabajo anterior de larga duración o que requiere muchos recursos, pero la nueva tarea 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 devolver cuando el conductor estima que la tarea no se completará antes de la fecha límite, incluso en condiciones perfectas, o que el modelo es demasiado grande y supera los recursos del conductor.

Validación

La funcionalidad de calidad del servicio se prueba en las pruebas de VTS de NNAPI (VtsHalNeuralnetworksV1_3Target). Esto incluye un conjunto de pruebas para la 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 maneje los plazos correctamente.