Calidad de servicio

Obsoleto: A partir de Android 15 (experimental de AOSP), la NNAPI (API del NDK) dejó de estar disponible. Se seguirá admitiendo la interfaz de la HAL de redes neuronales.

Para obtener más información, consulta la Guía de migración de NNAPI.

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 máximo esperado para que se prepare un modelo determinado y el tiempo máximo que se espera para que se complete una ejecución determinada. Además, Android 11 presenta 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 mejor y recuperarse.

Prioridad

Para Android 11 o versiones posteriores, los modelos se preparan con una prioridad en la 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 las ejecuciones de menor prioridad.

La llamada 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 respaldar las prioridades según las capacidades del controlador y el acelerador. Estas son varias estrategias:

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

• Pausa o cancela los modelos de prioridad baja que se están ejecutando para liberar el acelerador a fin de ejecutar modelos de prioridad alta. Para ello, inserta puntos de control en modelos de prioridad baja que, cuando se alcancen, consultan una marca para determinar si la ejecución actual debe detenerse de forma prematura o particiona el modelo en submodelos y consulta la marca entre las ejecuciones de submodelos. Ten en cuenta que el uso de puntos de control o submodelos en modelos preparados con una prioridad puede introducir una sobrecarga adicional que no está presente para 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 el submodelo que se ejecutará y cualquier dato intermedio del operando relevante. Usa este contexto de ejecución para reanudar la ejecución más adelante.
  • No es necesaria la compatibilidad total con la interrupción, por lo que no es necesario conservar el contexto de ejecución. Debido a que las ejecuciones del modelo de la NNAPI son determinísticas, las ejecuciones se pueden reiniciar desde cero más adelante.

Android habilita a los servicios a diferenciar entre diferentes apps de llamadas mediante el uso de un AID (UID de Android). El 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 AID en libcutils/include/cutils/android_filesystem_config.h.

Plazos

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

Las llamadas de 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

Si quieres ver una implementación de referencia de la función de plazo para cada uno de los métodos anteriores, consulta el controlador de ejemplo 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 de manera más fluida. Estos son los valores del 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 mediante el 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 se anuló la carga de trabajo porque se alcanzó el plazo límite o porque el controlador predijo que la carga de trabajo no se completaría antes de la fecha límite. Se pueden usar los dos códigos de error RESOURCE_EXHAUSTED para indicar que la tarea falló debido a una limitación de recursos en el 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 realizarse correctamente después de una breve demora. Por ejemplo, se debe mostrar este código de error cuando el controlador esté ocupado con trabajos anteriores de larga duración o que consuman muchos recursos, pero que la tarea nueva se completaría de forma correcta si el controlador no estuviera ocupado con el trabajo anterior. La versión PERSISTENT de ambos errores indica que siempre se espera que fallen las llamadas futuras a la misma tarea. Por ejemplo, se debe mostrar este código de error cuando el controlador estima que la tarea no se completaría dentro del plazo, incluso en condiciones perfectas, o cuando el modelo es intrínsecamente demasiado grande y excede los recursos del controlador.

Validación

La funcionalidad de calidad del servicio se prueba en las pruebas de VTS de la 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 denominadas DeadlineTest (TestGenerated/DeadlineTest#Test/) para garantizar que el controlador maneje correctamente los plazos.