Deux philosophies d’accélération
À l’edge, deux familles d’accélérateurs se disputent l’inférence, et elles ne résolvent pas le problème de la même manière. Le GPU embarqué (celui du Jetson Orin, par exemple) est un processeur massivement parallèle, programmable : il exécute n’importe quel graphe de calcul, parce qu’il dispose d’un jeu d’instructions et d’unités de calcul génériques qui peuvent enchaîner à peu près n’importe quelle séquence d’opérations.
Le NPU (Neural Processing Unit) prend le problème par l’autre bout. Au lieu d’unités génériques pilotées par des instructions, c’est un circuit dédié : des tableaux de multiplieurs-accumulateurs câblés directement pour les opérateurs les plus courants des réseaux de neurones, la convolution, la multiplication de matrices, quelques fonctions d’activation. Câblés signifie ici qu’ils sont fixes dans le silicium, pas reprogrammables.
L’un est un généraliste programmable. L’autre, un spécialiste figé. Le choix dépend moins des TOPS Tera Operations Per Second. Mille milliards d'opérations par seconde : métrique brute de débit d'un accélérateur, généralement annoncée en INT8 ou INT4. Elle ne dit rien du débit réel d'un modèle, qui dépend du compilateur et du repli éventuel sur CPU. Approfondir dans le glossaire affichés sur la fiche technique que de la nature de votre charge, et, on va le voir, de la maturité de l’outil qui va y compiler votre modèle.
Le GPU embarqué : flexible mais gourmand
Le GPU embarqué hérite de tout l’écosystème du GPU desktop : CUDA, runtimes d’inférence matures, frameworks qui suivent les nouveautés à quelques mois près. Si un nouveau modèle sort avec un opérateur exotique (une variante d’attention, une activation comme SwiGLU), le GPU le fera tourner. Peut-être pas avec un kernel optimisé dès le premier jour, mais il le fera, parce qu’on peut toujours écrire un kernel CUDA générique qui exécute n’importe quoi.
Cette flexibilité a son prix. Chaque opération sur GPU passe par un cycle d’instruction : on charge l’instruction, on la décode, on dispatch vers une unité d’exécution, on ordonnance les warps. Ce cycle consomme du courant à chaque étape, même quand l’opération réelle (une multiplication 8 bits, par exemple) ne demande qu’une fraction de cette énergie. Sur un GPU desktop branché au mur, on ne le voit pas. Dans une enveloppe de quelques watts, c’est un handicap structurel : on paie l’infrastructure de la programmabilité à chaque calcul.
Le NPU : efficace mais rigide
Le NPU inverse exactement ce compromis. Plutôt que d’exécuter un cycle d’instruction pour chaque opération, il se contente d’aiguiller les données dans un circuit déjà conçu pour ce qu’elles vont subir. Les opérateurs qu’il sait traiter (convolutions, matmul Multiplication de matrices, l'opération dominante des couches d'un réseau de neurones. Quand on dit qu'un GPU « calcule », il fait à 90 % des matmul. , quelques activations comme ReLU ou GELU) sont câblés directement dans le silicium : un tableau de MAC Multiplier-Accumulator. Unité de calcul élémentaire qui multiplie deux nombres et ajoute le résultat à un accumulateur : la brique de toute matmul. Un NPU est essentiellement un grand tableau de MAC câblés. reçoit ses entrées d’un côté, produit ses sorties de l’autre, sans qu’aucune instruction ne soit décodée ou ordonnancée pour chaque calcul.
On échange la flexibilité d’un processeur contre l’efficacité d’un ASIC Application-Specific Integrated Circuit. Circuit intégré conçu pour une tâche unique, gravé en dur dans le silicium. Très efficace en énergie sur ce pour quoi il a été conçu, incapable du reste. . À enveloppe énergétique comparable et sur une charge stable, ça se traduit par un écart structurel, typiquement de l’ordre d’un facteur sur l’énergie par opération utile, dont la valeur exacte dépend du modèle, du fournisseur et de la précision numérique.
La contrepartie de ce câblage est la rigidité. Un NPU ne peut pas exécuter un opérateur qui n’a pas été prévu à la conception. Il n’y a pas de « kernel générique de secours » comme sur GPU : le matériel ne sait littéralement pas faire cette opération. Tout ce qui sort de son périmètre doit être exécuté ailleurs, en pratique sur le CPU de l’hôte, via une implémentation logicielle de référence.
Comparatif : énergie, flexibilité, écosystème
À périmètre supporté, l’opposition se cristallise sur cinq axes, et c’est moins le silicium qui tranche que le comportement aux frontières de ce périmètre.
| Critère | NPU dédié | GPU embarqué |
|---|---|---|
| Efficacité énergétique | Excellente (opérateurs supportés) | Moyenne |
| Flexibilité des modèles | Faible | Excellente |
| Maturité de l'outillage | Variable selon le fournisseur | Élevée |
| Comportement hors support | Repli CPU coûteux | Repli intra-GPU, sans rupture |
| Cible idéale | Modèle figé, déployé en volume | Modèles variés ou évolutifs |
Le piège du compilateur
Pour comprendre pourquoi ce piège est si traître, il faut voir ce que fait concrètement un compilateur NPU. Quand vous lui passez un modèle PyTorch ou ONNX, il parcourt le graphe opérateur par opérateur et se demande à chaque pas : « est-ce que mon matériel sait faire ça ? ». Si oui, il l’inscrit dans le binaire NPU. Si non, il a deux options : soit décomposer l’opérateur en briques supportées (reconstruire une SwiGLU à partir de matmul + sigmoid + multiplication élément par élément, si toutes ces briques sont câblées), soit déléguer le sous-graphe au CPU.
C’est ce second cas qui tue le gain énergétique. Un repli sur CPU n’est pas un échec silencieux : c’est un transfert de tenseurs depuis l’accélérateur vers la mémoire centrale, l’exécution séquentielle sur quelques cœurs ARM peu adaptés à des matmul, puis le retour des résultats vers le NPU. Quand ce mouvement arrive plusieurs fois par inférence (typique d’un modèle moderne avec ne serait-ce qu’un ou deux opérateurs hors-périmètre), la latence peut doubler ou tripler, et la consommation moyenne efface l’avantage que le NPU avait sur les 80 % du graphe qu’il sait exécuter.
Erreur typique : choisir un NPU pour ses TOPS, valider qu’il les atteint sur un benchmark vendeur, puis déployer son propre modèle et découvrir qu’il ne se compile pas à 100 %. Un GPU embarqué un peu plus gourmand mais qui exécute tout le graphe sans repli peut gagner en pratique.
Comment choisir
Deux questions tranchent la décision en amont.
Le modèle est-il figé pour les 12 à 24 prochains mois ? Un modèle stable déployé en grand volume justifie l’investissement d’optimisation NPU, typiquement plusieurs semaines d’ingénieur pour valider la compilation, ajuster la quantification au format attendu par le compilateur, et écrire les éventuels kernels CPU de secours. À chaque release du modèle, cet investissement est en partie à refaire. Si vos itérations sont trimestrielles, vous passerez plus de temps à intégrer qu’à exploiter.
Le graphe se compile-t-il intégralement sur le NPU cible ? C’est un test à exécuter, pas une projection à partir de la fiche technique : sur le matériel réel, avec votre modèle réel, en lisant les warnings du compilateur ligne par ligne. Un projet qui s’engage sans ce test préalable s’expose à découvrir le repli CPU une fois le matériel commandé.
En cas de doute, le GPU embarqué est, de notre point de vue, le choix à plus faible risque. La raison est asymétrique : sur GPU, un opérateur sans kernel optimisé reste exécuté sur le GPU via un kernel générique : performances dégradées, pas effondrement. Sur NPU, le hors-périmètre tombe sur le CPU et la dégradation est brutale. Ce n’est pas une garantie absolue (un opérateur réellement absent du runtime ou une saturation mémoire restent possibles), mais c’est un mode de défaillance qui prévient, là où l’échec NPU écrase.
Conclusion
NPU et GPU embarqué ne sont pas en compétition sur le même axe. Le NPU optimise l’énergie d’un problème connu : topologie figée, chaîne d’opérateurs entièrement couverte par son compilateur. Le GPU absorbe l’incertitude : un modèle qui évolue, un opérateur qu’on n’avait pas anticipé, un nouveau benchmark qu’on veut faire tourner sans repasser six semaines à intégrer.
La vraie question à se poser n’est donc pas « lequel est techniquement supérieur », mais : votre modèle aura-t-il la même topologie dans dix-huit mois ? Si la réponse est non, ou si vous ne pouvez pas le garantir, vous avez déjà choisi.
Pour le déploiement concret sur module, voir Jetson Orin et edge AI.
Sources et méthode
La comparaison est volontairement qualitative : les chiffres bruts d’efficacité (TOPS/W, latence) dépendent trop du modèle, du fournisseur et de la version du compilateur pour qu’un classement absolu ait du sens. En revanche, les mécanismes décrits (périmètre d’opérateurs câblés, repli CPU, rôle de la chaîne de compilation) sont documentés par les fournisseurs :
- GPU embarqué : NVIDIA Jetson Orin, GPU Ampere programmable, pile CUDA / TensorRT
- NPU à fonction fixe : ARM Ethos-U et son compilateur Vela, un opérateur non conforme est planifié sur le CPU
- NPU edge : compilateur Google Edge TPU (Coral, maintenant abandonné), dès le premier opérateur non supporté, cette opération et toutes les suivantes s’exécutent sur le CPU
- Chaîne de compilation GPU : ONNX Runtime / TensorRT Execution Provider, un sous-graphe non pris en charge retombe sur un autre execution provider (CUDA, puis CPU)
Faits vérifiés : la nature à fonction fixe des micro-NPU et le mécanisme de repli CPU de leurs compilateurs ; le caractère programmable du GPU embarqué. Estimation crédible : l’ampleur de l’écart d’efficacité énergétique. Jugement éditorial : la recommandation de privilégier le GPU embarqué « en cas de doute ».
