Le ticket commence toujours de la même façon : « Nous avons activé la fonctionnalité IA et maintenant les ordinateurs portables chauffent, les ventilateurs hurlent,
et la file du helpdesk ressemble à une attaque par déni de service. » Quelqu’un propose « utilise juste le CPU, ça ira. »
Une autre personne suggère d’acheter des GPU pour tout le monde, ce qui transforme une demande de fonctionnalité modeste en audition budgétaire.
Les NPU existent parce que ces deux instincts sont généralement faux en production. Les CPU peuvent faire de l’IA, oui. Ils peuvent aussi griller du pain.
Cela ne signifie pas que vous voulez les voir fonctionner comme un grille-pain toute la journée tout en étant votre tableur, votre appel vidéo et votre agent de sécurité.
Les NPU, en termes simples : ce que c’est (et ce que ce n’est pas)
Un NPU (Neural Processing Unit) est un accélérateur spécialisé conçu pour exécuter efficacement les mathématiques de type réseau de neurones :
beaucoup d’opérations de multiplication-accumulation, de l’algèbre linéaire dense, et les schémas de déplacement de données qui vont avec.
L’objectif opérationnel n’est pas « le plus rapide possible quoi qu’il arrive ». C’est « assez rapide avec une faible consommation, une latence prévisible,
sans s’accaparer toute la machine ».
Dans les systèmes clients modernes (ordinateurs portables, tablettes, téléphones), un NPU est couramment intégré sur la puce ou dans le même package que le CPU,
partageant souvent la mémoire et le fabric/interconnect. Dans les serveurs, on voit plus souvent des accélérateurs discrets (GPU, TPU, cartes d’inférence)
parce que l’enveloppe puissance/refroidissement est plus importante et les charges de travail plus lourdes. Mais la logique est la même :
déplacer les bons calculs vers le bon moteur.
Ce qu’un NPU n’est pas :
- Pas un remplacement du GPU si vous entraînez de grands modèles ou faites de l’inférence par lots à grande échelle.
- Pas magique si votre goulet d’étranglement est la bande passante mémoire, l’I/O disque, ou un pipeline lent de pré/post-traitement.
- Pas automatiquement plus rapide pour tous les modèles ; la couverture des opérateurs, la quantification et le support des frameworks décident du résultat.
Pourquoi les NPU existent : les contraintes que les CPU ne peuvent pas ignorer
Un CPU est un généraliste. Il est conçu pour faire un million de choses correctement : code sujet aux branches, travail du système d’exploitation, chiffrement,
mise en réseau, logique métier aléatoire, toutes les petites aspérités qui rendent le logiciel « réel ». Il est aussi construit autour
d’un accès basse latence aux caches, d’une large spéculation, et d’une logique de contrôle sophistiquée. C’est coûteux en silicium et en énergie.
L’inférence de réseaux neuronaux, en revanche, est fréquemment dominée par :
- Des multiplications de matrices (GEMM) et des opérations de type convolution.
- Une forte intensité arithmétique quand la réutilisation des données est bonne, mais une pression sur la bande passante mémoire quand ce n’est pas le cas.
- Des mathématiques en basse précision (INT8, FP16, BF16) que les CPU peuvent faire, mais pas aussi efficacement par watt qu’un moteur dédié.
Les NPU existent parce que le « modèle de coût » pour l’IA client est impitoyable :
- Puissance : Les utilisateurs remarquent immédiatement la décharge de batterie et le bruit des ventilateurs. La facture cloud est une douleur différente ; les utilisateurs ne l’entendent pas.
- Thermique : Une inférence CPU soutenue peut amener du throttling, puis tout le reste est throttlé avec elle.
- Latence : Les fonctionnalités sur appareil (flou d’arrière-plan, transcription, mot d’activation, amélioration d’image) nécessitent une latence faible et stable.
- Concurrence : Le CPU doit aussi exécuter l’OS, le navigateur, l’agent EDR, et tout ce que votre entreprise lance automatiquement.
Si vous avez déjà vu un portable essayer de transcrire de l’audio sur le CPU pendant un appel vidéo, vous avez vu ce film.
Le rebondissement est toujours le même : la fonctionnalité IA est « seulement 10 ms par image » en laboratoire, mais sur le terrain elle devient
« pics aléatoires à 200 ms et la réunion se transforme en diaporama ».
« L’IA sur CPU » : vérification de la réalité — ce qui se passe réellement
Oui, les CPU peuvent exécuter de l’inférence. Les cœurs x86 et ARM modernes ont des extensions vectorielles (AVX2/AVX-512 sur x86 ; NEON/SVE sur ARM),
et il existe des bibliothèques optimisées (oneDNN, variantes BLAS, kernels fournisseurs) qui font un travail respectable.
Mais « respectable » n’est pas la même chose que « bon marché et prévisible ».
En production, l’inférence CPU échoue de façons répétables :
1) Vous heurtez le mur mémoire, pas le mur calcul
Beaucoup de charges d’inférence sont effectivement limitées par la bande passante mémoire, surtout quand les poids ne tiennent pas dans le cache.
Vous pouvez avoir beaucoup de puissance vectorielle disponible et rester bloqué en attendant les données.
Quand le CPU est bloqué, il consomme de l’énergie sans faire grand-chose, et votre latence devient irrégulière.
2) Vous vous battez contre l’ordonnanceur
Les CPU font du time-slicing. C’est le but. Mais pour des fonctionnalités IA quasi temps réel, la préemption et la contention comptent.
L’OS, les services en arrière-plan et d’autres apps interrompront vos threads d’inférence.
Si vous « optimisez » en épinglant des cœurs ou en augmentant le nombre de threads, vous pouvez gagner un benchmark et perdre l’expérience utilisateur.
3) Les choix de précision deviennent des choix produit
L’inférence CPU demande généralement de la quantification (INT8, parfois INT4) pour être compétitive.
La quantification n’est pas seulement un réglage de performance ; elle affecte la précision du modèle, la stabilité des sorties et le comportement sur les cas limites.
En entreprise, « précision régresse pour certains accents » devient un problème de conformité et de ressources humaines, pas une simple note technique.
4) Vous payez une taxe d’intégration
Faire « l’IA sur CPU » fonctionner correctement signifie choisir le bon runtime, les bons kernels, la bonne configuration de threads,
et le bon format de modèle. Vous pouvez le faire. Mais c’est du travail. Les NPU existent pour réduire le coût de faire cela de façon répétée
sur une flotte.
Une règle sèche qui tient : si le modèle tourne « bien » sur la station de développement, attendez-vous à ce qu’il tourne « épicé » sur l’ordinateur portable médian.
Votre ordinateur portable médian est l’endroit où le bonheur va mourir.
À l’intérieur de la boîte : comment les NPU sont conçus différemment
À un niveau élevé, un NPU est un convoyeur purpose-built pour les opérations sur tenseurs. Les détails varient selon le fournisseur, mais les thèmes sont constants :
Le dataflow l’emporte sur la spéculation
Les CPU excellent quand le flux de contrôle est imprévisible. Les NPU supposent le contraire : le graphe de calcul est connu, les opérations sont répétitives,
et la meilleure chose à faire est de garder les données en mouvement à travers les unités MAC avec un minimum de surcharge de contrôle.
Moins de prédiction de branche, moins de complexité out-of-order, plus de débit soutenu.
La mémoire locale et le tiling sont des citoyens de première classe
Les NPU ont typiquement des mémoires locales de type SRAM (scratchpads) qui sont gérées explicitement par le compilateur/runtime.
Ce n’est pas un accident ; c’est la façon d’éviter d’aller en DRAM à chaque réutilisation des poids/activations.
Le runtime découpe les tenseurs en tuiles qui tiennent localement, effectue un bloc de travail, puis passe au suivant.
La basse précision est la valeur par défaut
Les NPU sont les plus efficaces quand vous leur fournissez INT8/INT16/FP16/BF16 et des opérations qu’ils reconnaissent.
Ils ont souvent des instructions dédiées pour des opérations fusionnées (par ex. convolution + activation, ou GEMM + bias + activation),
parce que la fusion économise de la bande passante et réduit les allers-retours en mémoire.
La latence prévisible est une exigence produit
Sur les appareils clients, le « ressenti » compte plus que le débit maximal. Cela oriente les choix de conception :
files bornées, ordonnanceurs matériels, et isolation pour que le NPU puisse exécuter des tâches IA en arrière-plan sans voler le déjeuner du CPU.
Un modèle mental utile : les CPU sont conçus autour du contrôle. Les GPU sont conçus autour du débit.
Les NPU sont conçus autour du débit par watt avec mémoire gérée par le compilateur.
NPU vs GPU vs CPU : choisissez votre poison
Si vous devez décider où exécuter l’inférence, utilisez ce cadrage : qu’optimisez-vous — coût, latence, puissance, ou temps d’ingénierie ?
La mauvaise réponse est « ce qui est disponible ». C’est ainsi que vous vous retrouvez avec un CPU faisant 80 % du travail tandis que le NPU reste inoccupé,
attendant patiemment que vous arrêtiez d’être créatif.
CPU : idéal pour le glue code, les petits modèles, et « ça doit tourner partout »
- Avantages : disponibilité universelle ; excellent pour le pré/post-traitement ; débogage simple ; outils matures.
- Inconvénients : contraintes de puissance/thermique ; latence variable sous charge ; souvent limité par la mémoire ; augmenter les threads peut nuire.
- À utiliser quand : le modèle est petit, le cycle de service est faible, ou la portabilité compte plus que l’efficacité maximale.
GPU : idéal pour un grand débit et l’entraînement (et de nombreux cas d’inférence)
- Avantages : parallélisme massif ; écosystème mature ; bon support FP16/BF16 ; excellent pour le batching.
- Inconvénients : consommation électrique ; les GPU discrets ajoutent coût/complexité ; les petites tâches temps réel peuvent souffrir des frais de lancement/ordonnancement.
- À utiliser quand : vous avez de grands modèles, des besoins de haut débit, ou de l’entraînement. Ou vous êtes déjà en environnement GPU et c’est peu coûteux opérationnellement.
NPU : idéal pour l’inférence sur appareil avec contraintes strictes de puissance et de latence
- Avantages : excellent perf/W ; peut exécuter des tâches toujours actives ; isole le travail IA du CPU ; bon pour la confidentialité (pas de roundtrip cloud).
- Inconvénients : lacunes dans la couverture des opérateurs ; outils variables ; conversion de modèle parfois pénible ; risque d’enfermement fournisseur.
- À utiliser quand : vous livrez des fonctionnalités client à une flotte, et vous avez besoin d’une consommation et d’un thermique prédictibles ainsi que d’une expérience utilisateur cohérente.
Une blague, comme promis : Un NPU, c’est comme un chariot élévateur — excellent pour déplacer des palettes, nul pour écrire des e-mails, et curieusement blâmé pour les deux.
Faits intéressants et courte histoire
Dix faits courts pour calibrer vos instincts. Ce ne sont pas des trivia ; ils expliquent pourquoi l’écosystème ressemble à ce qu’il est.
- Les accélérateurs neuronaux ne sont pas nouveaux. Les DSP et les premiers ASIC d’inférence existaient bien avant que « NPU » devienne un terme marketing ; ils n’étaient juste pas à la mode.
- Le mobile a poussé les premiers NPU. Les téléphones avaient besoin de vision et de parole sur appareil sans cuire la batterie, poussant les fournisseurs vers des blocs dédiés.
- La quantification s’est généralisée à cause de la puissance. L’inférence INT8 n’a pas été adoptée parce que les ingénieurs aiment la précision réduite ; elle a été adoptée parce que les batteries existent.
- Les tenseur cores ont changé les attentes. Les unités tenseur des GPU ont popularisé la précision mixte et fait de la « mathématique matricielle spécialisée » une partie par défaut de la planification IA.
- Les piles de compilateurs sont devenues stratégiques. Pour les NPU, le compilateur et l’optimiseur de graphe peuvent compter autant que le silicium. Parfois plus.
- La couverture des opérateurs est une contrainte réelle. Si le NPU ne supporte pas une opération ou un schéma de fusion, vous retombez sur le CPU/GPU et les performances s’effondrent.
- Le marketing « TOPS » masque la difficulté. Les chiffres de téra-op peak supposent souvent des kernels idéaux, un tiling parfait, et zéro pénalité de mouvement de données. La réalité vous facture la mémoire.
- L’IA sur appareil est aussi une histoire de confidentialité. Garder le traitement audio/vidéo local réduit l’exposition des données et la charge légale, ce que les entreprises apprécient en silence.
- Windows et Linux rattrapent leur retard de façon inégale. Certains NPU ont une intégration OS de première classe ; d’autres ressemblent à un projet de foire scientifique agrafé à un driver.
- L’inférence en périphérie porte de plus en plus sur l’orchestration. L’« accélérateur » n’est pas juste une puce ; c’est le format de modèle, le runtime, l’ordonnancement, la politique d’énergie et l’observabilité.
Playbook de diagnostic rapide : trouver le goulet d’étranglement vite
Quand une fonctionnalité IA « tourne lentement », vous avez peut-être 20 minutes avant que quelqu’un ne propose une réécriture en Rust.
Voici un playbook qui fonctionne sur ordinateurs portables, stations de dev et boîtiers edge.
Premier point : confirmez où l’inférence s’exécute réellement
- Objectif : Le modèle s’exécute-t-il sur CPU, GPU, NPU — ou saute-t-il entre eux ?
- Pourquoi : Une exécution mixte ressemble souvent à « il utilise l’accélérateur » tout en restant liée au CPU sur des opérations non supportées.
Second point : décidez si vous êtes lié par le calcul ou par la mémoire
- Objectif : Les cœurs sont-ils occupés à faire des calculs, ou bloqués sur la mémoire et les défauts de cache ?
- Pourquoi : Si vous êtes limité par la mémoire, « plus de threads » est de l’essence sur un feu de poubelle.
Troisième point : vérifiez le throttling thermique et de puissance
- Objectif : Le système réduit-il sa fréquence sous une charge soutenue ?
- Pourquoi : Le throttling transforme vos graphiques de performance en art moderne : pointu et difficile à justifier.
Quatrième point : profilez la chaîne, pas seulement le modèle
- Objectif : Mesurez le décodage, le redimensionnement, l’extraction de caractéristiques, la tokenisation et le post-traitement.
- Pourquoi : Il est courant que « le modèle » ne représente que la moitié de la latence ; le reste est votre glue code et l’I/O.
Cinquième point : validez la couverture des opérateurs / taux de fallback
- Objectif : Identifiez quelles opérations ne sont pas supportées sur le NPU et où le fallback a lieu.
- Pourquoi : Une opération non supportée au mauvais endroit peut provoquer une boucle copie device-to-host qui détruit la perf et la puissance.
Une citation opérationnelle pour rester honnête, paraphrasée parce que la précision compte : paraphrased idea
— Gene Kranz :
« La dureté et la compétence » battent l’« ingéniosité » quand les systèmes sont sous pression.
Tâches pratiques : commandes, sorties et décisions (12+)
Ces tâches sont conçues pour le monde réel : vous avez une machine, un runtime modèle, et une plainte.
Chaque tâche inclut une commande, une sortie d’exemple, ce que la sortie signifie, et la décision suivante à prendre.
Les commandes ciblent Linux parce que c’est là que l’on voit les engrenages. Si vous êtes sur Windows/macOS, les principes s’appliquent toujours.
Task 1: Identify CPU features relevant to inference (AVX/AVX-512, etc.)
cr0x@server:~$ lscpu | egrep -i 'Model name|Socket|Thread|Core|Flags'
Model name: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
Socket(s): 2
Core(s) per socket: 16
Thread(s) per core: 2
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... avx2 avx512f avx512bw avx512vl ...
Signification : Vous avez AVX2 et AVX-512. Beaucoup de bibliothèques d’inférence CPU sélectionneront des kernels différents selon ces flags.
Décision : Si AVX-512 est absent sur une flotte cible, ne faites pas de benchmark uniquement sur un Xeon de dev pour déclarer victoire. Bâtissez des bases sur du matériel représentatif.
Task 2: Check whether the kernel sees an NPU-like accelerator device
cr0x@server:~$ lspci -nn | egrep -i 'neural|npu|vpu|accelerator|inference'
00:0b.0 Processing accelerators [1200]: Intel Corporation Device [8086:7d1d] (rev 01)
Signification : La couche PCI voit un « processing accelerator ». C’est un début, pas la preuve qu’il est exploitable.
Décision : Poursuivre par des vérifications de driver et de runtime. Si rien n’apparaît, vous êtes peut-être dans un cas « périphérique intégré exposé différemment », ou vous n’avez simplement pas de NPU.
Task 3: Confirm the driver is loaded (and not silently failing)
cr0x@server:~$ lsmod | egrep -i 'vpu|npu|accel|ivpu|amdxdna'
ivpu 151552 0
accel_core 32768 1 ivpu
Signification : Les modules kernel sont présents. Cela réduit la probabilité que vous soyez coincé en fallback CPU à cause de pilotes manquants.
Décision : Si les modules ne sont pas chargés, consultez dmesg pour des erreurs de firmware et d’initialisation avant d’incriminer le runtime.
Task 4: Read dmesg for accelerator initialization and firmware issues
cr0x@server:~$ dmesg -T | egrep -i 'ivpu|npu|vpu|firmware|accel' | tail -n 20
[Mon Jan 12 09:02:11 2026] ivpu 0000:00:0b.0: enabling device (0000 -> 0002)
[Mon Jan 12 09:02:11 2026] ivpu 0000:00:0b.0: loading firmware intel/vpu/vpu_37xx.bin
[Mon Jan 12 09:02:12 2026] ivpu 0000:00:0b.0: initialized successfully
Signification : Le firmware est chargé et le périphérique initialisé. Si vous voyez des réinitialisations répétées ou « failed to load firmware », attendez-vous à des performances « CPU-only ».
Décision : Corrigez le firmware/driver d’abord. L’ajustement du modèle ne servira à rien si l’accélérateur n’est pas opérationnel.
Task 5: Confirm CPU frequency scaling and detect throttling risk
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Signification : Vous êtes en powersave. Super pour la batterie ; possiblement terrible pour des benchmarks de latence.
Décision : Pour des tests contrôlés, passez en performance. En production, conservez les politiques d’énergie mais mesurez dans ces conditions.
Task 6: Change governor for a benchmark run (controlled testing only)
cr0x@server:~$ sudo bash -lc 'for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > $c; done'
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
Signification : Vous avez réduit la variance due au scaling de fréquence.
Décision : Si les performances s’améliorent drastiquement, votre problème « l’IA est lente » peut être une politique d’alimentation, pas une question d’architecture. Décidez si vous pouvez demander une QoS plus élevée pour la charge.
Task 7: Measure CPU saturation and scheduler pressure during inference
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server) 01/12/2026 _x86_64_ (64 CPU)
09:10:01 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
09:10:02 AM all 78.12 0.00 3.10 0.02 0.00 0.55 0.00 18.21
09:10:02 AM 12 99.00 0.00 0.80 0.00 0.00 0.20 0.00 0.00
09:10:02 AM 13 98.50 0.00 1.00 0.00 0.00 0.50 0.00 0.00
Signification : Quelques cœurs sont saturés ; le CPU global est élevé. Cela suggère soit une charge compute mono-flux, soit un épinglage de threads.
Décision : Si la latence compte, envisagez moins de threads avec meilleure localité de cache, ou déplacez le chemin chaud vers NPU/GPU si supporté.
Task 8: Detect memory pressure and swapping (silent inference killer)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 31Gi 27Gi 1.2Gi 196Mi 3.0Gi 2.1Gi
Swap: 8.0Gi 3.4Gi 4.6Gi
Signification : Le swap est utilisé. C’est un signal rouge pour la latence et la gigue d’inférence.
Décision : Réduisez la taille du modèle, utilisez la quantification, ou imposez des limites mémoire. Si vous devez exécuter localement, évitez à tout prix le swap.
Task 9: Confirm whether you’re I/O bound due to model loading
cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server) 01/12/2026 _x86_64_ (64 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
42.10 0.00 2.80 18.60 0.00 36.50
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 320.0 86000.0 0.0 0.00 12.40 268.8 10.0 512.0 1.20 4.10 92.00
Signification : Forte utililation disque et iowait pendant les runs. Vous mesurez peut-être le chargement du modèle et les défauts de page, pas le calcul.
Décision : Préchauffez le modèle en mémoire, utilisez mmap de poids avec précaution, et séparez la « latence de démarrage » de la « latence en régime permanent ».
Task 10: Check NUMA topology (server inference often trips here)
cr0x@server:~$ numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 128790 MB
node 0 free: 12410 MB
node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 1 size: 128733 MB
node 1 free: 80210 MB
Signification : La mémoire est inégalement libre entre les nœuds NUMA. Si votre processus tourne sur le nœud 0 mais alloue sur le nœud 1, la latence devient erratique.
Décision : Épinglez le processus et ses allocations mémoire sur le même nœud NUMA pour des résultats reproductibles, surtout pour l’inférence CPU.
Task 11: Run with NUMA pinning to reduce remote memory access (benchmark)
cr0x@server:~$ numactl --cpunodebind=0 --membind=0 ./inference_bench --model ./models/model.int8.onnx --threads 16
model_load_ms=420
p50_latency_ms=18.2
p95_latency_ms=23.9
throughput_qps=54.1
Signification : L’amélioration de la latence tail indique typiquement que vous payiez des pénalités NUMA distantes auparavant.
Décision : Si vous ne pouvez pas épingler en production, au moins détectez NUMA et évitez les placements pathologiques dans la configuration du gestionnaire de services.
Task 12: Confirm which shared libraries you’re actually using (kernel selection matters)
cr0x@server:~$ ldd ./inference_bench | egrep -i 'onnx|dnn|mkl|openvino|cuda|tensorrt'
libonnxruntime.so.1 => /usr/local/lib/libonnxruntime.so.1 (0x00007f8c1c000000)
libmkl_rt.so.2 => /opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_rt.so.2 (0x00007f8c17000000)
Signification : Vous utilisez des kernels soutenus par MKL (bon pour CPU). Si vous attendiez un fournisseur d’exécution NPU, il n’est pas présent.
Décision : Corrigez la configuration du runtime. Ne benchmarkez pas « CPU seulement » et ne l’appelez pas « NPU lent ».
Task 13: Trace context switches and migrations (jitter source)
cr0x@server:~$ pidof inference_bench
24817
cr0x@server:~$ sudo perf sched record -p 24817 -- sleep 10
cr0x@server:~$ sudo perf sched latency | head
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms
inference_bench:24817 | 9521.330 | 8212 | 0.141 | 7.882
Signification : Beaucoup de switches et un délai maximal non négligeable. Pour une inférence quasi temps réel, ces pics apparaissent comme des saccades visibles par l’utilisateur.
Décision : Envisagez de réduire le nombre de threads, de définir l’affinité CPU, ou de déplacer la charge hors du CPU si vous avez besoin d’une latence cohérente.
Task 14: Watch power/thermal throttling signals (on systems that expose them)
cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2 --num_iterations 3
CPU Avg_MHz Busy% Bzy_MHz TSC_MHz PkgTmp PkgWatt
- 1890 72.15 2620 2400 92 54.30
- 1710 74.02 2310 2400 96 55.10
- 1605 76.40 2100 2400 99 55.40
Signification : La température monte et la fréquence effective baisse. C’est un comportement de throttling en devenir (ou déjà en cours).
Décision : Si vous avez besoin d’une inférence soutenue, un NPU (ou un GPU correctement refroidi) est un meilleur choix. Sinon diminuez le cycle de service, réduisez la taille du modèle, ou acceptez une qualité inférieure.
Task 15: Confirm cgroup CPU limits (containers love to surprise you)
cr0x@server:~$ cat /sys/fs/cgroup/cpu.max
200000 100000
Signification : Le processus est limité à l’équivalent de 2 CPU. Votre « pourquoi c’est lent » peut être « parce que vous lui avez dit d’être lent ».
Décision : Ajustez les limites CPU, ou dimensionnez le modèle sur le quota. Aussi : cessez de comparer des benchmarks en conteneur à des nombres bare-metal sans reconnaître la limite.
Task 16: Check hugepages and THP status (can affect large weight access patterns)
cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
Signification : THP est en mode madvise. Si cela aide dépend de l’allocateur et du schéma d’accès.
Décision : Si vous observez des coûts de défaut de page et des misses TLB en profilage, expérimentez avec les réglages THP dans un test contrôlé. Ne l’activez pas à l’échelle de la flotte comme « solution performance » sans preuve.
Trois mini-histoires d’entreprise sorties du terrain
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne a déployé une fonctionnalité de « résumé sur appareil » pour les notes de réunion internes. Les architectes avaient fait le calcul :
le modèle était quantifié, l’inférence CPU semblait acceptable en laboratoire calme, et le NPU était « là pour plus tard ».
Le plan de déploiement supposait que « le CPU est toujours disponible » signifiait « le CPU est toujours disponible pour celle-ci ».
Deux jours après le lancement, les tickets de support ont explosé. Les utilisateurs se plaignaient que les appels vidéo saccadaient et que leurs machines chauffaient.
Le service IT a remarqué quelque chose de pire : les scans de protection des points d’accès échouaient, parce que le CPU restait saturé assez longtemps pour que d’autres agents manquent leurs fenêtres. Rien n’a planté, mais tout s’est dégradé en même temps — l’incident classique en lente combustion.
La mauvaise hypothèse était subtile : l’équipe avait mesuré la latence moyenne par inférence, pas le cycle de service.
En production, la fonctionnalité tournait en continu en arrière-plan pour « rester prête ». L’utilisation CPU est devenue soutenue,
l’enveloppe thermique s’est remplie, le CPU a réduit sa fréquence, et la latence de queue a explosé de façon non linéaire.
La correction fut opérationnelle, pas héroïque. Ils ont déplacé la partie toujours active (extraction de caractéristiques et petits embeddings)
vers le NPU là où c’était supporté, et changé le comportement produit : les résumés étaient générés à la demande,
pas pré-calculés continuellement. Ils ont aussi ajouté une règle de « recul sous charge » basée sur la température CPU et les métriques de délai de l’ordonnanceur.
La leçon clé : si votre fonctionnalité IA est continue, traitez-la comme un daemon. Les daemons ont besoin de budgets, pas d’optimisme.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une autre entreprise a livré un appliance edge qui faisait de la détection d’anomalies en temps réel sur des flux vidéo.
Un ingénieur performance a remarqué que les blocs convolutionnels du modèle étaient amicaux au NPU, mais le pré-traitement se faisait sur le CPU.
Ils ont décidé « d’optimiser » en déplaçant le pré-traitement dans un shader GPU personnalisé sur les systèmes équipés de GPU discrets,
tandis que l’inférence restait sur le NPU. Sur le papier : parallélisme ! Sur les slides : synergie !
En réalité, ils ont créé une taxe de mouvement de données. Les images allaient CPU → GPU pour le pré-traitement, puis GPU → mémoire CPU,
puis CPU → NPU. Chaque saut impliquait synchronisation, copies et conversions de format occasionnelles. Le débit moyen semblait correct,
mais la latence p95 s’est dégradée et la consommation d’énergie a augmenté. Le système chauffait plus et s’est mis à throttler plus tôt, transformant un ajustement de performance en problème de fiabilité.
Le pire : le débogage est devenu plus difficile. Le pipeline avait trois ordonnanceurs (CPU, driver GPU, runtime NPU),
et le timing dépendait des versions exactes des drivers. Ils couraient après des pics « aléatoires » qui étaient en réalité de la contention de files
et des points de synchronisation inter-périphériques.
Ils ont annulé le pipeline scindé et fait un changement ennuyeux mais efficace : garder le pré-traitement sur CPU avec des kernels vectorisés,
mais le batcher de façon à alimenter le NPU efficacement. Moins de sauts, moins de sync, moins de puissance, meilleure latence tail.
Le FPS maximal a légèrement baissé, mais le système a cessé de se comporter comme hanté.
Deuxième blague, et on a fini : Ajouter un accélérateur pour corriger la latence, c’est comme ajouter une voie pour résoudre un embouteillage — parfois vous venez juste d’élargir le bouchon.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une grande entreprise a déployé des ordinateurs portables avec NPU et une fonctionnalité de suppression de bruit IA pour les appels.
Le pilote s’est bien passé. Le déploiement plus large non. Les utilisateurs dans une région ont signalé que la fonctionnalité fonctionnait parfois,
puis s’arrêtait silencieusement, puis revenait après des redémarrages. Comportement intermittent classique — le genre qui bouffe des semaines.
L’équipe avait un avantage : elle avait insisté sur une pratique ennuyeuse et old-school dès le début — un inventaire matériel et pilotes à l’échelle de la flotte,
avec des bases versionnées et la détection de dérive. Chaque endpoint rapportait les ID de chipset, les versions de drivers, et si le runtime NPU passait un auto-test simple.
Les données ont rapidement montré un motif : les machines affectées partageaient une build de driver particulière, déployée via un anneau de mise à jour régional.
Le driver NPU se chargeait, mais l’initialisation du firmware échouait parfois après veille/reprise. Le runtime retombait alors sur le CPU,
et la politique d’alimentation bridait le CPU sous appels soutenus, donnant l’impression que « la fonctionnalité IA est instable ».
Parce qu’ils avaient une base, ils ont pu revenir en arrière sur cet anneau et épingler un driver connu bon pendant que le fournisseur corrigeait le problème.
La partie « ennuyeuse » — inventaire, déploiements en anneaux, et un autotest — a transformé un bazar intermittent en une régression contrôlée.
La leçon : les NPU sont du matériel. Le matériel nécessite une gestion de cycle de vie. Traitez-le comme un cluster, pas comme un coprocesseur magique.
Erreurs courantes : symptôme → cause racine → correctif
Voici les modes de défaillance que je vois souvent quand des équipes « ajoutent le support NPU » puis se demandent pourquoi rien n’a amélioré.
1) Symptom: NPU utilization shows near-zero; CPU is high
Cause racine : Le runtime utilise l’exécution CPU à cause d’un provider manquant, d’opérations non supportées, ou d’une init device échouée.
Fix : Vérifiez l’initialisation device dans dmesg, confirmez que le provider runtime est activé, et inspectez quelles ops font fallback. Convertissez le modèle vers un ensemble d’opérateurs supporté.
2) Symptom: Average latency improves, but p95/p99 gets worse
Cause racine : Synchronisation cross-device, contention de files, ou pré/post-traitement côté CPU qui devient le moteur de la queue.
Fix : Minimisez les sauts de device, fusions d’opérations quand c’est possible, et profilez l’ensemble du pipeline. Si nécessaire, isolez les threads d’inférence ou déplacez le pré/post sur le même device.
3) Symptom: Performance great on AC power, terrible on battery
Cause racine : Changement de governor, limites PL1/PL2, ou le système privilégie l’efficacité et réduit les fréquences CPU/GPU alors que le NPU reste sous-utilisé.
Fix : Utilisez les API OS QoS d’alimentation, assurez-vous que l’inférence s’exécute bien sur le NPU, et testez dans des modes d’alimentation réalistes. Ajustez le cycle de service et la taille du modèle.
4) Symptom: “NPU is fast” in vendor demo, slow in your app
Cause racine : La démo utilise un modèle façonné pour le NPU (opérations supportées, layouts idéaux, quantifié), tandis que votre modèle déclenche des chemins de fallback.
Fix : Réexportez le modèle avec des ops compatibles ; adoptez la quantification-aware training ou la quantification post-entraînement validée sur vos données ; utilisez les outils fournisseurs pour vérifier la couverture des opérateurs.
5) Symptom: CPU usage drops, but battery life still suffers
Cause racine : Vous avez déplacé le calcul hors du CPU mais augmenté le trafic mémoire, les réveils de device, ou l’exécution constante en arrière-plan.
Fix : Ajoutez un budget d’activité. Exécutez le modèle seulement quand nécessaire, batcher le travail, et évitez de maintenir l’accélérateur en état haute puissance continuellement.
6) Symptom: Inference occasionally hangs or times out after sleep/resume
Cause racine : Bugs de cycle de vie driver/firmware ou runtime qui ne gère pas bien la réinitialisation du device.
Fix : Détectez la santé du device, redémarrez le provider runtime en cas d’échec, et gardez les drivers épinglés à des versions connues bonnes avec des déploiements en anneaux.
7) Symptom: “More threads” makes CPU inference slower
Cause racine : Thrash de cache, saturation de bande passante mémoire, ou oversubscription avec d’autres workloads.
Fix : Ajustez le nombre de threads selon le sous-système mémoire ; utilisez l’épinglage NUMA sur serveurs ; mesurez. Cessez de supposer une montée en linéaire.
8) Symptom: NPU path is fast, but output quality regressed
Cause racine : Quantification agressive ou kernels/precisions différents affectant la numératie.
Fix : Validez la qualité sur des données représentatives ; préférez la quantification-aware training quand possible ; utilisez la quantification par canal et calibrez avec des entrées réelles.
Listes de contrôle / plan étape par étape
Étape par étape : décider d’utiliser CPU, GPU ou NPU
- Classifiez la charge : interactive (latence serrée), background (sensible à la puissance), batch (débit), ou mixte.
- Mesurez le cycle de service : à quelle fréquence l’inférence s’exécute-t-elle, et pendant combien de temps ? « Occasionnel » devient « continu » avec un changement produit.
- Profilez la répartition du pipeline : prétraitement, inférence, post-traitement, I/O, et copies entre devices.
- Vérifiez la couverture matérielle : quelle fraction de la flotte a un NPU capable de votre modèle ? N’optimisez pas pour 5 % sauf si ces 5 % sont votre PDG.
- Vérifiez la couverture des opérateurs : le NPU cible peut-il exécuter votre graphe sans fallback majeur ?
- Choisissez la précision et validez la qualité : INT8 peut être requis pour la perf NPU ; prouvez que cela ne casse pas les cas limites.
- Définissez des budgets : % CPU, état d’alimentation, plafond thermique, et SLOs de latence.
- Planifiez le comportement de fallback : si le NPU échoue, retombez-vous sur CPU, désactivez la fonction, ou dégradez la qualité ?
- Déployez l’observabilité : enregistrez quel device a exécuté l’inférence, la version du modèle, la précision, et les taux de fallback.
- Déployez en anneaux : surtout pour les drivers/firmware. Traitez la stack NPU comme une mise à jour kernel.
Checklist opérationnelle : avant d’activer une fonctionnalité IA à l’échelle de la flotte
- Définissez des objectifs de latence p50 et p95 pour les chemins interactifs ; définissez un budget moyen de puissance pour les chemins en arrière-plan.
- Testez en mode économie de batterie / faiblesse énergétique et sous les pires charges normales (appel vidéo + navigateur + EDR).
- Vérifiez le comportement veille/reprise et la gestion des réinitialisations de devices.
- Confirmez le temps de chargement du modèle et l’empreinte mémoire ; évitez le swap à tout prix.
- Assurez-vous que vos logs runtime indiquent « device selected » et « fallback ops » au moins au niveau debug.
- Épinglez les versions driver/runtime par anneau ; gardez un plan de rollback rapide.
FAQ
1) Les NPU sont-ils réservés aux ordinateurs portables et téléphones ?
Non. L’étiquette « NPU » apparaît le plus souvent sur les appareils clients parce que l’efficacité énergétique y est cruciale.
Dans les serveurs, le même concept existe sous forme d’accélérateurs d’inférence, mais ils sont souvent commercialisés comme GPU, TPU ou cartes.
2) Si j’ai un NPU, dois-je toujours l’utiliser pour l’inférence ?
Seulement si votre modèle et votre runtime s’y mappent vraiment bien. Si la couverture d’opérateurs est faible, vous retomberez sur le CPU et perdrez tout.
De plus, certaines tâches (tokenisation, parsing, logique métier) appartiennent toujours au CPU.
3) Que me dit vraiment le « TOPS » ?
Le débit théorique pico sous conditions idéales. C’est un plafond, pas une prévision.
Le vrai limiteur est souvent la bande passante mémoire, la couverture des opérateurs, et la portion du graphe réellement accélérée.
4) Pourquoi les NPU tiennent-ils tant à la quantification ?
Parce que la basse précision multiplie la performance par watt et réduit la demande en bande passante mémoire.
Mais la quantification peut changer le comportement du modèle ; il faut valider la qualité, pas seulement la vitesse.
5) Un NPU peut-il aider spécifiquement avec les LLM ?
Parfois, pour des modèles plus petits ou quantifiés et pour des opérateurs spécifiques. Mais beaucoup de NPU clients sont optimisés pour des graphes vision/audio.
L’inférence LLM est souvent limitée par la mémoire et peut ne pas se mapper proprement sans un support kernels et runtime soigné.
6) Quelle est la principale raison pour laquelle le « support NPU » n’améliore pas les performances ?
Le fallback. Une opération non supportée peut forcer des sauts device ou l’exécution CPU pour de larges parties du graphe.
Mesurez toujours quelles ops ont été exécutées où.
7) Les NPU sont-ils plus fiables que les GPU ?
Différents modes de défaillance. Les NPU sont intégrés et souvent plus simples à alimenter/gérer, mais la maturité du driver/runtime varie.
Les GPU ont des stacks matures dans de nombreux environnements, mais ajoutent complexité et consommation. La fiabilité dépend surtout de la gestion du cycle de vie et de l’observabilité.
8) Que dois-je journaliser en production pour éviter les conjectures ?
Journalisez le device d’exécution (CPU/GPU/NPU), la version du modèle et la précision, le nombre d’opérations de fallback, la latence d’inférence (p50/p95),
et toute erreur de reset/init device. Sans cela, vous dépannez à partir d’impressions.
9) Comment décider de déplacer aussi le prétraitement vers le NPU ?
Préférez garder les données sur un seul device quand c’est possible, mais ne forcez pas. Si le prétraitement est petit et avec beaucoup de branches, le CPU suffit.
Déplacez-le uniquement quand les copies dominent ou que l’accélérateur a un support dédié pour ces ops.
10) Quel est le « gain » le plus simple pour l’inférence CPU si je ne peux pas utiliser un NPU ?
Quantifiez, ajustez le nombre de threads, évitez le swap, et corrigez le placement NUMA sur serveurs. Puis profilez le pipeline.
La majorité des rapports « CPU lent » sont en réalité des rapports « mémoire lente ».
Prochaines étapes pratiques
Si vous êtes responsable de la livraison d’une fonctionnalité IA sur des machines réelles, faites ceci ensuite :
- Mesurez où le travail s’exécute (CPU vs NPU vs GPU) et à quelle fréquence il retombe en fallback.
- Profilez la latence de bout en bout, pas seulement le temps d’exécution du modèle.
- Définissez des budgets : utilisation CPU, marge thermique, et impact batterie sont des exigences, pas des après-coup.
- Choisissez une stratégie modèle : quantifiez avec validation qualité, ou acceptez une perf moindre. Ne prétendez pas obtenir les deux gratuitement.
- Opérationnalisez le matériel : bases drivers, déploiement en anneaux, et plans de rollback. Traitez l’activation NPU comme un changement kernel.
Les NPU ne sont pas là parce que les CPU sont « mauvais ». Ils existent parce que la physique est impitoyable, les batteries sont petites, et les utilisateurs se plaignent immédiatement.
Mettez le bon travail sur le bon silicium, et gardez vos systèmes ennuyeux. L’ennui scale.