Nie kolejny język, lecz wspólny poziom kompilacji

AscendNPU IR ma być otwartym fundamentem kompilatora BiSheng, a nie kolejnym językiem programowania dla użytkowników końcowych. Podczas dziewiątego salonu technicznego Meet AI Compiler, który odbył się 1 sierpnia 2026 r. w pekińskim Zhongguancun, architektka Huawei Hai Lijuan przedstawiła sposób, w jaki oparty na MLIR stos ma łączyć Triton i inne ekosystemy operatorów ze sprzętem Ascend. 37

Znaczenie praktyczne jest proste: frontend może opisywać obliczenia na wyższym poziomie, a kompilator przejmuje coraz trudniejsze zadania związane z dzieleniem danych na tile, przenoszeniem ich między poziomami pamięci, synchronizacją rdzeni Cube i Vector oraz generowaniem kodu urządzenia.

AscendNPU IR działa jako wielopoziomowa reprezentacja pośrednia (IR — intermediate representation) zbudowana w ekosystemie MLIR. Oferuje zarówno abstrakcje ukrywające szczegóły instrukcji i synchronizacji, jak i niższe poziomy pozwalające precyzyjnie sterować rozmieszczeniem danych w pamięci układowej oraz zachowaniem potoków. 411

Jak wygląda droga od Tritona do układu Ascend?

AscendNPU IR może przyjmować dane z kilku ścieżek. Języki DSL, takie jak Triton i TileLang, mogą obniżać swoje konstrukcje do AscendNPU IR. Z kolei frameworki i inne kompilatory mogą podłączać się przez Torch IR, Linalg/HFusion IR albo HIVM IR. Wyższe poziomy zapewniają między innymi automatyczne łączenie operacji, tiling, dzielenie obliczeń i harmonogramowanie, natomiast HIVM daje bardziej bezpośrednią kontrolę nad pamięcią i potokami obliczeniowymi Ascend. 522

Uproszczony przepływ wygląda następująco:

Triton, TileLang lub IR frameworka
                ↓
      AscendNPU IR oparty na MLIR
                ↓
         HFusion → obniżanie do HIVM
                ↓
      Instrukcje urządzenia i binarium Ascend

W udokumentowanym przykładzie narzędzie bishengir-compile przekształca kod MLIR w obiekt przeznaczony dla urządzenia. Następnie taki obiekt można zarejestrować i uruchomić za pomocą interfejsów runtime środowiska CANN. 6

W szerszym ujęciu AscendNPU IR ma łączyć wejście z języków i frameworków z niższymi poziomami kompilacji, w tym z LLVM IR, a ostatecznie generować binaria dla akceleratorów Ascend. 1

Dlaczego ważny jest poziom tile?

Tile to niewielki, zarządzalny blok danych i obliczeń. Bez wspólnej reprezentacji każdy frontend musiałby osobno opisywać transfery, decyzje dotyczące poziomu pamięci, punkty synchronizacji i instrukcje konkretnego układu. AscendNPU IR pozwala opisać te elementy w jednym, zorientowanym na tile modelu.

To kompromis między przenośnością a strojenie wydajności. Na wyższym poziomie programista może wyrazić operacje tensorowe bez ręcznego określania każdego szczegółu sprzętowego. Na niższym poziomie kompilator może jednak ujawnić lub wywnioskować rozmieszczenie danych w obszarach takich jak GM, UB, L1 i L0, a także wykorzystanie zasobów Vector, Cube i jednostek przenoszenia danych. 522

Dokumentacja architektury opisuje ten model jako zestaw rozdzielonych abstrakcji, które stopniowo odwzorowują instrukcje Ascend, zasoby lokalne rdzenia, zasoby międzyrdzeniowe oraz zasoby system-on-chip. 11

HFusion i HIVM: dwa poziomy optymalizacji

HFusion — optymalizacja z większego dystansu

HFusion jest względnie niezależną od sprzętu warstwą modelu kompilatora. Operuje na tensorach i wyższych konstrukcjach, a przed zejściem do szczegółowych instrukcji wykonuje między innymi łączenie operacji, bufferization, tiling i harmonogramowanie. 1122

To właśnie tutaj kompilator może połączyć kilka operacji w większy fragment obliczeń, a następnie podzielić go na tile dopasowane do modelu wykonawczego. Celem jest zachowanie znaczenia operacji na wysokim poziomie i jednoczesne przygotowanie ich do specyficznego dla Ascend obniżania.

HIVM — zejście do realiów sprzętu

HIVM jest warstwą świadomą sprzętu. Przekłada wyrażenia tile na operacje odzwierciedlające jednostki wykonawcze, hierarchię pamięci i działanie potoków Ascend. Obejmuje to:

• mapowanie operacji macierzowych na rdzenie Cube, a wektorowych na rdzenie Vector;
• uzupełnianie lub zarządzanie komunikacją i synchronizacją między tymi jednostkami;
• zarządzanie pamięcią roboczą dla danych pośrednich;
• odwzorowanie logicznych tensorów w fizycznej pamięci układowej;
• obsługę układów macierzowych Cube, w tym reprezentacji fraktalnych macierzy;
• wektoryzację, tensorization, potokowanie i transformacje na poziomie instrukcji. 214

Podział pozwala optymalizować obliczenia z dwóch perspektyw. HFusion analizuje ogólną strukturę tensorów i możliwości łączenia operacji, a HIVM rozstrzyga, z jakich dokładnie zasobów pamięci i wykonawczych trzeba skorzystać, aby uruchomić gotowe tile.

Co zmienia Ascend 950?

Podział na HFusion i HIVM pozostaje bez zmian, ale warstwa sprzętowa musi obsłużyć więcej niż wcześniejszy model SIMD oparty na dostępie do pamięci. Materiały dotyczące Ascend 950 opisują wsparcie dla SIMD opartego na rejestrach oraz dla SIMT, obok dotychczasowego modelu wykonania. 2

SIMD oparty na rejestrach

W rejestrowym SIMD dane są ładowane z pamięci układowej do rejestrów, przetwarzane w nich, a następnie zapisywane z powrotem. Jeśli charakter obliczeń na to pozwala, fuzja na poziomie rejestrów może utrzymać wartości pośrednie w rejestrach przez kilka operacji. Ogranicza to liczbę powtarzających się odczytów i zapisów. 2

SIMT dla mniej regularnych obliczeń

SIMT daje kompilatorowi dodatkową ścieżkę obsługi fragmentów z nieregularnym dostępem do danych lub rozbieżnymi ścieżkami wykonania. Opisany model rozdziela pracę, która lepiej pasuje do SIMT, od gęstych i przyjaznych SIMD obliczeń, stosuje dla nich odpowiednie transformacje, a następnie łączy wyniki w szerszy przepływ wektorowy. 2

Krótsza droga między Cube i Vector

W starszych przepływach A2/A3 część przejść między obliczeniami Cube i Vector wykorzystywała pamięć globalną. W Ascend 950 opisywana ścieżka może przenosić wyniki Cube z L0C do pamięci układowej Vector, a rezultaty Vector z powrotem do pamięci Cube. Skraca to dystans między dwiema domenami wykonawczymi. 2

Ma to znaczenie dla operatorów, w których obliczenia macierzowe są następnie przetwarzane wektorowo. Kompilator nadal musi jednak poprawnie ustalić, gdzie znajdują się tensory i kiedy potrzebny jest transfer — zwłaszcza gdy operacje Cube i Vector występują w różnych gałęziach sterowania.

Pasy, które zamieniają abstrakcję w harmonogram

Kilka nazwanych passów pokazuje, jak AscendNPU IR przekłada model tile na konkretne decyzje dotyczące pamięci i wykonania.

InsertCVLoadStore

Rozszerzony przepływ InsertCVLoadStore analizuje komunikację Cube–Vector także w złożonych strukturach sterowania, zamiast dodawać transfery na podstawie prostego lokalnego dopasowania wzorców. Najpierw ustanawia kotwice lokalizacji pamięci — przykładowo wejścia mnożenia macierzy w L1, wyjścia w L0C, a dane wektorowe w UB. Następnie propaguje te ograniczenia przez program i dodaje konwersje lub kopie tam, gdzie dochodzi do konfliktu domen pamięci. 2

W A2/A3 opisywane przejścia mogą korzystać z operacji odczytu i zapisu przez pamięć globalną. Ascend 950 może używać obsługiwanych ścieżek lokalnych w pamięci układowej. 2

MultiBuffer

MultiBuffer tworzy wiele kopii istniejącego tensora. Może to umożliwić buforowanie ping-pong oraz nakładanie transferu danych na obliczenia, o ile pozwalają na to budżet pamięci i harmonogram. 1718

AutoBlockify i DynamicCVPipeline

AutoBlockify oraz DynamicCVPipeline to przykłady passów specyficznych dla stosu Triton-Ascend. Ich nazwy dobrze oddają dwa kluczowe zadania: dzielenie obliczeń na wykonywalne bloki oraz budowanie potoku Cube–Vector. 19

Udokumentowany zestaw funkcji obejmuje również automatyczne planowanie pamięci, synchronizację, harmonogramowanie i optymalizacje komunikacji Cube–Vector. 24

Podział CV 1:2

Prezentacja opisywała konfigurację, w której jednemu rdzeniowi Cube odpowiadają dwa rdzenie Vector. AutoSubTiling może podzielić pracę Vector tak, aby oba rdzenie przetwarzały osobne fragmenty równolegle. 214

Co otwarcie kodu oznacza dla programistów?

Huawei udostępniło AscendNPU IR oraz Triton-Ascend w modelu otwartego współtworzenia. Triton-Ascend to dostosowany do platformy Ascend framework kompilacji Tritona. Zachowuje podstawową składnię Tritona, a jednocześnie dodaje obsługę kompilacji i wdrażania na produktach z serii A2, A3 i 950. 3037

Otwarcie kodu tworzy bardziej bezpośrednią ścieżkę dla osób, które chcą pracować nad passami kompilatora, integracją frontendów, obniżaniem operatorów lub optymalizacją świadomą sprzętu — bez konieczności budowania całego łańcucha kompilacji od podstaw.

Według dostępnych informacji program społecznościowy obejmuje staże powiązane z repozytoriami oraz zadania z nagrodami. Programiści mogą zgłosić się do wskazanego zadania, a następnie przesłać ukończoną pracę zgodnie z zasadami programu. 31

Osoby bez lokalnego sprzętu Ascend mogą według tych samych informacji skorzystać z chmurowego środowiska HiDevLab społeczności Ascend, które oferuje 100 bezpłatnych godzin obliczeniowych. Dostępne materiały potwierdzają sam limit, ale nie precyzują wszystkich warunków dotyczących uprawnień, weryfikacji, terminu ważności ani dostępności regionalnej. Te szczegóły warto sprawdzić podczas rejestracji. 31

Najważniejszy wniosek

Główna propozycja AscendNPU IR ma charakter architektoniczny: udostępnić sprzęt Ascend przez wspólne punkty wejścia kompilatora, nie odbierając jednocześnie możliwości szczegółowego strojenia pod konkretny układ. Triton, TileLang i IR frameworków mogą wejść na wyższym poziomie abstrakcji, HFusion może wykonać szersze transformacje, a HIVM sprowadza tile do decyzji dotyczących pamięci, rdzeni, komunikacji i potoków wymaganych przez urządzenia Ascend. 511

Ascend 950 podnosi sufit możliwych optymalizacji dzięki rejestrowemu SIMD, SIMT i bliższym ścieżkom przesyłania danych między Cube i Vector. Nie oznacza to jednak automatycznej przewagi w każdym zastosowaniu. Rzeczywista wydajność nadal zależy od kształtu operatora, presji na pamięć, przepływu sterowania, dojrzałości kompilatora i konkretnego układu.

Otwarte udostępnienie stosu sprawia, że te kompromisy są łatwiejsze do zbadania, a programiści kompilatorów i operatorów mogą bezpośrednio uczestniczyć w ich dalszym rozwoju.

Nie kolejny język, lecz wspólny poziom kompilacji

AscendNPU IR ma być otwartym fundamentem kompilatora BiSheng, a nie kolejnym językiem programowania dla użytkowników końcowych. Podczas dziewiątego salonu technicznego Meet AI Compiler, który odbył się 1 sierpnia 2026 r. w pekińskim Zhongguancun, architektka Huawei Hai Lijuan przedstawiła sposób, w jaki oparty na MLIR stos ma łączyć Triton i inne ekosystemy operatorów ze sprzętem Ascend. 37

Znaczenie praktyczne jest proste: frontend może opisywać obliczenia na wyższym poziomie, a kompilator przejmuje coraz trudniejsze zadania związane z dzieleniem danych na tile, przenoszeniem ich między poziomami pamięci, synchronizacją rdzeni Cube i Vector oraz generowaniem kodu urządzenia.

AscendNPU IR działa jako wielopoziomowa reprezentacja pośrednia (IR — intermediate representation) zbudowana w ekosystemie MLIR. Oferuje zarówno abstrakcje ukrywające szczegóły instrukcji i synchronizacji, jak i niższe poziomy pozwalające precyzyjnie sterować rozmieszczeniem danych w pamięci układowej oraz zachowaniem potoków. 411

Jak wygląda droga od Tritona do układu Ascend?

AscendNPU IR może przyjmować dane z kilku ścieżek. Języki DSL, takie jak Triton i TileLang, mogą obniżać swoje konstrukcje do AscendNPU IR. Z kolei frameworki i inne kompilatory mogą podłączać się przez Torch IR, Linalg/HFusion IR albo HIVM IR. Wyższe poziomy zapewniają między innymi automatyczne łączenie operacji, tiling, dzielenie obliczeń i harmonogramowanie, natomiast HIVM daje bardziej bezpośrednią kontrolę nad pamięcią i potokami obliczeniowymi Ascend. 522

Uproszczony przepływ wygląda następująco:

Triton, TileLang lub IR frameworka
                ↓
      AscendNPU IR oparty na MLIR
                ↓
         HFusion → obniżanie do HIVM
                ↓
      Instrukcje urządzenia i binarium Ascend

W udokumentowanym przykładzie narzędzie bishengir-compile przekształca kod MLIR w obiekt przeznaczony dla urządzenia. Następnie taki obiekt można zarejestrować i uruchomić za pomocą interfejsów runtime środowiska CANN. 6

W szerszym ujęciu AscendNPU IR ma łączyć wejście z języków i frameworków z niższymi poziomami kompilacji, w tym z LLVM IR, a ostatecznie generować binaria dla akceleratorów Ascend. 1

Dlaczego ważny jest poziom tile?

Tile to niewielki, zarządzalny blok danych i obliczeń. Bez wspólnej reprezentacji każdy frontend musiałby osobno opisywać transfery, decyzje dotyczące poziomu pamięci, punkty synchronizacji i instrukcje konkretnego układu. AscendNPU IR pozwala opisać te elementy w jednym, zorientowanym na tile modelu.

To kompromis między przenośnością a strojenie wydajności. Na wyższym poziomie programista może wyrazić operacje tensorowe bez ręcznego określania każdego szczegółu sprzętowego. Na niższym poziomie kompilator może jednak ujawnić lub wywnioskować rozmieszczenie danych w obszarach takich jak GM, UB, L1 i L0, a także wykorzystanie zasobów Vector, Cube i jednostek przenoszenia danych. 522

Dokumentacja architektury opisuje ten model jako zestaw rozdzielonych abstrakcji, które stopniowo odwzorowują instrukcje Ascend, zasoby lokalne rdzenia, zasoby międzyrdzeniowe oraz zasoby system-on-chip. 11

HFusion i HIVM: dwa poziomy optymalizacji

HFusion — optymalizacja z większego dystansu

HFusion jest względnie niezależną od sprzętu warstwą modelu kompilatora. Operuje na tensorach i wyższych konstrukcjach, a przed zejściem do szczegółowych instrukcji wykonuje między innymi łączenie operacji, bufferization, tiling i harmonogramowanie. 1122

To właśnie tutaj kompilator może połączyć kilka operacji w większy fragment obliczeń, a następnie podzielić go na tile dopasowane do modelu wykonawczego. Celem jest zachowanie znaczenia operacji na wysokim poziomie i jednoczesne przygotowanie ich do specyficznego dla Ascend obniżania.

HIVM — zejście do realiów sprzętu

HIVM jest warstwą świadomą sprzętu. Przekłada wyrażenia tile na operacje odzwierciedlające jednostki wykonawcze, hierarchię pamięci i działanie potoków Ascend. Obejmuje to:

• mapowanie operacji macierzowych na rdzenie Cube, a wektorowych na rdzenie Vector;
• uzupełnianie lub zarządzanie komunikacją i synchronizacją między tymi jednostkami;
• zarządzanie pamięcią roboczą dla danych pośrednich;
• odwzorowanie logicznych tensorów w fizycznej pamięci układowej;
• obsługę układów macierzowych Cube, w tym reprezentacji fraktalnych macierzy;
• wektoryzację, tensorization, potokowanie i transformacje na poziomie instrukcji. 214

Podział pozwala optymalizować obliczenia z dwóch perspektyw. HFusion analizuje ogólną strukturę tensorów i możliwości łączenia operacji, a HIVM rozstrzyga, z jakich dokładnie zasobów pamięci i wykonawczych trzeba skorzystać, aby uruchomić gotowe tile.

Co zmienia Ascend 950?

Podział na HFusion i HIVM pozostaje bez zmian, ale warstwa sprzętowa musi obsłużyć więcej niż wcześniejszy model SIMD oparty na dostępie do pamięci. Materiały dotyczące Ascend 950 opisują wsparcie dla SIMD opartego na rejestrach oraz dla SIMT, obok dotychczasowego modelu wykonania. 2

SIMD oparty na rejestrach

W rejestrowym SIMD dane są ładowane z pamięci układowej do rejestrów, przetwarzane w nich, a następnie zapisywane z powrotem. Jeśli charakter obliczeń na to pozwala, fuzja na poziomie rejestrów może utrzymać wartości pośrednie w rejestrach przez kilka operacji. Ogranicza to liczbę powtarzających się odczytów i zapisów. 2

SIMT dla mniej regularnych obliczeń

SIMT daje kompilatorowi dodatkową ścieżkę obsługi fragmentów z nieregularnym dostępem do danych lub rozbieżnymi ścieżkami wykonania. Opisany model rozdziela pracę, która lepiej pasuje do SIMT, od gęstych i przyjaznych SIMD obliczeń, stosuje dla nich odpowiednie transformacje, a następnie łączy wyniki w szerszy przepływ wektorowy. 2

Krótsza droga między Cube i Vector

W starszych przepływach A2/A3 część przejść między obliczeniami Cube i Vector wykorzystywała pamięć globalną. W Ascend 950 opisywana ścieżka może przenosić wyniki Cube z L0C do pamięci układowej Vector, a rezultaty Vector z powrotem do pamięci Cube. Skraca to dystans między dwiema domenami wykonawczymi. 2

Ma to znaczenie dla operatorów, w których obliczenia macierzowe są następnie przetwarzane wektorowo. Kompilator nadal musi jednak poprawnie ustalić, gdzie znajdują się tensory i kiedy potrzebny jest transfer — zwłaszcza gdy operacje Cube i Vector występują w różnych gałęziach sterowania.

Pasy, które zamieniają abstrakcję w harmonogram

Kilka nazwanych passów pokazuje, jak AscendNPU IR przekłada model tile na konkretne decyzje dotyczące pamięci i wykonania.

InsertCVLoadStore

Rozszerzony przepływ InsertCVLoadStore analizuje komunikację Cube–Vector także w złożonych strukturach sterowania, zamiast dodawać transfery na podstawie prostego lokalnego dopasowania wzorców. Najpierw ustanawia kotwice lokalizacji pamięci — przykładowo wejścia mnożenia macierzy w L1, wyjścia w L0C, a dane wektorowe w UB. Następnie propaguje te ograniczenia przez program i dodaje konwersje lub kopie tam, gdzie dochodzi do konfliktu domen pamięci. 2

W A2/A3 opisywane przejścia mogą korzystać z operacji odczytu i zapisu przez pamięć globalną. Ascend 950 może używać obsługiwanych ścieżek lokalnych w pamięci układowej. 2

MultiBuffer

MultiBuffer tworzy wiele kopii istniejącego tensora. Może to umożliwić buforowanie ping-pong oraz nakładanie transferu danych na obliczenia, o ile pozwalają na to budżet pamięci i harmonogram. 1718

AutoBlockify i DynamicCVPipeline

AutoBlockify oraz DynamicCVPipeline to przykłady passów specyficznych dla stosu Triton-Ascend. Ich nazwy dobrze oddają dwa kluczowe zadania: dzielenie obliczeń na wykonywalne bloki oraz budowanie potoku Cube–Vector. 19

Udokumentowany zestaw funkcji obejmuje również automatyczne planowanie pamięci, synchronizację, harmonogramowanie i optymalizacje komunikacji Cube–Vector. 24

Podział CV 1:2

Prezentacja opisywała konfigurację, w której jednemu rdzeniowi Cube odpowiadają dwa rdzenie Vector. AutoSubTiling może podzielić pracę Vector tak, aby oba rdzenie przetwarzały osobne fragmenty równolegle. 214

Co otwarcie kodu oznacza dla programistów?

Huawei udostępniło AscendNPU IR oraz Triton-Ascend w modelu otwartego współtworzenia. Triton-Ascend to dostosowany do platformy Ascend framework kompilacji Tritona. Zachowuje podstawową składnię Tritona, a jednocześnie dodaje obsługę kompilacji i wdrażania na produktach z serii A2, A3 i 950. 3037

Otwarcie kodu tworzy bardziej bezpośrednią ścieżkę dla osób, które chcą pracować nad passami kompilatora, integracją frontendów, obniżaniem operatorów lub optymalizacją świadomą sprzętu — bez konieczności budowania całego łańcucha kompilacji od podstaw.

Według dostępnych informacji program społecznościowy obejmuje staże powiązane z repozytoriami oraz zadania z nagrodami. Programiści mogą zgłosić się do wskazanego zadania, a następnie przesłać ukończoną pracę zgodnie z zasadami programu. 31

Osoby bez lokalnego sprzętu Ascend mogą według tych samych informacji skorzystać z chmurowego środowiska HiDevLab społeczności Ascend, które oferuje 100 bezpłatnych godzin obliczeniowych. Dostępne materiały potwierdzają sam limit, ale nie precyzują wszystkich warunków dotyczących uprawnień, weryfikacji, terminu ważności ani dostępności regionalnej. Te szczegóły warto sprawdzić podczas rejestracji. 31

Najważniejszy wniosek

Główna propozycja AscendNPU IR ma charakter architektoniczny: udostępnić sprzęt Ascend przez wspólne punkty wejścia kompilatora, nie odbierając jednocześnie możliwości szczegółowego strojenia pod konkretny układ. Triton, TileLang i IR frameworków mogą wejść na wyższym poziomie abstrakcji, HFusion może wykonać szersze transformacje, a HIVM sprowadza tile do decyzji dotyczących pamięci, rdzeni, komunikacji i potoków wymaganych przez urządzenia Ascend. 511

Ascend 950 podnosi sufit możliwych optymalizacji dzięki rejestrowemu SIMD, SIMT i bliższym ścieżkom przesyłania danych między Cube i Vector. Nie oznacza to jednak automatycznej przewagi w każdym zastosowaniu. Rzeczywista wydajność nadal zależy od kształtu operatora, presji na pamięć, przepływu sterowania, dojrzałości kompilatora i konkretnego układu.

Otwarte udostępnienie stosu sprawia, że te kompromisy są łatwiejsze do zbadania, a programiści kompilatorów i operatorów mogą bezpośrednio uczestniczyć w ich dalszym rozwoju.