Optimierung des Neural Compute Stick für die Inferenz von Bildverarbeitungsmodellen am Edge

Tulip ist eine Computervision fürden Fertigungsbereich. Sie ermöglicht die ErstellungApps Computervision nutzen, Computervision Arbeitsabläufe Computervision steuern und Computervision überwachen. Tulip kann zur Erkennung von Aktivitäten am Arbeitsplatz sowie zur Verfolgung von Objekten und Personen eingesetzt werden. Die Bildverarbeitungssignale lassen sich so konfigurieren, dass sie die Sicherheit, manuelle Montage , die Konfektionierung und Kommissionierung sowie viele andere Anwendungen überwachen, die die Zuverlässigkeit erhöhen und Fehler reduzieren. Im Zentrum von Vision für den Fertigungsbereich stehen Computervision , die auf tiefen neuronalen Netzen basieren. Die Algorithmen sind so konzipiert, dass sie auf der vorhandenen Hardware in der Fertigung laufen, bei der es sich oft um einen einfachen PC mit Windows handelt. Um die allerneueste KI auf leistungsschwache Computer in der Fertigung zu bringen, verwenden wir den Intel Compute Stick Version 2 (NCS v2), auch bekannt als Movidius Vision Processing Unit (VPU). Ein USB-Gerät mit Rechenhardware, das für den Betrieb tiefer neuronaler Netze ausgelegt ist und die Rechenlast von der CPU oder GPU des PCs nimmt. Der NCS ist eine kostengünstige und stromsparende Lösung für KI am Netzwerkrand, die zudem Plug-and-Play-fähig ist.

Warum ist eine Optimierung erforderlich?

Wir haben festgestellt, dass der Intel für unsere Anforderungen bei Tulip ein sehr leistungsfähiger Prozessor ist. Unser Schwerpunkt liegt auf der Erkennung von Personen und deren Aktivitäten an der Produktionslinie; daher ist es wichtig, dass wir Hände und Personen in einem eingehenden Kamerastream erkennen können. Die neuesten Modelle zur Personenerkennung nutzen tiefe neuronale Netze und ressourcenintensive Modelle, was den NCS in Bezug auf die Leistung vor eine Herausforderung stellt.

Bei der Standardausführung eines Handerkennungsmodells konnten wir eine Inferenzgeschwindigkeit von 14 Bildern pro Sekunde (FPS) erreichen. Es sind einige Optimierungen erforderlich, damit wir unser Ziel erreichen können, menschliche Handlungen in Echtzeit zu erkennen (umgangssprachlich gilt hierfür eine Bildrate von 30 FPS und mehr, was der üblichen Bildrate der meisten Kameras entspricht). Außerdem wollten wir das Beste aus der NCS-Hardware herausholen, deren Kosten im Voraus bezahlt werden. Die NCS-Spezifikationen geben eine theoretische Verarbeitungsrate von 100 GFLOP/s (Giga-Gleitkommaoperationen pro Sekunde) an, während wir anfangs nur 20–25 GFLOP/s (mit einem 1,5-GFLOP-Netzwerk bei 14 FPS) bei beträchtlicher Latenz herausholen konnten.

In diesem Artikel gehen wir auf die von uns untersuchten Optimierungstechniken ein und stellen insbesondere jene vor, die für uns den entscheidenden Unterschied gemacht und uns in den Bereich der Echtzeit-Inferenz gebracht hat. Intel hat Intel einen nützlichen Leitfaden zur Optimierung von Netzwerken für NCSv2 bereitgestellt, auf den wir uns bei unserer Arbeit gestützt haben.

Zunächst haben wir den Graphen und die Gewichte für ein Netzwerk zur Handerkennung bereitgestellt. Wir trainieren unsere eigenen Modelle zur Handerkennung, die auf die Leistung in Produktionsumgebungen abgestimmt sind, aber es gibt online frei verfügbare Modelle, die überraschend gut funktionieren. Hier ist ein Beispielmodell auf GitHub, das wir für Tests und Basisvergleiche verwendet haben. Bei einem vortrainierten Modell möchte man es möglicherweise für den eigenen Zweck und die eigenen Daten feinabstimmen. Wir haben eine Reihe von Tools aus Googles TensorFlow verwendet, um Techniken zur Feinabstimmung und zum Transferlernen zu testen.

Damit ein Modell auf dem NCS ausgeführt werden kann, muss es in das richtige Format konvertiert werden. Intel nutzt OpenVINO für die Entwicklung auf dem NCS. Es handelt sich um ein sehr umfassendes Toolkit, das die Ausführung von Modellen in heterogenen Umgebungen (z. B. CPU, GPU, VPU) ermöglicht, die Konvertierung aus vielen Quellarchitekturen wie TensorFlow, ONYX, PyTorch usw. unterstützt und die Optimierung von Modellen auf verschiedene Weise ermöglicht.

Um ein Modell zu konvertieren, muss es sich zunächst in einem „frozen graph“-Zustand befinden. Das bedeutet, dass nur die für die Inferenz benötigten Teile des neuronalen Netzes beibehalten werden, während alles andere verworfen wird; außerdem muss sichergestellt sein, dass alle Gewichte des Graphen finalisiert sind. Es gibt verschiedene Daten, die mit den Ausführungsgraphen des neuronalen Netzes einhergehen und mit dessen Training zu tun haben. Diese werden für die Inferenz nicht benötigt und können bei der Konvertierung sogar Probleme verursachen. Um unser Beispielmodell zur Handerkennung in einen „frozen graph“-Zustand zu versetzen, verwenden wir das folgende Skript:

python3 /content/models/research/object_detection/export_inference_graph.py \
 --input_type=image_tensor \ 
 --pipeline_config_path=/path/to/pipeline.config \
 --output_directory=/path/to/output_directory \
 --trained_checkpoint_prefix=/path/to/model.ckpt-xyz # Ersetze xyz durch den Wert des Checkpoint-Schritts.

Abbildung 1. Skript zum Exportieren des Inferenzgraphen für Modelle, die mit der TensorFlow Object Detection API trainiert wurden

Für die Konvertierung nutzen wir die DL (Deep Learning) Workbench von OpenVINO. Sie lässt sich problemlos auf allen gängigen Betriebssystemen installieren und kann als eigenständige grafische Anwendung (GUI) oder über die Befehlszeile bedient werden. Wir konzentrieren uns hier auf die Verwendung der GUI zur Visualisierung unserer Vorgänge. OpenVINO bietet eine hervorragende „Erste Schritte“-Anleitung für die DL Workbench. In der DL Workbench laden wir das Modell und legen die Formen der Eingabe- und Ausgabetensoren fest.

Abbildung 2. Modellkonfiguration in der Intel Learning Workbench

Die Arbeitsumgebung bietet zudem sehr nützliche Werkzeuge zur Leistungsmessung bei der Modellausführung sowie Tests, mit denen sichergestellt werden kann, dass das Modell hinsichtlich der implementierten neuronalen Netzschichten auf dem NCS lauffähig ist.

Abbildung 3. Modellvergleich anhand von Testdaten (ohne Anmerkungen) unter Verwendung Intel CPU

Schließlich macht es die Arbeitsumgebung sehr einfach, das Modell in das vom NCS geforderte Format zu konvertieren:

Abbildung 4. Herunterladen des konvertierten OpenVINO-Modells

Zunächst haben wir den Beispielcode von OpenVINO für die Objekterkennung verwendet. Dieser nutzt eine einfache synchrone API, die eine Inferenzanforderung (IR) an das NCS sendet und wartet (den Thread blockiert), bis diese abgeschlossen ist, wobei davon ausgegangen wird, dass die Ausführung des Modells einfach einige Zeit in Anspruch nimmt. Dies führte zu unserer ursprünglichen, enttäuschenden Leistung von etwa 14 FPS. Nach einer Berechnung stellten wir fest, dass dies im Vergleich zu den tatsächlichen Fähigkeiten des NCS eine deutlich zu geringe Leistung darstellt.

Wir stellten die Hypothese auf, dass das Modell zu groß ist und dies der Grund für die schlechte Leistung ist. Daher versuchten wir zunächst, die Größe des Eingabebildes für das Modell zu reduzieren. Die vorherrschende Theorie war, dass die großen anfänglichen Faltungsschichten bei großen Eingabegrößen vor dem Pooling einen Großteil der Rechenlast tragen. Wir änderten die Eingabeform von ursprünglich 224x224 auf 64x64 und 128x128. Dies führte jedoch auch zu einem erheblichen Rückgang der Genauigkeit – was für uns inakzeptabel ist.

Abbildung 5. Balkendiagramm, das die FPS im Vergleich zur Eingabegröße des Modells darstellt. Alle Modelle basieren auf Mobilenetv2 (SSDLite). Bei Mobilenetv2 xy-abc steht xy für den Tiefenmultiplikator und abc für die Eingabegröße.

Wir haben auch verschiedene Backbone- und Detektorarchitekturen getestet, z. B. MobileNet V3 und EfficientDet, die im OpenVINO Model Zoo verfügbar sind. Wir sind jedoch zu dem Schluss gekommen, dass das Verhältnis zwischen Geschwindigkeit und Genauigkeit bei der Inferenz auf NCS für unseren Anwendungsfall nicht günstig ist.

Abbildung 6. Modell-Backbone und Architektur im Vergleich zur Bildwiederholrate (FPS). Alle Mobilenet-Backbones verwenden SSDLite als Box-Detektoren.

Da uns diese Ergebnisse vor ein Rätsel stellten, versuchten wir, das Modell zu beschneiden. Beim Beschneiden entfernen wir Teile des Modells, die nicht wesentlich zu seiner Leistung beitragen, wobei wir Geschwindigkeit zugunsten der Genauigkeit opfern. Wir probierten das intelligente Modell-Pruning von TensorFlow aus, das auf der Suche nach „leichten Schichten“ basiert. Derzeit unterstützt TensorFlow das Modell-Pruning nur für sequenzielle Modelle auf Keras-Basis und nicht für Modelle, die mit der TensorFlow Object Detection API trainiert wurden. Dies erschwerte unsere Bemühungen, ein leichtgewichtiges, beschnittenes Modell zu erstellen, zusätzlich.

Ein weiterer Ansatz zur Optimierung ist die Quantisierung. Bei der Quantisierung ändern wir die numerische Genauigkeit einiger Schichten im Netzwerk hin zu einem weniger rechenintensiven, schnelleren Typ. Dies setzt voraus, dass leistungsschwächere Hardware, wie beispielsweise Mobiltelefone, bei der Ausführung von Gleitkomma-Arithmetikoperationen (z. B. 32-Bit-Gleitkomma, FLOAT32) langsamer ist als bei Ganzzahloperationen (z. B. 8-Bit-Ganzzahl, INT8). Dies ist einer der besten Tricks zur Optimierung neuronaler Netze. Allerdings unterstützt das NCS auch hier keine INT8-Operationen, und wir stehen wieder am Anfang.

Schließlich haben wir nach zahlreichen Versuchen mit Optimierungstechniken festgestellt, dass wir nicht einfach auf den Abschluss der Inferenzanforderung warten können, sondern mithilfe der asynchronen API von OpenVINO (wie im Leitfaden beschrieben) parallel eine weitere Anforderung ausführen können. Wir können eine weitere Inferenzanfrage empfangen, während die anderen noch laufen, und diese an ein anderes Bild zur Erkennung weiterleiten. Da wir Echtzeit-Bilder von der Kamera erfassen, führt dies zu einer geringen Verzögerung bei der Ausgabe, aber zu einem sehr großen Geschwindigkeitsgewinn. Das folgende Diagramm zeigt den Vorteil des asynchronen IR-Streams:

In der Praxis betreiben wir einen Pool mit vier gleichzeitig laufenden Inferenzanfragen. Die Größe des Pools wird durch das Inferenzgerät, d. h. den NCS, bestimmt. Eine CPU verfügt über mehr Inferenzanfragen als der NCS, und eine leistungsstarke GPU kann sogar noch weitaus mehr haben. Wenn ein Modell jedoch groß und daher langsam ist und die Bearbeitung der Anfrage viel Zeit in Anspruch nimmt, kann es vorkommen, dass der Pool an Inferenzanfragen erschöpft ist und es dennoch zu einem Rückgang der Bildrate kommt.

Unsere wichtigsten Kennzahlen für die Leistungsbewertung sind die Bildwiederholrate (FPS) und die Latenz. Wir streben eine höhere Bildwiederholrate und eine geringere Latenz an, doch beim asynchronen API-Ansatz stehen diese beiden Faktoren in einem Spannungsverhältnis zueinander. Die Ausführung von mehr gleichzeitigen IRs bedeutet zwar eine längere Aufwärmphase und höhere Latenz, führt aber insgesamt zu einer schnelleren Durchlaufzeit.

Zur Leistungsmessung verfügen wir über interne Tools, haben aber auch das von OpenVINO bereitgestellte C++-Benchmark-Tool genutzt. Es ermöglicht die Ausführung der Modelle auf dem NCS und liefert sehr nützliche Statistiken. Auch wenn es sich dabei nicht um eine echte Simulation der Modellinferenz in Tulip handelt, lieferte es uns sehr gute Daten, ohne dass wir das Modell tatsächlich in unserem Framework ausführen mussten.

Abbildung 7. Modellleistung von SSDLite MobilenetV2 bei Verwendung der asynchronen und der synchronen API.

Wir haben festgestellt, dass sich die Intel und das OpenVINO-Toolkit für unsere Anforderungen als sehr nützlich erwiesen haben. Es handelt sich nicht nur um eine heterogene Plattform zur Ausführung von Modellen, die reibungslos mit der NCS-VPU zusammenarbeitet, sondern bietet auch eine recht umfassende Unterstützung für Konvertierung und Benchmarking sowie nützliche Tools zur Optimierung. Wir haben vieles ausprobiert, bevor wir die Option der asynchronen Inferenz gefunden haben, und dabei viel gelernt. Auf diese Weise liefern wir unseren Kunden mit Tulip erstklassige Leistung zu sehr geringen Kosten. Die asynchrone API in OpenVINO erzielte im Vergleich zu vielen anderen traditionellen Ansätzen bei der Optimierung der Modellinferenz die größte Leistungssteigerung, doch diese können weiterhin nützlich sein, wenn wir weitere Deep-Learning-Modelle in die Vision-Produktion einführen.