AscendNPU IR má propojit Triton s hardwarem Huawei Ascend

AscendNPU IR není další programovací jazyk pro koncové uživatele. Jde o otevřenou mezivrtsvu kompilátoru BiSheng, postavenou na ekosystému MLIR. Jejím cílem je propojit Triton, TileLang a další frameworky či DSL s hardwarem Huawei Ascend, aniž by každý z nich musel samostatně řešit všechny detaily paměti, přesunů dat, synchronizace a generování instrukcí. 37

Architektka AscendNPU IR Hai Lijuan tento přístup představila 1. srpna 2026 na devátém technickém semináři Meet AI Compiler v pekingské čtvrti Zhongguancun. 37

Co AscendNPU IR dělá

AscendNPU IR je intermediate representation (IR), tedy mezivrstva mezi vyšším programovacím modelem a strojovým kódem pro NPU. Vychází z MLIR a nabízí několik úrovní abstrakce: vyšší vrstvy skrývají detaily instrukcí, přesunů a synchronizace, zatímco nižší vrstvy umožňují přesně řídit umístění dat v paměti a chování výpočetní pipeline. 411

Důležitým stavebním prvkem je tile, tedy dlaždice – menší blok tensorových dat a výpočtů. Front-end nemusí ručně popisovat každý přesun mezi paměťovými úrovněmi ani každý synchronizační bod. Kompilátor pracuje se společnou tile-based reprezentací a následně ji přizpůsobí konkrétnímu čipu.

Zjednodušený tok vypadá takto:

Triton, TileLang nebo frameworkové IR
                ↓
      MLIR-based AscendNPU IR
                ↓
        HFusion → HIVM lowering
                ↓
       instrukce a binární soubor pro Ascend

K AscendNPU IR lze přistupovat několika cestami. DSL jako Triton a TileLang se převádějí do AscendNPU IR, zatímco frameworky mohou využít například Torch IR, Linalg/HFusion IR nebo HIVM IR. Vyšší úrovně podporují automatické slučování operací, tiling, dělení a plánování; HIVM nabízí podrobnější kontrolu nad pamětí a výpočetními pipeline. 522

Dokumentovaný postup používá nástroj bishengir-compile, který převede MLIR na objektový soubor pro zařízení. Ten lze zaregistrovat a spustit prostřednictvím runtime rozhraní CANN. 6

Proč záleží na tile-level abstrakci

NPU musí současně řešit výpočet, přesouvání dat mezi paměťovými úrovněmi, synchronizaci i využití specializovaných jednotek. Pokud by všechny tyto volby musel řešit každý front-end zvlášť, integrace nového jazyka nebo frameworku by byla výrazně složitější.

AscendNPU IR proto odděluje snadnější použití od hlubokého ladění výkonu. Na vyšší úrovni lze popsat tensorové operace bez znalosti každé instrukce. Na nižší úrovni je možné explicitně nebo prostřednictvím kompilátoru pracovat s úrovněmi GM, UB, L1 a L0 a s prostředky Vector, Cube a MTE. 522

Oficiální architektura popisuje postupné vrstvení abstrakcí od instrukcí Ascendu přes zdroje uvnitř jader a mezi jádry až po zdroje celého systému na čipu. Výsledkem má být kompromis mezi přenositelností a možností detailního ladění. 11

HFusion a HIVM: dvě různé vzdálenosti od hardwaru

HFusion řeší vyšší úroveň optimalizace

HFusion je relativně hardwarově nezávislá část modelu. Pracuje s tensorovými operacemi a před podrobným mapováním na instrukce provádí například slučování operací, bufferizaci, dělení na dlaždice a plánování. 1122

Tato vrstva může spojit více operací do jednoho výpočetního celku a rozdělit rozsáhlejší úlohu na bloky vhodné pro cílový NPU. Zachovává přitom vyšší význam operací a připravuje je na následné převedení do hardwarově specifické podoby.

HIVM převádí dlaždice na konkrétní zdroje

HIVM je hardwarově uvědomělá vrstva. Tile výrazy převádí na operace odpovídající výpočetním jednotkám, paměťové hierarchii a pipeline Ascendu. Její úkoly zahrnují zejména:

• mapování maticových operací na jádra Cube a vektorových operací na jádra Vector;
• doplnění nebo správu komunikace a synchronizace mezi těmito jednotkami;
• správu dočasného workspace;
• mapování logických tensorů na fyzickou lokální paměť;
• práci s layouty pro Cube, včetně fraktálních reprezentací matic;
• vektorizaci, tensorizační transformace, pipeline a instrukční optimalizace. 214

HFusion tak může uvažovat o širší struktuře výpočtu a příležitostech ke slučování, zatímco HIVM řeší, kde konkrétní dlaždice skončí, jakými jednotkami projdou a kdy se musí přesunout či synchronizovat.

Co přináší Ascend 950

Rozdělení mezi HFusion a HIVM zůstává zachováno, ale hardwarově zaměřená část musí u Ascendu 950 pokrýt více než dřívější model SIMD založený na práci s pamětí. Popsané novinky zahrnují register-based SIMD a SIMT. 2

SIMD nad registry

Při register-based SIMD se data načtou z lokální paměti do registrů, zpracují se přímo v nich a následně se zapíší zpět. Pokud to charakter výpočtu dovolí, může slučování na úrovni registrů udržet mezivýsledky na místě a omezit opakované načítání a ukládání dat. 2

SIMT pro méně pravidelné části výpočtu

SIMT představuje další způsob zpracování vhodných částí s nepravidelným přístupem k datům nebo s větvením. Kompilátor může oddělit úseky, kterým SIMT vyhovuje, od hustých a pro SIMD vhodných částí, použít pro ně rozdílné transformace a následně výsledky znovu začlenit do širší vektorové pipeline. 2

Kratší cesta mezi Cube a Vector

U dřívějších toků A2/A3 se při některých přechodech mezi výpočtem Cube a Vector používala globální paměť. U Ascendu 950 může popsaná cesta přenést výsledek z L0C přímo do lokální paměti Vector a výsledek Vector vrátit zpět do paměti pro Cube. 2

Takové propojení je důležité u operací, v nichž po maticové části zpracovávané jednotkou Cube následuje vektorová část. Kompilátor však stále musí určit, kde se tensor nachází a kdy je přenos nutný – zejména pokud se Cube a Vector operace nacházejí v různých větvích řídicího toku.

Passy, které abstrakci převádějí do praxe

Několik konkrétních compiler passů ukazuje, jak se obecný tile-based model mění v rozhodnutí o paměti a plánování.

InsertCVLoadStore

Vylepšený tok InsertCVLoadStore analyzuje komunikaci mezi Cube a Vector i přes složitý řídicí tok. Nespoléhá jen na jednoduché lokální rozpoznání vzoru.

Nejprve vytvoří kotvy pro umístění dat – například vstupy matic v L1, výstupy v L0C a vektorová data v UB. Tyto podmínky následně šíří programem a při konfliktu paměťových domén vloží potřebné konverze nebo kopie. 2

U A2/A3 mohou popsané přenosy využívat operace načtení a uložení přes globální paměť, zatímco Ascend 950 podporuje tam, kde je to možné, kratší lokální cesty. 2

MultiBuffer

MultiBuffer vytváří více kopií existujícího tensoru. To umožňuje například ping-pong buffering, při němž se přesun dat překrývá s výpočtem. Přínos ale závisí na dostupné paměti a konkrétním rozvrhu. 1718

AutoBlockify a DynamicCVPipeline

AutoBlockify a DynamicCVPipeline patří mezi Ascend-specific passy v kompilátoru Triton-Ascend. První rozděluje výpočet na proveditelné bloky, druhý pomáhá sestavit chování pipeline mezi Cube a Vector. 19

Dokumentace mezi souvisejícími funkcemi uvádí také automatické plánování paměti, synchronizaci, scheduling a optimalizace Cube–Vector. 24

Dělení CV v poměru 1:2

Prezentace popsala konfiguraci, v níž na jedno jádro Cube připadá dvojice jader Vector. AutoSubTiling může vektorovou práci rozdělit tak, aby obě jádra zpracovávala různé části současně. 214

Co otevření kódu znamená pro vývojáře

Huawei zveřejnila AscendNPU IR společně s Triton-Ascend s cílem umožnit komunitní spolupráci. Triton-Ascend zachovává základní syntaxi Tritonu a přidává kompilaci a nasazení pro platformu Ascend, včetně produktových řad A2, A3 a 950. 3037

Vývojáři tak mohou pracovat na compiler passech, integraci front-endů, převodu operátorů i hardwarově specifických optimalizacích, aniž by museli od začátku stavět celý kompilátor. Oznámený komunitní program zahrnuje také stáže a úkoly navázané na repozitáře. Podle dostupných informací si vývojáři nárokují uvedené úkoly a po jejich dokončení odevzdávají práci v souladu s pravidly programu. 31

Kdo nemá lokální hardware Ascend, může podle dostupných zpráv využít cloudové prostředí HiDevLab od komunity Ascend, které nabízí 100 hodin výpočetního času zdarma. Zdroj ale neupřesňuje všechny podmínky způsobilosti, ověření, platnosti ani regionální dostupnosti, takže je vhodné ověřit je přímo při registraci. 31

Hlavní závěr

AscendNPU IR se snaží vyřešit jeden z dlouhodobých problémů akcelerátorů: jak zpřístupnit specializovaný hardware více programovacím ekosystémům, aniž by se ztratila možnost detailního ladění výkonu.

Triton, TileLang a frameworková IR mohou vstoupit na vyšší úrovni. HFusion se postará o širší transformace, slučování, tiling a plánování. HIVM pak dlaždice převede do konkrétní práce s pamětí, výpočetními jádry, komunikací a pipeline Ascend. 511

Ascend 950 posouvá možnosti dál díky register-based SIMD, SIMT a kratším cestám mezi Cube a Vector. Skutečný výkon však bude i nadále záviset na tvaru operátoru, tlaku na paměť, řídicím toku, vyspělosti kompilátoru a konkrétním čipu. Otevřený stack přinejmenším činí tyto kompromisy lépe prozkoumatelnými a dává vývojářům možnost podílet se na jejich zlepšování.