CPU, GPU et NPU dans un PC : comment ils se répartissent le travail et où chaque tâche s’exécute

Les CPU, GPU et NPU sont souvent présentés comme trois moteurs de traitement, mais ils ne sont pas interchangeables pour une même tâche. Chacun possède une architecture et une fonction dominante : le CPU coordonne et exécute les tâches générales, le GPU excelle lorsqu’une charge peut être répartie entre de nombreux calculs similaires, et le NPU est conçu pour les opérations utilisées par les réseaux neuronaux et d’autres modèles d’IA. La frontière n’est pas absolue : le fonctionnement réel dépend du programme, de ses bibliothèques et des ressources disponibles dans l’ordinateur.

Le CPU est le processeur généraliste qui exécute les instructions du système d’exploitation et des applications. Il peut prendre en charge les calculs, la logique, les entrées et sorties, ainsi que les séquences d’instructions qui nécessitent des décisions successives. Cette polyvalence le rend indispensable même dans un ordinateur doté d’accélérateurs : il organise le travail, exécute les parties qui ne sont pas déléguées et traite les tâches du système. Il est inexact de le résumer comme « le plus lent » ou « le plus rapide » sans préciser la charge, car la comparaison varie selon le type d’opération. Microsoft décrit le CPU comme le composant qui dirige les autres éléments d’un appareil.

Le GPU était à l’origine une unité dédiée aux graphismes, mais sa capacité à effectuer de nombreux calculs en parallèle est également utile au-delà du rendu. En pratique, un GPU ne fait pas tout mieux : il peut traiter efficacement une charge lorsque ses opérations sont répartissables en parallèle. Une tâche comportant des dépendances séquentielles ou beaucoup de logique de contrôle peut ne pas en tirer le même bénéfice. La documentation de NVIDIA sur le calcul GPU et l’explication d’AWS sur les différences entre GPU et CPU décrivent précisément cette spécialisation dans les calculs parallèles. NVIDIA · AWS.

Le NPU, quant à lui, est un accélérateur conçu pour exécuter certains calculs associés à l’intelligence artificielle. Sa présence ne signifie pas que toutes les fonctions d’IA s’exécuteront dessus : le modèle, le format de ses opérations, les pilotes et le logiciel d’exécution doivent être compatibles. En l’absence de cette voie, un système peut effectuer l’inférence sur CPU ou GPU. Le nom de la puce décrit une capacité, mais ne garantit pas son utilisation par chaque application ni une amélioration universelle de la vitesse ou de la consommation.

Dans un programme réel, une opération visible par l’utilisateur peut comprendre plusieurs étapes : préparer les données, exécuter le modèle, traiter le résultat et l’afficher à l’écran. Rien n’impose que toutes ces étapes correspondent à une seule puce. Le CPU peut préparer les entrées et coordonner l’exécution, un accélérateur peut traiter les opérations intensives, puis le CPU ou le GPU peut prendre en charge les étapes suivantes. La répartition concrète dépend de la conception de l’application et de l’infrastructure logicielle qui relie le modèle au matériel.

Windows ML fournit un exemple documenté de cette couche de coordination sous Windows : Microsoft le décrit comme un cadre d’inférence locale reposant sur ONNX Runtime, qui peut exécuter des modèles sur CPU, GPU ou NPU par l’intermédiaire de fournisseurs d’exécution. La documentation indique que Windows gère ces fournisseurs et que la sélection dépend de la voie d’exécution disponible ; cela ne signifie pas que chaque modèle utilisera toutes les unités ou qu’une charge sera automatiquement répartie entre elles. Documentation Windows ML.

Il faut distinguer la répartition des tâches d’une application du découpage d’un même calcul. Un programme peut utiliser le CPU pour certaines fonctions et le GPU pour d’autres sans répartir une opération unique entre les deux. Il peut aussi déléguer une partie du modèle tout en gardant les autres étapes sur le processeur central. Pour savoir ce qui se passe, il faut consulter la documentation du cadre ou de l’application ; la simple présence de plusieurs processeurs dans la liste du matériel ne suffit pas.

Ce que le logiciel peut décider

L’application, le format du modèle, le fournisseur d’exécution, le pilote et le système d’exploitation forment une chaîne. Si l’un de ces maillons ne prend pas en charge une opération donnée, il peut être nécessaire de recourir à une autre unité ou à une autre implémentation. C’est pourquoi une application peut se comporter différemment sur deux ordinateurs annonçant un NPU ou un GPU : la compatibilité, le pilote, la mémoire disponible et la version du logiciel peuvent varier.

La documentation de Windows ML indique que l’exécution locale peut s’appuyer sur CPU, GPU et NPU, mais cette possibilité ne prouve pas que toutes les applications suivent une politique identique. Le point pertinent est la voie d’exécution activée par l’application, et non le seul inventaire matériel. Les caractéristiques générales du processeur ne permettent pas non plus d’identifier l’unité qui a exécuté une fonction précise pendant une session.

Qu’un ordinateur puisse accélérer une tâche signifie qu’il existe une voie d’exécution compatible, à la fois sur le plan matériel et logiciel. Cela ne démontre ni l’ampleur de l’accélération, ni que le résultat sera sensiblement plus rapide, ni que la consommation énergétique totale sera réduite. Pour tirer ces conclusions, il faudrait des mesures reproductibles portant sur la même charge, la même configuration, la même version logicielle et des conditions de comparaison identiques. Disponibilité et résultat sont deux questions différentes.

Un GPU peut convenir aux charges parallèles, mais le bénéfice effectif dépend aussi de la capacité de la tâche à suivre ce modèle et du temps consacré au transfert des données ou à la coordination des opérations. Une petite tâche peut ne pas compenser le coût de sa délégation. De même, un NPU peut améliorer l’efficacité d’une opération compatible, mais sa seule présence ne permet pas d’extrapoler le résultat à tous les modèles ni à l’application entière. La documentation des fabricants décrit la conception et les usages prévus ; elle ne remplace pas un essai sur la charge concernée.

Le contexte compte également. Dans un bureau virtuel, par exemple, l’accélération peut concerner à la fois le rendu et l’encodage des images envoyées sur le réseau. Microsoft avertit que l’encodage accéléré par GPU peut améliorer l’expérience, mais aussi consommer davantage de bande passante et de ressources côté client et côté hôte. Un rappel utile : même lorsqu’une unité précise est identifiée, les coûts se déplacent entre les ressources, et le résultat dépend du système dans son ensemble. Microsoft : accélération GPU dans Azure Virtual Desktop.

C’est pourquoi les comparaisons utiles précisent ce qui est mesuré : temps de réponse, débit soutenu, consommation de l’appareil, qualité du résultat ou charge du réseau. Une affirmation générique comme « utilise le GPU » ne répond pas à ces questions. Si la source ne publie pas de méthodologie et de résultats pertinents, il est plus rigoureux de décrire la capacité technique que de promettre une amélioration chiffrée.

L’inférence locale signifie qu’un modèle s’exécute sur l’appareil, au lieu que toute l’exécution soit nécessairement envoyée à un service distant. Windows ML est présenté comme un cadre permettant d’exécuter des modèles localement sur le matériel de l’utilisateur et d’accéder au CPU, au GPU ou au NPU. Une application peut ainsi traiter certaines données sans connexion au cloud pour cette étape, mais cela ne prouve pas qu’elle n’envoie aucune donnée pour d’autres raisons. Microsoft : Windows ML.

Un accélérateur ne prouve pas, à lui seul, où circulent les données. La présence d’un GPU ou d’un NPU ne confirme ni qu’une fonction fonctionne hors ligne, ni que toutes les données restent sur l’appareil, ni que l’application ne contacte pas des serveurs pour l’authentification, la synchronisation, la télémétrie ou d’autres tâches. Pour évaluer la confidentialité, il faut consulter la documentation et la politique de l’application, identifier les informations traitées et vérifier quelles fonctions nécessitent une connexion réseau. Le modèle d’exécution et le comportement de l’application sont liés, mais distincts.

La même prudence s’applique au mot local. Il peut désigner une étape particulière de l’inférence, et non tous les composants d’un service. Si un fabricant affirme qu’une fonction est traitée sur l’appareil, les questions utiles sont : quelle fonction, quelles données et avec quelle configuration ? Une affirmation bien délimitée précise mieux la portée qu’une promesse générale d’« IA privée » fondée uniquement sur le type de puce.

Pour vérifier une affirmation d’accélération, il est utile de partir de la documentation la plus précise avant de passer aux indicateurs du système. Il faut d’abord consulter la documentation de l’application ou du cadre et vérifier les unités prises en charge, les versions requises et l’activation par défaut de la fonction. On peut ensuite examiner la documentation du système d’exploitation et du fabricant du matériel. La compatibilité annoncée constitue un premier filtre, pas une preuve d’utilisation effective.

Un gestionnaire des tâches ou un autre outil de surveillance peut fournir des indices sur l’activité du CPU, du GPU ou du NPU pendant une opération. Mais un graphique d’activité n’identifie pas toujours le processus, le sous-composant ou l’étape à l’origine de cette activité ; il ne prouve pas non plus, à lui seul, que le résultat a été accéléré. La visibilité dépend de la version du système, du pilote et des capacités de surveillance. Si le système ne propose pas de compteur spécifique, il ne faut pas en déduire que l’unité est inactive : cette observation peut simplement ne pas être disponible.

Une vérification pratique peut suivre ces étapes :

• Identifier la fonction exacte et le nom du modèle ou de la tâche exécutée.
• Vérifier si l’application annonce une compatibilité avec CPU, GPU ou NPU, et quel fournisseur d’exécution elle utilise.
• Examiner les exigences du système, le pilote et la version de l’application.
• Observer l’activité des ressources pendant une tâche contrôlée, sans considérer l’indicateur comme une preuve concluante.
• Si les performances comptent, comparer la même charge avec une méthodologie et des conditions documentées.

Pour parvenir à une conclusion solide, il faut associer les déclarations du logiciel à une observation appropriée et, lorsqu’une amélioration est revendiquée, à une mesure comparable. Aucun indicateur unique ne répond à toutes les questions : un moniteur peut signaler une activité, la documentation confirmer la compatibilité et un test mesurer les performances, mais chaque élément apporte une réponse différente.

La façon la plus sûre d’interpréter CPU, GPU et NPU consiste à y voir des spécialisations complémentaires, et non une échelle où chaque nouvelle puce remplace la précédente. Le CPU conserve son rôle généraliste et de coordination ; le GPU peut accélérer les charges graphiques et parallélisables ; le NPU peut traiter les opérations d’IA que le logiciel et le modèle savent lui confier. La combinaison dépend de la charge et de la prise en charge logicielle, pas seulement du nom inscrit sur une fiche technique.

Face à une affirmation comme « l’IA s’exécute sur le NPU », demandez-vous quelle fonction y est exécutée, si le modèle et le programme prennent en charge cette voie, comment l’activité est vérifiée et quel résultat a été mesuré. Pour « fonctionne localement », il faut préciser quelle étape se déroule sur l’appareil et quelles données peuvent encore être communiquées à des services externes. Ces questions distinguent une capacité réelle d’une conclusion plus large que les éléments disponibles ne justifient pas.

La distinction finale est simple : les caractéristiques décrivent ce qu’un composant est conçu pour faire ; la documentation logicielle explique les voies qu’il peut utiliser ; la surveillance montre une activité dans un contexte précis ; et des tests comparables permettent d’évaluer le résultat. Aucun de ces éléments, pris séparément, ne démontre tous les autres. Les utiliser ensemble aide à comprendre ce que fait l’ordinateur sans transformer une étiquette d’accélération en promesse de performance, d’efficacité ou de confidentialité.