LiteRT Accelerator Test Suite (ATS)

Die LiteRT Accelerator Test Suite (ATS) ist ein umfassendes Tool, mit dem die funktionale Richtigkeit validiert und die Leistung benutzerdefinierter Accelerator-Implementierungen gemessen werden kann, die in das LiteRT-Framework integriert sind.

Übersicht und Hauptfunktionen

Die Hauptfunktion von ATS besteht darin, vordefinierte Modelle für maschinelles Lernen für einen Zielbeschleuniger auszuführen und die Ergebnisse mit dem LiteRT-Standard-CPU-Backend zu vergleichen.

• Validierung:Die Suite führt eine numerische Validierung durch, indem sie die vom Beschleuniger erzeugten Ausgabetensoren (Aktivierungen) mit denen vergleicht, die vom bekannten CPU-Backend erzeugt werden. So wird sichergestellt, dass die Implementierung des Accelerators die erforderliche Präzision und Richtigkeit beibehält.
• Leistungsmesswerte:Wichtige Leistungsdetails wie Latenz und andere relevante Messwerte werden automatisch erfasst und aufgezeichnet und dem Nutzer zur Verfügung gestellt.
• Ausführung:Die Tests werden in der Regel auf einem Zielgerät (z.B. einem Android-Smartphone) ausgeführt und von einem Shell-Script-Wrapper verwaltet, der Dateiübertragungen und die Einrichtung mit dem Tool adb (Android Debug Bridge) übernimmt.

Testdaten (Modelle)

Die ATS-Suite verwendet eine Sammlung weitverbreiteter .tflite-Modelle als Testdaten. Eingabedaten werden basierend auf dem Datentyp zufällig generiert und können bei Bedarf mit einem Startwert versehen werden.

Enthaltene Modelle

Die folgenden Modelle werden automatisch für Tests heruntergeladen (Änderungen vorbehalten):

• 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

Manuelles Abrufen von Modellen

Modelle werden zwar während eines bazel run automatisch heruntergeladen, Sie können das gesamte Modellset aber auch manuell mit wget abrufen:

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

ATS-Suite mit Bazel definieren

Verwenden Sie das litert_define_ats-Bazel-Makro, um ein ATS-Testziel zu konfigurieren und zu definieren, das speziell auf den Beschleuniger zugeschnitten ist.

Mit dem Makro werden automatisch zwei ausführbare Ziele erstellt:

1. Der standardmäßige On-Device-JIT-Test (zur Ausführung und Validierung).
2. Ein dedizierter AOT-Test im Modus „Nur kompilieren“ (für die Hostkompilierung).

Beispiel für die Verwendung von litert_define_ats

Im Beispiel wird eine ATS-Suite mit dem Namen example_ats für einen Beschleuniger mit dem Backend-Namen example definiert:

# 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 = "",
)

Ausführung

So führen Sie den Standardtest für Android aus (der alle adb-Vorgänge verarbeitet):

# 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

So führen Sie den AOT-Kompilierungstest aus:

# 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

Linux-Ausführung (Host)

Bei der Ausführung unter Linux, wenn ATS auf demselben Computer ausgeführt wird, auf dem auch der Build erfolgt, müssen Nutzer das Binärprogramm :ats direkt verwenden:

bazel run -c opt :ats

IoT-Ausführung

Für die IoT-Ausführung müssen Nutzer das Binärprogramm auf dem Host erstellen und manuell auf ihr Gerät übertragen.

Befehlszeilen-Flags

Die ausführbare Datei ats akzeptiert mehrere Flags für eine detaillierte Steuerung von Tests und Berichten.

litert_device_script-Build-Dienstprogramme für ATS verwenden

Die ATS-Ziele für Nutzer werden automatisch ausgeführt und enthalten einen Shell-Einstiegspunkt, der die gesamte Umgebungseinrichtung und das Pushen erforderlicher Bibliotheken übernimmt, wenn sich das Zielgerät vom Host unterscheidet, auf dem der Build abgeschlossen wurde (z.B. adb push).

Diese Funktion wird generisch über die litert_device_script-Dienstprogramme bereitgestellt, die von ATS-Builds im Hintergrund verwendet werden. Für den Zugriff auf diese Build-Funktion ist eine Registrierung erforderlich. Zusätzlich zur Unterstützung von ats können diese Dienstprogramme eigenständig verwendet werden, um cc_binary und cc_test zu simulieren, die auf einem Gerät ausgeführt werden sollen, das sich vom Build-Host unterscheidet und Push-Abhängigkeiten erfordert.

Backend-Registrierung

Damit ein neuer Beschleuniger mit litert_device_script (und damit ATS) verwendet werden kann, müssen die erforderlichen Bibliotheken in der Bazel-Datei litert_device_common.bzl registriert werden. Die Registrierung basiert auf einem eindeutigen Backend-Namen, der einer Reihe von kompilierbaren oder vorkompilierten Bibliotheken zugeordnet wird, die für die Ausführung von LiteRT mit diesem Beschleuniger erforderlich sind.

Registrierungsschritte

1. BackendSpec-Funktion definieren:Erstellen Sie eine Funktion, die ein Dictionary mit der Spezifikation Ihres neuen Beschleunigers zurückgibt.

2. Bibliotheken angeben (libs): Dies ist eine Liste von Tupeln mit dem Bazel-Zielpfad für die gemeinsam genutzte Bibliothek und der Umgebungsvariable (LD_LIBRARY_PATH), die für den Geräte-Linker erforderlich ist, um sie zu finden.

   • Dispatch-Bibliothek:Für die Laufzeitausführung erforderlich.
   • Compiler-Plug-in-Bibliothek:Erforderlich für den AOT-Kompilierungsmodus.

3. Bibliotheksnamen angeben (plugin, dispatch): Geben Sie die Dateinamen des Plug-ins und der Dispatch-Bibliotheken an.

4. Spezifikation registrieren:Führen Sie Ihre neue Spezifikationsfunktion in die Hauptfunktion _Specs ein, damit sie über ihre eindeutige Backend-ID verfügbar ist.

Beispielregistrierung (_ExampleSpec)

Der folgende Code aus litert_device_common.bzl veranschaulicht, wie der Accelerator „example“ registriert wird:

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]

Registrierung mit litert_device_exec nutzen

Nach der Registrierung verwenden Sie die litert_device_exec und die zugehörigen Makros mit der neuen backend_id. Mit diesem Makro werden die erforderlichen Bibliotheken und alle angegebenen Datendateien automatisch mit dem Ziel-Binärprogramm gebündelt.

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",
)

Wenn Sie dieses Ziel (bazel run ... :example_bin_device) ausführen, passiert Folgendes:

1. Erstellen Sie die C++-Binärdatei example_bin.
2. Übertragen Sie die Binärdatei libLiteRtDispatch_Example.so, libLiteRtCompilerPlugin_Example.so und die Datei .tflite auf das Gerät.
3. Führen Sie die Binärdatei mit adb shell aus.

Hinweis zu Gerätepfaden:Der kanonische Speicherort für Dateien auf dem Gerät entspricht dem Runfile-Baum von Bazel, insbesondere /data/local/tmp/runfiles/runfiles_relative_path. Das Geräteskript legt automatisch die entsprechenden Pfade für den dynamischen Linker fest.

Kompilierungsmodus (AOT)

Für Beschleuniger, die einen AOT-Kompilierungsschritt (Ahead-of-Time) unterstützen, kann ATS in einem dedizierten Kompilierungsmodus ausgeführt werden.

• Zweck:Dieser Modus ist für die Ausführung auf einer Workstation (Hostcomputer) und nicht auf dem Zielgerät vorgesehen. Die Modelle werden für die angegebene Zielhardware kompiliert, ohne dass sie ausgeführt werden.
• Ausgabe:Alle kompilierten Modelle werden in ein dafür vorgesehenes Verzeichnis auf der Arbeitsstation ausgegeben.
• Aktivierung:Die ATS-Build-Makros geben ein bestimmtes Ziel für AOT aus, in dem Bibliotheken für die Hostplattform erstellt werden. Dieser Ablauf kann für jedes Binärprogramm mit dem Flag --compile_mode aktiviert werden, ist aber automatisch an die Argumente des AOT-Builds gebunden.

Geplante Ausweitung

Die Suite soll um spezielle Tests für einzelne Vorgänge (Ops) zusätzlich zu vollständigen Modellen erweitert werden.