CUDA : pourquoi une puce ne suffit pas à faire une plateforme
CUDA associe un modèle de programmation à des logiciels permettant d’exécuter et d’optimiser des calculs sur les GPU NVIDIA.
La documentation NVIDIA distingue le pilote, le toolkit, le runtime et les bibliothèques. Le toolkit sert à écrire, compiler et analyser les programmes ; le runtime organise notamment la mémoire et le lancement des calculs. Un développeur peut utiliser CUDA sans programmer directement chaque instruction bas niveau.
Cette superposition explique pourquoi changer d’accélérateur n’est pas comparable à remplacer un écran. Le programme attend des fonctions, des formats et un comportement. La nouvelle plateforme doit fournir ces possibilités, ou le logiciel doit être adapté. Le mot « compatible » doit donc toujours préciser à quel étage il s’applique.
Notre lecture est que l’avantage d’un écosystème se mesure aussi dans les opérations quotidiennes : comprendre une erreur, retrouver une version fonctionnelle, observer un goulot d’étranglement et reproduire un résultat. Une bibliothèque rapide compte, mais la facilité de la maintenir dans un service compte également. C’est cette chaîne, plutôt qu’une seule puce, que les nouvelles publications rendent intéressante.
Du modèle au NPU : lire les différentes couches
Le modèle décrit des opérations ; la pile logicielle transforme ces opérations en calculs exécutables sur un matériel donné.
Un modèle IA traite des tableaux de nombres appelés tenseurs. Le framework exprime le calcul, puis des opérateurs et des bibliothèques réalisent les transformations. Le runtime pilote leur exécution. Un compilateur traduit les implémentations vers la cible. Ces rôles se recouvrent parfois : le tableau suivant est une grille pédagogique, pas un schéma officiel exhaustif.
Dans l’environnement Ascend, Huawei décrit CANN comme la couche qui relie les frameworks au NPU. La plateforme organise la collaboration entre CPU et NPU et propose des moyens de développer les opérateurs. Cela ne signifie pas qu’elle reprend l’implémentation NVIDIA : elle fournit sa propre chaîne vers son matériel.
| Couche | Rôle | Question lors d’une migration |
|---|---|---|
| Modèle | Architecture et poids | Les opérations et formats sont-ils pris en charge ? |
| Framework / adaptation | Exprimer le calcul et choisir le backend | Quelles versions fonctionnent ensemble ? |
| Runtime / bibliothèques | Planifier, communiquer, lancer les opérations | Les fonctions nécessaires existent-elles ? |
| Kernels / compilateur | Implémenter et traduire le calcul ciblé | Les données et la compilation sont-elles adaptées ? |
| GPU / NPU | Exécuter le calcul | Mémoire, échanges et capacités suffisent-ils ? |
Kernels et GEMM : les opérations derrière une réponse
Un kernel est une fonction de calcul lancée sur l’accélérateur. Un GEMM réalise une multiplication générale de matrices.
La référence cuBLAS définit notamment l’opération C = αAB + βC, avec des variantes de disposition et de types. Pour un lecteur non spécialiste, l’idée utile est de combiner efficacement de grands tableaux de nombres. Les couches d’un réseau neuronal répètent de nombreuses opérations de ce genre ; leur implémentation influence le temps de calcul.
Une même opération mathématique peut demander des choix très différents selon le matériel : où ranger les blocs, comment alimenter les unités de calcul, quand déplacer les données et comment synchroniser le travail. Un kernel bien adapté essaie de réduire l’attente entre ces opérations. Il ne change pas, à lui seul, la prestation rendue par le modèle.
Pour évaluer un portage, nous séparons trois questions : le calcul donne-t-il le résultat attendu, fonctionne-t-il sur la cible et est-il efficace pour les dimensions utiles ? Une réponse positive à la dernière question sur un cas ne remplace pas les deux premières sur tout le service. Cette distinction évite de confondre démonstration locale et solution opérationnelle.
DeepGEMM-Ascend : un portage réel, avec un contrat précis
DeepGEMM-Ascend porte la bibliothèque DeepGEMM vers la plateforme Huawei, avec des kernels développés et validés sur la série Ascend 950.
Le README annonce une première release le 30 septembre et le support des GEMM BF16, FP8 et FP4, des MQA logits et de MegaMoE. Il demande notamment CANN 9.20, torch_npu, Python 3.10 ou plus et un environnement C++20 adapté. Le code est publié sous licence MIT. Ce sont des composants disponibles, pas simplement une intention de recherche.
DeepSeek annonce une API compatible avec DeepGEMM, mais précise que les facteurs d’échelle n’ont pas le même format sur Ascend et NVIDIA. Conserver le nom d’une fonction facilite l’intégration ; cela ne rend pas identiques les données qu’elle reçoit. La compatibilité doit être vérifiée avec les outils de conversion et les tests du dépôt.
Pour un responsable de projet, la conséquence n’est pas « tout migrer maintenant », mais identifier un périmètre testable. Quelle opération est remplacée ? Quel format arrive en entrée ? Quel résultat et quelle tolérance sont attendus ? Les interfaces communes facilitent cette démarche sans dispenser d’une procédure de retour arrière.
BF16, FP8, FP4 : moins de bits, pas une promesse gratuite
Ces formats représentent les nombres avec des budgets différents ; la précision, le stockage et l’exécution doivent être considérés ensemble.
BF16 utilise 16 bits, FP8 huit et FP4 quatre. Réduire le nombre de bits peut alléger les données et ouvrir des chemins de calcul spécialisés. Mais une représentation compacte doit être interprétée correctement, avec ses facteurs d’échelle et ses contraintes. Il serait trompeur d’en déduire une réponse deux fois plus rapide chaque fois que le nombre de bits est divisé par deux.
Les MQA logits participent à la sélection des informations à examiner dans l’attention. MegaMoE regroupe plusieurs opérations liées aux experts, plutôt que de les traiter comme des étapes indépendantes. Dans un modèle à mélange d’experts, le routage et les échanges font donc partie du problème de performance, avec le calcul lui-même.
Notre recommandation est de choisir la mesure qui correspond à l’usage : exactitude sur des cas de référence, délai avant le premier token, débit sous charge et mémoire réellement mobilisée. Un format utile pour une opération n’est pas automatiquement le bon format pour chaque autre partie. La décision doit rester liée au modèle et au service visés.
FlashMLA : optimiser aussi la lecture du contexte
Le prefill traite le contexte initial ; le decoding produit ensuite les tokens. Ces phases ne sollicitent pas nécessairement le matériel de la même façon.
La release Ascend de FlashMLA ajoute des kernels d’attention sparse pour ces deux phases. L’attention sparse utilise une sélection de tokens plutôt que tous les éléments du contexte pour chaque calcul ciblé. La publication technique explique notamment comment les blocs KV sont lus, convertis et transmis entre unités de calcul.
Le rapport montre pourquoi le portage ne consiste pas à changer le nom du processeur : l’équipe arbitre entre mémoire locale, mouvements de données, déquantification et synchronisation. Son organisation CUBE/VECTOR répond à des contraintes Ascend précises. Copier une optimisation conçue pour une autre architecture ne suffit pas à retrouver le même équilibre.
Le README maintient toutefois des fonctions exclusivement CUDA, notamment le kernel fusionné norm/RoPE/attention et le dense MHA. Le decoding Ascend exige un cache principal FP8 ; un cache supplémentaire peut être FP8 ou FP4. Les données sont déquantifiées en BF16 avant calcul, et le cache BF16 non quantifié n’est pas pris en charge. Il faut lire le support fonction par fonction.
Ce que prouvent les performances publiées — et leurs limites
Un benchmark de kernel mesure un calcul et un environnement déterminés ; il n’établit pas automatiquement la performance d’une application complète.
Selon les mesures DeepSeek publiées pour FlashMLA, les kernels Ascend atteignent jusqu’à 410 TFLOPS en prefill et 360 en decoding, soit respectivement 95 % et 83 % du pic théorique utilisé dans ce rapport. Ce sont les chiffres de l’éditeur sur ses charges de travail, pas une comparaison indépendante de services commerciaux.
Dans DeepGEMM-Ascend, un cas dense BF16 annonce 431 TFLOPS pour une limite de 432, avec M=4096, N=7168 et K=16384. Le protocole indique Ascend 950DT, CANN 9.20, bench_msprof et un cache L2 froid. Les dimensions et le protocole sont indispensables : le pourcentage ne doit pas être présenté comme celui de toute exécution DeepSeek.
Notre analyse est qu’une utilisation élevée du pic matériel montre la qualité d’une optimisation locale. Elle ne fournit pas à elle seule le prix d’une requête, la consommation électrique du cluster ni le temps d’une conversation. Pour comparer deux infrastructures, il faudrait garder constants modèle, précision, contexte, concurrence et niveau de service, puis publier les conditions.
CANN, Ascend C et PTO : construire le chemin logiciel
L’alternative demande des outils pour exprimer, compiler et exécuter les opérateurs, pas uniquement des poids téléchargeables.
Huawei présente Ascend C comme un langage de développement d’opérateurs compatible avec les conventions C/C++. L’annonce logicielle du 19 septembre décrit son évolution pour Ascend 950, avec programmation SIMD/SIMT et Regbase. Ces termes concernent la manière d’exposer les capacités du matériel aux développeurs, pas une nouvelle interface de chatbot.
PTO, pour Parallel Tile Operation, décrit des instructions virtuelles travaillant sur des blocs de données. La documentation lie leur compilation à BiSheng et leur exécution au runtime CANN. Une abstraction peut améliorer la portabilité du code source sans rendre les binaires identiques ni garantir des performances identiques entre générations.
Il faut aussi séparer visibilité du code et liberté de réutilisation. La licence CANN Open Software v2.0 du dépôt PTO réserve les usages autorisés aux systèmes Huawei définis par le texte. Elle ne doit pas être assimilée à la licence MIT de DeepGEMM-Ascend. Avant intégration, la vérification doit porter sur chaque dépendance et sa version, pas sur une étiquette générale « ouvert ».
DeepSeek V4.1 sur Ascend : distinguer preuve technique et accès
Des kernels ciblant un modèle et une puce constituent une preuve technique précise, pas une offre prête pour chaque entreprise.
La carte officielle DeepSeek-V4.1-Flash existe, et FlashMLA documente des kernels pour son inférence sur NVIDIA et Ascend. Cela étaye la voie Ascend décrite ici. Ces sources ne suffisent pas à affirmer que tout l’entraînement du modèle a été effectué sur Ascend, ni qu’une configuration quelconque exécutera le modèle sans adaptation.
La keynote Huawei du 17 septembre décrit Atlas 950 comme déjà utilisé commercialement à grande échelle. Elle distingue cette génération des Ascend 960 annoncés pour 2027. Un état commercial déclaré par le fabricant ne renseigne pas, à lui seul, les stocks, tarifs ou conditions d’accès d’une équipe française.
Même le mot « lancement » demande une lecture attentive : le communiqué Huawei Cloud du 18 septembre prévoit la commercialisation du nouvel AICS hors Chine pour le 30 novembre. Il ne nomme pas une offre Ascend 950 particulière. Nous ne transformons donc pas cette annonce en disponibilité immédiate d’un environnement de test local.
Migrer : vérifier les versions avant la promesse d’indépendance
L’autonomie d’une plateforme se juge sur une charge complète, reproductible et maintenable, pas sur le seul démarrage d’un kernel.
FlashMLA signale explicitement une rupture au 30 septembre : retrait du support Hopper et d’anciens modèles, changement des formats KV FP8/FP4, incompatibilité avec les versions précédentes. Une mise à jour de bibliothèque ne doit donc pas être assimilée à un remplacement transparent. Un projet existant peut avoir besoin d’un commit antérieur.
Notre méthode proposée commence par un inventaire : modèle exact, version du framework, opérateurs utilisés, types, mémoire et outils d’observation. On teste ensuite les résultats, puis le comportement sous charge, enfin la reprise après incident. Une preuve reproductible vaut davantage qu’une démonstration sur un exemple choisi.
La dépendance peut aussi se déplacer : quitter une implémentation CUDA pour une charge donnée ne supprime pas les exigences CANN, torch_npu, compilateur et matériel. Ce n’est pas un défaut en soi, mais un changement de contrat technique. L’intérêt doit être évalué face aux compétences, aux contraintes d’exploitation et à la possibilité réelle de changer de solution.
Questions à poser avant un pilote
- Quelle combinaison de versions a réellement été testée ?
- Quels kernels et formats sont disponibles sur la cible ?
- Quelles mesures portent sur le service complet ?
- Quelles licences et conditions matérielles s’appliquent ?
- Comment reproduire le test et revenir à l’état précédent ?
L’enjeu : une autre voie, pas la disparition de CUDA
Le progrès observable est l’élargissement de certaines possibilités d’exécution, avec des limites documentées.
DeepGEMM-Ascend et FlashMLA rendent visible un travail concret de portage et d’optimisation. Pour nous, le point stratégique est la possibilité d’examiner le code, les contraintes et les mesures, puis de construire un pilote borné. Ce n’est pas la preuve que tous les modèles, frameworks et outils de l’écosystème NVIDIA sont remplaçables aujourd’hui.
Pour les équipes qui utilisent l’IA via une API, ces kernels ne modifient pas directement la qualité d’une réponse sur leur écran. Ils concernent d’abord les acteurs qui déploient et exploitent les modèles. Leur éventuel effet sur les offres, prix ou choix des utilisateurs devra être observé, et non annoncé à partir d’un seul résultat technique.
Questions fréquentes
Non. Il porte des opérations ciblées vers Ascend. CUDA couvre une plateforme beaucoup plus large ; les sources ne démontrent pas son remplacement général.
La branche Ascend vise le matériel Huawei et sa pile CANN/torch_npu. Cela ne rend pas les autres kernels du dépôt compatibles avec Ascend : certains restent exclusivement CUDA.
Non. Les formats de données, versions et opérations prises en charge restent à vérifier. La compatibilité d’appel ne suffit pas à établir celle de toute l’application.
Non. Le stockage compact, les conversions et l’exécution dépendent de la charge. Il faut mesurer la qualité et le service complet dans les conditions prévues.
Les chiffres retenus sont ceux de DeepSeek. Ils décrivent des kernels et leurs conditions ; webcreaplus n’a pas reproduit les mesures et n’en déduit pas un classement global.
Cet article ne le recommande pas. L’approche proposée consiste à définir une charge limitée, des critères vérifiables et un retour arrière avant toute décision d’exploitation.
Conclusion
DeepSeek publie une voie technique sérieuse vers Ascend : du code, des contraintes et des mesures attribuées. Cela permet d’étudier certaines opérations hors de CUDA, sans déclarer l’écosystème NVIDIA obsolète.
La question utile n’est pas « quelle puce gagne ? », mais « quelle pile sait exécuter notre charge avec des résultats fiables, un coût mesuré et une maintenance maîtrisée ? ». C’est à cette échelle qu’une alternative devient exploitable.
