Så kopplar AscendNPU IR ihop Triton med Huaweis Ascend-hårdvara

Huawei positionerar AscendNPU IR som den öppna kompilatorgrunden under BiSheng – inte som ännu ett programmeringsspråk för slutanvändare. Vid HyperAI:s nionde tekniska Meet AI Compiler-salong i Zhongguancun i Peking den 1 augusti 2026 beskrev AscendNPU IR-arkitekten Hai Lijuan hur den MLIR-baserade stacken ska koppla ihop Triton och andra operatörsekosystem med Ascend-hårdvara. 37

För utvecklare är poängen framför allt att skilja frontendens programmering från det allt mer avancerade arbetet med att dela upp beräkningar i tiles, flytta data mellan minnesnivåer, samordna Cube- och Vector-beräkning samt generera kod för själva enheten.

AscendNPU IR:s plats i BiSheng-kompilatorn

AscendNPU IR är en MLIR-baserad intermediate representation, eller mellanrepresentation, för kompilering av Ascend-anpassade operatorer. Den har flera abstraktionsnivåer: högre nivåer döljer detaljer om instruktioner och synkronisering, medan lägre nivåer ger utvecklare finmaskig kontroll över minnesplacering och pipelinebeteende. 411

Stacken kan ta emot kod på flera sätt. Domänspecifika språk som Triton och TileLang kan sänkas till AscendNPU IR. Ramverk och andra kompilatoringångar kan i sin tur ansluta via Torch IR, Linalg/HFusion IR eller HIVM IR. På de högre nivåerna kan kompilatorn automatiskt hantera fusion, tiling, uppdelning och schemaläggning. HIVM ger mer direkt kontroll över Ascends minnesnivåer och beräkningspipelines. 522

Förenklat ser flödet ut så här:

Triton, TileLang eller ramverks-IR
              ↓
       MLIR-baserad AscendNPU IR
              ↓
       HFusion → HIVM
              ↓
       Ascend-instruktioner och binärkod

I den dokumenterade kompileringsprocessen används bishengir-compile för att omvandla MLIR till ett objekt för enheten. Objektet kan därefter registreras och köras via CANN:s runtime-miljö. 6

Därför spelar tile-abstraktionen roll

En tile är ett hanterbart block av tensor-data och beräkningar. I stället för att varje frontend själv ska beskriva varje dataöverföring, minnesplacering, synkroniseringspunkt och hårdvaruinstruktion ger AscendNPU IR kompilatorn en gemensam representation med fokus på tiles.

Abstraktionen är medvetet skiktad. På högre nivå kan utvecklare uttrycka tensoroperationer utan att ange varje detalj i hårdvaran. På lägre nivå kan kompilatorn visa eller härleda placering i exempelvis GM, UB, L1 och L0, samt användningen av Vector-, Cube- och dataflyttningsresurser. 522

Det ger en kompromiss mellan portabilitet och prestandajustering. En frontend för Triton eller ett ramverk kan rikta sig mot samma kompilatorgrund, samtidigt som prestandakänslig kod kan sänkas till en mer hårdvarunära representation när det behövs. I den officiella arkitekturbeskrivningen presenteras detta som frikopplade abstraktioner som stegvis modellerar Ascend-instruktioner, resurser inom en kärna, resurser mellan kärnor och resurser på systemkretsnivå. 11

HFusion och HIVM delar på optimeringsarbetet

HFusion: fusion och schemaläggning på högre nivå

HFusion är den relativt hårdvaruoberoende av de två centrala lagren. Det representerar tensoroperationer på en högre nivå och utför bland annat fusion, bufferisering, tiling och schemaläggning innan kompilatorn bestämmer de detaljerade hårdvaruinstruktionerna. 1122

Här kan flera operationer kombineras och en större beräkning delas upp i tiles som passar den tänkta exekveringsmodellen. Målet är att bevara användbara semantiska egenskaper på hög nivå, samtidigt som beräkningen förbereds för Ascend-specifik sänkning.

HIVM: sänkning med kännedom om hårdvaran

HIVM är det hårdvarumedvetna lagret. Det översätter tile-uttryck till operationer som speglar Ascends beräkningsenheter, minneshierarki och pipelinebeteende. Bland uppgifterna finns att:

• mappa matrisoperationer till Cube-kärnor och vektoroperationer till Vector-kärnor,
• lägga till eller hantera kommunikation och synkronisering mellan enheterna,
• hantera mellanliggande workspace-minne,
• mappa logiska tensorer till fysiskt lokalt chipminne,
• hantera Cube-orienterade layouter, bland annat fraktala matrisrepresentationer, och
• tillämpa vektorisering, tensorisering, pipelining och instruktionstransformationer. 214

Uppdelningen gör det möjligt att optimera på två olika avstånd från hårdvaran. HFusion kan resonera kring den övergripande tensorstrukturen och möjligheter till fusion, medan HIVM kan arbeta med de exakta minnes- och exekveringsresurser som behövs för att köra de färdiga tilen.

Vad Ascend 950 förändrar

Uppdelningen mellan HFusion och HIVM finns kvar, men den hårdvarunära delen måste hantera mer än den tidigare SIMD-modellen som främst byggde på minnesåtkomst. Materialet om Ascend 950 beskriver stöd för registerbaserad SIMD och SIMT utöver den befintliga exekveringsmodellen. 2

Registerbaserad SIMD

Med registerbaserad SIMD laddas data från lokalt chipminne till register, bearbetas där och skrivs sedan tillbaka. Registerbaserad fusion kan hålla mellanresultat i registren över flera operationer och därmed minska antalet upprepade läsningar och skrivningar när beräkningen tillåter det. 2

SIMT för mindre regelbundna beräkningar

SIMT ger ytterligare ett sätt att hantera lämpliga delar med oregelbundna minnesåtkomster eller avvikande kontrollflöden. Den beskrivna metoden skiljer ut arbete som passar SIMT från tätare, SIMD-vänliga delar, tillämpar rätt transformation på respektive del och sammanför sedan resultaten i den övergripande vektorberäkningen. 2

Tätare kommunikation mellan Cube och Vector

Presentationens material lyfte också fram en förändring i samspelet mellan Cube och Vector. I tidigare flöden för A2 och A3 gick vissa överföringar mellan Cube- och Vector-beräkning via globalt minne. På Ascend 950 kan Cube-resultat enligt beskrivningen flyttas från L0C till Vector-enhetens lokala chipminne och Vector-resultat skickas tillbaka till Cube-minnet. Det minskar avståndet mellan de två exekveringsdomänerna. 2

Det är relevant för operatorer där matrisorienterat Cube-arbete följs av vektorbehandling. Kompilatorn måste fortfarande kunna avgöra var tensorerna befinner sig och när överföringar krävs, särskilt när Cube- och Vector-operationer ligger i olika grenar av ett kontrollflöde.

Pass som gör modellen körbar i praktiken

Flera namngivna pass visar hur AscendNPU IR omsätter abstraktionen i konkreta beslut om minne och schemaläggning.

InsertCVLoadStore

Det förbättrade flödet för InsertCVLoadStore analyserar kommunikation mellan Cube och Vector över komplexa kontrollflöden, i stället för att enbart lägga in överföringar genom enkel lokal mönstermatchning. Först skapas ankare för minnesplaceringen – till exempel matrisinmatning i L1, matrisutdata i L0C och vektordata i UB. Därefter sprids begränsningarna genom programmet, och konverteringar eller kopior läggs in när minnesdomänerna inte stämmer överens. 2

På A2 och A3 kan de beskrivna överföringarna använda läsning och skrivning via globalt minne. Ascend 950 kan använda de kortare lokala chipvägarna där det stöds. 2

MultiBuffer

MultiBuffer representerar flera kopior av en befintlig tensor. Det möjliggör så kallad pingpong-buffring och kan överlappa dataflytt med beräkning när minnesbudgeten och schemat tillåter det. 1718

AutoBlockify och DynamicCVPipeline

AutoBlockify och DynamicCVPipeline är två Ascend-specifika pass i Triton-Ascend. Namnen speglar två centrala uppgifter: att dela upp beräkningen i körbara block och att bygga pipelinebeteende mellan Cube och Vector. 19

Den dokumenterade funktionsuppsättningen omfattar även automatisk minnesplanering, synkronisering, schemaläggning samt optimeringar för Cube–Vector-samspel. 24

CV-delning i förhållandet 1:2

Presentationens material beskriver en konfiguration med en Cube-kärna i relation till två Vector-kärnor. AutoSubTiling kan dela upp Vector-arbetet så att de två Vector-kärnorna behandlar separata delar parallellt. 214

Vad den öppna källkoden betyder för utvecklare

Huawei har öppnat AscendNPU IR tillsammans med Triton-Ascend för gemensam utveckling i communityn. Triton-Ascend är det Ascend-anpassade Triton-ramverket. Det behåller Tritons centrala syntax och lägger till kompilering och driftsättning för Ascend-produkter i A2-, A3- och 950-serierna. 3037

För utvecklare skapar lanseringen en mer direkt väg in i arbete med kompilatorpass, frontend-integration, sänkning av operatorer och hårdvarunära optimering – utan att man behöver bygga en hel kompilatorstack från grunden. Det rapporterade communityprogrammet omfattar repository-länkade praktikplatser och uppgiftsbaserade belöningar. Utvecklare kan välja och göra anspråk på listade uppgifter och lämna in resultat enligt programmets regler. 31

Den som saknar lokal Ascend-hårdvara kan enligt rapporteringen använda Ascend-communityns molnmiljö HiDevLab, där registrerade utvecklare erbjuds 100 kostnadsfria beräkningstimmar. Det tillgängliga underlaget bekräftar timtilldelningen, men anger inte alla villkor för behörighet, verifiering, giltighetstid eller regional tillgänglighet. Dessa detaljer bör därför kontrolleras vid registreringen. 31

Den större bilden

AscendNPU IR:s huvuderbjudande är arkitektoniskt: att göra Ascend-hårdvara tillgänglig via gemensamma kompilatoringångar, samtidigt som det finns en väg till detaljerad hårdvaruoptimering. Triton, TileLang och ramverks-IR kan ansluta på högre abstraktionsnivåer. HFusion kan utföra bredare transformationer, medan HIVM sänker tilen till de minnes-, kärn-, kommunikations- och pipelinebeslut som Ascend-enheterna kräver. 511

Ascend 950 höjer optimeringstaket genom registerbaserad SIMD, SIMT och kortare Cube–Vector-vägar på chipet. Om det leder till bättre prestanda i verkliga arbetslaster beror fortfarande på operatorernas form, minnestryck, kontrollflöden, kompilatorns mognad och vilket chip som används. Den öppna stacken gör dessa avvägningar lättare att granska – och ger utvecklare av kompilatorer och operatorer möjlighet att bidra till att förbättra dem.