Testy Huawei Ascend opisane przez SemiAnalysis dotyczą konkretnych operacji na układzie Ascend 950PR_9579, a analiza profilu DeepSeek-V4.1-Flash obejmuje jeden rank na 32 układach Ascend 950DT. Wyniki pokazują, jak zachowują się wybrane kernele i wdrożenie, ale nie określają ogólnej wydajności całego modelu.
Co oznacza wynik 99,7%?
W analizie opublikowanej 21 października 2026 r. SemiAnalysis podało, że najlepsze standardowe kernele torch.matmul na Ascend 950PR osiągnęły 99,7% zmierzonego pułapu wydajności. Wynik pochodzi z testów 1 055 kształtów BF16 GEMM, czyli wariantów mnożenia macierzy w formacie liczbowym BF16. Testowany układ Ascend 950PR_9579 miał 28 rdzeni Cube i 128 GiB pamięci HBM.
Liczba 99,7% opisuje najlepsze wyniki tych operacji względem zmierzonego pułapu. Nie mówi, z jaką szybkością DeepSeek-V4.1-Flash generuje odpowiedzi ani jak sprawuje się cały system. Pełne zadanie modelu obejmuje także przesyłanie danych i komunikację między układami, a nie tylko mnożenie macierzy.
Jak Ascend 950PR wypada w wybranym porównaniu z H100?
Dla wybranych kształtów ograniczonych obliczeniami SemiAnalysis podało medianę stosunku osiągniętej do osiągalnej wydajności: 41,5% dla Ascend 950PR i 46,8% dla NVIDIA H100.
| Akcelerator | Mediana osiągniętej wydajności względem osiągalnej |
| Ascend 950PR | 41,5% |
| NVIDIA H100 | 46,8% |
To porównanie dotyczy wybranego zestawu obliczeń, a nie wszystkich zadań czy ogólnej pozycji obu układów. SemiAnalysis zaznaczyło również, że część wyników H100 ograniczał pobór mocy. Wartości te nie zastępują pomiarów całego modelu ani systemu obsługującego wiele układów.
Co mówi profil DeepSeek-V4.1-Flash?
Profil opublikowany przez Huawei i analizowany przez SemiAnalysis obejmuje jeden rank DeepSeek-V4.1-Flash działający na 32 układach Ascend 950DT. Opisany fragment wykonania zawiera 40 warstw modelu docelowego, trzy bloki modułu DSpark oraz pięć rund próbkowania.
W oknie pracy ustalonej Stream 19, strumień wykonujący główne obliczenia, był zajęty przez 88,8% czasu. Jednocześnie odpowiadał za 72,6% sumarycznego czasu pracy urządzenia. Te wartości mają różne podstawy: praca strumieni może nakładać się w czasie, dlatego udział w oknie i udział w sumie czasu urządzenia nie są tym samym wskaźnikiem.
SemiAnalysis opisało także scenariusz, w którym podwojenie przepustowości jednostek Cube dałoby 1,32× poprawy czasu kroku. To obliczenie zakłada niezmienione nakładanie się strumieni i taki sam czas bezczynności jak w analizowanym profilu. Nie jest to wynik zmierzonego przyspieszenia.
Oprogramowanie i ograniczenia hostów x86
30 września 2026 r. DeepSeek udostępnił obsługę Ascend w repozytoriach TileLang, DeepGEMM, DeepEP, TileKernels, FlashMLA i DeepSelect. W analizie z 21 października SemiAnalysis oceniło, że wówczas użyteczny był TileLang. NeoTeo opisało wcześniejsze ogłoszenie wsparcia programowego dla Ascend; obecne wyniki dotyczą pomiarów i profilu wykonania.
W anglojęzycznym samouczku Cloud Codes DeepGEMM-Ascend jest przedstawiony jako wyspecjalizowana biblioteka kerneli do określonych operacji, a CANN jako szersza warstwa oprogramowania Huawei. Materiał omawia też dostosowanie układu danych do hierarchii pamięci Ascend oraz pakowanie współczynników skalujących FP8 do 16-bitowych kontenerów. Wynik 99,8% pułapu sprzętowego wspomniany w tym samouczku dotyczy odrębnego pomiaru i nie jest bezpośrednio porównywalny z wynikiem 99,7% dla torch.matmul.
Dla wersji vLLM-Ascend_0.26.0rc1 SemiAnalysis opisało problemy z hostami x86, w tym brak obsługi DeepGEMM oraz błąd startowy związany z nagłówkami ARM. Wskazało też, że przypinanie procesów CPU było pomijane na procesorach innych niż ARM.