AscendNPU IR, il ponte open source tra Triton e i chip Ascend

AscendNPU IR non è un nuovo linguaggio pensato per gli utenti finali, ma il livello intermedio open source che Huawei colloca alla base del compilatore BiSheng. Durante il nono Meet AI Compiler, organizzato da HyperAI a Pechino l’1 agosto 2026, l’architetta di Huawei Hai Lijuan ha illustrato come questa infrastruttura basata su MLIR possa collegare Triton e altri ecosistemi di operatori all’hardware Ascend. 37

L’obiettivo è separare il codice con cui si descrive un’operazione dal lavoro molto più complesso necessario per eseguirla su un NPU: suddividere i dati in tile, trasferirli tra i diversi livelli di memoria on-chip, coordinare i core Cube e Vector, inserire sincronizzazioni e generare il codice binario del dispositivo.

Che cos’è AscendNPU IR

AscendNPU IR è una rappresentazione intermedia, o IR, costruita sull’ecosistema MLIR e destinata alla compilazione di operatori ottimizzati per i processori Ascend. Offre più livelli di astrazione: quelli superiori nascondono i dettagli di istruzioni, trasferimenti e sincronizzazioni; quelli inferiori consentono agli sviluppatori di controllare con maggiore precisione indirizzi della memoria on-chip, pipeline e riuso dei buffer. 411

Il sistema può ricevere input da più percorsi. Linguaggi specifici per dominio come Triton e TileLang possono essere convertiti in AscendNPU IR, mentre framework e compilatori possono collegarsi attraverso Torch IR, Linalg/HFusion IR o HIVM IR. I livelli più alti possono automatizzare fusione, tiling, suddivisione e scheduling; HIVM offre invece un controllo più diretto sui livelli di memoria e sulle pipeline di calcolo Ascend. 522

Il flusso, in forma semplificata, è questo:

Triton, TileLang o IR di un framework
                    ↓
          AscendNPU IR basato su MLIR
                    ↓
             HFusion → HIVM
                    ↓
       istruzioni e binario per Ascend

La documentazione indica bishengir-compile come lo strumento per trasformare l’MLIR in un oggetto destinato al dispositivo, che può poi essere registrato ed eseguito tramite il runtime CANN. 6

Perché l’astrazione a tile è importante

Un tile è un blocco gestibile di dati e calcoli. Invece di costringere ogni front-end a descrivere singolarmente ogni trasferimento, decisione sulla memoria, punto di sincronizzazione e istruzione hardware, AscendNPU IR usa una rappresentazione comune orientata ai tile.

La struttura è volutamente stratificata. Ai livelli superiori si possono esprimere operazioni tensoriali senza indicare ogni dettaglio dell’hardware. Ai livelli inferiori, invece, il compilatore può dedurre o rendere esplicita la collocazione dei dati in GM, UB, L1 e L0 e l’impiego delle risorse Vector, Cube e MTE. 522

Il compromesso è tra portabilità e ottimizzazione: Triton, TileLang o un framework possono puntare alla stessa base di compilazione, mentre il codice più sensibile alle prestazioni può scendere verso una rappresentazione molto più consapevole dell’architettura. La documentazione ufficiale descrive una serie di astrazioni disaccoppiate che modellano progressivamente istruzioni Ascend, risorse locali ai core, risorse tra core e risorse del system-on-chip. 11

HFusion e HIVM: due livelli, due compiti

HFusion: fusioni e scheduling ad alto livello

HFusion è il livello relativamente indipendente dall’hardware. Rappresenta le operazioni tensoriali a un livello elevato e applica trasformazioni come fusione, bufferizzazione, tiling e scheduling prima della scelta delle istruzioni hardware dettagliate. 1122

Qui il compilatore può combinare più operazioni e dividere un calcolo in tile adatti al modello di esecuzione. L’idea è conservare la semantica dell’operazione, preparando al tempo stesso il passaggio verso un’esecuzione specifica per Ascend.

HIVM: la discesa verso l’hardware

HIVM è il livello consapevole dell’hardware. Traduce le espressioni a tile in operazioni che riflettono unità di calcolo, gerarchia della memoria e comportamento delle pipeline Ascend. Tra i suoi compiti rientrano:

• assegnare le operazioni matriciali ai core Cube e quelle vettoriali ai core Vector;
• inserire o gestire comunicazioni e sincronizzazioni tra queste unità;
• amministrare la memoria di workspace intermedia;
• associare i tensori logici alla memoria fisica on-chip;
• gestire layout Cube come le rappresentazioni matriciali frattali;
• applicare vettorizzazione, tensorizzazione, pipelining e trasformazioni a livello di istruzione. 214

Questa separazione consente di ottimizzare a due distanze diverse dall’hardware. HFusion ragiona sulla struttura complessiva dei tensori e sulle opportunità di fusione; HIVM si concentra sulle risorse di memoria, calcolo e comunicazione necessarie per eseguire i tile risultanti.

Cosa cambia con Ascend 950

La divisione tra HFusion e HIVM resta invariata, ma il livello hardware deve ora gestire più del precedente percorso SIMD basato sulla memoria. Il materiale dedicato ad Ascend 950 descrive il supporto anche a SIMD basato sui registri e SIMT. 2

SIMD basato sui registri

In questo modello i dati vengono caricati dalla memoria on-chip nei registri, elaborati al loro interno e poi riscritti. Quando la struttura del calcolo lo consente, la fusione a livello di registro può mantenere i valori intermedi nei registri tra un’operazione e l’altra, riducendo caricamenti e scritture ripetuti. 2

SIMT per i calcoli meno regolari

SIMT offre un percorso alternativo per porzioni adatte con accessi irregolari o divergenze. L’approccio descritto separa il lavoro che beneficia di SIMT da quello denso e più adatto a SIMD, applica a ciascuna parte la trasformazione appropriata e ricompone il risultato nel calcolo vettoriale complessivo. 2

Comunicazione più stretta tra Cube e Vector

La presentazione ha evidenziato anche un cambiamento nel collegamento tra Cube e Vector. Nei flussi A2/A3 alcuni passaggi tra i due domini utilizzavano la memoria globale. Su Ascend 950, il percorso descritto può trasferire i risultati Cube da L0C alla memoria on-chip Vector e riportare i risultati Vector nella memoria Cube, accorciando la distanza tra le due unità di esecuzione. 2

Questo è rilevante per gli operatori in cui un calcolo matriciale Cube è seguito da un’elaborazione vettoriale. Il compilatore deve comunque determinare dove risiedono i tensori e quando siano necessari trasferimenti, soprattutto se le operazioni Cube e Vector compaiono in rami diversi del controllo di flusso.

I pass che rendono il modello eseguibile

Alcuni pass nominati nella documentazione mostrano come AscendNPU IR trasformi l’astrazione in decisioni concrete su memoria e scheduling.

InsertCVLoadStore

Il flusso potenziato InsertCVLoadStore analizza le comunicazioni Cube–Vector anche attraverso strutture di controllo complesse, invece di inserire i trasferimenti con semplici corrispondenze locali. Il pass stabilisce ancoraggi di memoria — per esempio input matriciali in L1, output matriciali in L0C e dati vettoriali in UB — quindi propaga questi vincoli nel programma e inserisce conversioni o copie quando i domini di memoria entrano in conflitto. 2

Su A2/A3 i passaggi descritti possono utilizzare operazioni di caricamento e scrittura attraverso la memoria globale; su Ascend 950 sono disponibili, quando supportati, percorsi on-chip più ravvicinati. 2

MultiBuffer

MultiBuffer rappresenta più copie dello stesso tensore. Questo abilita schemi di buffering alternato, o ping-pong buffering, e può aiutare a sovrapporre trasferimenti di dati e calcolo quando memoria e scheduling lo permettono. 1718

AutoBlockify e DynamicCVPipeline

AutoBlockify e DynamicCVPipeline sono tra i pass specifici di Ascend presenti nello stack Triton-Ascend. I nomi descrivono due attività centrali: dividere il calcolo in blocchi eseguibili e costruire il comportamento della pipeline Cube–Vector. 19

Il set di funzionalità documentato comprende inoltre pianificazione automatica della memoria, sincronizzazione, scheduling e ottimizzazioni Cube–Vector. 24

Suddivisione CV 1:2

La presentazione ha descritto, per una configurazione Ascend rilevante, un rapporto tra un core Cube e due core Vector. AutoSubTiling può dividere il lavoro vettoriale affinché i due core Vector elaborino porzioni separate in parallelo. 214

Cosa significa l’apertura del codice per gli sviluppatori

Huawei ha pubblicato AscendNPU IR insieme a Triton-Ascend per favorire lo sviluppo della comunità. Triton-Ascend è il framework di compilazione di Triton orientato alla piattaforma Ascend: mantiene la sintassi principale di Triton e aggiunge supporto alla compilazione e al deployment sui prodotti Ascend A2, A3 e della serie 950. 3037

L’apertura crea anche un percorso più diretto per chi vuole lavorare su pass del compilatore, integrazione dei front-end, lowering degli operatori o ottimizzazione consapevole dell’hardware senza dover costruire da zero un’intera toolchain. Il programma della comunità comprende tirocini collegati ai repository e attività con ricompense: gli sviluppatori possono rivendicare i task disponibili e inviare il lavoro completato secondo le regole del programma. 31

Chi non dispone di hardware Ascend può inoltre utilizzare, secondo le informazioni disponibili, HiDevLab, l’ambiente cloud della comunità Ascend, con 100 ore gratuite di calcolo. Le fonti confermano il monte ore, ma non specificano tutti i requisiti di idoneità, le modalità di verifica, la scadenza o la disponibilità regionale; questi aspetti vanno quindi controllati al momento della registrazione. 31

Il punto chiave

La proposta di AscendNPU IR è soprattutto architetturale: rendere l’hardware Ascend accessibile attraverso punti d’ingresso comuni, mantenendo al tempo stesso una strada per la messa a punto a basso livello. Triton, TileLang e gli IR dei framework possono entrare ai livelli più alti; HFusion può occuparsi delle trasformazioni generali; HIVM può tradurre i tile nelle decisioni su memoria, core, comunicazioni e pipeline richieste dai dispositivi Ascend. 511

Ascend 950 amplia il margine di ottimizzazione con SIMD basato sui registri, SIMT e percorsi Cube–Vector on-chip più diretti. Questo non garantisce automaticamente prestazioni migliori in ogni scenario: il risultato dipenderà dalla forma dell’operatore, dalla pressione sulla memoria, dal controllo di flusso, dalla maturità del compilatore e dal chip utilizzato. L’apertura del codice, però, rende questi compromessi più analizzabili e offre agli sviluppatori di compilatori e operatori un modo concreto per contribuire alla loro evoluzione.