Benchmarking-Tools
LiteRT-Benchmark-Tools messen und berechnen derzeit Statistiken für die folgenden wichtigen Leistungsmesswerte an:
- Initialisierungszeit
- Inferenzzeit des Aufwärmstatus
- Inferenzzeit des stabilen Zustands
- Arbeitsspeichernutzung während der Initialisierung
- Arbeitsspeichernutzung insgesamt
Die Benchmark-Tools sind als Benchmark-Apps für Android und iOS sowie als native Befehlszeilen-Binärdateien, die alle dieselbe Kernleistung haben Messlogik. Beachten Sie, dass die verfügbaren Optionen und Ausgabeformate aufgrund der unterschiedlichen Laufzeitumgebungen leicht abweichen.
Android-Benchmark-App
Es gibt zwei Möglichkeiten, das Benchmark-Tool mit Android zu verwenden. Eins ist ein native Benchmark-Binärprogramm und ein weiteres ist ein Android- Benchmark-App, um besser einschätzen zu können, wie das Modell in der App abschneiden würde. Egal unterscheiden sich die Zahlen im Benchmark-Tool jedoch eine Inferenz mit dem Modell in der App ausführen.
Diese Android-Benchmark-App hat keine Benutzeroberfläche. Installiere es und führe es mit der adb
aus
und rufen Sie die Ergebnisse mit dem Befehl adb logcat
ab.
App herunterladen oder erstellen
Über die folgenden Links können Sie die fertigen Android-Benchmark-Apps für die Nacht herunterladen:
Android-Benchmark-Apps, die TF Ops unterstützen über Flex Delegate, klicken Sie auf die folgenden Links:
Sie können die App auch aus dem Quellcode erstellen, indem Sie Anleitung.
Benchmark vorbereiten
Bevor Sie die Benchmark-App ausführen, installieren Sie die App und übertragen Sie die Modelldatei per Push in den Gerät so an:
adb install -r -d -g android_aarch64_benchmark_model.apk
adb push your_model.tflite /data/local/tmp
Benchmark ausführen
adb shell am start -S \
-n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \
--es args '"--graph=/data/local/tmp/your_model.tflite \
--num_threads=4"'
graph
ist ein erforderlicher Parameter.
graph
:string
Der Pfad zur TFLite-Modelldatei.
Sie können weitere optionale Parameter zum Ausführen der Benchmark angeben.
num_threads
:int
(Standard=1)
Die Anzahl der Threads, die zum Ausführen des TFLite-Interpreters verwendet werden sollen.use_gpu
:bool
(Standard=falsch)
Verwenden Sie GPU Delegate.use_xnnpack
:bool
(Standard=false
)
Verwenden Sie XNNPACK-Bevollmächtigter.
Je nachdem, welches Gerät Sie verwenden, sind einige dieser Optionen möglicherweise nicht verfügbar sind oder keine Auswirkungen haben. Weitere Informationen finden Sie unter Parameter für weitere Leistungsparameter, die Sie mit der Benchmark-App ausführen könnten.
Sehen Sie sich die Ergebnisse mit dem Befehl logcat
an:
adb logcat | grep "Inference timings"
Die Benchmark-Ergebnisse werden so dargestellt:
... tflite : Inference timings in us: Init: 5685, First inference: 18535, Warmup (avg): 14462.3, Inference (avg): 14575.2
Native Benchmark-Binärprogramm
Das Benchmarktool ist auch als natives Binär-benchmark_model
verfügbar. Sie können
führen Sie dieses Tool über eine Shell-Befehlszeile auf Linux, Mac, eingebetteten Geräten und
Android-Geräten
Binärprogramm herunterladen oder erstellen
Laden Sie die nächtlichen vordefinierten nativen Befehlszeilen-Binärprogramme herunter. Folgen Sie dazu der Links unten:
Für nächtliche vorgefertigte Binärdateien, die TF-Operationen unterstützen über Flex Delegate, klicken Sie auf die folgenden Links:
Sie können die native Benchmark-Binärdatei auch aus Quelle auf Ihrem Computer.
bazel build -c opt //tensorflow/lite/tools/benchmark:benchmark_model
Zum Erstellen mit der Android-NDK-Toolchain müssen Sie die Build-Umgebung einrichten indem Sie dem guide oder verwenden Sie das Docker-Image, wie in diesem in diesem Artikel.
bazel build -c opt --config=android_arm64 \
//tensorflow/lite/tools/benchmark:benchmark_model
Benchmark ausführen
Um Benchmarks auf Ihrem Computer auszuführen, führen Sie die Binärdatei über die Shell aus.
path/to/downloaded_or_built/benchmark_model \
--graph=your_model.tflite \
--num_threads=4
Sie können denselben Satz an Parameter wie oben erwähnt, mit dem nativen Befehlszeilen-Binärprogramm.
Modellvorgänge zur Profilerstellung
Mit der Binärdatei des Benchmark-Modells können Sie außerdem ein Profil für Modellvorgänge erstellen
Ausführungszeiten der einzelnen Operatoren. Dazu übergeben Sie die Markierung
--enable_op_profiling=true
bis benchmark_model
beim Aufruf. Details sind
Erklärung
hier.
Native Benchmark-Binärdatei für mehrere Leistungsoptionen in einer einzelnen Ausführung
Außerdem steht ein praktisches und einfaches C++-Binärprogramm zur Verfügung,
mehrere Leistungsoptionen vergleichen
in einem Durchlauf. Diese Binärdatei basiert auf dem oben genannten Benchmark-Tool.
die jeweils nur eine einzige
Leistungsoption vergleichen kann. Sie teilen die
derselbe Build-/Installations-/Ausführungsprozess, aber der Build-Zielname dieser Binärdatei lautet
benchmark_model_performance_options
und es sind einige zusätzliche Parameter erforderlich.
Ein wichtiger Parameter für diese Binärdatei ist:
perf_options_list
: string
(Standard=alle)
Eine durch Kommas getrennte Liste der TFLite-Leistungsoptionen für das Benchmarking.
Für dieses Tool können Sie nachts vorgefertigte Binärdateien abrufen, wie unten aufgeführt:
Benchmark-App für iOS
Um Benchmarks auf einem iOS-Gerät auszuführen, müssen Sie die App
Quelle:
Legen Sie die LiteRT-Modelldatei im
benchmark_data
des Quellbaums und ändern Sie die Datei benchmark_params.json
. Diese
-Dateien werden in die Anwendung gepackt und die Anwendung liest Daten aus dem Verzeichnis. Besuchen Sie
die
Benchmark-App für iOS
.
Leistungs-Benchmarks für bekannte Modelle
In diesem Abschnitt werden LiteRT-Leistungs-Benchmarks bei ordnungsgemäßer Ausführung aufgeführt. auf einigen Android- und iOS-Geräten.
Android-Leistungsvergleiche
Diese Werte wurden mit dem natives Benchmark-Binärprogramm.
In Android-Benchmarks ist die CPU-Affinität auf große Kerne auf dem Gerät festgelegt um die Varianz zu reduzieren (siehe Details).
Dabei wird davon ausgegangen, dass Modelle heruntergeladen und in den Ordner
/data/local/tmp/tflite_models
-Verzeichnis. Die Benchmark-Binärdatei wird mithilfe von
dieser Anleitung
und es wird davon ausgegangen, dass sie sich im Verzeichnis /data/local/tmp
befindet.
So führen Sie die Benchmark aus:
adb shell /data/local/tmp/benchmark_model \
--num_threads=4 \
--graph=/data/local/tmp/tflite_models/${GRAPH} \
--warmup_runs=1 \
--num_runs=50
Legen Sie --use_gpu=true
für die Ausführung mit GPU-Delegate fest.
Die folgenden Leistungswerte werden unter Android 10 gemessen.
Modellname | Gerät | CPU, 4 Threads | GPU |
---|---|---|---|
Mobilenet_1.0_224(float) | Pixel 3 | 23,9 ms | 6,45 ms |
Pixel 4 | 14,0 ms | 9,0 ms | |
Mobilenet_1.0_224 (quant) | Pixel 3 | 13,4 ms | --- |
Pixel 4 | 5,0 ms | --- | |
NASNet Mobile | Pixel 3 | 56 ms | --- |
Pixel 4 | 34,5 ms | --- | |
SqueezeNet | Pixel 3 | 35,8 ms | 9,5 ms |
Pixel 4 | 23,9 ms | 11,1 ms | |
Inception_ResNet_V2 | Pixel 3 | 422 ms | 99,8 ms |
Pixel 4 | 272,6 ms | 87,2 ms | |
Inception_V4 | Pixel 3 | 486 ms | 93 ms |
Pixel 4 | 324,1 ms | 97,6 ms |
iOS-Leistungsvergleiche
Diese Werte wurden mit dem Benchmark-App für iOS
Zum Ausführen von iOS-Benchmarks wurde die Benchmark-App so geändert, dass sie die entsprechenden
und benchmark_params.json
wurde geändert, um num_threads
auf 2 festzulegen. Zur Verwendung
den GPU-Delegaten, die Optionen "use_gpu" : "1"
und "gpu_wait_type" : "aggressive"
wurden auch zu benchmark_params.json
hinzugefügt.
Modellname | Gerät | CPU, 2 Threads | GPU |
---|---|---|---|
Mobilenet_1.0_224(float) | iPhone XS | 14,8 ms | 3,4 ms |
Mobilenet_1.0_224 (quant) | iPhone XS | 11 ms | --- |
NASNet Mobile | iPhone XS | 30,4 ms | --- |
SqueezeNet | iPhone XS | 21,1 ms | 15,5 ms |
Inception_ResNet_V2 | iPhone XS | 261,1 ms | 45,7 ms |
Inception_V4 | iPhone XS | 309 ms | 54,4 ms |
LiteRT-Interna verfolgen
LiteRT-Interna in Android verfolgen
Interne Ereignisse des LiteRT-Interpreters einer Android-App können erfasst von Android-Tracing-Tools Bei Android sind es dieselben Trace API, sodass der Parameter Erfasste Ereignisse aus Java-/Kotlin-Code werden zusammen mit LiteRT angezeigt für interne Ereignisse.
Hier einige Beispiele für Ereignisse:
- Operatoraufruf
- Diagrammänderung nach Bevollmächtigtem
- Tensor-Zuweisung
Neben verschiedenen Optionen zum Erfassen von Traces behandelt dieser Leitfaden die Android- Studio CPU Profiler und die System-Tracing-App Weitere Informationen finden Sie unter Perfetto-Befehlszeilentool oder Systrace-Befehlszeilentool für weitere Optionen.
Trace-Ereignisse in Java-Code hinzufügen
Dies ist ein Code-Snippet aus der
Bildklassifizierung
Beispiel-App. Der LiteRT-Interpreter läuft in der
recognizeImage/runInference
. Dieser Schritt ist optional,
um festzustellen,
wo der Inferenzaufruf erfolgt.
Trace.beginSection("recognizeImage");
...
// Runs the inference call.
Trace.beginSection("runInference");
tflite.run(inputImageBuffer.getBuffer(), outputProbabilityBuffer.getBuffer().rewind());
Trace.endSection();
...
Trace.endSection();
LiteRT-Tracing aktivieren
Legen Sie die Android-Systemeigenschaft fest, um LiteRT-Tracing zu aktivieren.
debug.tflite.trace
auf 1, bevor die Android-App gestartet wird.
adb shell setprop debug.tflite.trace 1
Wurde diese Eigenschaft bei der Initialisierung des LiteRT-Interpreters festgelegt, Schlüsselereignisse (z.B. Operatoraufrufe) vom Interpreter werden erfasst.
Nachdem Sie alle Traces erfasst haben, deaktivieren Sie das Tracing, indem Sie den Attributwert festlegen. auf 0 gesetzt.
adb shell setprop debug.tflite.trace 0
CPU-Profiler von Android Studio
Erfassen Sie Traces mit dem CPU-Profiler von Android Studio indem Sie die folgenden Schritte ausführen:
Wählen Sie Ausführen > Profil „app“ über die oberen Menüs erstellen
Klicken Sie im Profiler-Fenster auf eine beliebige Stelle auf der CPU-Zeitachse.
Wählen Sie „Systemaufrufe verfolgen“ aus. zwischen den Modi für die CPU-Profilerstellung.
Drücken Sie auf "Aufzeichnen". Schaltfläche.
Drücken Sie auf "Stopp" Schaltfläche.
Prüfen Sie das Trace-Ergebnis.
In diesem Beispiel sehen Sie die Hierarchie der Ereignisse in einem Thread und Statistiken. für jede Bedienerzeit abrufen und den Datenfluss der gesamten App Threads.
System-Tracing-Anwendung
Erfassen Sie Traces ohne Android Studio, indem Sie die Schritte ausführen in System Tracing App
In diesem Beispiel wurden dieselben TFLite-Ereignisse erfasst und in Perfetto gespeichert. oder Systrace-Format an. Die erfassten Trace-Dateien können in der Perfetto-UI geöffnet werden.
LiteRT-Interna in iOS verfolgen
Interne Ereignisse des LiteRT-Interpreters einer iOS-App können erfasst von Instrumente in Xcode enthalten. Sie sind die iOS-Apps, signpost Ereignisse, sodass die erfassten Ereignisse aus dem Swift/Objective-C-Code zusammen angezeigt werden mit internen LiteRT-Events.
Hier einige Beispiele für Ereignisse:
- Operatoraufruf
- Diagrammänderung nach Bevollmächtigtem
- Tensor-Zuweisung
LiteRT-Tracing aktivieren
Legen Sie die Umgebungsvariable debug.tflite.trace
so fest:
Wählen Sie Produkt > Schema > Edit Scheme... (Schema bearbeiten...) aus.
Klicken Sie auf "Profil". im linken Bereich.
Heben Sie die Auswahl von „Argumente und Umgebungsvariablen der Ausführungsaktion verwenden“ auf .
Fügen Sie
debug.tflite.trace
unter „Umgebungsvariablen“ hinzu. .
Wenn Sie bei der Profilerstellung für die iOS-App LiteRT-Ereignisse ausschließen möchten, Deaktivieren Sie das Tracing, indem Sie die Umgebungsvariable entfernen.
XCode-Instrumente
So können Sie Traces erfassen:
Wählen Sie Produkt > Profile aus.
Klicken Sie in den Profilerstellungsvorlagen auf Logging, wenn das Instruments-Tool gestartet wird.
Drücken Sie auf "Start". Schaltfläche.
Drücken Sie auf "Stopp" Schaltfläche.
Klicken Sie auf "os_signpost". , um OS Logging-Subsystemelemente zu erweitern.
Klicken Sie auf „org.tensorflow.lite“. Betriebssystem-Logging-Subsystem.
Prüfen Sie das Trace-Ergebnis.
In diesem Beispiel sehen Sie die Hierarchie der Ereignisse und Statistiken für jedes Zeit des Bedieners.
Tracing-Daten verwenden
Mit den Tracing-Daten können Sie Leistungsengpässe erkennen.
Hier sind einige Beispiele für Erkenntnisse, die Sie vom Profiler erhalten, mögliche Lösungen zur Verbesserung der Leistung:
- Wenn die Anzahl der verfügbaren CPU-Kerne kleiner als die Anzahl der Inferenzen ist kann der CPU-Planungs-Overhead zu einer unterdurchschnittlichen Leistung führen. Sie können andere CPU-intensive Aufgaben in Ihrer Anwendung verschieben, um sich mit Ihrer Modellinferenz überschneiden, oder ändern Sie die Anzahl der Interpreter Threads.
- Wenn die Operatoren nicht vollständig delegiert werden, sind einige Teile der Modellgrafik auf der CPU statt auf dem erwarteten Hardwarebeschleuniger ausgeführt. Ich können die nicht unterstützten Operatoren durch ähnliche unterstützte Operatoren ersetzen.