LiteRT-Bevollmächtigte

Delegates ermöglichen die Hardwarebeschleunigung von LiteRT-Modellen durch Nutzung von On-Device-Beschleunigern wie der GPU und dem Digital Signal Processor (DSP).

Standardmäßig verwendet LiteRT CPU-Kernel, die für den ARM Neon-Befehlssatz optimiert sind. Die CPU ist jedoch ein Universalprozessor, der nicht unbedingt für die rechenintensiven Aufgaben optimiert ist, die typischerweise in Machine-Learning-Modellen vorkommen (z. B. die Matrixmathematik, die in Faltungs- und Dense-Layern verwendet wird).

Die meisten modernen Smartphones enthalten jedoch Chips, die diese anspruchsvollen Vorgänge besser verarbeiten können. Die Nutzung für neuronale Netzwerkoperationen bietet enorme Vorteile in Bezug auf Latenz und Energieeffizienz. GPUs können beispielsweise die Latenz um das Fünffache reduzieren.

Jeder dieser Beschleuniger hat zugehörige APIs, die benutzerdefinierte Berechnungen ermöglichen, z. B. OpenCL oder OpenGL ES für mobile GPUs. Normalerweise müssten Sie viel benutzerdefinierten Code schreiben, um ein neuronales Netzwerk über diese Schnittstellen auszuführen. Die Sache wird noch komplizierter, wenn man bedenkt, dass jeder Beschleuniger seine Vor- und Nachteile hat und nicht jede Operation in einem neuronalen Netzwerk ausführen kann. Die Delegate API von TensorFlow Lite löst dieses Problem, indem sie als Brücke zwischen der TFLite-Laufzeit und diesen APIs auf niedrigerer Ebene fungiert.

Delegierten auswählen

LiteRT unterstützt mehrere Delegates, die jeweils für bestimmte Plattformen und bestimmte Arten von Modellen optimiert sind. In der Regel gibt es je nach Anwendungsfall mehrere Delegates, die auf zwei Hauptkriterien basieren: der Plattform (Android oder iOS?), die Sie anvisieren, und dem Modelltyp (Gleitkomma oder quantisiert?), den Sie beschleunigen möchten.

Bevollmächtigte nach Plattform

Plattformübergreifend (Android und iOS)

• GPU-Delegate: Der GPU-Delegate kann sowohl unter Android als auch unter iOS verwendet werden. Sie ist für die Ausführung von 32-Bit- und 16-Bit-Gleitkommamodellen optimiert, wenn eine GPU verfügbar ist. Außerdem werden 8‑Bit-quantisierte Modelle unterstützt und die GPU-Leistung ist mit der der Float-Versionen vergleichbar. Weitere Informationen zum GPU-Delegate finden Sie unter LiteRT auf GPU.

iOS

• Core ML-Delegate für neuere iPhones und iPads: Auf neueren iPhones und iPads, auf denen Neural Engine verfügbar ist, können Sie den Core ML-Delegate verwenden, um die Inferenz für 32-Bit- oder 16-Bit-Gleitkommamodelle zu beschleunigen. Die Neural Engine ist auf Apple-Mobilgeräten mit A12‑SoC oder höher verfügbar. Eine Übersicht über den Core ML-Delegate und eine detaillierte Anleitung finden Sie unter LiteRT Core ML-Delegate.

Delegierte nach Modelltyp

Jeder Accelerator ist für eine bestimmte Bitbreite von Daten konzipiert. Wenn Sie einem Delegate, der nur 8-Bit-quantisierte Vorgänge unterstützt, ein Gleitkommamodell zur Verfügung stellen, werden alle Vorgänge abgelehnt und das Modell wird vollständig auf der CPU ausgeführt. Damit Sie nicht überrascht werden, finden Sie in der folgenden Tabelle einen Überblick über die Unterstützung von Delegaten basierend auf dem Modelltyp:

Leistung validieren

Die Informationen in diesem Abschnitt dienen als grobe Richtlinie für die Auswahl der Delegaten, die Ihre Anwendung verbessern könnten. Es ist jedoch wichtig zu beachten, dass jeder Delegat eine vordefinierte Reihe von unterstützten Vorgängen hat und je nach Modell und Gerät unterschiedlich ausgeführt werden kann. Daher wird in der Regel empfohlen, einige Benchmarks durchzuführen, um zu ermitteln, wie nützlich ein Delegat für Ihre Anforderungen ist. Dies trägt auch dazu bei, die mit dem Anhängen eines Delegates an die LiteRT-Laufzeit verbundene Erhöhung der Binärgröße zu rechtfertigen.

LiteRT bietet umfangreiche Tools zur Leistungs- und Genauigkeitsbewertung, mit denen Entwickler Delegaten in ihrer Anwendung vertrauen können. Diese Tools werden im nächsten Abschnitt beschrieben.

Tools für die Bewertung

Latenz und Speicherbedarf

Das Benchmark-Tool von LiteRT kann mit geeigneten Parametern verwendet werden, um die Modellleistung zu schätzen, einschließlich der durchschnittlichen Inferenzlatenz, des Initialisierungsaufwands, des Speicherbedarfs usw. Dieses Tool unterstützt mehrere Flags, um die beste Delegatkonfiguration für Ihr Modell zu ermitteln. --gpu_backend=gl kann beispielsweise mit --use_gpu angegeben werden, um die GPU-Ausführung mit OpenGL zu messen. Die vollständige Liste der unterstützten Delegierungsparameter ist in der ausführlichen Dokumentation definiert.

Hier ist ein Beispiel für einen Lauf für ein quantisiertes Modell mit GPU über adb:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

Hier können Sie eine vorkompilierte Version dieses Tools für Android mit 64-Bit-ARM-Architektur herunterladen (weitere Informationen).

Genauigkeit und Richtigkeit

Delegates führen Berechnungen in der Regel mit einer anderen Genauigkeit als ihre CPU-Pendants aus. Daher ist die Nutzung eines Delegates für die Hardwarebeschleunigung in der Regel mit einem geringen Genauigkeitsverlust verbunden. Das ist nicht immer der Fall. Da die GPU beispielsweise Gleitkommazahlen verwendet, um quantisierte Modelle auszuführen, kann es zu einer leichten Verbesserung der Genauigkeit kommen (z. B. <1% Verbesserung bei der ILSVRC-Bildklassifizierung in den Top 5).

LiteRT bietet zwei Arten von Tools, um zu messen, wie genau sich ein Delegate für ein bestimmtes Modell verhält: aufgabenbasiert und aufgabenunabhängig. Alle in diesem Abschnitt beschriebenen Tools unterstützen die erweiterten Delegierungsparameter, die vom Benchmarking-Tool aus dem vorherigen Abschnitt verwendet werden. Die Unterabschnitte unten konzentrieren sich auf die Delegatbewertung (Führt der Delegat die gleiche Leistung wie die CPU aus?) und nicht auf die Modellbewertung (Ist das Modell selbst für die Aufgabe geeignet?).

Aufgabenbasierte Bewertung

LiteRT bietet Tools zur Bewertung der Richtigkeit bei zwei bildbasierten Aufgaben:

• ILSVRC 2012 (Bildklassifizierung) mit Top-K-Genauigkeit

• COCO-Objekterkennung (mit Begrenzungsrahmen) mit mittlerer durchschnittlicher Präzision (mean Average Precision, mAP)

Vorkompilierte Binärdateien dieser Tools (Android, 64-Bit-ARM-Architektur) sowie die Dokumentation finden Sie hier:

• ImageNet-Bildklassifizierung (Weitere Details) * COCO-Objekterkennung (Weitere Details)

Im folgenden Beispiel wird die Bildklassifizierung mit GPU auf einem Pixel 4 demonstriert:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

Die erwartete Ausgabe ist eine Liste der Top-K-Messwerte von 1 bis 10:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

Aufgabenunabhängige Bewertung

Für Aufgaben, für die es kein etabliertes On-Device-Bewertungstool gibt, oder wenn Sie mit benutzerdefinierten Modellen experimentieren, bietet LiteRT das Tool Inference Diff. (Android, 64-Bit-ARM-Binärarchitektur, hier)

Mit „Inference Diff“ wird die Ausführung von LiteRT (in Bezug auf Latenz und Abweichung des Ausgabewerts) in zwei Einstellungen verglichen:

• Singlethread-CPU-Inferenz
• Benutzerdefinierte Inferenz – definiert durch diese Parameter

Dazu generiert das Tool zufällige Gaußsche Daten und übergibt sie an zwei TFLite-Interpreters. Einer führt Single-Threaded-CPU-Kernels aus, der andere wird durch die Argumente des Nutzers parametrisiert.

Sie misst die Latenz beider sowie die absolute Differenz zwischen den Ausgabetensoren der einzelnen Interpreter auf Elementbasis.

Bei einem Modell mit einem einzelnen Ausgabetensor sieht die Ausgabe möglicherweise so aus:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

Das bedeutet, dass sich die Elemente des Ausgabetensors am Index 0 im Durchschnitt um 1.96e-05 von der CPU-Ausgabe unterscheiden.

Die Interpretation dieser Zahlen erfordert ein tieferes Wissen über das Modell und die Bedeutung der einzelnen Ausgabetensoren. Wenn es sich um eine einfache Regression handelt, mit der eine Art Punktzahl oder Einbettung ermittelt wird, sollte die Differenz gering sein. Andernfalls liegt ein Fehler beim Delegaten vor. Ausgaben wie die „Erkennungsklasse“ von SSD-Modellen sind jedoch etwas schwieriger zu interpretieren. Das Tool zeigt möglicherweise einen Unterschied an, was aber nicht unbedingt bedeutet, dass mit dem Delegaten etwas nicht stimmt. Betrachten Sie dazu zwei (fiktive) Klassen: „TV (ID: 10)“ und „Monitor (ID: 20)“. Wenn ein Delegat leicht von der Golden Truth abweicht und anstelle von „TV“ „Monitor“ anzeigt, kann die Ausgabedifferenz für diesen Tensor bis zu 20–10 = 10 betragen.