AIREITERUn dépôt GitHub public peut donner l’impression qu’une pile matérielle est immédiatement accessible. Le travail de DeepSeek autour d’Ascend est bien réel et utile, mais il ne transforme pas un cluster NVIDIA en solution de remplacement installable en une commande : la version actuelle cible les kernels Ascend 950 et nécessite CANN, torch_npu ainsi qu’un matériel compatible.
En bref : des composants ouverts, pas un cluster Ascend prêt à l’emploi
DeepSeek a publié du code conçu pour Ascend, notamment DeepGEMM-Ascend, une bibliothèque de kernels sous licence MIT qui conserve la forme de l’API DeepGEMM tout en ciblant les NPU de Huawei. Sa première version prend en charge les appareils Ascend 950 et documente un environnement composé de CANN 9.20, de torch_npu, de Python 3.10 ou ultérieur, d’une toolchain C++20 et de TileLang.
De quoi permettre à une équipe disposant d’un accès Ascend compatible d’inspecter, compiler, mesurer et intégrer certains kernels. Pas de quoi fournir une pile complète pour l’entraînement ou la production.
Les laboratoires équipés d’Ascend, les opérateurs cloud et les entreprises peuvent déjà évaluer ce code. En revanche, un développeur qui ne dispose que de NVIDIA peut l’étudier ou utiliser les projets de DeepSeek destinés à NVIDIA, mais pas exécuter ces kernels Ascend sur une H100 ou une carte GeForce grand public.
Ce que DeepSeek a réellement publié
L’open-infra-index de DeepSeek organise ses travaux d’infrastructure par couches. L’index d’origine reste principalement orienté NVIDIA/Hopper : FlashMLA fournit un kernel de décodage MLA pour les GPU Hopper, DeepEP est une bibliothèque de communication pour le parallélisme par experts, DeepGEMM une bibliothèque GEMM FP8, tandis que DualPipe et EPLB traitent le parallélisme distribué et que 3FS/Smallpond couvrent l’accès aux données.
La version dédiée à Ascend change de cible matérielle pour certains chemins de calcul, sans remplacer toutes les couches d’un coup. L’artefact public le plus concret est DeepGEMM-Ascend, qui couvre :
- les opérations GEMM BF16, FP8 et FP4 ;
- les logits MQA ;
- les chemins grouped GEMM et MegaMoE ;
- un kernel mHC prenorm ; et
- la compilation JIT et les transformations de layouts propres à Ascend.
Le projet indique être compatible avec l’API de DeepGEMM. Cette compatibilité est précieuse pour les ingénieurs modèles, mais elle ne rend pas les binaires CUDA portables pour autant. Les layouts matriciels, le conditionnement des facteurs d’échelle, le compilateur, le runtime et les API de gestion des appareils propres à Ascend restent déterminants.
Cartographie des composants : les équivalents Ascend d’une pile orientée NVIDIA
Le tableau ci-dessous met en correspondance des rôles, et non des implémentations présentées comme identiques. Un équivalent remplit une fonction comparable, mais peut reposer sur une API, une interconnexion ou une stratégie de kernel différente.
| Couche | Code ou dépendance Ascend confirmés | Équivalent orienté NVIDIA | Limites |
|---|---|---|---|
| Multiplication matricielle | DeepGEMM-Ascend | DeepGEMM avec kernels CUDA/Tensor Core | Même rôle GEMM, mais primitives matérielles et layouts de données différents |
| Calcul groupé pour MoE | M-Grouped GEMM et MegaMoE dans DeepGEMM-Ascend | Layouts MoE de DeepGEMM avec kernels CUDA personnalisés | Calcul fusionné des experts, avec des formes et des limites propres à chaque plateforme |
| Routage des experts | Aucune bibliothèque complète de dispatch Ascend de DeepSeek n’est identifiée dans cette version ; il faut utiliser les collectives Ascend et les intégrations d’opérateurs | DeepEP avec NVLink/RDMA | Problématique système similaire, mais dépôts non interchangeables |
| Attention/logits | Logits MQA dans DeepGEMM-Ascend | FlashMLA pour Hopper | Charge de travail similaire ; FlashMLA cible explicitement Hopper |
| Passerelle PyTorch vers l’appareil | TorchNPU (torch_npu) | Backend PyTorch CUDA, runtime CUDA et cuBLAS | TorchNPU fait appel aux NPU Ascend ; il n’émule pas CUDA |
| Toolchain compilateur/opérateurs | CANN et outils Ascend C/Bisheng | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | Le code Python peut sembler familier, mais le contrat avec l’appareil change |
| Runtime distribué | Collectives TorchNPU et outils Huawei/opérateurs pour le déploiement | NCCL, réseau compatible CUDA et logiciels de cluster NVIDIA | Interconnexion, pilotes, collectives et versions des frameworks restent distincts |
| Stockage/accès aux données | Aucun composant de stockage DeepSeek spécifique à Ascend n’est identifié ici ; le stockage est fourni par l’opérateur | 3FS/Smallpond de DeepSeek avec la pile de stockage de l’opérateur | La version des kernels n’inclut pas de cluster de stockage associé |
En résumé, chaque équivalent Ascend remplit un rôle dans le système, mais aucun ne fait disparaître l’écosystème logiciel NVIDIA.
Kernels de calcul : DeepGEMM-Ascend face à DeepGEMM
DeepGEMM-Ascend est le pont le plus concret de cette version. Son README décrit une abstraction légère au-dessus des primitives MAD d’Ascend, qui masque les layouts fractals, les contraintes d’alignement, les calculs d’adresses et les paramètres bas niveau. Le projet exploite aussi des techniques propres à Ascend, comme le chargement parcimonieux des données et le pipeline fondé sur les coroutines.
Les prérequis publiés sont précis : matériel de la série Ascend 950, CANN 9.20, torch_npu, Python 3.10 ou ultérieur, bibliothèque standard compatible C++20, TileLang et dépendances de compilation comprenant Tree-sitter. La procédure d’installation documentée inclut git clone --recursive, puis pip install . --no-build-isolation.
Le dépôt annonce une utilisation du dense GEMM atteignant 99.8% de la limite matérielle indiquée sur une configuration de test Ascend 950DT. Un cas BF16 est donné à 431 TFLOPS pour une limite matérielle de 432 TFLOPS ; les cas FP8 atteignent 861 pour 865. Il s’agit de résultats de kernels pour certaines formes, pas du débit de DeepSeek de bout en bout ni d’une preuve de parité avec un cluster NVIDIA.
Exécution MoE : MegaMoE et dispatch des experts
L’open-infra-index de DeepSeek identifie une infrastructure de parallélisme par experts pour ses systèmes V3/R1. La question n’est donc pas seulement de savoir à quelle vitesse s’exécute une multiplication matricielle isolée : les tokens doivent être routés, les experts doivent calculer, puis les résultats doivent être regroupés entre les différents ranks.
Le benchmark MegaMoE de DeepGEMM-Ascend fusionne le dispatch du parallélisme par experts, deux grouped GEMM, SwiGLU et la phase de combine. La configuration annoncée est EP8, top-k 6, un expert partagé, avec une moyenne calculée sur huit ranks. Pour un cas à 384 experts et 16,384 tokens, le README indique 846.3 TFLOPS pour une configuration hidden/intermediate présentée et 103.3 GB/s de bande passante de communication pour un autre cas.
Chez NVIDIA, la comparaison repose sur DeepEP, les layouts MoE de DeepGEMM et l’environnement NCCL/NVLink/RDMA qui les entoure. Le problème d’architecture est similaire, mais les chiffres ne peuvent pas être transposés d’un fournisseur à l’autre sans aligner le nombre de tokens, le routage des experts, la précision, le nombre de ranks et les conditions réseau.
Kernels spécifiques aux modèles : logits MQA et mHC prenorm
Le projet Ascend inclut aussi des kernels faciles à manquer si l’on résume la version à un simple « portage de GEMM ». Le README de DeepGEMM-Ascend présente son benchmark des logits MQA comme destiné au chemin DeepSeek Lightning Indexer. Il liste des cas de prefill et de decode en FP8 et FP4 ; le decode FP4 est donné à 124.2 microsecondes pour la forme documentée, contre 150.9 microsecondes en FP8.
Le même README associe son kernel HC prenorm au module mHC de DeepSeek, ou Manifold-Constrained Hyper-Connections. La bande passante mémoire annoncée atteint 3,463 GB/s à M=8,192 pour les valeurs N et K documentées. Ces résultats montrent une optimisation ciblée sur certaines charges, pas une couverture de tous les opérateurs du modèle ou de tous les chemins de serving.
Framework et runtime : CANN et TorchNPU face à CUDA
Le dépôt TorchNPU de Huawei présente TorchNPU comme un adaptateur PyTorch pour les NPU Ascend. Sa liste de fonctionnalités comprend les API PyTorch natives et personnalisées, FSDP2, DTensor, les opérations collectives, la capture de graphes, le profiling, la supervision WatchDog et des fonctions de gestion mémoire.
Chez NVIDIA, l’équivalent conceptuel est l’ensemble PyTorch, runtime CUDA et bibliothèques associées. La différence opérationnelle est importante : une installation Ascend nécessite la bonne version de CANN, du pilote, du firmware, de Python, de PyTorch et de TorchNPU. L’exemple de la documentation TorchNPU installe CANN 9.1.0, PyTorch 2.12.0 et torch-npu 2.12.0, tandis que DeepGEMM-Ascend documente séparément CANN 9.20. Cet écart de version rappelle qu’il faut suivre la matrice de compatibilité de chaque dépôt plutôt que mélanger des commandes issues de guides différents.
La documentation CANN de Huawei présente CANN comme la couche logicielle qui relie les frameworks au matériel Ascend, avec des fonctions de runtime et de développement d’opérateurs. En pratique, CANN se rapproche davantage du socle de la plateforme que d’une bibliothèque CUDA isolée. Un modèle PyTorch peut conserver une syntaxe Python familière tout en nécessitant des kernels propres à Ascend, un comportement de graphe spécifique et des procédures de débogage différentes.
Ce qui reste en dehors de cette version
L’index d’infrastructure ouverte d’origine de DeepSeek inclut des projets de stockage et de niveau système comme 3FS et Smallpond, et décrit également DualPipe, EPLB ainsi qu’une architecture de système d’inférence. Ces projets constituent des références importantes, mais la version de kernels dédiée à Ascend ne doit pas être interprétée comme leur portage complet.
Un cluster de production nécessite encore le provisionnement du matériel, les pilotes et le firmware, l’installation de CANN, la configuration de l’interconnexion, la prise en charge du runtime distribué, l’observabilité, la gestion des checkpoints, la reprise après incident et un orchestrateur de serving ou d’entraînement. Le guide de déploiement de DeepSeek sur Huawei Cloud illustre cette dimension infrastructure avec des instances, du réseau, des sous-réseaux et des groupes de sécurité ; ces services sont des prérequis de déploiement, pas des composants de DeepGEMM-Ascend.
Cette distinction est particulièrement importante pour l’entraînement. Des kernels publics peuvent réduire un goulot d’étranglement sans démontrer qu’un entraînement à l’échelle d’un modèle de pointe est reproductible à partir des seuls dépôts publics.
Qui peut utiliser cette pile aujourd’hui ?
| Utilisateur ou organisation | Utilisable maintenant ? | Ce qu’il faut | Verdict pratique |
|---|---|---|---|
| Équipe disposant de matériel Ascend 950 | Oui, pour les kernels pris en charge | Environnement Linux, pilote/firmware compatibles, CANN 9.20, TorchNPU, compilateur et configuration Python/PyTorch compatible | Le profil idéal pour une adoption précoce |
| Opérateur Huawei Cloud ou entreprise disposant de capacité Ascend | Potentiellement oui | Une instance ou un cluster compatible, la matrice logicielle exacte et l’expertise nécessaire au déploiement | Adapté à une évaluation et à du serving contrôlés |
| Laboratoire de recherche équipé d’un ancien matériel Ascend | Pas automatiquement | Vérifier la prise en charge de l’appareil ; la première version de DeepGEMM-Ascend a été développée et validée sur la série Ascend 950 | Ne pas supposer la compatibilité avec 910B/910C |
| Propriétaire d’une station de travail uniquement équipée de NVIDIA | Non pour les kernels Ascend | Le matériel Ascend est un prérequis documenté | Utiliser plutôt les dépôts DeepSeek destinés à NVIDIA |
| Développeur PyTorch sans accès à un accélérateur | Pas dans un sens réellement opérationnel | Il peut consulter le code et étudier les API, mais pas reproduire les benchmarks matériels | L’accès à la documentation ne vaut pas accès à l’exécution |
| Équipe cherchant un remplacement clé en main pour l’entraînement de modèles de pointe | Non, aucune preuve publique à ce stade | Il faut un cluster complet, une intégration système et une validation en production allant au-delà des dépôts de kernels | À traiter comme un programme d’infrastructure, pas comme un simple pip install |
La limite pratique apparaît aussi dans les prérequis : pour la version documentée, le logiciel reste lié au matériel Ascend 950, à CANN et à torch_npu. C’est une promesse bien plus limitée que la portabilité générale entre accélérateurs.
Ce que les chiffres publiés démontrent — et ce qu’ils ne démontrent pas
Le chiffre de 99.8% pour le dense GEMM montre utilement que le kernel Ascend testé peut exploiter efficacement l’appareil sur certaines formes. Les tableaux MegaMoE indiquent en outre que les ingénieurs de DeepSeek se sont attaqués à des charges de travail fusionnées et parallélisées par experts, et pas uniquement à une multiplication matricielle isolée.
Aucun de ces résultats ne répond toutefois aux questions qui intéressent au bout du compte une équipe chargée des achats ou de l’entraînement :
- Quel est le nombre de tokens par seconde de bout en bout sur le modèle complet ?
- Quel est le coût par token pour la taille de batch visée ?
- Quelle est la stabilité des longues exécutions et des redémarrages ?
- Quels opérateurs repassent par des chemins moins optimisés ?
- Comment l’interconnexion, la mémoire et la consommation se comparent-elles au cluster NVIDIA envisagé ?
- Les mêmes résultats sont-ils reproductibles en dehors de l’environnement de test d’origine ?
DeepSeek a publié un travail sérieux sur les kernels Ascend, avec des détails de configuration et des tableaux de performances ciblés. Cette version réduit la barrière logicielle pour les équipes déjà présentes dans l’écosystème Ascend, mais les barrières matérielles et de compatibilité restent bien là.
FAQ
L’infrastructure Ascend de DeepSeek est-elle entièrement open source ?
Non. DeepGEMM-Ascend et la documentation associée sont publics, mais l’ensemble ne fournit pas un cluster d’entraînement DeepSeek clé en main avec toutes ses dépendances et procédures d’exploitation.
Puis-je exécuter DeepGEMM-Ascend sur un GPU NVIDIA ?
Non. Il cible le matériel Ascend 950. Les utilisateurs NVIDIA doivent se tourner vers les projets DeepSeek orientés NVIDIA.
Est-ce la preuve que DeepSeek entraîne des modèles de pointe sur Ascend ?
Non. Cela prouve que DeepSeek a publié des kernels Ascend et mesuré certaines charges de travail. Cela ne constitue pas une reproduction publique et complète d’un entraînement de modèle de pointe.
Utilisez cette pile dès maintenant si vous disposez déjà d’une capacité Ascend compatible et pouvez prendre en charge les questions de compatibilité entre CANN et TorchNPU. Avec du matériel NVIDIA uniquement, considérez cette version comme une référence technique, pas comme un backend directement exécutable.