Neuer KI-Beschleuniger für SoCs Arm Ethos-N78 macht künstliche Intelligenz schneller

Auf dem TechDay von Arm stellte sein Chefarchitekt den neuen Ethos-N78-Beschleuniger für künstliche Intelligenz vor. Dank massiver Datenkompression soll der IP-Block unter vergleichbaren Bedingungen 25 Prozent mehr Inference-Ausführungen pro Sekunde liefern als sein Vorgänger.

Bereits Anfang 2018 kündigte Arm sein »Projekt Trillium« an, eine Prozessor-IP für maschinelles Lernen auf der Basis neuronaler Netzwerke oder auch NPU genannt (Neuronal Networks Processing Unit). Die NPU soll CPUs und GPUs bei neuronalen Netzwerkoperationen ergänzen. 2019 wurde mit dem Ethos-N77 der erste IP-Block auf Basis der Scylla-Architekur vorgestellt, nunmehr folgte die Präsentation des Ethos-N78 durch seine Chefarchitektin Rachel Trimble auf Arms alljährlichem TechDay.

Im Gegensatz zu rechenzentrumsbasierten Ansätzen will Arm maschinelles Lernen »on the edge« möglich machen, das heißt direkt im Endgerät. Dies hat auf den ersten Blick zahlreiche Vorteile, wie etwa geringere Latenzzeiten, da der Datentransfer vom und zum Rechenzentrum entfällt, und Kostenreduktion zum Beispiel durch den Entfall des (drahtlosen) Datentransfers. Ein weiterer Aspekt ist die Datensicherheit, da die Daten das Endgerät nicht mehr verlassen und damit nicht mehr im Rechenzentrum selbst oder auf dem Weg dahin von Hackern abgefangen werden können.
Das Problem beim Edge-Computing besteht jedoch darin, dass die für neuronale Netzwerke wichtigen rechenintensiven Operationen wie Matrizen-Multiplikationen auf herkömmlichen CPU- und GPU-Architekturen nicht oder nur mit enormem Hardware-Einsatz realisierbar sind, da weder CPU- noch GPU-Mikroarchitekturen für diese Art von Workloads (zum Beispiel eben zweidimensionale MAC-Operationen im Fall von Matrizen) designt wurden. Als Antwort auf diese Herausforderungen wurden spezielle NN-Prozessoren entwickelt.

Der maschinelle Lernprozessor von Arm basiert auf einer neuen Architektur speziell für neuronale Netze, genannt Scylla. Sie ist vom Mobiltelefon bis hin zum Einsatz in Rechenzentren skalierbar und soll drei wesentliche Aspekte abdecken, die bei dieser Art von Workloads relevant sind: Effizienz bei der Berechnung von Faltungen, effiziente Datenverschiebung und hinreichend einfache Programmierbarkeit. Dazu kommen die »Engine« genannte Einheiten (Bild 1) für die reine Datenberechnung, ein Speichersubsystem und ein programmierbarer Block für die Ablaufsteuerung, der aus einem Mikrocontroller und einer DMA-Engine besteht. Die Faltungsberechnungen konzentrieren sich normalerweise auf 8-bit-Datentypen, die sich als Standard in maschinellen Lernanwendungen etabliert haben, wobei interne Operationen mit unterschiedlichen Präzisionen ausgeführt werden. Der Datendurchsatz konnte laut Arm bei Verwendung von int 8-Daten auf maximal 10 TOP/s gegenüber dem Vorgänger verdoppelt werden. Typische Muster mit 16 bit Aktivierung, 8 bit Gewichtung und 16x16 Operationen reduzieren freilich den Durchsatz. Die NPU kann dabei in drei Dimensionen vom Kunden konfiguriert werden, die Parameter dabei sind dabei neben dem Datendurchsatz das SRAM und die Vektor-Engines.

Die NPUs  können in einer Multicore-Konfiguration in einem eng angebundenen Cluster verbunden werden und dabei nichtkohärent verschaltet werden, um z. B. mehrere Inferenz-Typen parallel laufen zu lassen, wobei dann auch mehrere Adressräume unterstützt werden (Bild 1). Man kann aber auch ein neuronales Netzwerk auf allen Cores im kohärenten Betrieb ausführen, um den Durchsatz z. B. für die Analyse von hochauflösenden 4K-Bildern zu maximieren.

Das SRAM ist ein gemeinsamer Block, der als lokaler Puffer für die Berechnungen der Compute-Engines dient. Deren Funktionsblöcke arbeiten auf den verschiedenen Ebenen des neuronalen Netzwerkmodells, zum Beispiel Faltungsberechnungen, Gewichte-Dekoder usw. Die Faltungsberechnungen werden in einer 128 bit breiten MAC-Einheit ausgeführt.

Jede Engine hat ihren eigenen lokalen Speicher, der von den Modulen zur Verarbeitung von DNN-Modellen verwendet wird (DNN-Deep Neuronal Network). Der Ablauf ist typisch für DNN-Implementierungen, beginnend mit der Gewichtung der eingehenden Daten, der Verarbeitung über die MAC-Faltungsengine und der Verarbeitung der Ergebnisse durch die programmierbare Layer-Engine (PLE).

Entwicklung für zukünftige NN

Die sogenannte Programmable-Layer-Engine (PLE) soll die Architektur bezüglich fortlaufender Entwicklung des maschinellen Lernens flexibel halten. Ob die derzeitigen Modelle auch noch in Jahren verwendet werden, ist nämlich alles andere als sicher, wenn man erstmal hinreichende Erfahrungen mit den heutigen Modellen gemacht hat. Die PLE ermöglicht es dem ML-Prozessor, über Vektor- und NN-spezifische Befehle neue Operatoren einzubinden und verarbeitet die Ergebnisse der MAC-Engines, bevor die Daten wieder in das SRAM geschrieben werden.

Eine weitere Herausforderung beim Edge-Computing sind der limitierte Datendurchsatz vom und zum Chip und das verfügbare Energiebudget, insbesondere kann externes DRAM eine ähnlich hohe Leistungsaufnahme generieren wie der ML-Prozessor selbst. Die Architektur von Arm nutzt daher gängige Verfahren, um Feature-Maps verlustfrei zu komprimieren, indem das häufige Auftreten von sich wiederholenden Nullen in einem gegebenen 8×8-Block verborgen wird. SRAM, in dem Zwischenergebnisse und Daten gespeichert werden, beansprucht ebenfalls ein hohes Energiebudget, so dass jede Möglichkeit zur Reduzierung der benötigten SRAM-Kapazität genutzt wird.

Um den Speicherbedarf weiter zu reduzieren, werden auch die Gewichte komprimiert und reduziert. Analog zu einer biologischen Synapse im Gehirn repräsentieren die Gewichte das Wissen in einem neuronalen Netz. Die Reduktion von Neuronen, die keinen signifikanten Einfluss auf das Endergebnis haben würden, erlaubt es der Hardware, bestimmte Berechnungen zu überspringen und reduziert so die Anzahl der DRAM-Aufrufe.

Um die Anzahl der Berechnungen zu reduzieren, können Winograd-Technologien (Terry Allen Winograd, ein US-Informatiker, bekannt für Forschungen zur Künstlichen Intelligenz) eingesetzt werden, welche bei Netzwerken wie Inception v1-v4, Resnet-v1/v2, VGG16 und YOLOv2 Fläche und Energiebedarf um bis zu 50 % reduzieren können.

Bei gleicher Anzahl an MAC-Einheiten sowie identischem Takt und derselben Speicherbandbreite soll die Ethos-N78 im Vergleich zur Ethos-N77 je nach verwendetem Framework zwischen 18 (ResNetv2-50) und 40 Prozent (Inception-v4) schneller sein, im Mittel sollen es 25 Prozent mehr Inference-Ausführungen pro Sekunde sein.

Wie schon oben erwöhnt, ist die DRAM-Bandbreite ein Engpass in vielen
Anwendungsfällen. Würde man es schaffen, die Größe des des DRAMs in einem System zu verringern, würde man auch eine geringere Bandbreite der Speicherschnittstelle benötigen, geringere Systemkosten und System-Leistungsaufnahme haben und bei Systemen mit begrenzter Bandbreite auch eine höhere Robustheit erzielen.

Daher bestand Arms Design-Ziel primär darin, beim Ethos-N78 die Kompression für Aktivierungen und Gewichte gegenüber seinem Vorgänger weiter zu erhöhen.

Tatsächlich benötigt der Ethos-N78 je nach Framework 27 (ResNet-50) bis 55 Prozent (YOLOv3) weniger MByte pro Inference-Schritt, im Schnitt rund 40 Prozent weniger. Hierzu komprimiert die Ethos-N78 die Gewichte in Software zwischen zwischen dem SRAM und den MACs, sie werden in Hardware dann wieder entpackt (Bild 2, links). Die Aktivierungen werden sowohl in Hardware gepackt und wieder entpackt, konkret bei der Ausgabe von der NPU komprimiert und dekomprimiert, während sie eingelesen werden (Bild 2, rechts).

Die Rechenleistung pro mm2 Siliziumfläche soll dabei gut skalieren, konkret war von 5,5facher Rechenleistung bei 4,5facher Fläche bei Verwendung von ResNet-50 die Rede.

Arm will Workloads für NPU, CPUs und GPUs mit einer gemeinsamen Software-Bibliothek bedienen. Der Kern davon ist »Arm NN«, eine Art Brücke zwischen den gängigen neuronalen Netzwerkframeworks von Drittanbietern wie TensorFlow, Caffe und Android NNAPI sowie den verschiedenen Arm-CPUs und -GPUs (Bild 3). Code kann generisch geschrieben und auf jeder verfügbaren Verarbeitungseinheit ausgeführt werden. Beispielsweise kann ein budgetorientiertes Gerät mit herkömmlichem CPU- und GPU-Setup denselben NN-Code ausführen wie ein High-End-Gerät mit einem diskreten ML-Prozessor – nur langsamer. Arm bietet auch Unterstützung für IP von Drittanbietern, die bei Bedarf in den Stack integriert werden können. Durch optimierte Implementierungen von Arms Partnern soll Arms NN im Vergleich zu anderen NN-Frameworks deutlich schneller sein.

In gewisser Weise verfolgt Arm mit ArmNN den gleichen Ansatz, den Nvidia mit seiner Cuda-Plattform verfolgt, die auf eine Reihe von GPUs abzielt. Diese GPUs sind ähnlich, haben aber jeweils kleine Unterschiede, die durch die Cuda-Unterstützung verdeckt sind. Ein eigenes Framework macht es für Entwickler schwer, auf verschiedene Plattformen zu wechseln. Cuda beherrscht mehr als nur künstliche Intelligenz (AI) und ML-Anwendungen. Entwickler, die auf ML-Tools wie TensorFlow abzielen, können normalerweise von Plattform zu Plattform wechseln, einschließlich des ML-Prozessors von Arm. Bild 4 zeigt Arm NN im Systemkontext.

Last but not least hat Arm ein Software-Dienstprogramm zur Analyse der Netzwerkleistung auf Ethos-NPUs entwickelt (Bild 5), welches dem Entwickler hilft, die Rechenleistung seines NN-Modells zu verstehen und zu messen, bevor ein Silizium-Chip verfügbar ist. Wahlweise kann es Inferenzen/Sekunde messen oder Taktzyklen zählen, den SRAM/DRAM-Durchsatz in MB/Inferenz anzeigen ebenso wie die DRAM-Bandbreite (GB/s), ein Aktivitätsprofil pro Operator/Schicht und die Anzahl der MAC-Operationen in den Engines. Das Tool erzielt laut Arm eine hohe Genauigkeit, da der eigentliche Befehlsstrom durch den Ethos-NPU-Software-Treiber generiert wird.

Heute werden noch 85 % aller KI-Workloads auf CPUs oder CPUs/GPUs ausgeführt – mangels Alternative. Einfache Use-Cases wie die Erkennung von Schlüsselwörtern (z. B. »Hallo, Siri«, benötigt werden rund 400 MOP/s) mögen noch auf CPUs gut laufen, ein Freischalten von Geräten auf Grund von Gesichtserkennung benötigt hingegen schon rund 30 GOP/s – ein entsprechender ML-Prozessor wäre damit weniger als 90 % ausgelastet.

Die entscheidende Aussage ist, unterschiedliche Anwendungen benötigen unterschiedliche Hardware – CPU, GPU und NPU. Arms NN-Framework bietet hier den optimalen Support – und kann sogar Fremd-IP von Drittherstellern anbinden.