Les tests publiés par SemiAnalysis le 21 octobre 2026 mesurent des opérations précises sur un Huawei Ascend 950PR_9579. La même analyse examine un profil de DeepSeek-V4.1-Flash publié par Huawei pour 32 puces Ascend 950DT. Ces résultats décrivent des kernels et un déploiement particulier, pas les performances globales de DeepSeek ni une parité générale avec NVIDIA.
Un kernel est une fonction de calcul exécutée par un accélérateur. Son efficacité peut être très élevée sans que l’ensemble d’un modèle d’IA atteigne le même niveau : les échanges entre puces et les autres étapes du travail comptent aussi.
Ce que mesurent les tests de l’Ascend 950PR
Le modèle testé, l’Ascend 950PR_9579, comptait 28 cœurs Cube et 128 GiB de mémoire HBM. Sur 1 055 formes de multiplication de matrices en BF16, les meilleurs kernels de torch.matmul, l’opération standard de multiplication de matrices de PyTorch, ont atteint 99,7 % du plafond de calcul mesuré par SemiAnalysis.
Ce chiffre concerne le meilleur résultat des kernels dans cette série de tests. Il ne signifie pas que DeepSeek-V4.1-Flash utilise 99,7 % de la capacité de la puce, ni qu’un service ou un entraînement complet atteint ce rendement.
Un autre test, dit de parcours de pointeurs, mesurait la latence pour lire 16 KiB à chaque lancement. Elle restait proche de 134 ns jusqu’à 18 blocs, puis atteignait 182 ns à 56 blocs et 391 ns à 64 blocs. Ces valeurs concernent ce test précis sur le 950PR_9579.
Ascend 950PR et H100 sur les formes limitées par le calcul
Pour un sous-ensemble de formes limitées par le calcul, SemiAnalysis rapporte la fraction médiane de la performance atteinte par rapport à la performance atteignable : 41,5 % sur Ascend 950PR et 46,8 % sur NVIDIA H100.
| Accélérateur | Fraction médiane atteinte/atteignable sur les formes sélectionnées limitées par le calcul |
| Ascend 950PR | 41,5 % |
| NVIDIA H100 | 46,8 % |
SemiAnalysis indique que certains résultats du H100 étaient limités par la puissance. Ces deux pourcentages décrivent les formes retenues dans cette comparaison, pas un classement universel des accélérateurs. Le même article rapporte aussi des résultats de bande passante mémoire qui varient selon la taille des transferts : l’Ascend 950PR dépassait le H100 pour les petits messages et s’en rapprochait en taux d’utilisation pour les grands.
Ce que révèle le profil de DeepSeek-V4.1-Flash
Le profil publié par Huawei et analysé par SemiAnalysis porte sur un rang de DeepSeek-V4.1-Flash exécuté sur 32 puces Ascend 950DT. Dans la fenêtre observée en régime stable, le flux d’exécution Stream 19 était occupé pendant 88,8 % du temps. Il représentait 72,6 % du temps total additionné sur les appareils. Ces mesures diffèrent parce que plusieurs flux peuvent travailler en chevauchement.
SemiAnalysis a également calculé un scénario de premier ordre : si le débit des unités Cube doublait, l’amélioration d’une étape serait de 1,32×, à condition que le chevauchement mesuré des flux et les périodes d’inactivité restent identiques. C’est un calcul conditionnel, pas une accélération mesurée sur une nouvelle puce.
Logiciels adaptés à Ascend, avec des limites côté x86
Le 30 septembre 2026, DeepSeek a publié la prise en charge d’Ascend dans six dépôts : TileLang, DeepGEMM, DeepEP, TileKernels, FlashMLA et DeepSelect. Ce jalon faisait suite à l’annonce des outils de programmation pour Ascend couverte dans notre précédent article. Dans son analyse du 21 octobre, SemiAnalysis indiquait que TileLang était alors le seul de ces dépôts utilisable.
Les logiciels n’ont pas tous le même rôle. DeepGEMM-Ascend est une bibliothèque spécialisée dans certains kernels de multiplication de matrices ; CANN est la plateforme logicielle plus large de Huawei. Dans son tutoriel en anglais, Cloud Codes détaille aussi les dispositions de données adaptées à la hiérarchie mémoire d’Ascend, le traitement des facteurs d’échelle FP8 et des opérations d’API groupées masquées indiquées comme non implémentées.
SemiAnalysis décrit DeepEP-Ascend comme un port de DeepEP V2.5 qui conserve la même API Python et utilise URMA et HCCL pour les communications. Le calcul et la communication peuvent se chevaucher, mais ils sollicitent aussi des ressources communes, notamment le traitement vectoriel et la bande passante mémoire.
Pour les développeurs utilisant un hôte x86, SemiAnalysis signalait des limites dans vLLM-Ascend_0.26.0rc1 : DeepGEMM n’y était pas pris en charge, une dépendance comportait des en-têtes ARM codés en dur qui bloquaient le démarrage, l’association des tâches aux cœurs du processeur était ignorée sur les processeurs non ARM et l’intégration continue ne couvrait pas les configurations NPU avec x86.
