AscendNPU IR yhdistää Tritonin ja muut etupuolet Huawein Ascend-laitteistoon

Huawei AscendNPU IR ei ole uusi loppukäyttäjille tarkoitettu ohjelmointikieli, vaan BiSheng-kääntäjän avoin compiler-perusta. HyperAI:n yhdeksännessä Meet AI Compiler -teknologiaseminaarissa 1. elokuuta 2026 AscendNPU IR:n arkkitehti Hai Lijuan esitteli, kuinka MLIR-pohjainen kokonaisuus yhdistää Tritonin ja muut operaattoriekosysteemit Ascend-laitteistoon. 37

Käytännössä tavoitteena on erottaa operaattorin ohjelmointi vaikeammasta laitteistotyöstä: tilesten ajoituksesta, datan siirtämisestä sirun sisäisen muistin eri tasojen välillä, Cube- ja Vector-laskennan koordinoinnista sekä laitekäskyjen tuottamisesta.

Mikä AscendNPU IR on?

AscendNPU IR on MLIR:ään perustuva välikuvaus (intermediate representation, IR), joka on suunniteltu Ascend-laitteistolle optimoitavien operaattorien kääntämiseen. MLIR eli Multi-Level Intermediate Representation on kääntäjäekosysteemi, jossa ohjelmaa voidaan kuvata useilla abstraktiotasoilla. AscendNPU IR:n avulla korkeamman tason koodi voidaan laskea kohti LLVM IR:ää ja lopulta Ascend-laitteella ajettavaa binääriä. 14

Sen keskeinen abstraktio on tilе: hallittavan kokoinen tensoridatan ja laskennan lohko. Etupään ei tarvitse kuvata erikseen jokaista tiedonsiirtoa, synkronointipistettä, muistitasoa ja laitekäskyä. Samalla alemmilla tasoilla kehittäjälle voidaan antaa tarkka kontrolli muistin sijoittelusta ja suoritusputken toiminnasta. 411

AscendNPU IR voi vastaanottaa syötettä useita reittejä pitkin. Tritonin ja TileLangin kaltaiset DSL-kielet voidaan laskea AscendNPU IR:ään, kun taas kehykset ja kääntäjät voivat liittyä mukaan Torch IR:n, Linalg/HFusion IR:n tai HIVM IR:n kautta. Korkeammilla tasoilla kääntäjä voi hoitaa automaattisesti esimerkiksi operaattorien fuusion, tilestyksen, lohkomisen ja ajoituksen. HIVM puolestaan mahdollistaa Ascendin muistitasojen ja laskentaputkien suoraviivaisemman hallinnan. 522

Yksinkertaistettu käännöspolku näyttää tältä:

Triton, TileLang tai kehyskohtainen IR
                 ↓
        MLIR-pohjainen AscendNPU IR
                 ↓
          HFusion → HIVM-lasku
                 ↓
        Ascend-käskyt ja laitebinääri

Dokumentoidussa työnkulussa bishengir-compile muuntaa MLIR:n laitepuolen objektiksi. Se voidaan rekisteröidä ja suorittaa CANN-ajonaikaisen ympäristön kautta. 6

Miksi tile-tason abstraktio on tärkeä?

NPU-operaattorin suorituskyky riippuu usein siitä, miten data jaetaan pienempiin lohkoihin ja miten nämä lohkot liikkuvat muistitasojen välillä. Jos jokainen ohjelmointikieli joutuisi kuvaamaan nämä ratkaisut omalla tavallaan, eri etupäiden ylläpito ja uusien Ascend-sukupolvien tukeminen olisi raskasta.

AscendNPU IR tarjoaa yhteisen tile-tasoisen mallin. Ylemmillä tasoilla kehittäjä voi kuvata tensoritoimintoja ilman kaikkien laitteistoyksityiskohtien määrittelyä. Alemmilla tasoilla voidaan kuitenkin kuvata tai päätellä, sijoitetaanko data esimerkiksi GM-, UB-, L1- tai L0-muistiin ja käytetäänkö laskennassa Vector-, Cube- tai tiedonsiirtoresursseja. 522

Tämä on kompromissi siirrettävyyden ja hienosäädön välillä: Triton- tai kehyskohtainen etupää voi käyttää samaa kääntäjäperustaa, mutta suorituskykykriittinen operaattori voidaan laskea laitteistotietoisempaan esitysmuotoon. Arkkitehtuuridokumentaatio kuvaa kokonaisuutta irrotettujen abstraktioiden ketjuna, joka mallintaa vaiheittain Ascend-käskyjä, ydinpaikallisia resursseja, ytimien välisiä resursseja ja järjestelmäpiirin resursseja. 11

HFusion ja HIVM jakavat optimointityön

HFusion: fuusio, tilestys ja ajoitus

HFusion on kaksikerroksisen mallin suhteellisen laitteistoriippumaton osa. Se käsittelee tensoritoimintoja korkeammalla tasolla ja suorittaa muun muassa fuusiota, bufferointia, tilestystä ja ajoitukseen liittyviä muunnoksia ennen yksityiskohtaista laitteistokohdistusta. 1122

Tässä vaiheessa useita toimintoja voidaan yhdistää ja suurempi laskenta jakaa kohdelaitteelle sopiviin tilеihin. Tarkoitus on säilyttää korkean tason semantiikka mahdollisimman pitkään ja valmistella laskenta Ascend-kohtaista käännöstä varten.

HIVM: laitteistotietoinen käännös

HIVM on laitteistoon sidotumpi kerros. Se muuntaa tile-lausekkeet operaatioiksi, jotka vastaavat Ascendin laskentayksiköitä, muistihierarkiaa ja putkitusta. Sen tehtäviin kuuluvat muun muassa:

• matriisioperaatioiden kohdistaminen Cube-ytimille ja vektorilaskennan kohdistaminen Vector-ytimille;
• näiden yksiköiden välisen tiedonsiirron ja synkronoinnin lisääminen tai hallinta;
• väliaikaisen workspace-työtilan hallinta;
• loogisten tensorien sijoittaminen fyysiseen sirun sisäiseen muistiin;
• Cube-laskennassa käytettävien fractal-matriisimuotojen käsittely; sekä
• vektoroinnin, tensoroinnin, putkituksen ja käskytason muunnosten soveltaminen. 214

Jako antaa kääntäjälle kaksi näkökulmaa samaan laskentaan. HFusion voi etsiä laajempia tensorirakenteita ja fuusiomahdollisuuksia, kun taas HIVM ratkaisee, mitä muistia, laskentayksiköitä ja tiedonsiirtoreittejä syntyvät tilеt tarvitsevat.

Mitä Ascend 950 tuo mukaan?

HFusionin ja HIVM:n perusjako säilyy, mutta Ascend 950:n laitteistotietoisen kerroksen on tuettava aiempaa laajempaa suoritusmallia. Aiemman muistipohjaisen SIMD-polun rinnalle kuvataan rekisteripohjainen SIMD sekä SIMT. 2

Rekisteripohjainen SIMD

Rekisteripohjaisessa SIMD-mallissa data ladataan sirun sisäisestä muistista rekistereihin, käsitellään siellä ja kirjoitetaan takaisin. Rekisteritason fuusio voi pitää välituloksia rekistereissä useiden operaatioiden ajan, mikä vähentää toistuvia luku- ja kirjoitusoperaatioita silloin, kun laskennan rakenne sallii sen. 2

SIMT epäsäännöllisempään laskentaan

SIMT tarjoaa vaihtoehtoisen mallin operaattorin osille, joissa muistiosoitteet ovat epäsäännöllisiä tai suoritus haarautuu. Kuvatussa lähestymistavassa SIMT:stä hyötyvät osat erotetaan tiheästä, SIMD:lle sopivasta työstä. Molemmille tehdään sopivat muunnokset, minkä jälkeen tulokset yhdistetään laajempaan vektorilaskentaan. 2

Tiiviimpi Cube–Vector-yhteys

Esityksessä korostettiin myös Cube- ja Vector-laskennan välistä tiedonsiirtoa. A2- ja A3-sukupolvien joissakin työnkuluissa Cube- ja Vector-osien välinen siirto kulki globaalin muistin kautta. Ascend 950:ssä kuvattu polku voi siirtää Cube-tuloksia L0C:stä Vectorin sirun sisäiseen muistiin ja Vector-tuloksia takaisin Cube-muistiin, mikä lyhentää laskentayksiköiden välistä reittiä. 2

Tämä on merkittävää operaattoreissa, joissa matriisipainotteinen Cube-laskenta seuraa vektorikäsittelyä. Kääntäjän on silti pääteltävä tarkasti, missä tensorit sijaitsevat ja milloin siirtoja tarvitaan — erityisesti silloin, kun Cube- ja Vector-operaatiot ovat eri ohjausvirtahaaroissa.

Passit tekevät mallista käytännöllisen

Useat nimetyt kääntäjäpassit osoittavat, miten AscendNPU IR muuttaa abstraktion konkreettisiksi muisti- ja ajoituspäätöksiksi.

InsertCVLoadStore

Parannettu InsertCVLoadStore analysoi Cube–Vector-tiedonsiirtoa myös monimutkaisen ohjausvirran yli. Se ei perustu vain yksinkertaiseen paikalliseen hahmontunnistukseen. Passi asettaa muistipaikkojen ankkurit — esimerkiksi matriisituloille L1-muistin, matriisituloille ja -tuloksille L0C:n sekä vektoridatalle UB:n — ja välittää nämä rajoitteet ohjelman läpi. Jos muistialueet eivät täsmää, kääntäjä lisää tarvittavat muunnokset tai kopiot. 2

A2- ja A3-laitteistoilla osa näistä risteävistä siirroista voidaan toteuttaa globaalin muistin kautta. Ascend 950 hyödyntää tuettuna lyhyempiä sirun sisäisiä reittejä. 2

MultiBuffer

MultiBuffer muodostaa olemassa olevasta tensorista useita puskuroituja kopioita. Se tukee esimerkiksi ping-pong-puskurointia, jossa datan siirtoa ja laskentaa voidaan limittää, jos muistibudjetti ja ajoitus sen sallivat. 1718

AutoBlockify ja DynamicCVPipeline

AutoBlockify ja DynamicCVPipeline kuuluvat Triton-Ascend-kääntäjäpinon Ascend-kohtaisiin passeihin. Nimet viittaavat kahteen keskeiseen tehtävään: laskennan jakamiseen suoritettaviksi lohkoiksi ja Cube–Vector-putken muodostamiseen. 19

Dokumentoitu ominaisuusjoukko sisältää lisäksi automaattisen muistisuunnittelun, synkronoinnin, ajoituksen sekä Cube–Vector-optimointeja. 24

CV 1:2 -jako

Esityksessä kuvattiin kokoonpano, jossa yhtä Cube-ydintä vastaa kaksi Vector-ydintä. AutoSubTiling voi jakaa Vector-työn niin, että kaksi Vector-ydintä käsittelee erillisiä osuuksia samanaikaisesti. 214

Mitä avoin julkaisu merkitsee kehittäjille?

Huawei julkaisi AscendNPU IR:n ja Triton-Ascendin avoimesti yhteisökehitystä varten. Triton-Ascend on Ascend-alustalle sovitettu Triton-käännöskehys: se säilyttää Tritonin keskeisen syntaksin ja lisää Ascend-kohtaisen käännös- ja käyttöönottotuen A2-, A3- ja 950-sarjan tuotteille. 3037

Avoin julkaisu antaa kehittäjille suoremman väylän esimerkiksi kääntäjäpassien, etupääintegraatioiden, operaattorien laskun ja laitteistotietoisten optimointien kehittämiseen ilman, että koko kääntäjäpinoa tarvitsee rakentaa itse.

Ascend-yhteisön ohjelmaan kuuluu lähteiden mukaan repositorioihin linkitettyjä harjoittelupaikkoja ja tehtäväkohtaisia palkkioita. Kehittäjä voi varata listatun tehtävän, toteuttaa sen ja toimittaa työn ohjelman sääntöjen mukaisesti. 31

Jos paikallista Ascend-laitteistoa ei ole, kehittäjät voivat tiettävästi käyttää yhteisön HiDevLab-pilviympäristöä, jossa on tarjolla 100 tuntia ilmaista laskenta-aikaa. Saatavilla oleva raportointi vahvistaa tuntimäärän, mutta ei kerro kaikkia kelpoisuus-, tunnistautumis-, vanhenemis- tai alueellisen saatavuuden ehtoja. Ne kannattaa tarkistaa rekisteröitymisen yhteydessä. 31

Lopputulos

AscendNPU IR:n tärkein lupaus on arkkitehtuurinen: Ascend-laitteistolle voidaan tuoda useita tuttuja ohjelmointirajapintoja ilman, että mahdollisuus yksityiskohtaiseen suorituskyvyn virittämiseen katoaa. Triton, TileLang ja kehyskohtaiset IR:t voivat liittyä mukaan korkeammalla abstraktiotasolla, HFusion hoitaa laajemmat muunnokset ja HIVM laskee tilеt Ascend-laitteiden vaatimiksi muisti-, ydin-, tiedonsiirto- ja putkipäätöksiksi. 511

Ascend 950 nostaa optimoinnin tavoitetasoa rekisteripohjaisella SIMD:llä, SIMT:llä ja tiiviimmillä Cube–Vector-datapoluilla. Todellinen suorituskyky riippuu silti operaattorin muodosta, muistipaineesta, ohjausvirrasta, kääntäjän kypsyydestä ja käytettävästä piiristä. Avoin pino tekee näistä kompromisseista aiempaa läpinäkyvämpiä ja antaa operaattori- sekä kääntäjäkehittäjille mahdollisuuden osallistua niiden parantamiseen.