Huawei åbner AscendNPU IR for Triton og flere programmeringssprog

En fælles compiler-bund for Ascend

Huawei har åbnet AscendNPU IR som open source for at gøre det lettere at føre Triton og andre operator-økosystemer over på virksomhedens Ascend-hardware. På HyperAI’s niende Meet AI Compiler-tekniksalon den 1. august 2026 gennemgik Huawei-arkitekten Hai Lijuan, hvordan den nye compiler-bund skal fungere som forbindelsesled mellem flere frontends og Ascend-NPU’ens hardware. 37

AscendNPU IR er ikke tænkt som endnu et sprog, som udviklere skal lære fra bunden. Det er en MLIR-baseret mellemliggende repræsentation, der ligger under BiSheng-compileren. Den kan modtage kode fra blandt andet Triton og TileLang samt input fra framework- og compilerlag som Torch IR, Linalg/HFusion IR og HIVM IR. 4511

Den praktiske idé er at flytte en stor del af det komplicerede hardwarearbejde ind i compileren: hvordan tensorer opdeles i tiles, hvordan data flyttes gennem lokal hukommelse, hvordan Cube- og Vector-beregninger synkroniseres, og hvordan den endelige device-kode genereres.

Et forenklet compilationsforløb ser sådan ud:

Triton, TileLang eller framework-IR
                ↓
       MLIR-baseret AscendNPU IR
                ↓
        HFusion → HIVM-lowering
                ↓
       Ascend-instruktioner og binærfil

Med værktøjet bishengir-compile kan MLIR ifølge dokumentationen kompileres til et device-side-objekt, som registreres og køres via CANN-runtime. 6

Hvorfor tile-abstraktionen er vigtig

En tile er en håndterbar blok af tensor-data og beregning. Uden en fælles abstraktion skulle hvert frontend selv beskrive alle dataflytninger, hukommelsesvalg, synkroniseringspunkter og hardwareinstruktioner.

AscendNPU IR samler i stedet disse beslutninger i en lagdelt, tile-orienteret model. På de øverste niveauer kan udviklere beskrive tensoroperationer uden at fastlægge alle hardwaredetaljer. På de nederste niveauer kan der finjusteres på placeringen i blandt andet GM, UB, L1 og L0 samt på brugen af Vector-, Cube- og dataflytningsressourcer. 522

Det giver en balance mellem portabilitet og performance-tuning: Triton- eller framework-kode kan ramme den samme compiler-bund, mens tidskritiske operatorer kan sænkes til en mere hardwarebevidst repræsentation, når der er behov for det. Huaweis arkitekturdokumentation beskriver modellen som flere afkoblede abstraktioner, der gradvist repræsenterer Ascend-instruktioner, ressourcer i den enkelte kerne, ressourcer mellem kerner og system-on-chip-ressourcer. 11

HFusion og HIVM deler optimeringsarbejdet

HFusion: fusion og planlægning på højt niveau

HFusion er det relativt hardwareuafhængige lag. Her repræsenteres tensoroperationer på et højere abstraktionsniveau, og compileren udfører blandt andet operatorfusion, bufferization, tiling og scheduling, før den fastlægger de konkrete hardwareinstruktioner. 1122

Det er også her, flere operationer kan samles, og en større beregning kan opdeles i tiles, der passer til den ønskede eksekveringsmodel. Målet er at bevare de overordnede tensorsemantikker, mens beregningen forberedes til Ascend-specifik lowering.

HIVM: den hardwarebevidste del

HIVM tager over, når compileren skal forholde sig direkte til Ascend-hardware. Laget oversætter tile-udtryk til operationer, der afspejler chippenes beregningsenheder, hukommelseshierarki og pipeline-adfærd.

Det omfatter blandt andet:

• mapping af matrixoperationer til Cube-kerner og vektoroperationer til Vector-kerner;
• indsættelse og håndtering af kommunikation og synkronisering mellem enhederne;
• styring af midlertidigt workspace;
• mapping af logiske tensorer til fysisk lokal hukommelse på chippen;
• håndtering af Cube-orienterede layouts, herunder fraktale matrixrepræsentationer; og
• vektorisering, tensorisering, pipelining og transformationer på instruktionsniveau. 214

Opdelingen gør det muligt at optimere på to forskellige afstande fra hardwaren. HFusion kan se på den samlede tensorstruktur og mulighederne for fusion, mens HIVM kan tage stilling til de konkrete hukommelses- og eksekveringsressourcer, som de enkelte tiles kræver.

Ascend 950 udvider HIVM-modellen

Selve HFusion/HIVM-opdelingen består, men den hardwarebevidste del skal håndtere mere end den tidligere SIMD-model baseret på data i hukommelsen. Materialet om Ascend 950 beskriver støtte til både registerbaseret SIMD og SIMT. 2

Registerbaseret SIMD

Ved registerbaseret SIMD hentes data fra lokal hukommelse ind i registre, behandles dér og skrives tilbage. Hvis beregningen tillader det, kan registerbaseret fusion holde mellemresultater i registrene på tværs af flere operationer. Det kan reducere gentagne læsninger og skrivninger. 2

SIMT til mindre regelmæssige beregninger

SIMT giver en anden måde at håndtere dele af operatorer med mere uregelmæssige hukommelsesadgange eller divergerende kontrolflow. Den beskrevne tilgang adskiller arbejde, der egner sig til SIMT, fra tæt og SIMD-venlig beregning, anvender den relevante transformation på hver del og samler resultaterne i den overordnede vektorberegning. 2

Tættere Cube–Vector-kommunikation

Præsentationen fremhævede også en ændring i samspillet mellem Cube og Vector. I tidligere A2/A3-forløb gik visse dataoverførsler mellem Cube- og Vector-beregning via global hukommelse. På Ascend 950 kan Cube-resultater ifølge materialet flyttes fra L0C til lokal Vector-hukommelse og Vector-resultater tilbage til Cube-hukommelse. 2

Det forkorter afstanden mellem de to eksekveringsdomæner og er især relevant, når en matrixorienteret Cube-beregning efterfølges af vektorbehandling. Compileren skal dog stadig analysere, hvor tensorerne befinder sig, og hvornår flytninger er nødvendige – også når Cube- og Vector-operationer ligger i forskellige grene af et kontrolflow.

Passes, der gør abstraktionen anvendelig

Flere navngivne compiler-pass viser, hvordan AscendNPU IR omsætter den høje abstraktion til konkrete beslutninger om hukommelse og planlægning.

InsertCVLoadStore

Den forbedrede InsertCVLoadStore-proces analyserer Cube–Vector-kommunikation på tværs af komplekst kontrolflow i stedet for blot at indsætte overførsler ud fra simple lokale mønstre.

Først etableres faste hukommelsesankre – eksempelvis matrixinput i L1, matrixoutput i L0C og vektordata i UB. Derefter viderefører compileren disse begrænsninger gennem programmet og indsætter konverteringer eller kopier, når to hukommelsesdomæner ikke passer sammen. 2

På A2/A3 kan de beskrevne overførsler benytte load- og store-operationer via global hukommelse. Ascend 950 kan, hvor hardwaren understøtter det, bruge de tættere forbindelser på chippen. 2

MultiBuffer

MultiBuffer repræsenterer flere kopier af en eksisterende tensor. Det understøtter blandt andet pingpong-buffering og kan gøre det muligt at overlappe dataflytning og beregning, hvis hukommelsesbudgettet og planen tillader det. 1718

AutoBlockify og DynamicCVPipeline

AutoBlockify og DynamicCVPipeline er blandt de Ascend-specifikke passes i Triton-Ascend-stakken. Navnene peger på to centrale opgaver: at opdele beregningen i eksekverbare blokke og at konstruere pipeline-forløbet mellem Cube og Vector. 19

Den dokumenterede funktionsliste omfatter desuden automatisk hukommelsesplanlægning, synkronisering, scheduling og optimering af Cube–Vector-forløb. 24

CV 1:2-opdeling

Præsentationen beskrev en relevant Ascend-konfiguration med ét Cube- og to Vector-kerner. Med AutoSubTiling kan Vector-arbejdet deles, så de to Vector-kerner behandler hver sin del parallelt. 214

Hvad open source-udgivelsen betyder

Huawei har åbnet AscendNPU IR sammen med Triton-Ascend for fælles udvikling i communityet. Triton-Ascend er Huaweis Ascend-orienterede Triton-compilerframework. Det bevarer Tritons centrale syntaks, men tilføjer compiler- og deployment-understøttelse for Ascend A2-, A3- og 950-serien. 3037

For udviklere betyder det en mere direkte vej til at arbejde med compiler-pass, frontend-integration, operator-lowering og hardwarebevidst optimering uden at skulle bygge en hel compiler-stak selv.

Det rapporterede community-program omfatter repository-linkede praktikforløb og opgavebaserede belønninger. Udviklere kan gøre krav på de angivne opgaver og indsende det færdige arbejde efter programmets regler. 31

Udviklere uden lokal Ascend-hardware kan ifølge den tilgængelige rapportering bruge Ascend-communityets cloudmiljø HiDevLab, hvor der tilbydes 100 gratis beregningstimer. Kilderne fastslår ikke alle detaljer om adgangskrav, verificering, udløb eller regional tilgængelighed, så vilkårene bør kontrolleres ved registrering. 31

Den større pointe

AscendNPU IR’s vigtigste bidrag er arkitektonisk: at gøre Ascend-hardware tilgængelig via flere fælles compiler-indgange uden at fjerne muligheden for dyb hardwaretuning.

Triton, TileLang og framework-IR kan komme ind på et højere abstraktionsniveau. HFusion kan stå for bredere transformationer, fusion og scheduling, mens HIVM sænker tiles til de konkrete beslutninger om hukommelse, kerner, kommunikation og pipelines, som Ascend-enhederne kræver. 511

Ascend 950 hæver loftet for optimering med registerbaseret SIMD, SIMT og tættere Cube–Vector-dataforbindelser. Det er dog ikke en garanti for højere performance i alle scenarier. Resultatet afhænger fortsat af operatorens form, hukommelsestryk, kontrolflow, compilerens modenhed og den konkrete chip.

Det åbne stack gør disse afvejninger lettere at inspicere – og giver compiler- og operatørudviklere mulighed for selv at bidrage til at forbedre dem.