Huawei positioneert AscendNPU IR als de open compilerbasis onder de BiSheng-compiler, niet als een nieuwe programmeertaal voor eindgebruikers. Tijdens de negende technische Meet AI Compiler-salon van HyperAI, op 1 augustus 2026 in Zhongguancun in Beijing, legde AscendNPU IR-architect Hai Lijuan uit hoe de MLIR-gebaseerde stack Triton en andere operator-ecosystemen met Ascend-hardware moet verbinden. 37

De praktische inzet is duidelijk: programmeurs hoeven niet voor elke chipvariant afzonderlijk vast te leggen hoe data tussen geheugenniveaus bewegen, hoe tensoren in tegels worden verdeeld of wanneer Cube- en Vector-berekeningen moeten synchroniseren. AscendNPU IR moet die vertaalslag zoveel mogelijk bij de compiler leggen, zonder de mogelijkheid voor zeer gedetailleerde hardware-optimalisatie weg te nemen.

De rol van AscendNPU IR in BiSheng

AscendNPU IR is een op MLIR gebaseerde intermediate representation (IR): een tussenlaag waarin compilerbewerkingen worden beschreven voordat ze worden omgezet in uitvoerbare code voor Ascend-NPU’s. De meerlagige opzet biedt zowel abstracte interfaces, die details van instructies en synchronisatie verbergen, als fijnmazige interfaces voor ontwikkelaars die zelf geheugenplaatsing en pijplijngedrag willen sturen. 411

De compilerlaag kan vanuit verschillende richtingen worden aangesproken. Domeinspecifieke talen zoals Triton en TileLang kunnen naar AscendNPU IR worden verlaagd. Frameworks en andere compilerlagen kunnen aansluiten via onder meer Torch IR, Linalg/HFusion IR of HIVM IR. Op hogere niveaus kan de stack fusie, tiling, opsplitsing en planning automatiseren; HIVM biedt juist directe controle over Ascend-geheugenniveaus en rekenpijplijnen. 522

In vereenvoudigde vorm ziet de route er zo uit:

Triton, TileLang of framework-IR
              ↓
       MLIR-gebaseerde AscendNPU IR
              ↓
       HFusion → HIVM
              ↓
       Ascend-instructies en binaire code

Volgens de documentatie kan bishengir-compile MLIR omzetten in een objectbestand voor het apparaat. Dat bestand kan vervolgens via de CANN-runtime worden geregistreerd en op een Ascend-NPU worden uitgevoerd. 6

Waarom de tegelabstractie belangrijk is

Een tegel is een beheersbaar blok tensorgegevens en berekeningen. Zonder zo’n gemeenschappelijke abstractie zou elke front-end afzonderlijk moeten beschrijven hoe gegevens worden verplaatst, welk geheugenniveau wordt gebruikt, waar synchronisatie nodig is en welke hardware-instructies de berekening uitvoeren.

AscendNPU IR maakt van die tegel het verbindende concept. Op hogere niveaus kunnen ontwikkelaars tensorbewerkingen beschrijven zonder elk hardwaredetail te specificeren. Op lagere niveaus kan de compiler juist expliciet maken of afleiden hoe data worden geplaatst in bijvoorbeeld GM, UB, L1 en L0, en hoe Vector-, Cube- en data-movement-eenheden worden ingezet. 522

Dat levert een compromis op tussen draagbaarheid en tuning. Triton- of frameworkcode kan dezelfde compilerbasis gebruiken, terwijl prestatiekritische code kan afdalen naar een hardwarebewustere representatie. De architectuurdocumentatie beschrijft dit als een reeks ontkoppelde abstracties die stapsgewijs Ascend-instructies, lokale core-resources, communicatie tussen cores en systeem-op-chip-resources modelleren. 11

HFusion en HIVM verdelen het optimalisatiewerk

HFusion: fusie en planning op hoger niveau

HFusion is de relatief hardware-onafhankelijke laag. Deze laag beschrijft tensorbewerkingen op een hoger abstractieniveau en voert transformaties uit zoals operatorfusie, bufferization, tiling en scheduling voordat de compiler zich vastlegt op concrete hardware-instructies. 1122

Hier kunnen meerdere bewerkingen worden samengevoegd en grotere berekeningen worden opgesplitst in tegels die passen bij het uitvoeringsmodel van de chip. De bedoeling is om de semantiek van de oorspronkelijke bewerking te behouden en tegelijk de berekening voor te bereiden op Ascend-specifieke verlaging.

HIVM: verlaging naar de hardware

HIVM is de hardwarebewuste laag. Deze vertaalt tegelbewerkingen naar operaties die rekening houden met de rekenkernen, de geheugenhiërarchie en het pijplijngedrag van Ascend. De taken omvatten onder meer:

• matrixbewerkingen toewijzen aan Cube-cores en vectorbewerkingen aan Vector-cores;
• communicatie en synchronisatie tussen die eenheden invoegen of beheren;
• tijdelijk workspace-geheugen beheren;
• logische tensoren koppelen aan fysiek on-chipgeheugen;
• Cube-gerichte indelingen verwerken, zoals fractale matrixrepresentaties; en
• vectorisatie, tensorisatie, pipelining en instructietransformaties toepassen. 214

De scheiding tussen HFusion en HIVM maakt optimalisatie op twee afstanden van de hardware mogelijk. HFusion redeneert over de bredere tensorstructuur en kansen voor fusie, terwijl HIVM bepaalt welke concrete geheugen- en rekenresources nodig zijn om de resulterende tegels uit te voeren.

Wat Ascend 950 toevoegt

De verdeling tussen HFusion en HIVM blijft bestaan, maar de hardwarebewuste laag moet op Ascend 950 meer uitvoeringsmodellen ondersteunen dan de eerdere, vooral op geheugen gebaseerde SIMD-route. Het materiaal over Ascend 950 noemt naast het bestaande model ook registergebaseerde SIMD en SIMT. 2

Registergebaseerde SIMD

Bij registergebaseerde SIMD worden gegevens vanuit on-chipgeheugen naar registers geladen, daar verwerkt en vervolgens teruggeschreven. Registerfusie kan tussenresultaten gedurende meerdere bewerkingen in registers houden. Als de berekening dat toelaat, vermindert dit het aantal herhaalde laad- en schrijfoperaties. 2

SIMT voor minder regelmatige berekeningen

SIMT biedt een alternatieve aanpak voor geschikte berekeningen met onregelmatige geheugentoegang of uiteenlopende uitvoeringspaden. De beschreven methode scheidt delen die baat hebben bij SIMT van dichte, SIMD-vriendelijke delen, past voor elk deel een geschikte transformatie toe en voegt de resultaten daarna weer samen in de bredere vectorberekening. 2

Directere Cube–Vector-communicatie

De presentatie wees ook op een wijziging in de communicatie tussen Cube en Vector. In eerdere A2- en A3-stromen liepen sommige overdrachten tussen Cube- en Vector-berekeningen via globaal geheugen. Op Ascend 950 kunnen Cube-resultaten vanuit L0C naar Vector-on-chipgeheugen worden verplaatst en Vector-resultaten terug naar Cube-geheugen gaan. Daarmee verkort de gegevensroute tussen beide uitvoeringsdomeinen. 2

Dat is relevant voor operators waarbij matrixgerichte Cube-berekeningen worden gevolgd door vectorverwerking. De compiler moet nog steeds vaststellen waar tensoren zich bevinden en wanneer overdrachten nodig zijn, vooral als Cube- en Vector-bewerkingen in verschillende takken van de besturingsstroom staan.

Compilerpasses maken het model uitvoerbaar

Verschillende benoemde passes laten zien hoe AscendNPU IR de abstractie omzet in concrete geheugen- en planningsbeslissingen.

InsertCVLoadStore

De uitgebreide InsertCVLoadStore-stroom analyseert Cube–Vector-communicatie over complexe besturingsstromen heen. In plaats van alleen eenvoudige lokale patronen te herkennen, legt de pass geheugenankers vast — bijvoorbeeld matrixinvoer in L1, matrixuitvoer in L0C en vectordata in UB — en verspreidt die beperkingen door het programma. Waar geheugendomeinen botsen, worden conversies of kopieën ingevoegd. 2

Bij A2 en A3 kunnen bepaalde overdrachten tussen Cube en Vector gebruikmaken van laad- en schrijfoperaties via globaal geheugen. Ascend 950 ondersteunt voor de beschreven routes directere overdrachten op de chip. 2

MultiBuffer

MultiBuffer maakt meerdere kopieën van een bestaande tensor mogelijk. Dat ondersteunt pingpongbuffers en kan het overlappen van gegevensverplaatsing en berekening bevorderen, zolang het geheugengebruik en de planning dat toelaten. 1718

AutoBlockify en DynamicCVPipeline

AutoBlockify en DynamicCVPipeline behoren tot de Ascend-specifieke passes in de Triton-Ascend-compilerstack. Hun namen verwijzen naar twee centrale taken: berekeningen opdelen in uitvoerbare blokken en het gedrag van de Cube–Vector-pijplijn opbouwen. 19

De gedocumenteerde functies omvatten daarnaast automatische geheugenplanning, synchronisatie, scheduling en Cube–Vector-optimalisaties. 24

CV 1:2-splitsing

De presentatie beschreef voor een relevante Ascend-configuratie een verhouding van één Cube-core tot twee Vector-cores. Met AutoSubTiling kan Vector-werk worden opgesplitst, zodat beide Vector-cores gelijktijdig afzonderlijke delen verwerken. 214

Wat de open-source release betekent voor ontwikkelaars

Huawei heeft AscendNPU IR samen met Triton-Ascend open source gemaakt voor gezamenlijke ontwikkeling door de community. Triton-Ascend is de voor Ascend aangepaste Triton-compilerstack. De kernsyntaxis van Triton blijft behouden, terwijl ondersteuning voor compilatie en deployment op Ascend A2-, A3- en 950-series wordt toegevoegd. 3037

Voor ontwikkelaars ontstaat zo een directere route naar werk aan compilerpasses, front-endintegratie, operatorverlaging en hardwarebewuste optimalisatie. Zij hoeven niet langer een volledige compilerstack vanaf nul op te bouwen. Het aangekondigde communityprogramma omvat repositorygekoppelde stages en taakbeloningen. Deelnemers kunnen volgens de beschreven regels een taak claimen en na oplevering een beloning ontvangen. 31

Wie geen Ascend-hardware bezit, kan volgens de beschikbare berichtgeving gebruikmaken van HiDevLab, de cloudomgeving van de Ascend-community. Daar kunnen ontwikkelaars zich registreren voor 100 gratis rekenuren. De bronnen bevestigen de hoeveelheid, maar geven niet alle voorwaarden rond toelating, verificatie, vervaldatum of regionale beschikbaarheid. Die details moeten bij registratie worden gecontroleerd. 31

De bredere betekenis

De belangrijkste belofte van AscendNPU IR is architectonisch: Ascend-hardware toegankelijker maken via gedeelde compileringangen, terwijl er een route naar diepgaande hardwaretuning behouden blijft. Triton, TileLang en framework-IR kunnen op een hoger abstractieniveau instromen; HFusion kan bredere transformaties uitvoeren; HIVM kan tegels verlagen naar de geheugen-, core-, communicatie- en pijplijnbeslissingen die Ascend-apparaten nodig hebben. 511

Ascend 950 verhoogt de mogelijke optimalisatieruimte met registergebaseerde SIMD, SIMT en directere Cube–Vector-gegevenspaden. Of dat in de praktijk ook hogere prestaties oplevert, hangt nog steeds af van de vorm van de operator, geheugendruk, besturingsstroom, compilerontwikkeling en de gekozen chip. De open-source stack maakt die afwegingen beter inzichtelijk en geeft ontwikkelaars van compilers en operators de mogelijkheid om eraan mee te bouwen.

Huawei positioneert AscendNPU IR als de open compilerbasis onder de BiSheng-compiler, niet als een nieuwe programmeertaal voor eindgebruikers. Tijdens de negende technische Meet AI Compiler-salon van HyperAI, op 1 augustus 2026 in Zhongguancun in Beijing, legde AscendNPU IR-architect Hai Lijuan uit hoe de MLIR-gebaseerde stack Triton en andere operator-ecosystemen met Ascend-hardware moet verbinden. 37

De praktische inzet is duidelijk: programmeurs hoeven niet voor elke chipvariant afzonderlijk vast te leggen hoe data tussen geheugenniveaus bewegen, hoe tensoren in tegels worden verdeeld of wanneer Cube- en Vector-berekeningen moeten synchroniseren. AscendNPU IR moet die vertaalslag zoveel mogelijk bij de compiler leggen, zonder de mogelijkheid voor zeer gedetailleerde hardware-optimalisatie weg te nemen.

De rol van AscendNPU IR in BiSheng

AscendNPU IR is een op MLIR gebaseerde intermediate representation (IR): een tussenlaag waarin compilerbewerkingen worden beschreven voordat ze worden omgezet in uitvoerbare code voor Ascend-NPU’s. De meerlagige opzet biedt zowel abstracte interfaces, die details van instructies en synchronisatie verbergen, als fijnmazige interfaces voor ontwikkelaars die zelf geheugenplaatsing en pijplijngedrag willen sturen. 411

De compilerlaag kan vanuit verschillende richtingen worden aangesproken. Domeinspecifieke talen zoals Triton en TileLang kunnen naar AscendNPU IR worden verlaagd. Frameworks en andere compilerlagen kunnen aansluiten via onder meer Torch IR, Linalg/HFusion IR of HIVM IR. Op hogere niveaus kan de stack fusie, tiling, opsplitsing en planning automatiseren; HIVM biedt juist directe controle over Ascend-geheugenniveaus en rekenpijplijnen. 522

In vereenvoudigde vorm ziet de route er zo uit:

Triton, TileLang of framework-IR
              ↓
       MLIR-gebaseerde AscendNPU IR
              ↓
       HFusion → HIVM
              ↓
       Ascend-instructies en binaire code

Volgens de documentatie kan bishengir-compile MLIR omzetten in een objectbestand voor het apparaat. Dat bestand kan vervolgens via de CANN-runtime worden geregistreerd en op een Ascend-NPU worden uitgevoerd. 6

Waarom de tegelabstractie belangrijk is

Een tegel is een beheersbaar blok tensorgegevens en berekeningen. Zonder zo’n gemeenschappelijke abstractie zou elke front-end afzonderlijk moeten beschrijven hoe gegevens worden verplaatst, welk geheugenniveau wordt gebruikt, waar synchronisatie nodig is en welke hardware-instructies de berekening uitvoeren.

AscendNPU IR maakt van die tegel het verbindende concept. Op hogere niveaus kunnen ontwikkelaars tensorbewerkingen beschrijven zonder elk hardwaredetail te specificeren. Op lagere niveaus kan de compiler juist expliciet maken of afleiden hoe data worden geplaatst in bijvoorbeeld GM, UB, L1 en L0, en hoe Vector-, Cube- en data-movement-eenheden worden ingezet. 522

Dat levert een compromis op tussen draagbaarheid en tuning. Triton- of frameworkcode kan dezelfde compilerbasis gebruiken, terwijl prestatiekritische code kan afdalen naar een hardwarebewustere representatie. De architectuurdocumentatie beschrijft dit als een reeks ontkoppelde abstracties die stapsgewijs Ascend-instructies, lokale core-resources, communicatie tussen cores en systeem-op-chip-resources modelleren. 11

HFusion en HIVM verdelen het optimalisatiewerk

HFusion: fusie en planning op hoger niveau

HFusion is de relatief hardware-onafhankelijke laag. Deze laag beschrijft tensorbewerkingen op een hoger abstractieniveau en voert transformaties uit zoals operatorfusie, bufferization, tiling en scheduling voordat de compiler zich vastlegt op concrete hardware-instructies. 1122

Hier kunnen meerdere bewerkingen worden samengevoegd en grotere berekeningen worden opgesplitst in tegels die passen bij het uitvoeringsmodel van de chip. De bedoeling is om de semantiek van de oorspronkelijke bewerking te behouden en tegelijk de berekening voor te bereiden op Ascend-specifieke verlaging.

HIVM: verlaging naar de hardware

HIVM is de hardwarebewuste laag. Deze vertaalt tegelbewerkingen naar operaties die rekening houden met de rekenkernen, de geheugenhiërarchie en het pijplijngedrag van Ascend. De taken omvatten onder meer:

• matrixbewerkingen toewijzen aan Cube-cores en vectorbewerkingen aan Vector-cores;
• communicatie en synchronisatie tussen die eenheden invoegen of beheren;
• tijdelijk workspace-geheugen beheren;
• logische tensoren koppelen aan fysiek on-chipgeheugen;
• Cube-gerichte indelingen verwerken, zoals fractale matrixrepresentaties; en
• vectorisatie, tensorisatie, pipelining en instructietransformaties toepassen. 214

De scheiding tussen HFusion en HIVM maakt optimalisatie op twee afstanden van de hardware mogelijk. HFusion redeneert over de bredere tensorstructuur en kansen voor fusie, terwijl HIVM bepaalt welke concrete geheugen- en rekenresources nodig zijn om de resulterende tegels uit te voeren.

Wat Ascend 950 toevoegt

De verdeling tussen HFusion en HIVM blijft bestaan, maar de hardwarebewuste laag moet op Ascend 950 meer uitvoeringsmodellen ondersteunen dan de eerdere, vooral op geheugen gebaseerde SIMD-route. Het materiaal over Ascend 950 noemt naast het bestaande model ook registergebaseerde SIMD en SIMT. 2

Registergebaseerde SIMD

Bij registergebaseerde SIMD worden gegevens vanuit on-chipgeheugen naar registers geladen, daar verwerkt en vervolgens teruggeschreven. Registerfusie kan tussenresultaten gedurende meerdere bewerkingen in registers houden. Als de berekening dat toelaat, vermindert dit het aantal herhaalde laad- en schrijfoperaties. 2

SIMT voor minder regelmatige berekeningen

SIMT biedt een alternatieve aanpak voor geschikte berekeningen met onregelmatige geheugentoegang of uiteenlopende uitvoeringspaden. De beschreven methode scheidt delen die baat hebben bij SIMT van dichte, SIMD-vriendelijke delen, past voor elk deel een geschikte transformatie toe en voegt de resultaten daarna weer samen in de bredere vectorberekening. 2

Directere Cube–Vector-communicatie

De presentatie wees ook op een wijziging in de communicatie tussen Cube en Vector. In eerdere A2- en A3-stromen liepen sommige overdrachten tussen Cube- en Vector-berekeningen via globaal geheugen. Op Ascend 950 kunnen Cube-resultaten vanuit L0C naar Vector-on-chipgeheugen worden verplaatst en Vector-resultaten terug naar Cube-geheugen gaan. Daarmee verkort de gegevensroute tussen beide uitvoeringsdomeinen. 2

Dat is relevant voor operators waarbij matrixgerichte Cube-berekeningen worden gevolgd door vectorverwerking. De compiler moet nog steeds vaststellen waar tensoren zich bevinden en wanneer overdrachten nodig zijn, vooral als Cube- en Vector-bewerkingen in verschillende takken van de besturingsstroom staan.

Compilerpasses maken het model uitvoerbaar

Verschillende benoemde passes laten zien hoe AscendNPU IR de abstractie omzet in concrete geheugen- en planningsbeslissingen.

InsertCVLoadStore

De uitgebreide InsertCVLoadStore-stroom analyseert Cube–Vector-communicatie over complexe besturingsstromen heen. In plaats van alleen eenvoudige lokale patronen te herkennen, legt de pass geheugenankers vast — bijvoorbeeld matrixinvoer in L1, matrixuitvoer in L0C en vectordata in UB — en verspreidt die beperkingen door het programma. Waar geheugendomeinen botsen, worden conversies of kopieën ingevoegd. 2

Bij A2 en A3 kunnen bepaalde overdrachten tussen Cube en Vector gebruikmaken van laad- en schrijfoperaties via globaal geheugen. Ascend 950 ondersteunt voor de beschreven routes directere overdrachten op de chip. 2

MultiBuffer

MultiBuffer maakt meerdere kopieën van een bestaande tensor mogelijk. Dat ondersteunt pingpongbuffers en kan het overlappen van gegevensverplaatsing en berekening bevorderen, zolang het geheugengebruik en de planning dat toelaten. 1718

AutoBlockify en DynamicCVPipeline

AutoBlockify en DynamicCVPipeline behoren tot de Ascend-specifieke passes in de Triton-Ascend-compilerstack. Hun namen verwijzen naar twee centrale taken: berekeningen opdelen in uitvoerbare blokken en het gedrag van de Cube–Vector-pijplijn opbouwen. 19

De gedocumenteerde functies omvatten daarnaast automatische geheugenplanning, synchronisatie, scheduling en Cube–Vector-optimalisaties. 24

CV 1:2-splitsing

De presentatie beschreef voor een relevante Ascend-configuratie een verhouding van één Cube-core tot twee Vector-cores. Met AutoSubTiling kan Vector-werk worden opgesplitst, zodat beide Vector-cores gelijktijdig afzonderlijke delen verwerken. 214

Wat de open-source release betekent voor ontwikkelaars

Huawei heeft AscendNPU IR samen met Triton-Ascend open source gemaakt voor gezamenlijke ontwikkeling door de community. Triton-Ascend is de voor Ascend aangepaste Triton-compilerstack. De kernsyntaxis van Triton blijft behouden, terwijl ondersteuning voor compilatie en deployment op Ascend A2-, A3- en 950-series wordt toegevoegd. 3037

Voor ontwikkelaars ontstaat zo een directere route naar werk aan compilerpasses, front-endintegratie, operatorverlaging en hardwarebewuste optimalisatie. Zij hoeven niet langer een volledige compilerstack vanaf nul op te bouwen. Het aangekondigde communityprogramma omvat repositorygekoppelde stages en taakbeloningen. Deelnemers kunnen volgens de beschreven regels een taak claimen en na oplevering een beloning ontvangen. 31

Wie geen Ascend-hardware bezit, kan volgens de beschikbare berichtgeving gebruikmaken van HiDevLab, de cloudomgeving van de Ascend-community. Daar kunnen ontwikkelaars zich registreren voor 100 gratis rekenuren. De bronnen bevestigen de hoeveelheid, maar geven niet alle voorwaarden rond toelating, verificatie, vervaldatum of regionale beschikbaarheid. Die details moeten bij registratie worden gecontroleerd. 31

De bredere betekenis

De belangrijkste belofte van AscendNPU IR is architectonisch: Ascend-hardware toegankelijker maken via gedeelde compileringangen, terwijl er een route naar diepgaande hardwaretuning behouden blijft. Triton, TileLang en framework-IR kunnen op een hoger abstractieniveau instromen; HFusion kan bredere transformaties uitvoeren; HIVM kan tegels verlagen naar de geheugen-, core-, communicatie- en pijplijnbeslissingen die Ascend-apparaten nodig hebben. 511

Ascend 950 verhoogt de mogelijke optimalisatieruimte met registergebaseerde SIMD, SIMT en directere Cube–Vector-gegevenspaden. Of dat in de praktijk ook hogere prestaties oplevert, hangt nog steeds af van de vorm van de operator, geheugendruk, besturingsstroom, compilerontwikkeling en de gekozen chip. De open-source stack maakt die afwegingen beter inzichtelijk en geeft ontwikkelaars van compilers en operators de mogelijkheid om eraan mee te bouwen.