LiteRT Accelerator Test Suite (ATS)

El LiteRT Accelerator Test Suite (ATS) es una herramienta integral que se usa para validar la corrección funcional y medir el rendimiento de las implementaciones de aceleradores personalizados integrados en el framework de LiteRT.

Descripción general y funcionalidad principal

La función principal de ATS es ejecutar modelos de aprendizaje automático predefinidos en un acelerador objetivo y comparar los resultados con el backend de CPU estándar de LiteRT.

• Validación: El paquete realiza una validación numérica comparando los tensores de salida (activaciones) que produce el acelerador con los que produce el backend de CPU conocido como correcto. Esto garantiza que la implementación del acelerador mantenga la precisión y la exactitud requeridas.
• Métricas de rendimiento: Captura y registra automáticamente detalles de rendimiento críticos, incluida la latencia y otras métricas relevantes, que se ponen a disposición del usuario.
• Ejecución: Por lo general, las pruebas se ejecutan en un dispositivo de destino (p.ej., un teléfono Android) y se administran con un wrapper de secuencia de comandos de shell que controla las transferencias de archivos y la configuración con la herramienta adb (Android Debug Bridge).

Datos de prueba (modelos)

El paquete de pruebas de ATS usa una colección de modelos .tflite ampliamente utilizados como datos de prueba. Los datos de entrada se generan de forma aleatoria según el tipo de datos y se pueden inicializar según sea necesario.

Modelos incluidos

Los siguientes modelos se incluyen y descargan automáticamente para las pruebas (sujeto a cambios):

• hf_all_minilm_l6_v2
• hf_mobilevit_small
• qai_hub_midas
• qai_hub_real_esrgan_x4plus
• torchvision_mobilenet_v2
• torchvision_resnet18
• torchvision_squeezenet1_1
• u2net_lite
• whisper_tiny_decoder
• whisper_tiny_encoder
• yamnet
• yolo11n

Recuperación manual del modelo

Si bien los modelos se descargan automáticamente durante un bazel run, puedes recuperar manualmente todo el conjunto de modelos con wget:

wget -p -O <target_file> https://storage.googleapis.com/litert/ats_models.tar.gz

Cómo definir un conjunto de pruebas de ATS con Bazel

Usa la macro litert_define_ats de Bazel para configurar y definir un destino de prueba de ATS específico para su acelerador.

La macro crea automáticamente dos destinos ejecutables:

1. La prueba JIT integrada en el dispositivo estándar (para ejecución y validación).
2. Una prueba de modo "solo compilación" de AOT dedicada (para la compilación del host).

Ejemplo de uso de litert_define_ats

En el ejemplo, se define un conjunto de pruebas de ATS llamado example_ats para un acelerador con el nombre de backend example:

# Emits aot-mode and jit-mode test targets, one for running compilation test on host
# and another for running JIT and inference on device
# These targets are named with their respective suffix attribute.
litert_define_ats(
    name = "example_ats",
    backend = "example",
    compile_only_suffix = "_aot",
    do_register = [
        "*mobilenet*",
    ],
    extra_flags = ["--limit=1"],
    jit_suffix = "",
)

Ejecución

Para ejecutar la prueba estándar orientada a Android (que controla todas las operaciones de adb), haz lo siguiente:

# Handles environment setup, and build + push of library and data dependencies to the device,
# executes the suite on the target.
bazel run -c opt --config=android_arm64 :example_ats

Para ejecutar la prueba de compilación AOT, haz lo siguiente:

# Handle environment setup, and builds library dependencies for host platform.
# Executes the ats compile only flow. The "--compile_mode" flag is already
# bound to the program arguments.
bazel run :example_ats_aot

Ejecución de Linux (host)

Para la ejecución en Linux, en la que ATS se ejecuta en la misma máquina que realiza la compilación, los usuarios deberán usar el archivo binario :ats directamente:

bazel run -c opt :ats

Ejecución de IoT

Para la ejecución de IoT, los usuarios deberán compilar el archivo binario en el host y enviarlo manualmente a su dispositivo.

Marcas de línea de comandos

El ejecutable ats acepta varias marcas para un control detallado sobre las pruebas y los informes.

Cómo usar las utilidades de compilación de litert_device_script para ATS

Los destinos de ATS que se ejecutan automáticamente incluyen un punto de entrada de shell que controla toda la configuración del entorno y cualquier envío de bibliotecas requeridas cuando el dispositivo de destino difiere del host en el que se completó la compilación (p.ej., adb push).

Esta funcionalidad se proporciona de forma genérica a través de las utilidades de litert_device_script que usan las compilaciones de ATS de forma interna. Los aceleradores deben completar un proceso de registro para acceder a esta función de compilación. Además de admitir ats, estas utilidades se pueden usar de forma independiente para simular cc_binary y cc_test, que se ejecutan en un dispositivo diferente del host de compilación que requiere dependencias push.

Registro de backend

Para habilitar un nuevo acelerador para usarlo con litert_device_script (y, por lo tanto, con ATS), sus bibliotecas requeridas deben registrarse en el archivo litert_device_common.bzl de Bazel. El registro se basa en un "nombre de backend" único que se asigna a un conjunto de bibliotecas compilables o precompiladas necesarias para que LiteRT funcione con ese acelerador.

Pasos para el registro

1. Define una función BackendSpec: Crea una función que devuelva un diccionario que contenga la especificación de tu nuevo acelerador.

2. Specify Libraries (libs): Es una lista de tuplas que detallan la ruta de destino de Bazel para la biblioteca compartida y la variable de entorno (LD_LIBRARY_PATH) que requiere el vinculador del dispositivo para encontrarla.

   • Biblioteca de envío: Se requiere para la ejecución en el tiempo de ejecución.
   • Biblioteca del complemento del compilador: Se requiere para el modo de compilación AOT.

3. Specify Library Names (plugin, dispatch): Proporciona los nombres de archivo de las bibliotecas de complementos y de envío.

4. Registra la especificación: Combina tu nueva función de especificación en la función _Specs principal para que esté disponible por su ID único de backend.

Ejemplo de registro (_ExampleSpec)

El siguiente código de litert_device_common.bzl ilustra cómo se registra el acelerador "ejemplo":

def _ExampleSpec():
    return {
        # The unique backend ID
        "example": BackendSpec(
            id = "example",
            libs = [
                # Dispatch Library and how to find it on device
                ("//third_party/odml/litert/litert/vendors/examples:libLiteRtDispatch_Example.so", "LD_LIBRARY_PATH"),
                # Compiler Plugin Library
                ("//third_party/odml/litert/litert/vendors/examples:libLiteRtCompilerPlugin_Example.so", "LD_LIBRARY_PATH"),
            ],
            plugin = "libLiteRtCompilerPlugin_Example.so",
            dispatch = "libLiteRtDispatch_Example.so",
        ),
    }

# ... (Other specs are defined here)

def _Specs(name):
    # Your new spec function must be included here
    return (_QualcommSpec() | _GoogleTensorSpec() | _MediatekSpec() | _CpuSpec() | _GpuSpec() | _ExampleSpec())[name]

Aprovecha el registro con litert_device_exec

Una vez que se registre, usa litert_device_exec y las macros relacionadas con el nuevo backend_id. Esta macro agrupa automáticamente las bibliotecas requeridas y los archivos de datos especificados con el archivo binario de destino.

cc_binary(
    name = "example_bin",
    srcs = ["example_bin.cc"],
)

litert_device_exec(
    name = "example_bin_device",
    backend_id = "example",  # Uses the libraries registered under "example"
    data = [
        "//third_party/odml/litert/litert/test:testdata/constant_output_tensor.tflite",
    ],
    target = ":example_bin",
)

Si ejecutas este destino (bazel run ... :example_bin_device), sucederá lo siguiente:

1. Compila el objeto binario example_bin de C++.
2. Envía el archivo binario, libLiteRtDispatch_Example.so, libLiteRtCompilerPlugin_Example.so y el archivo .tflite al dispositivo.
3. Ejecuta el objeto binario con adb shell.

Nota sobre las rutas de acceso del dispositivo: La ubicación canónica de los archivos en el dispositivo refleja el árbol de archivos ejecutables de Bazel, específicamente /data/local/tmp/runfiles/runfiles_relative_path. La secuencia de comandos del dispositivo controla automáticamente la configuración de las rutas de acceso adecuadas para el vinculador dinámico.

Modo de compilación (AOT)

En el caso de los aceleradores que admiten un paso de compilación anticipada (AOT), ATS se puede ejecutar en un "modo de compilación" dedicado.

• Propósito: Este modo está diseñado para ejecutarse en una estación de trabajo (máquina host), no en el dispositivo de destino. Compila los modelos para el hardware de destino especificado sin ejecutarlos.
• Resultado: Todos los modelos compilados se envían a un directorio designado en la estación de trabajo.
• Activación: Las macros de compilación de ATS emitirán un destino específico para AOT, en el que se compilan las bibliotecas para la plataforma host. Este flujo se puede habilitar en cualquier archivo binario con la marca --compile_mode, pero se vincula automáticamente a los argumentos de la compilación de AOT.

Expansión a futuro

Se planea expandir el paquete para incluir pruebas específicas para operaciones (ops) individuales, además de modelos completos.