Slik kobler AscendNPU IR Triton til Huaweis Ascend-maskinvare

AscendNPU IR er ikke ment å være enda et programmeringsspråk for sluttbrukere. Det er et mellomlag i kompilatoren – fundamentet under BiSheng – som skal koble språk og rammeverk som Triton og TileLang til Huaweis Ascend-maskinvare.

På HyperAIs niende tekniske Meet AI Compiler-salong i Beijing 1. august 2026 presenterte Huawei-arkitekten Hai Lijuan hvordan den MLIR-baserte plattformen er bygget for å støtte flere innganger til Ascend-systemet. 37

Den praktiske ideen er å skille programmeringen av en operatør fra det kompliserte arbeidet som skjer under panseret: hvordan tensorer deles i tiles, hvordan data flyttes mellom minnenivåer, hvordan Cube- og Vector-beregninger koordineres, og hvordan ferdig enhetskode genereres.

AscendNPU IR i BiSheng-kompilatoren

AscendNPU IR er en MLIR-basert mellomrepresentasjon for kompilering av Ascend-tilpassede operatører. Den har flere abstraksjonsnivåer. På høyt nivå skjules detaljer om instruksjoner, dataflytting og synkronisering. På lavere nivå kan utviklere styre plasseringen av data i minnet og hvordan beregningspipelinene skal oppføre seg. 411

Plattformen kan ta imot kode gjennom flere veier. Domenespesifikke språk som Triton og TileLang kan senkes til AscendNPU IR, mens rammeverk og andre kompilatorinnganger kan kobles til via Torch IR, Linalg/HFusion IR eller HIVM IR. De høyere nivåene kan automatisere fusjon, oppdeling i tiles og planlegging, mens HIVM gir mer direkte kontroll over Ascends minnehierarki og beregningspipelines. 522

En forenklet kompilatorflyt ser slik ut:

Triton, TileLang eller rammeverks-IR
                ↓
       MLIR-basert AscendNPU IR
                ↓
        HFusion → HIVM-lowering
                ↓
       Ascend-instruksjoner og binærfil

Den dokumenterte arbeidsflyten bruker bishengir-compile til å gjøre MLIR om til et objekt for enheten. Objektet kan deretter registreres og kjøres gjennom CANN-kjøretidsmiljøet. 6

Hvorfor tile-abstraksjonen er viktig

En tile er en håndterlig blokk med tensor-data og beregninger. Uten en felles abstraksjon måtte hvert front-end-språk selv beskrive alle dataoverføringer, minnevalg, synkroniseringspunkter og maskinvareinstruksjoner.

AscendNPU IR samler i stedet dette i en felles, tile-orientert representasjon. På høyt nivå kan utviklere beskrive tensoroperasjoner uten å spesifisere hver eneste maskinvarenær detalj. På lavere nivå kan kompilatoren eksponere eller utlede plassering i blant annet GM, UB, L1 og L0, samt bruken av Vector-, Cube- og dataflyttingsressurser. 522

Det gir et kompromiss mellom portabilitet og ytelsesjustering. Triton- eller rammeverkskode kan bruke den samme kompilatorbasen, mens tidskritisk kode kan senkes til en mer maskinvarebevisst representasjon når det er nødvendig. Huaweis arkitekturdokumentasjon beskriver dette som frikoblede abstraksjoner som gradvis modellerer Ascend-instruksjoner, ressurser i enkeltkjerner, ressurser mellom kjerner og ressurser på systembrikken. 11

HFusion og HIVM deler på optimaliseringsjobben

HFusion: fusjon og planlegging på høyere nivå

HFusion er det relativt maskinvareuavhengige laget i kompilatormodellen. Her representeres tensoroperasjoner på et høyere nivå, før kompilatoren låser seg til detaljerte maskinvareinstruksjoner. Laget kan blant annet utføre fusjon, bufferisering, tiling og planlegging. 1122

Det er også her flere operasjoner kan slås sammen, og en større beregning kan deles opp i tiles som passer til den aktuelle kjøringsmodellen. Målet er å bevare den høye semantikken samtidig som beregningen klargjøres for Ascend-spesifikk lowering.

HIVM: lowering med kjennskap til maskinvaren

HIVM er det maskinvarebevisste laget. Det oversetter tile-uttrykk til operasjoner som gjenspeiler Ascends beregningsenheter, minnehierarki og pipelineoppførsel. Oppgavene omfatter blant annet å:

• mappe matriseoperasjoner til Cube-kjerner og vektoroperasjoner til Vector-kjerner;
• sette inn og håndtere kommunikasjon og synkronisering mellom enhetene;
• administrere mellomliggende arbeidsminne;
• mappe logiske tensorer til fysisk minne på brikken;
• håndtere Cube-orienterte oppsett, som fraktale matriserepresentasjoner; og
• bruke vektorisering, tensorisering, pipelining og instruksjonstransformasjoner. 214

Denne todelingen lar kompilatoren optimalisere på to avstander fra maskinvaren. HFusion kan se på den overordnede tensorstrukturen og muligheter for fusjon, mens HIVM kan analysere de konkrete minne- og beregningsressursene som trengs for å kjøre de ferdige tilene.

Hva Ascend 950 tilfører

Skillet mellom HFusion og HIVM består, men det maskinvarebevisste laget må håndtere mer enn den tidligere SIMD-modellen basert på minne. Materialet for Ascend 950 beskriver støtte for registerbasert SIMD og SIMT i tillegg til den eksisterende kjøringsmodellen. 2

Registerbasert SIMD

Med registerbasert SIMD lastes data fra minne på brikken inn i registre, behandles der og skrives tilbake. Registerbasert fusjon kan holde mellomresultater i registrene gjennom flere operasjoner og dermed redusere unødvendige inn- og utlastingstrinn når beregningen tillater det. 2

SIMT for mindre regelmessige beregninger

SIMT gir en alternativ måte å håndtere deler av en operatør med uregelmessig tilgang eller avvikende kontrollflyt. Den beskrevne tilnærmingen skiller ut arbeid som egner seg for SIMT, fra tett og SIMD-vennlig arbeid. Deretter brukes riktig transformasjon på hver del før resultatene settes sammen igjen i den overordnede vektorberegningen. 2

Tettere kommunikasjon mellom Cube og Vector

Presentasjonen trakk også frem en endring i samspillet mellom Cube og Vector. I tidligere A2/A3-flyter gikk enkelte overføringer mellom Cube- og Vector-beregninger via globalt minne. På Ascend 950 kan Cube-resultater, slik den beskrevne løsningen viser, flyttes fra L0C til Vector-minne på brikken, og Vector-resultater kan sendes tilbake til Cube-minnet. Det reduserer avstanden mellom de to beregningsområdene. 2

Dette er særlig relevant for operatører der matriseorientert Cube-arbeid etterfølges av vektorbehandling. Kompilatoren må likevel kunne fastslå hvor tensorene befinner seg og når overføringer er nødvendige – spesielt når Cube- og Vector-operasjoner ligger i ulike grener av kontrollflyten.

Kompilatorpassene som gjør modellen kjørbar

Flere navngitte pass viser hvordan AscendNPU IR omsetter abstraksjonen til konkrete beslutninger om minne og planlegging.

InsertCVLoadStore

Den forbedrede InsertCVLoadStore-flyten analyserer Cube–Vector-kommunikasjon på tvers av kompleks kontrollflyt. Den baserer seg dermed ikke bare på enkel lokal mønstergjenkjenning.

Først etableres minneankere – for eksempel matriseinnganger i L1, matriseutganger i L0C og vektordata i UB. Deretter spres disse begrensningene gjennom programmet, og nødvendige konverteringer eller kopier settes inn når minneområdene ikke passer sammen. 2

På A2/A3 kan de beskrevne overgangene bruke inn- og utlasting via globalt minne. Ascend 950 kan benytte de tettere banene på brikken der dette støttes. 2

MultiBuffer

MultiBuffer oppretter flere kopier av en eksisterende tensor. Det støtter blant annet pingpong-bufring, slik at dataflytting og beregning kan overlappes når minnebudsjettet og planen tillater det. 1718

AutoBlockify og DynamicCVPipeline

AutoBlockify og DynamicCVPipeline er blant de Ascend-spesifikke passene i Triton-Ascend-stakken. Navnene peker på to sentrale oppgaver: å dele beregningen i kjørbare blokker og å bygge en pipeline mellom Cube- og Vector-beregninger. 19

Den dokumenterte funksjonaliteten omfatter også automatisk minneplanlegging, synkronisering, planlegging og Cube–Vector-optimalisering. 24

CV 1:2-oppdeling

Presentasjonen beskrev et oppsett med én Cube-kjerne mot to Vector-kjerner for en relevant Ascend-konfigurasjon. AutoSubTiling kan dele opp Vector-arbeidet slik at de to Vector-kjernene behandler hver sin del parallelt. 214

Hva åpen kildekode betyr for utviklere

Huawei åpnet AscendNPU IR sammen med Triton-Ascend for videre utvikling i fellesskapet. Triton-Ascend er Huaweis Ascend-tilpassede Triton-kompilatorrammeverk. Det beholder Tritons grunnleggende syntaks, samtidig som det tilfører Ascend-spesifikk kompilering og utrulling for A2-, A3- og 950-serien. 3037

Åpningen gir en mer direkte inngang for utviklere som vil arbeide med kompilatorpass, integrasjon av frontender, lowering av operatører eller maskinvarebevisst optimalisering – uten å måtte bygge hele kompilatorstakken fra bunnen av.

Det rapporterte samfunnsprogrammet omfatter praksisplasser knyttet til kodebasene og oppgaver med belønning. Utviklere kan velge og gjøre krav på oppførte oppgaver, og sende inn ferdig arbeid i tråd med programmets regler. 31

Utviklere som ikke har lokal Ascend-maskinvare, skal ifølge rapporteringen kunne bruke HiDevLab, Ascend-fellesskapets skybaserte utviklingsmiljø, med 100 gratis timer. Kildene bekrefter timetallet, men spesifiserer ikke alle krav til kvalifisering, verifisering, utløp eller regional tilgjengelighet. Disse vilkårene bør derfor sjekkes ved registrering. 31

Den store linjen

Hovedideen bak AscendNPU IR er arkitektonisk: å gjøre Ascend-maskinvare tilgjengelig gjennom vanlige kompilatorinnganger, samtidig som utviklere fortsatt får en vei ned til detaljert maskinvarejustering.

Triton, TileLang og rammeverks-IR kan kobles til på høyere abstraksjonsnivåer. HFusion kan utføre bredere transformasjoner, mens HIVM kan senke tiles til de konkrete beslutningene om minne, kjerner, kommunikasjon og pipelines som kreves på Ascend-enheter. 511

Ascend 950 hever optimaliseringsmulighetene med registerbasert SIMD, SIMT og tettere Cube–Vector-dataflyt på brikken. Om dette faktisk gir bedre ytelse i praksis, vil fortsatt avhenge av operatørens form, minnepress, kontrollflyt, kompilatorens modenhet og hvilken brikke som brukes.

Det åpne kompilatorlaget gjør imidlertid disse avveiningene lettere å undersøke – og gir utviklere av kompilatorer og operatører en konkret mulighet til å bidra til å forbedre dem.