DeepSeek na Ascend 950: co działa poza CUDA?

Tak. Na Ascend 950 można już uruchamiać wyspecjalizowane biblioteki DeepSeek do mnożenia macierzy, komunikacji MoE, selekcji TopK oraz sparse attention. README’y DeepGEMM-Ascend, DeepSelect i FlashMLA datują publikację odpowiednich komponentów na 30 września 2026 roku (DeepGEMM-Ascend, DeepSelect, FlashMLA).

To konkretne biblioteki operatorów, a nie gotowy zamiennik CUDA ani kompletny runtime do uruchamiania dowolnego modelu. Przy migracji trzeba uwzględnić natywny stos Ascend, zgodne wersje CANN i torch_npu, formaty tensorów oraz wymagania sieciowe komunikacji między akceleratorami.

W skrócie

• GEMM: DeepGEMM-Ascend obsługuje BF16, FP8 i FP4, a także MQA logits i MegaMoE. README wymaga CANN 9.20 oraz torch_npu (dokumentacja DeepGEMM-Ascend).
• Komunikacja MoE: DeepEP-Ascend oferuje dispatch w BF16 lub FP8 i combine w BF16. Wymaga Ascend 950 A5 oraz właściwej łączności między rangami (dokumentacja DeepEP-Ascend).
• TopK: wariant Ascend w DeepSelect obsługuje BF16, topk do 4096 i indeksy int32; optymalizowano go głównie dla topk=512. Wejście FP32 w scenariuszu samplera pozostaje obsługiwane tylko przez CUDA (dokumentacja DeepSelect).
• Sparse attention: FlashMLA dostarcza na Ascend 950 kernele do faz prefill i decoding. FP4 ma jednak określoną rolę w formacie KV cache i nie jest dowolnym wyborem dla całego cache (README FlashMLA).

Co można już uruchomić

DeepGEMM-Ascend: mnożenie macierzy i obliczenia MoE

DeepGEMM-Ascend jest portem biblioteki DeepGEMM na platformę Ascend. README deklaruje zgodność API z DeepGEMM oraz obsługę GEMM w BF16, FP8 i FP4, obliczania MQA logits i MegaMoE. To daje zespołowi konkretne operatory do wykorzystania w przepływach modelu, ale samo istnienie tych operatorów nie przesądza o zgodności całego modelu ani jego runtime’u z Ascend. (Dokumentacja DeepGEMM-Ascend)

Zgodność API nie oznacza, że binaria CUDA można przenieść bez zmian. Repozytorium wskazuje, że format czynników skalujących na Ascend różni się od wariantu NVIDIA: pary wartości są pakowane i przechowywane w innym układzie. Przy integracji należy zatem sprawdzić przygotowanie tensora oraz ścieżkę kwantyzacji, a nie tylko podmienić urządzenie docelowe. (Dokumentacja DeepGEMM-Ascend)

DeepEP-Ascend: dispatch i combine dla MoE

DeepEP-Ascend realizuje komunikację expert-parallel typu all-to-all: rozsyła tokeny do ekspertów, a później zbiera wyniki. README wymienia dispatch dla wejść BF16 lub FP8 oraz combine w BF16. Choć publiczne API buforów jest zbliżone do wersji NVIDIA, obsługiwane tryby i zachowanie strumieni są specyficzne dla backendu Ascend. (Dokumentacja DeepEP-Ascend)

Warunki sprzętowo-sieciowe są istotne dla odtworzenia konfiguracji wielorangowej. README wymaga Ascend 950 A5 z łącznością UBMEM i kanałami UBC_CTP/URMA między rangami; przy komunikacji wielorangowej podaje parzystą liczbę rang. Wymienia też CANN, kompilator Bisheng oraz biblioteki i nagłówki HCCL/HCOMM. (Wymagania DeepEP-Ascend)

Warto ostrożnie czytać wyniki wydajności podane w repozytorium. Zmierzono je na ręcznie skonfigurowanym, niepublicznym HDK PoC. README opisuje komercyjny pakiet HDK dla Atlas 850E jako planowany na połowę października 2026 roku, z zastrzeżeniem, że termin zależy od publikacji Huawei. Na 5 października te pomiary nie potwierdzają więc wydajności komercyjnej konfiguracji, która nie była jeszcze publicznie dostępna. (Warunki pomiarów i wymagania DeepEP-Ascend)

DeepSelect i FlashMLA: TopK oraz sparse attention

DeepSelect udostępnia TopK używany między innymi w scenariuszu Lightning Indexer. Wariant Ascend przyjmuje BF16, wymaga topk nie większego niż 4096 i jest optymalizowany przede wszystkim dla wartości 512. Ascend obsługuje indeksy int32. W scenariuszu samplera wejście FP32 działa obecnie tylko w implementacji CUDA, więc jeśli model wymaga tej ścieżki, trzeba zachować osobny wariant albo zmienić typ wejścia i zweryfikować skutki numeryczne. (Dokumentacja DeepSelect)

FlashMLA dostarcza na Ascend 950 kernele sparse attention dla prefill i decoding. W decoding cache BF16 nie jest obsługiwany. Główny k_cache powinien używać formatu V4.1, a FP4 jest dopuszczony wyłącznie dla extra_k_cache przy głównym k_cache w formacie V4.1. To ograniczenie ma znaczenie przy integracji: ogólna informacja o FP8 i FP4 nie oznacza, że można swobodnie wybrać format dla całego cache. (README FlashMLA, format KV cache)

Zakres operatorów attention również nie jest jednolity. FlashMLA udostępnia na Ascend sparse prefill i decoding, natomiast opisany w README kernel gęstego MHA, obejmujący forward i backward, obsługuje obecnie tylko CUDA. Sama obecność kernelu attention nie oznacza więc parytetowości wszystkich ścieżek obliczeń. (README FlashMLA, obsługiwane kernele)

CANN i zależności środowiska

CANN to stos programistyczny Huawei dla akceleratorów Ascend. Dokumentacja instalacyjna Huawei opisuje narzędzia do tworzenia aplikacji i operatorów oraz integrację z frameworkami AI, w tym PyTorch (przewodnik instalacji CANN). Wymagania konkretnych bibliotek należy jednak sprawdzać osobno: DeepGEMM-Ascend podaje CANN 9.20, README DeepEP-Ascend wymienia CANN 9.2.0 jako wersję zweryfikowanego stosu użytego w pomiarach, a FlashMLA wymaga CANN 9.2.0 lub nowszego. Repozytoria wymagają także torch_npu; DeepGEMM-Ascend i FlashMLA wskazują Bisheng w wymaganiach budowania. (DeepGEMM-Ascend, DeepEP-Ascend, FlashMLA)

Moja praktyczna rekomendacja: przypiąć wersje według instrukcji każdej biblioteki i sprawdzić cały zestaw na docelowym obrazie systemowym. Zgodność jednej biblioteki z daną wersją CANN nie potwierdza automatycznie zgodności pozostałych.

Co trzeba sprawdzić przed migracją

Wydanie FlashMLA z 30 września wprowadziło zmianę niezgodną wstecz. Usunęło obsługę architektury Hopper oraz wcześniejszych modeli, w tym DeepSeek V3, V3.2 i V4.0, a także zmieniło format cache FP8/FP4. README zaznacza, że wydanie nie jest zgodne z poprzednimi wersjami; przy tych starszych modelach lub dawnym formacie cache odsyła do wcześniejszego commita. To konkretna pozycja do sprawdzenia przed migracją, zwłaszcza gdy wdrożenie współdzieli cache między wersjami serwisu. (Informacja o niezgodności FlashMLA)

DeepEP-Ascend także nie obejmuje jeszcze wszystkich funkcji komunikacyjnych. Batched all-gather jest dostępny, ale reduce-scatter i all-reduce dla BucketBuffer są nadal rozwijane. Funkcje równoważenia obciążenia ekspertów nie mają jeszcze zaimplementowanych kerneli komunikacyjnych dla Ascend, a interfejsy PP i Engram pozostają eksperymentalne. README wskazuje ponadto brak obsługi hybrid communication, pamięci Engram opartej na CPU i graph capture. (Aktualne ograniczenia DeepEP-Ascend)

Z zakresu tych repozytoriów wnioskuję, że opisują one przede wszystkim biblioteki operatorów i komunikacji. Nie gwarantują automatycznie integracji z servingiem, schedulerem, checkpointami ani pozostałymi operatorami modelu. Te elementy trzeba zweryfikować w wybranym runtime’ie i konkretnym wdrożeniu.

Jak oceniłbym migrację

Zacząłbym od pojedynczej ścieżki krytycznej. Dla modelu MoE sprawdziłbym razem grouped GEMM oraz dispatch i combine w DeepEP. Dla sparse attention przetestowałbym przepływ BF16 przez TopK w DeepSelect i przekazanie indeksów do FlashMLA.

Następnie spisałbym wymagania każdego etapu: kształty tensorów, typy danych, układy skalowania, format głównego k_cache i ewentualnego extra_k_cache, a także wersję CANN i dostępne funkcje sieciowe. Dla FlashMLA uwzględniłbym warunek FP4 i upewniłbym się, że docelowy model nie należy do wyłączonych wersji.

Na koniec porównałbym wyjścia z dotychczasową implementacją CUDA przy tych samych kształtach i tolerancjach numerycznych. Osobno zmierzyłbym pierwszą kompilację, kolejne uruchomienia, prefill, decoding i koszt komunikacji przy docelowej liczbie rang. To plan walidacji, nie wynik benchmarku.

Na 5 października 2026 roku Ascend 950 ma już wartościowe komponenty DeepSeek do GEMM, komunikacji EP, TopK i sparse attention. Ocenę wdrożenia produkcyjnego wyznaczają jednak ograniczenia operatorów, wymagania CANN i HDK, format cache oraz zgodność z konkretną wersją modelu.