CPU, GPU, NPU : quelle puce fait réellement tourner votre application IA ?

Une application IA peut utiliser un CPU, un GPU et un NPU au cours du même traitement. Le nom de la puce ne suffit pas à prévoir sa vitesse ou sa consommation : il faut vérifier ce que le logiciel lui confie réellement, ce qui reste exécuté ailleurs et le coût des transferts entre les étapes. La première question utile est donc celle du travail à accomplir.

Cet article propose une grille de lecture d’une démonstration ou d’une fiche technique. Il ne recommande aucun ordinateur et ne classe pas les fabricants. Les résultats dépendent du modèle, de sa représentation numérique, du moteur d’exécution et de la charge observée.

Trois rôles, des frontières qui dépendent du système

Le CPU, processeur généraliste, exécute notamment la logique de l’application et orchestre des tâches variées. Un GPU offre une organisation adaptée à de nombreux calculs parallèles. Un NPU désigne un accélérateur spécialisé pour certaines opérations de réseaux neuronaux ; les capacités concrètes varient avec son architecture et ses logiciels.

La documentation CUDA sur les systèmes hétérogènes décrit explicitement la coopération CPU-GPU : le programme commence sur le CPU, qui peut lancer du code sur le GPU et organiser des échanges mémoire. Cette documentation concerne CUDA et ne décrit pas toutes les architectures, mais elle suffit à montrer pourquoi « exécuté sur GPU » ne signifie pas « sans CPU ».

Pour un NPU, la documentation OpenVINO 2025 donne un exemple concret de dépendance au logiciel, au pilote et aux formes de modèles prises en charge. Ses restrictions sont propres à cette version et à ce matériel ; elles ne doivent pas être attribuées à tous les NPU.

Suivre un document de son arrivée à la réponse

Imaginons une application qui reçoit une photographie de facture, extrait les informations et les range dans un logiciel de gestion. La reconnaissance peut employer un accélérateur, mais la lecture du fichier, son redimensionnement, la vérification des champs et l’écriture finale sont aussi du travail.

Ce scénario est pédagogique, pas le relevé d’un produit. Il permet de demander pour chaque étape : quel composant l’exécute, combien de temps prend-elle et sur quelles données ? Si l’essentiel de l’attente vient du téléchargement ou d’un appel externe, accélérer le calcul neuronal ne résout pas cette attente.

Étape à observer	Question technique traduite en besoin concret
Préparation	Combien de temps avant que l’entrée soit prête pour le modèle ?
Inférence	Le modèle exact fonctionne-t-il sur l’accélérateur annoncé ?
Transfert	Les données doivent-elles changer de mémoire ou de format ?
Validation	Le résultat respecte-t-il les contraintes du document ?
Restitution	Quand l’utilisateur reçoit-il un résultat exploitable ?

Le guide sur l’IA multimodale et les documents aide à définir la qualité attendue. Une extraction rapide mais incorrecte ne représente pas le même service qu’une extraction validée.

Un calcul simple pour repérer une accélération sans grand effet

Considérons une application fictive dont la durée totale est de 100 millisecondes : 30 pour le calcul du modèle, 70 pour les autres étapes. Un accélérateur rend le calcul du modèle trois fois plus rapide, sans modifier le reste. Il prend alors 10 millisecondes et le total devient 80 millisecondes.

Le calcul isolé a été multiplié par trois en vitesse ; l’application complète n’est que 1,25 fois plus rapide, puisque 100 ÷ 80 = 1,25. Les valeurs sont inventées pour illustrer une décomposition arithmétique. Si des transferts supplémentaires apparaissaient, il faudrait encore les ajouter.

Cet exercice peut être refait avec des temps mesurés. Il indique où un investissement mérite d’être étudié. Il ne suppose pas que chaque étape demeure constante : une vraie modification peut aussi changer le parallélisme ou la préparation. Dans ce cas, mesurer à nouveau l’ensemble plutôt que conserver des hypothèses devenues fausses.

Vérifier le modèle qui s’exécute, pas seulement celui qui s’importe

La présence du nom d’un modèle dans un catalogue ne garantit pas que toutes ses opérations s’exécutent sur la puce voulue. Demander la configuration effective : version du moteur, pilote, formats numériques, dimensions d’entrée et éventuels replis vers une autre unité de calcul.

Un repli peut être utile pour assurer la compatibilité, mais il modifie l’interprétation du test. Si une partie revient sur CPU, la performance est celle du système hybride. Elle ne doit pas être présentée comme une mesure indépendante du NPU ou du GPU.

Dans la documentation OpenVINO 2025 citée, les formes statiques et la compatibilité de modèles précompilés entre versions font l’objet de limites explicites. C’est une illustration de ce qu’il faut chercher dans la documentation de la configuration retenue, pas une prédiction sur une version ultérieure.

La quantification introduit un autre paramètre. Deux démonstrations utilisant des précisions différentes peuvent exécuter des variantes différentes du modèle. La qualité de sortie doit alors être comparée, au lieu de considérer automatiquement les opérations annoncées comme équivalentes.

Mesurer l’énergie sur une tâche complète

Une puissance en watts décrit un rythme de consommation. Une énergie par tâche dépend aussi de la durée. Pour une mesure fictive à puissance constante, 20 watts pendant deux secondes donnent 40 joules ; 10 watts pendant cinq secondes donnent 50 joules. Une puissance plus basse ne suffit donc pas à établir une énergie plus faible par résultat.

Sur une machine réelle, préciser le périmètre : accélérateur seul, processeur complet ou appareil à la prise. Décrire également l’état de départ, le travail en arrière-plan et le nombre de tâches. Si l’on soustrait une consommation de repos, publier cette convention et la mesure utilisée.

Ces calculs ne classent pas les NPU et les GPU. Ils montrent les informations nécessaires pour examiner une affirmation d’efficacité. Une mesure locale de quelques secondes ne caractérise pas automatiquement un service exploité toute la journée, ni les impacts de fabrication de l’équipement.

Préparer un essai qui permet une décision

Retenir des entrées correspondant au futur usage : dimensions des images, longueur des textes, fréquence d’arrivée et contraintes de délai. Tester le résultat complet sur une machine identifiée. Documenter les étapes de compilation ou de chargement séparément, car elles peuvent compter lors du premier usage même si elles sont amorties ensuite.

Comparer les configurations avec le même critère d’exactitude. Relever les erreurs et les tâches refusées. Examiner ensuite délai total, variabilité, mémoire et énergie selon un périmètre constant. Cette procédure est une recommandation méthodologique de Pnebbula, pas un protocole de certification matérielle.

Le bon choix peut consister à conserver un équipement déjà disponible, à modifier le logiciel ou à employer un accélérateur pour une partie seulement du traitement. Sans mesure de la charge concernée, ces possibilités restent des options à tester. Un acronyme sur une fiche technique ne tranche pas entre elles.

Sources et portée

Consultées le 22 octobre 2026 : NVIDIA, CUDA Programming Model, archive 13.2.2 ; Intel, OpenVINO 2025, NPU Device. Ce sont des sources techniques de fabricants, utilisées pour décrire leur fonctionnement et leurs limites, sans reprendre leurs promesses comparatives. Les exemples de durée et d’énergie sont fictifs.