AscendNPU IR: Wie Huawei Triton mit Ascend-Hardware verbindet

Huawei positioniert AscendNPU IR nicht als weitere Programmiersprache, sondern als offene Compiler-Grundlage unterhalb des BiSheng-Compilers. Auf dem neunten technischen Meet-AI-Compiler-Salon von HyperAI am 1. August 2026 erläuterte Hai Lijuan, Architektin für AscendNPU IR, wie die MLIR-basierte Schicht Triton und andere Operator-Ökosysteme mit Ascend-Hardware verbinden soll. 37

Für Entwickler ist das vor allem deshalb relevant, weil der Compiler einen Teil der zunehmend komplizierten Hardwarearbeit übernimmt: die Aufteilung in Kacheln, Datenbewegungen durch den On-Chip-Speicher, die Abstimmung von Cube- und Vector-Berechnungen sowie die Erzeugung von gerätespezifischem Code.

Die Rolle von AscendNPU IR im BiSheng-Compiler

AscendNPU IR ist eine auf MLIR basierende Zwischenrepräsentation für Ascend-optimierte Operatoren. Die mehrstufige Architektur bietet einerseits höhere Abstraktionen, die Details von Instruktionen und Synchronisation verbergen. Andererseits stehen niedrigere Ebenen bereit, mit denen Entwickler Speicherplatzierung und Pipeline-Verhalten gezielt beeinflussen können. 411

Die Compiler-Schicht kann aus mehreren Richtungen angesprochen werden. Domänenspezifische Sprachen wie Triton und TileLang lassen sich in AscendNPU IR überführen. Frameworks und Compiler können außerdem über Torch IR, Linalg/HFusion IR oder HIVM IR angebunden werden. Auf höheren Ebenen sind automatische Fusion, Kachelung, Aufteilung und Ablaufplanung möglich; HIVM erlaubt eine deutlich direktere Kontrolle über Ascends Speicherebenen und Rechenpipelines. 522

Der vereinfachte Ablauf sieht so aus:

Triton, TileLang oder Framework-IR
              ↓
       MLIR-basiertes AscendNPU IR
              ↓
       HFusion → HIVM-Lowering
              ↓
       Ascend-Instruktionen und Binärdatei

Der dokumentierte Kompilierungsweg nutzt bishengir-compile, um MLIR in ein geräteseitiges Objekt umzuwandeln. Dieses kann anschließend über die CANN-Runtime registriert und auf einer Ascend-NPU ausgeführt werden. 6

Warum die Kachel-Abstraktion entscheidend ist

Eine Kachel – im Englischen „Tile“ – ist ein überschaubarer Block aus Tensor-Daten und Berechnungen. Ohne eine gemeinsame Abstraktion müsste jedes Frontend einzelne Transfers, Speicherentscheidungen, Synchronisationspunkte und Hardwareinstruktionen separat beschreiben.

AscendNPU IR führt diese Arbeit in einer gemeinsamen, kachelorientierten Darstellung zusammen. Die höheren Ebenen erlauben es, Tensoroperationen zu formulieren, ohne jedes Hardwaredetail vorzugeben. Auf den unteren Ebenen kann der Compiler dagegen die Platzierung in GM, UB, L1 und L0 berücksichtigen oder explizit vorgeben. Gleiches gilt für die Ressourcen von Vector, Cube und den Datenbewegungseinheiten. 522

Damit entsteht ein Kompromiss zwischen Portabilität und Feintuning: Ein Triton- oder Framework-Frontend kann dieselbe Compilerbasis ansprechen, während besonders performancekritischer Code bei Bedarf auf eine hardwarebewusstere Darstellung abgesenkt wird. Die offizielle Architektur beschreibt dafür entkoppelte Abstraktionen, die schrittweise Ascend-Instruktionen, kerninterne und kernübergreifende Ressourcen sowie Ressourcen des Systems-on-Chip modellieren. 11

HFusion und HIVM teilen die Optimierungsarbeit auf

HFusion: Fusion und Planung auf höherer Ebene

HFusion ist in dem zweistufigen Modell die vergleichsweise hardwareunabhängige Ebene. Sie beschreibt Tensoroperationen auf höherem Niveau und führt Transformationen wie Fusion, Bufferization, Kachelung und Ablaufplanung aus, bevor der Compiler konkrete Hardwareinstruktionen festlegt. 1122

Auf dieser Ebene können mehrere Operationen zusammengeführt und umfangreichere Berechnungen in Kacheln zerlegt werden, die zum jeweiligen Ausführungsmodell passen. Die übergeordnete Bedeutung der Operationen bleibt dabei erhalten, während der Code auf das Ascend-spezifische Lowering vorbereitet wird.

HIVM: Lowering mit Blick auf die Hardware

HIVM ist die hardwarebewusste Ebene. Sie übersetzt Kachelausdrücke in Operationen, die Ascends Recheneinheiten, Speicherhierarchie und Pipeline-Verhalten abbilden. Zu ihren Aufgaben gehören unter anderem:

• Matrixoperationen den Cube-Kernen und Vektoroperationen den Vector-Kernen zuzuordnen;
• Kommunikation und Synchronisation zwischen diesen Einheiten einzufügen oder zu verwalten;
• temporären Workspace zu organisieren;
• logische Tensoren auf physischen On-Chip-Speicher abzubilden;
• Cube-orientierte Layouts wie fraktale Matrixdarstellungen zu berücksichtigen; sowie
• Vektorisierung, Tensorisierung, Pipelining und Instruktionsoptimierungen anzuwenden. 214

So kann der Compiler in zwei unterschiedlichen Abständen zur Hardware optimieren: HFusion betrachtet die größere Tensorstruktur und mögliche Fusionen, HIVM die konkreten Speicher- und Rechenressourcen, die für die Ausführung der resultierenden Kacheln benötigt werden.

Was sich mit Ascend 950 ändert

Die Aufteilung zwischen HFusion und HIVM bleibt bestehen. Die hardwarebewusste Ebene muss beim Ascend 950 jedoch mehr abdecken als den bisherigen, speicherbasierten SIMD-Pfad. Die für Ascend 950 beschriebenen Erweiterungen umfassen registerbasiertes SIMD und SIMT. 2

Registerbasiertes SIMD

Beim registerbasierten SIMD werden Daten aus dem On-Chip-Speicher in Register geladen, dort verarbeitet und anschließend zurückgeschrieben. Wenn es die Berechnung erlaubt, kann eine Fusion auf Registerebene Zwischenwerte über mehrere Operationen hinweg in den Registern halten. Das reduziert wiederholte Lade- und Speichervorgänge. 2

SIMT für weniger regelmäßige Berechnungen

SIMT bietet eine zusätzliche Ausführungsform für geeignete Bereiche mit unregelmäßigen Zugriffen oder divergierenden Abläufen. Der beschriebene Ansatz trennt Arbeit, die von SIMT profitiert, von dichtem, SIMD-freundlichem Code. Beide Teile werden jeweils passend transformiert und anschließend wieder in die umfassendere Vektorberechnung integriert. 2

Engere Kommunikation zwischen Cube und Vector

Die Präsentation hob außerdem eine Veränderung bei der Cube-Vector-Kommunikation hervor. In früheren A2/A3-Abläufen liefen manche Übergaben zwischen Cube- und Vector-Berechnungen über den globalen Speicher. Beim Ascend 950 können Cube-Ergebnisse aus L0C in den On-Chip-Speicher des Vector-Bereichs gelangen und Vector-Ergebnisse zurück in den Cube-Speicher übertragen werden. Dadurch verkürzt sich der Weg zwischen den beiden Rechendomänen. 2

Das ist besonders für Operatoren relevant, bei denen auf eine matrixorientierte Cube-Berechnung eine Vektorverarbeitung folgt. Der Compiler muss allerdings weiterhin korrekt bestimmen, wo Tensoren liegen und wann Transfers notwendig sind – insbesondere dann, wenn Cube- und Vector-Operationen in unterschiedlichen Kontrollflusszweigen auftreten.

Compiler-Pässe, die das Modell praktisch nutzbar machen

Mehrere benannte Passes zeigen, wie AscendNPU IR aus der Abstraktion konkrete Speicher- und Scheduling-Entscheidungen ableitet.

InsertCVLoadStore

Der erweiterte Ablauf von InsertCVLoadStore analysiert Cube-Vector-Kommunikation auch über komplexe Kontrollflüsse hinweg. Statt Transfers lediglich anhand lokaler Muster einzufügen, setzt er zunächst Anker für Speicherorte – etwa Matrixeingaben in L1, Matrixausgaben in L0C und Vektordaten in UB. Diese Vorgaben werden anschließend durch das Programm propagiert. Wo Speicherdomänen nicht zusammenpassen, fügt der Compiler notwendige Konvertierungen oder Kopien ein. 2

Bei A2/A3 können die beschriebenen Übergaben über Lade- und Speicheroperationen im globalen Speicher erfolgen. Der Ascend 950 kann, sofern unterstützt, die engeren On-Chip-Wege nutzen. 2

MultiBuffer

MultiBuffer beschreibt mehrere Kopien eines bereits vorhandenen Tensors. Damit lassen sich Pingpong-Puffer aufbauen und Datenbewegungen mit Berechnungen überlappen, sofern Speicherbudget und Zeitplanung dies erlauben. 1718

AutoBlockify und DynamicCVPipeline

AutoBlockify und DynamicCVPipeline gehören zu den Ascend-spezifischen Passes im Triton-Ascend-Compiler. Die Namen verweisen auf zwei zentrale Aufgaben: Berechnungen in ausführbare Blöcke zu zerlegen und das Pipeline-Verhalten zwischen Cube und Vector aufzubauen. 19

Die dokumentierten Funktionen umfassen außerdem automatische Speicherplanung, Synchronisation, Scheduling sowie Optimierungen für Cube-Vector-Ausführung. 24

CV-Aufteilung im Verhältnis 1:2

Für eine relevante Ascend-Konfiguration beschreibt die Präsentation ein Verhältnis von einem Cube-Kern zu zwei Vector-Kernen. AutoSubTiling kann die Vector-Arbeit so aufteilen, dass beide Vector-Kerne parallel unterschiedliche Abschnitte verarbeiten. 214

Was die Öffnung für Entwickler bedeutet

Huawei hat AscendNPU IR gemeinsam mit Triton-Ascend für eine gemeinschaftliche Weiterentwicklung als Open Source veröffentlicht. Triton-Ascend ist das auf Ascend zugeschnittene Triton-Compiler-Framework. Es behält die zentrale Triton-Syntax bei und ergänzt sie um Kompilierungs- und Deployment-Unterstützung für Ascend-A2-, A3- und 950-Produkte. 3037

Für Entwickler entsteht damit ein direkterer Einstieg in Compiler-Passes, Frontend-Integration, Operator-Lowering und hardwarebewusste Optimierung, ohne eine komplette Compiler-Infrastruktur von Grund auf selbst bauen zu müssen. Das angekündigte Community-Programm umfasst repository-verknüpfte Praktika und aufgabenbasierte Belohnungen. Entwickler können jeweils eine gelistete Aufgabe übernehmen und nach den Regeln des Programms fertigstellen. 31

Wer keine Ascend-Hardware besitzt, kann laut den vorliegenden Berichten die Cloud-Umgebung HiDevLab der Ascend-Community nutzen. Dort stehen 100 kostenlose Rechenstunden zur Verfügung. Die Quellen bestätigen die genannte Freistellung, nennen jedoch nicht alle Bedingungen zu Teilnahmeberechtigung, Verifizierung, Ablauf oder regionaler Verfügbarkeit. Diese Details sollten bei der Registrierung geprüft werden. 31

Das größere Bild

Die zentrale Idee von AscendNPU IR ist architektonischer Natur: Ascend-Hardware soll über gemeinsame Compiler-Einstiegspunkte zugänglich werden, ohne den Weg zu detailliertem Hardware-Tuning zu versperren. Triton, TileLang und Framework-IR können auf höheren Abstraktionsebenen einsteigen. HFusion übernimmt umfassendere Transformationen, während HIVM Kacheln in die Speicher-, Kern-, Kommunikations- und Pipeline-Entscheidungen überführt, die für Ascend-Geräte notwendig sind. 511

Der Ascend 950 erhöht den Spielraum für Optimierungen durch registerbasiertes SIMD, SIMT und kürzere Cube-Vector-Datenwege. Ob sich diese Möglichkeiten in der Praxis in höhere Leistung übersetzen, hängt weiterhin von Operatorform, Speicherdruck, Kontrollfluss, Compiler-Reife und dem jeweiligen Chip ab. Der offene Stack macht diese Zielkonflikte zumindest nachvollziehbarer – und gibt Compiler- sowie Operatorentwicklern eine Möglichkeit, an ihrer Verbesserung mitzuwirken.