Der Compiler-Kern Von Bi Sheng, AscendNPU IR, Wurde Als Open Source veröffentlicht. Huawei-Architekt Hai Lijuan Erläutert Die Technischen Fortschritte Und Hebt Die Unterstützung Für Betreiber-Ökosysteme Wie Triton hervor.

1. AugustDer 9. Meet AI Compiler Technical Salon, veranstaltet von HyperAI, hat planmäßig stattgefunden.Gastredner führender Unternehmen und Forschungseinrichtungen wie der Beijing Academy of Artificial Intelligence, dem TileRT-Team, Tencent, Huawei und Zhiyuan Innovation führten intensive Gespräche über die gemeinsame Weiterentwicklung von KI-Compilern in verschiedenen Dimensionen, darunter Sprachausdruck, Operatorberechnung, Inferenzausführung und Szenarioimplementierung. Sie konzentrierten sich auf technische Herausforderungen, praktische Lösungen und Branchentrends und trugen mit ihren vielfältigen Ideen und praktischen Erfahrungen zum iterativen Prozess der KI-Compiler-Technologie und zur eingehenden Erforschung ihres industriellen Nutzens bei.

vor OrtHai Lijuan, Architektin von Huawei AscendNPU IR, teilte ihre Erkenntnisse zum Thema „AscendNPU IR: Open Source Compilation Base, Supporting Multi-Language Access to Ascend“.Sie stellte systematisch die technische Gesamtarchitektur und Designphilosophie der AscendNPU IR-Compilerkomponente vor und erläuterte detailliert die neuen Funktionen von AscendNPU IR für Ascend 950-Erweiterungen, die Vorteile der technologischen Iteration und den Aufbau einer Ökosystem-Community. Sie analysierte die Kernfunktionen und technischen Vorteile der Open-Source-Plattform, demonstrierte deren Anpassungsfähigkeit an verschiedene Frontend-Sprachen und präsentierte Entwicklern eine benutzerfreundliche und offene Plattform für die kollaborative Entwicklung mit AscendNPU IR.

HyperAI hat die Präsentationen zusammengestellt und zusammengefasst, ohne deren ursprüngliche Bedeutung zu verändern.

Folgen Sie dem offiziellen WeChat-Konto „HyperAI“ und antworten Sie mit dem Stichwort „0801 AI Compiler“, um die Präsentations-PPT des autorisierten Dozenten zu erhalten.

Warum ist die Triton-Programmierung effizient und benutzerfreundlich?

Als Programmiersprache ist Triton sowohl effizient als auch benutzerfreundlich. Woher rührt also dieser Entwicklungsvorteil?

Vereinfacht ausgedrückt verwendet Triton eine Python-ähnliche Syntax und bietet Block Level Tile-Programmierung, die die Entwickler vor den Details der Hardware-Speicherung, der Befehle, der Pipelining-Verarbeitung und anderer Operationen des abstrakten Kernels schützt und dadurch die Hürde für die Operatorentwicklung senkt und die Entwicklungseffizienz verbessert.

Das Tile-Programmiermodell von Triton bietet im Vergleich zu heterogenen Programmiersprachen wie C++ Vorteile gegenüber traditionellen Programmiersprachen.Dies ermöglicht es den Entwicklern, sich stärker auf die Datenpartitionierung für Operatoren zu konzentrieren und sich auf die Abstraktion von Tensoroperationen und logische Ausdrücke zu fokussieren.Auf Basis der Tile-basierten Programmierabstraktion können, mit Ausnahme der vom Benutzer verwalteten Datenplanung zwischen den Kernen, die Zusammenführung des Speicherzugriffs innerhalb eines Kerns und die Verwaltung des gemeinsam genutzten Speichers automatisch vom Compiler durchgeführt werden.

Wichtiger noch: Sowohl der Triton-Dialekt als auch der offizielle Triton-GPU-Compiler basieren auf einer mehrstufigen IR-Abstraktion, die auf MLIR aufbaut und eine tiefgreifende Optimierung für unterschiedliche Hardware ermöglicht.

AscendNPU IR wird weiterhin architekturoptimiert.

AscendNPU IR ist eine auf MLIR basierende Abstraktion der Ascend-Hardware auf Tile-Ebene, die zugrundeliegende Kompilierungsoptimierungen ermöglicht. Ihre Architektur ist im folgenden Diagramm dargestellt.Die AscendNPU IR-Schnittstelle kommuniziert mit der LLVM IR und wird letztendlich in die Ascend-Hardware-Binärdatei kompiliert.Drittanbietersprachen und Compiler höherer Schichten wie Triton können in AscendNPU IR integriert werden, wodurch Ascend-Kompatibilität erreicht wird.

Wichtigste technische Merkmale von AscendNPU IRErstens bietet es eine Bottom-up-Abstraktion für Ascend-Hardware, die verschiedene Ressourcen innerhalb des Kerns, wie Speicher und Datentransporteinheiten, abstrahiert. Zweitens stellt es abstrakte Operatoren auf Kachelebene bereit, die eine einheitliche, architekturübergreifende Unterstützung für die zugrunde liegende Hardware ermöglichen und die neuesten Hardwarearchitekturen von A2/A3 bis Ascend 950 SIMD und SIMT abdecken. Dank der Offenheit und Skalierbarkeit von MLIR unterstützt AscendNPU IR den Zugriff aus Sprachen höherer Schichten.

Das folgende Diagramm zeigt die Architektur des AscendNPU-IR-Kompilierungssystems, von Ascend A2/A3 bis zur neuesten Ascend 950-Hardware, die dieses Jahr erschienen ist. Die linke Seite zeigt die erste Version der AscendNPU-IR-Architektur aus dem letzten Jahr, die im Wesentlichen aus zwei Schichten besteht. Die obere Schicht ist die hardwareunabhängige Schicht HFusion, die hauptsächlich die mehrdimensionale Fusionsoptimierung implementiert. Sie basiert auf dem Community-Linalg und erweiterten OPs, verbindet sich mit verschiedenen standardisierten Dialekten, führt die Vorverarbeitung von Datentypen und OP-Normalisierung durch und optimiert die Fusion, beispielsweise durch Auto Schedule.

Die hardwarebezogene Schicht HIVM übernimmt hauptsächlich die Abstraktion der Ascend-Hardware auf hoher Ebene und führt nacheinander die Core-Mapping-Kompilierung, das On-Chip-Speicher-Mapping und das Processing-Unit-Mapping durch.

Der erste Schritt ist die Kompilierung des Kernel-Mappings.Dies umfasst Cube- und Vektorkerne. Hochrangige Kacheldarstellungen werden durch Kerne abgebildet, wobei Cube-Kerne anderen Cube-Kernen und Vektorkerne anderen Vektorkernen zugeordnet werden. Datenkommunikation, Datensynchronisation und die Verwaltung des Zwischenspeichers zwischen den Kernen erfolgen automatisch durch den Compiler, der zudem Optimierungen höherer Ordnung für die CV-Pipeline-Parallelität durchführt.

Als nächstes folgt das On-Chip-Speichermapping. Sowohl der Cube- als auch der Vector-Kern verfügen über eigenen On-Chip-Speicher. Damit ein Tensor auf Ascend-Hardware funktioniert, müssen die logischen Tensordaten in den entsprechenden physischen Speicher abgeleitet werden, ebenso wie die Cube-spezifische Ableitung des fraktalen Matrixformats. Die On-Chip-Speicherverwaltung erfolgt vollautomatisch durch den Compiler.

Die unterste Ebene ist die Zuordnung der Verarbeitungseinheiten.Die Pipeline-Synchronisierung gewährleistet Timing und parallele Effizienz. Vektorisierung und Tensorquantisierung ermöglichen es, mit leistungsstarken Hardware-Befehlen die abschließende Kompilierungsoptimierung durchzuführen.

Die rechte Seite des Diagramms zeigt einige der wichtigsten Änderungen der Ascend 950-Architektur im Vergleich zum Vorjahresmodell A2/A3. Die obere, hardwareunabhängige Schicht HFusion bleibt weitgehend stabil. Die größte Erweiterung stammt von der hardwareabhängigen Schicht HIVM, die von speicherbasiertem SIMD auf regbasiertes SIMD und SIMT erweitert wurde. Bisher erfolgte die CV-Fusion-Kompilierung über den globalen Speicher, wobei Cube- und Vektorkerne interagierten. Der Ascend 950 implementiert nun einen enger gekoppelten Ansatz für eine effizientere Dateninteraktion.

Insgesamt behält die neue Architektur weiterhin eine stabile zweischichtige Struktur bei, aber mit den Änderungen in der Architektur wurde die Tile-Kompilation deutlich verbessert.

Betrachten wir zunächst die Entwicklung der Vektor-Register-basierten SIMD-Architektur. Bei MemBased SIMD erfolgt die Vektorberechnung auf dem Chip mithilfe eines einheitlichen Puffers, und die Befehle werden direkt aus dem On-Chip-Speicher ausgeführt. Auf dem Ascend 950 wird die Berechnung mithilfe von Hochgeschwindigkeitsregistern durchgeführt, wodurch eine zusätzliche Registerebene entsteht. Für die Backend-Optimierung, insbesondere für Vektoroperationen, ändert sich der Kompilierungsprozess wie folgt:

Erstens, Vektorisierung für Reg-basierte Systeme. Tensoroperationen werden mittels vektorisierter Partitionierung auf Registerbefehle fester Breite abgebildet. Daten werden aus dem On-Chip-Speicher in Register geladen, Berechnungen werden auf Basis der Register durchgeführt und die Daten anschließend wieder im On-Chip-Speicher gespeichert. Dadurch entsteht eine Lade-Berechnungs-Speicher-Schleife.

Zweitens, Registergranularitätsfusion. Operationen, die wiederholt Daten in den On-Chip-Speicher laden und entladen, sind ineffizient. Tiefes Fusionsverfahren auf Registerbasis ermöglichen die Speicherung von Daten in Registern. Die Zusammenführung mehrerer Triton-Operationen in einer einzigen Schleife reduziert den Speicherbedarf. Dies erfordert den Einsatz verschiedener Suchalgorithmen und Kostenmodelle zur Entwicklung besserer Fusionsstrategien.

Drittens, Abstraktion des AVE-Dialekts.  Die benutzerfreundliche Vector-Dialekterweiterung von Ascend maskiert die zugrundeliegenden Hardware-Maskenunterschiede und ermöglicht so die Maskenanalyse und -ableitung. Hardware Vector Load bietet umfangreiche Optimierungsmöglichkeiten direkt im Befehlspfad. Durch die Aktivierung von Operationen direkt im Befehlspfad können mehrere Befehle zu einem einzigen Befehl kombiniert werden. All diese Optimierungen wurden speziell für den Regbase-SIMD-Dialekt entwickelt.

Die Ascend 950-Hardware unterstützt SIMT-Einheiten (grün dargestellt in der Abbildung unten). Dadurch stehen dem Vektorkern drei verschiedene Berechnungsmodi zur Verfügung: reines SIMD, reines SIMT und eine hybride, abwechselnde Ausführung von SIMT und SIMD. SIMT beschleunigt diskrete Speicherzugriffe, während dichte Berechnungen SIMD für eine aggressivere Vektoroptimierung nutzen können.

Vor der eigentlichen Vektor-SIMD- oder SIMT-Kompilierung führt der Kompilierungsprozess eine Fusionsanalyse und -optimierung durch. Dabei werden die für SIMT geeigneten Komponenten identifiziert, für separate SIMT- und SIMD-Kompilierungen extrahiert und anschließend für die Gesamtberechnung des Vektormodells kombiniert. Während dieses Prozesses werden sowohl SIMT als auch SIMD modelliert und analysiert.

Eng verwandt mit Attention-Operatoren ist die Aktualisierung und Änderung von CV-Kerneln. Auf A2/A3-Prozessoren fehlt die On-Chip-Verbindung zwischen Cube und Vector; die Interaktion erfolgt ausschließlich über den externen globalen Speicher. Auf dem Ascend 950 hingegen, wie im Diagramm rot dargestellt, befindet sich das Cube-Ergebnis im L0C und kann direkt in den On-Chip-Speicher des Vectors kopiert werden. Umgekehrt lässt sich das Berechnungsergebnis des Vectors ebenfalls direkt in den On-Chip-Speicher des Cubes kopieren, um es anschließend im Cube zu berechnen. Zusammenfassend lässt sich sagen, dass eine enge Kopplung und ein schneller Datenaustausch in der Computer Vision die Optimierung der Aufmerksamkeitsleistung erheblich verbessern.

Eine der Schlüsseltechnologien zur Optimierung von CV-Operatoren ist die Parallelisierung der CV-Pipeline. Die CV-Pipeline von Ascend Automation kann Latenzen besser verbergen und die Rechenleistung von Cube- und Vector-Kernen optimal nutzen.

Eine weitere wichtige Optimierung ist AutoSubTiling.Die Ascend Cube- und Vektorkerne sind im Verhältnis 1:2 konfiguriert, wobei zwei Vektorkerne einem Cube-Kern entsprechen. Der Compiler führt Vektoroperationen in einer 1:2-Blockaufteilung durch, sodass jeder Vektorkern die Hälfte der Daten gleichzeitig verarbeiten und die Berechnung dadurch schneller abschließen kann.

Die neueste Version der Feature-Generalisierungsarbeit des Compilers

Dieser Artikel stellt die wichtigen Generalisierungsarbeiten der neu veröffentlichten AscendNPU IR-Version vor.

Erstens: Interaktion der CV-Daten. Die Dateninteraktion zwischen den Kernen bei Cube- und Vektoroperationen wird automatisch vom Compiler durchgeführt. Die Berechnungen des Triton-Operators für Cube und Vektor können auf verschiedene Zweige des Kontrollflusses verteilt sein, was die Kompilierung und Analyse komplexer macht. Eine einfache Anweisungseinfügung per Pattern Matching ist nicht möglich. Im obigen Beispiel führen die beiden Zweige jeweils Cube- und Vektorberechnungen durch. Die CV-Dateninteraktion muss komplexe Kontrollflussableitungen unterstützen, um die funktionale Vollständigkeit zu gewährleisten.

Die neue Version verbessert die Analyse von Schlüsselpassagen in InsertCVLoadStore und vervollständigt die CV-Dateninteraktion durch globale Ableitung über komplexe Kontrollflüsse hinweg. Zunächst werden deterministische Ankerpunkte eingefügt: Matrixmultiplikationsoperationen werden in L1 eingegeben und in L0C ausgegeben, während Vektoroperationen sowohl ein- als auch ausgegeben werden. Anschließend werden basierend auf den initialen Ankerpunkten Typumwandlungsoperationen eingefügt, um Aufwärts- und Abwärtsableitung sowie Propagation über die Kontrollflüsse durchzuführen. Nach der Propagation ist die Speicherebene aller Operandentensoren eindeutig definiert.

Wie im obigen Beispiel gezeigt, enthält ein Tensor ursprünglich keine Speicherhierarchie-Semantik. Nach dem Einfügen einer Typumwandlungsoperation (Op) ist er auf den UB-Speicher des Vektorkerns beschränkt; darunter befindet er sich im L1-Speicher des Cube-Kerns. Während des Ableitungsprozesses entsteht ein Konflikt – die Speicherhierarchie ist inkonsistent, sodass eine Load-Store- oder Copy-Anweisung eingefügt werden muss, um die Datenverbindung herzustellen. Die Vorgehensweisen unterscheiden sich geringfügig zwischen den Generationen. A2/A3 Cube und Vector erfordern das Einfügen einer Global Memory Load-Store-Anweisung, um die Datenverbindung herzustellen, während Ascend 950 die Datenverbindung durch On-Chip-Datenkopieren herstellt.

Zweitens: MultiBuffer verbessert komplexe Kontrollabläufe. MultiBuffer ist eine entscheidende Voraussetzung für Pipelining und Parallelverarbeitung. Wie lässt sich also ein Tensor in einen MultiBuffer umwandeln?

Die bisherige Lösung unterstützte nur for-Schleifen. Während der Schleifeniteration nutzte MultiBuffer die Iterationsvariable der for-Schleife wieder und rotierte den Buffer-Slot entsprechend dieser Variable. Diese Lösung war jedoch insofern eingeschränkt, als sie keine anderen while-Schleifen und verschachtelte Kontrollstrukturen unterstützte. Daher wurde ein unabhängiger Buffer-Zähler eingeführt. Dieser Zähler folgt dem komplexen Kontrollfluss durch verzweigte Schleifen und erfasst so präzise Slot-Änderungen.

Darüber hinaus muss die alloc-Operation in der gemeinsamen Schleifenschicht von Cube und Vector sichtbar sein, damit sowohl Cube als auch Vector gleichzeitig Speicherzuweisungsoperationen durchführen können, wie z. B. die Zuweisung von 2 oder 3 Buffern, um die Konsistenz der MultiBuffer-Transformation zu gewährleisten.

Drittens: AutoBlockify, eine Multi-Core-Transformation, die eng mit der Optimierung des Ascend-Operators verwandt ist.Beim Schreiben von CUDA- oder Triton-Operatoren unterteilen wir den Code üblicherweise in viele Logikblöcke, die dann per Hardware-Scheduling ausgeführt werden. Ascend setzt stark auf repetitives Round-Robin-Scheduling. Dabei werden verschiedene Logikkerne in einer einzigen for-Schleife zusammengefasst und die Performance durch Software-Schleifen-Scheduling optimiert. Darüber hinaus können fortgeschrittene Optimierungstechniken wie MultiBuffer und Pipelining innerhalb der for-Schleife angewendet werden, um die Leistung weiter zu verbessern.

Viertens: CV-Pipeline.Der FlashAttention-Operator beispielsweise verteilt vier Aufgaben auf zwei Kerne, Cube und Vector, die separat ausgeführt werden. Diese Aufgaben werden sequenziell abgearbeitet, wobei die Berechnungen in Cube und Vector aufeinander warten müssen. Während des Kompilierungsprozesses kann MultiBuffer verwendet werden, um sicherzustellen, dass Cube und Vector so früh wie möglich ausgeführt werden, wodurch ein paralleler Pipeline-Beschleunigungseffekt erzielt wird.

Zuerst werden die C/V-Grenzpunkte identifiziert und anschließend der Codeabschnitt präzise in Cube- und Vektorbereich unterteilt. Danach wird MultiBuffer angewendet, um pipelinede parallele Transformationen basierend auf dem Scheduling-Algorithmus zu implementieren, einschließlich verschiedener Strategiemodi wie Unroll, Skew und dynamisch. Für unterschiedliche Rechenlasten kann der optimale pipelinede Parallelmodus ausgewählt werden.

Fünftens: CV 1:2 Aufteilung.Die beiden Vektorkerne und der Cube-Kern arbeiten zusammen, um die Rohdaten des Tensors so genau wie möglich zu halbieren und so eine effiziente Vektorberechnung zu ermöglichen. Idealerweise würden in der höheren Dimension parallele Achsen gefunden, um eine globale Halbierung durchzuführen. Allerdings können Kandidatenachsen Rechenoperationen wie Transponieren, Broadcasting und Reduzieren unterliegen, was die Komplexität der CV-1:2-Aufteilung erhöht.

Führen Sie zunächst eine globale Dimensionsanalyse durch, um die geeignetste Achse für die Aufteilung zu ermitteln. Nachdem die Aufteilungsachse bestimmt wurde, fügen Sie eine Startmarkierung für die Aufteilung am Ende der Speicheroperation ein und bewegen Sie sich von diesem Ende bis zum Wurzelknoten, um eine perfekte Aufteilung zu erreichen. Sollten komplexe Szenarien auftreten, die nicht aufgeteilt werden können, kehren Sie zum konservativen 1:1-Zustand zurück.

Darüber hinaus reicht in manchen komplexen Szenarien eine einfache Aufteilung der parallelen Achse für eine optimale Leistung nicht aus. Beispielsweise ist der FB8-Algorithmus für Aufmerksamkeit mit niedriger Präzision einer hohen Vektorlast ausgesetzt und erfordert daher eine Aufteilung und Reduzierung der Reduktionsachse. Da die beiden Vektorkerne keine Daten direkt austauschen können, müssen Zwischenergebnisse der Reduktion über den globalen Speicher für eine sekundäre Reduktion ausgetauscht werden, um die Gesamtreduktion und -aufteilung abzuschließen. Auch Szenarien mit dynamischen Formen erfordern verbesserte CV-1:2-Aufteilungsmethoden.

Triton-Ascend und AscendNPU IR sind Open Source und werden gemeinschaftlich entwickelt.

AscendNPU IR ist jetzt Open Source in der Ascend Community. Scannen Sie den QR-Code im Bild, um dem Open-Source-Projekt zu folgen. Das zweiwöchentliche Treffen der AscendNPU IR Community SIG wurde im Community-Aktivitätskalender veröffentlicht. Entwickler können sich dort vorab über die wöchentlichen Diskussionsthemen und Protokolle informieren.

Die Ascend Community hat Open-Source-Praktikumsprojekte und Community-Aufgaben ins Leben gerufen, um Entwicklern die Möglichkeit zu geben, sich am Aufbau des Ökosystems zu beteiligen. Den aktuellen Status der Aufgaben finden Sie hier. Sie können sich auch Aufgaben zuweisen. Die Community-Aufgaben haben unterschiedliche Schwierigkeitsgrade; bitte wählen Sie die Aufgaben entsprechend Ihren Fähigkeiten aus und beteiligen Sie sich.

Praktika und Community-Aufgaben im Open-Source-Bereich sind über Schnelllinks auf den Homepages der AscendNPU IR und des Triton-Ascend Open-Source-Repositorys verfügbar. Dort finden Sie auch Informationen zur Aufgabenübernahme. Jeder kann jeweils nur eine Aufgabe übernehmen. Die Community-Aufgaben werden regelmäßig aktualisiert, und der Entwicklungsprozess bleibt durchgehend interaktiv und offen. Jede Aufgabe bietet attraktive Belohnungen; jeder kann frei wählen.

Für Teilnehmer ohne Ascend-Entwicklungsumgebung bietet die Community mit HiDevLab (https://hidevlab.huawei.com/home) eine kostenlose Ascend-Rechenplattform an. Entwickler können sich registrieren und Rechenleistung beantragen. Nach erfolgreicher Bewerbung erhalten sie standardmäßig 100 Stunden kostenlose Rechenzeit. Entwickler, die Community-Aufgaben angenommen haben, können Rechenleistung beantragen, um die Entwicklung und Überprüfung dieser Aufgaben abzuschließen.

Vielen Dank für Ihre Aufmerksamkeit!