Hype des PC IA vs véritables changements d’architecture : ce qui compte en 2026

octobre 25, 2025 • février 3, 2026 • Lecture : 32 min • Views: 0

Cet article vous a aidé ?

Votre ordinateur portable peut désormais « faire de l’IA ». Très bien. La vraie question est de savoir s’il peut faire votre IA — de façon fiable, rapidement, sans surchauffer, et sans transformer le SSD en mémorial de l’amplification d’écriture.

Si vous gérez des flottes, développez des applications, ou voulez simplement que votre machine coûteuse ressemble à une vraie mise à niveau plutôt qu’à une expérience marketing, il faut séparer l’autocollant (« NPU à l’intérieur ! ») des changements d’architecture qui déplacent réellement l’aiguille : bande passante mémoire, comportements de mémoire unifiée, enveloppes thermiques, latence de stockage sous IO mixte, maturité des drivers, et comportement des pipelines d’inférence sous gestion d’énergie.

Ce que signifie vraiment « PC IA » (et ce que ce n’est pas)

En 2026, « PC IA » est une catégorie produit construite autour d’une revendication architecturale : une machine cliente peut exécuter une inférence ML significative localement, en temps réel, à puissance acceptable, avec une latence acceptable, et une pile logicielle qu’un utilisateur normal peut installer sans invoquer un exorciste de drivers.

La définition marketing est plus simple : un NPU (unité de traitement neuronal) existe, et l’OS propose des fonctionnalités IA. Ce n’est pas faux, c’est juste incomplet de façon à vous nuire.

Voici la définition opérationnelle qui prédit réellement si vos utilisateurs seront satisfaits :

Diversité des calculs : CPU, GPU, NPU, et parfois des blocs DSP peuvent tous exécuter des parties du pipeline.
Comportement mémoire : pouvez-vous garder les poids, le cache KV et les activations résidents sans pagination, swap ou blocage ?
Réalité IO : pouvez-vous charger les modèles rapidement, les mettre en cache intelligemment, et éviter que la latence soit détruite par des écritures en arrière-plan ?
Thermiques et puissance : la performance reste-t-elle stable après 5–15 minutes, ou s’effondre-t-elle ?
Maturité logicielle : le runtime choisit-il automatiquement le bon dispositif et les bons types de données — ou « aide-t-il » en se trompant ?

Ce qu’un PC IA n’est pas : une garantie que chaque charge de travail « IA » est plus rapide, moins chère ou plus sûre sur l’appareil. Certaines charges sont mieux traitées sur un serveur avec de grosses GPU, beaucoup de mémoire et des températures ennuyeuses. D’autres sont mieux dans le navigateur avec un modèle minuscule. Certaines ne devraient pas exister.

Une règle utile : si votre charge est limitée par la capacité mémoire (gros modèles) ou la bande passante (beaucoup de tokens/sec), votre « PC IA » vit ou meurt par la conception mémoire et les thermiques, pas par l’existence d’un logo NPU.

Les véritables changements d’architecture cachés derrière le battage

Ignorez les slogans. Les changements d’architecture sont la seule raison pour laquelle cette catégorie existe vraiment. Mais ces changements ne se trouvent pas toujours là où les pubs le montrent.

1) Plus de calcul hétérogène, avec un impôt du planificateur

Le silicium client moderne est un petit datacenter en pardessus : cœurs de performance, cœurs d’efficacité, GPU intégré, et maintenant un NPU avec ses propres chemins d’accès mémoire et pile de drivers.
Cette hétérogénéité est puissante, mais elle crée un nouveau mode d’échec : la charge est planifiée sur le moteur « mauvais », ou elle rebondit entre moteurs, remorquant les données comme un enfant traînant des briques.

2) Les enveloppes de puissance et thermiques sont maintenant des contraintes d’architecture de première classe

La performance que vous voyez dans un graphique de benchmark est souvent « batterie fraîche, châssis froid, ventilateurs optimistes ». L’usage réel c’est « appel Zoom, 14 onglets, protection endpoint, et l’ordinateur posé sur une couverture ».
Les charges IA sont soutenues. Les charges soutenues exposent la vérité : limites de puissance, comportement des VRM, et courbes d’étranglement thermique.

3) La hiérarchie mémoire compte plus que les TOPS bruts

Le marketing des PC IA adore les TOPS parce que c’est un nombre propre. Mais la plupart des pipelines d’inférence sont contraints par :

Bande passante mémoire : la vitesse à laquelle poids et cache KV se déplacent.
Capacité mémoire : le modèle peut-il tenir sans pagination ni streaming.
Comportement du cache : êtes-vous en train de thrash le L3 ou l’utilisez-vous efficacement.
Voies DMA : le NPU accède-t-il à la mémoire efficacement ou via une paille étroite.

4) La latence du stockage redevient visible par l’utilisateur

Nous avons passé des années à habituer les utilisateurs à ignorer le disque. « Le SSD a tout résolu. » Puis nous avons commencé à charger des modèles de plusieurs gigaoctets, à échanger des caches, à écrire des logs et à checkpointzer des embeddings localement.
Soudain, un NVMe lent sous charge mixte fait que votre « assistant IA instantané » ressemble à un modem commuté ambitieux.

5) La frontière de sécurité se déplace vers l’endpoint

L’inférence locale réduit le risque d’exfiltration réseau dans certains cas. Elle déplace aussi la propriété intellectuelle des modèles, les invites, et potentiellement des données dérivées sensibles vers les endpoints.
Cela change votre modèle de menace : chiffrement disque, démarrage sécurisé, isolation des identifiants, et « où vivent les caches ? » deviennent des questions d’architecture, pas des notes de bas de page politiques.

NPUs : quand ils aident, quand ils n’aident pas, et pourquoi

Les NPUs sont du silicium réel, pas une arnaque. L’arnaque est de prétendre qu’ils sont universellement utiles.
Les NPUs brillent lorsque la charge correspond à leur conception : algèbre linéaire dense, noyaux prévisibles, précision limitée (INT8/INT4), et modèles stables que les fournisseurs peuvent optimiser.

Les NPUs peinent quand :

Vous avez besoin de flexibilité : opérations personnalisées, architectures excentriques, modèles en évolution rapide.
Vous avez besoin de grands espaces mémoire : gros caches KV ou longues fenêtres de contexte.
Vous avez besoin d’ergonomie développeur : le débogage est plus difficile, les outils varient, le support de kernel accuse du retard.
Vous avez besoin de débit maximal : les GPU intégrés ou discrets dominent encore de nombreux scénarios d’inférence client.

La façon pratique d’y penser :

GPU est le moteur mathématique généraliste « rapide » avec des chaînes d’outils matures et généralement une bande passante supérieure.
NPU est l’« appareil d’inférence efficace » qui peut être incroyable pour les modèles supportés et catastrophique pour tout le reste.
CPU est la couche « secours et orchestration ». C’est aussi l’endroit où vous vous retrouvez quand les drivers plantent à 2h du matin.

Votre objectif en production n’est pas de vénérer un accélérateur. Votre objectif est de contrôler la sélection du dispositif, valider la stabilité des performances, et fournir un chemin de repli sûr.

Petite blague #1 : Une démo NPU qui ne fait tourner qu’un seul modèle, c’est comme un grille-pain qui ne grille qu’une seule marque de pain. Techniquement impressionnant, opérationnellement insultant.

La mémoire est le patron : bande passante, capacité, réalités proches du NUMA

Si vous voulez comprendre pourquoi les PC IA semblent rapides ou lents, arrêtez de demander « combien de TOPS ? » et commencez à demander :
Combien d’octets par seconde puis-je nourrir au calcul ?

Capacité : pouvez-vous garder le modèle résident ?

Un modèle quantifié qui tient en RAM tourne comme une machine. Un modèle qui tient de justesse tourne comme un comité.
Une fois que vous commencez à paginer, vous faites effectivement de l’inférence via un périphérique de stockage. Ce n’est pas « IA locale ». C’est « NVMe-comme-RAM », ce qui est un choix de vie.

Pour les flottes d’entreprise, cela devient une question de politique d’achat. Si votre cible inclut des LLM locaux au-delà de tailles minuscules, vous devriez traiter la capacité RAM comme une exigence stricte, pas comme un bonus.

Bande passante : tokens/sec est souvent une histoire de mémoire

L’inférence Transformer relit fréquemment les poids et met à jour le cache KV. La bande passante compte. Les GPU intégrés et les NPUs se disputent l’accès mémoire avec le CPU, et certains designs gèrent cela mieux que d’autres.
Si la mémoire système est partagée et que l’OS est occupé, votre « accélération IA » peut se transformer en « contention IA ».

Latence : l’IA interactive punit les pauses

Les humains remarquent les saccades. Si votre assistant marque une pause au milieu d’une phrase parce que le portable a décidé de mettre des cœurs en pause ou de vider des caches, l’expérience est cassée même si le débit moyen semble correct.
Les pics de latence proviennent de la gestion d’énergie, de l’étranglement thermique, de la pression mémoire et de la planification des drivers.

Mémoire unifiée : pratique… jusqu’à ce que ça ne le soit plus

Les designs à mémoire unifiée réduisent les copies, simplifient la programmation et rendent « utiliser le GPU » plus facile. Mais la mémoire unifiée signifie aussi contention unifiée.
Si vous faites de l’inférence pendant que le navigateur accélère tout sur le GPU et que l’OS anime vos fenêtres, vous pouvez finir avec un blocage de tête de ligne sur la mémoire et les files GPU.

Stockage et IO : le goulet silencieux qui ruine « l’IA locale »

Le stockage est de retour dans le chemin critique. Pas parce que les SSD se sont détériorés — parce que les charges sont devenues plus lourdes et plus explosives.
Les workflows IA locaux tirent de gros fichiers (poids de modèles), créent des caches (tokenizers, kernels compilés, caches d’attention pour certaines applications), et parfois persistent des embeddings.

Temps de chargement du modèle : votre première impression est un benchmark IO

Les utilisateurs jugent la performance « PC IA » dans les dix premières secondes : cliquez sur un bouton, attendez que le modèle charge, regardez le ventilateur se déclencher, vous demandez pourquoi le portable réfléchit autant.
Le débit séquentiel compte, mais la latence sous IO mixte compte aussi. Si Defender ou un EDR scanne et indexe, les chargements de modèles peuvent devenir imprévisibles.

Amplification d’écritures et endurance SSD : pas glamour, mais réel

Certains outils IA locaux écrivent de façon agressive : téléchargements répétés, extraction, churn de cache, logs, télémetrie, tenseurs temporaires vidés sur disque quand la RAM est serrée.
Si vous gérez des flottes, vous devriez vous soucier de l’endurance SSD et des compteurs d’usure SMART — pas parce qu’ils tombent en panne chaque jour, mais parce que les pannes arrivent par lots et au pire moment.

Surcharge système de fichiers et chiffrement : mesurez, ne devinez pas

Le chiffrement des endpoints est non négociable dans la plupart des organisations. Le surcoût du chiffrement est généralement acceptable sur les CPU modernes, mais il peut apparaître pendant des IO soutenus plus inférence.
La bonne posture : mesurer avec des traces réalistes, puis décider si vous devez ajuster les emplacements de cache, les schémas IO ou le packaging des modèles.

La pile logicielle : runtimes, drivers, et la taxe du « ça dépend »

Les PC IA sont vendus comme des appareils. Ils ne sont pas des appareils. Ce sont des écosystèmes : ordonnanceur OS, firmware, drivers, runtime d’inférence et code applicatif.
Si une couche est immature, vous obtenez l’expérience classique : « Ça marche bien sur ma machine » (c’est-à-dire : une machine, une version de driver, une température ambiante).

La sélection du dispositif est une décision produit

Si votre application tourne parfois sur CPU, parfois sur GPU, et parfois sur NPU, ce n’est pas de la flexibilité. C’est de la roulette.
Fournissez des bascules explicites, des valeurs par défaut sensées, et de la télémétrie qui vous dit quel dispositif a été utilisé et pourquoi.

La quantification est un choix d’architecture, pas seulement de modèle

La quantification INT8/INT4 peut débloquer les NPUs et améliorer le débit, mais elle peut aussi :

réduire la qualité de façon subtile qui casse des workflows d’entreprise (résumés, extraction, ou génération de code)
créer des charges de support (kernels différents par dispositif)
changer les motifs mémoire (poids plus petits, mais alignements et comportement cache différents)

Drivers et firmware : là où la réalité « PC IA » vit

Les mises à jour de firmware peuvent changer le comportement de puissance, les timings mémoire et la stabilité des accélérateurs. Les mises à jour de drivers peuvent changer la disponibilité des kernels et la performance.
Traitez-les comme des dépendances de production. Suivez les versions. Faites des rollouts par paliers. Ayez des plans de rollback.

Une citation qui tient encore en terrain d’IA endpoint :

« L’espoir n’est pas une stratégie. » — Vince Lombardi

Faits intéressants et contexte historique (court, concret, utile)

Les TOPS sont devenus un marketing dominant parce qu’ils compressent la « capacité d’inférence » en un seul nombre, à la manière des guerres du GHz au début des années 2000.
Les SoC mobiles ont livré des NPUs des années avant les PC, et les premières victoires étaient ennuyeuses : pipelines caméra, déclencheurs vocaux, et amélioration photo — pas des chatbots.
L’ère MMX puis AVX d’Intel fut un des premiers moments « PC IA » : de nouvelles instructions vectorielles promettaient l’accélération, mais le logiciel a mis des années à suivre.
Les GPU sont devenus des moteurs ML par accident : conçus pour le graphisme, puis réutilisés pour l’algèbre matricielle. Cet accident a produit la maturité des outils que les NPUs poursuivent encore.
La reconnaissance vocale sur appareil fut l’un des premiers workloads d’inférence client à grande échelle, motivé par la latence et la confidentialité.
La poussée du Neural Engine d’Apple a normalisé l’idée que les appareils clients peuvent avoir des blocs d’inférence dédiés — et que l’intégration OS compte autant que le silicium.
La quantification n’est pas nouvelle : elle est utilisée en traitement du signal et en ML embarqué depuis des années ; la nouveauté est de l’appliquer aux grands modèles de langue à l’échelle grand public.
L’adoption NVMe a caché une décennie de schémas IO logiciels négligents ; les grands modèles locaux réexposent ces schémas face aux attentes réelles des utilisateurs.

Guide de diagnostic rapide : trouver le goulet en quelques minutes

Quand quelqu’un dit « l’IA locale est lente », ne discutez pas l’architecture au tableau blanc. Lancez un triage rapide. Vous cherchez la classe du goulet : calcul, mémoire, stockage, ou thermique/puissance.

Première étape : identifier quel moteur exécute réellement le travail

L’inférence tourne-t-elle sur CPU, GPU ou NPU ?
Tombe-t-elle en fallback à cause d’opérations non supportées, d’une mauvaise précision, ou d’une config runtime ?

Deuxième étape : vérifier l’étranglement thermique et les limites de puissance

La fréquence chute-t-elle après quelques minutes ?
Le système est-il sur batterie ou en profil basse consommation ?

Troisième étape : vérifier la pression mémoire et la pagination

Le modèle tient-il dans RAM/VRAM/mémoire unifiée ?
Y a-t-il des défauts de page majeurs pendant l’inférence ?

Quatrième étape : vérifier la latence de stockage sous charge

Le chargement du modèle est-il lent seulement au premier lancement (cache froid) ou à chaque exécution ?
Des scans en arrière-plan, indexations ou outils de synchronisation frappent-ils le disque ?

Cinquième étape : valider les versions de la pile logicielle et le risque de régression

Changements de version de driver ?
Mises à jour du runtime ?
Changements de firmware ?

Petite blague #2 : Si la solution est « réinstaller les drivers », félicitations — vous faites de l’informatique artisanale.

Tâches pratiques : commandes, sorties, ce que ça signifie, et ce que vous décidez

Celles-ci sont centrées sur Linux parce que c’est le moyen le plus propre de montrer la vérité architecturale avec des outils dignes de confiance. La même logique s’applique ailleurs.
Exécutez-les sur une machine de test tout en reproduisant le problème : chargement du modèle, latence du premier token, génération soutenue, et charge concurrente « utilisateur normal » (navigateur + appel vidéo).

Task 1: Confirm CPU topology and frequency behavior

cr0x@server:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core|Socket|MHz'
Model name:            AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
CPU(s):                16
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             1
CPU MHz:               1896.000

Ce que la sortie signifie : Vous voyez le nombre de cœurs/threads et un instantané de fréquence. Si le MHz est bas pendant la charge, vous êtes en throttling ou en profil économie d’énergie.

Décision : Si le CPU MHz reste bas pendant l’inférence, vérifiez les profils d’alimentation et les thermiques avant de blâmer le modèle.

Task 2: Watch CPU frequency and throttling signals in real time

cr0x@server:~$ sudo turbostat --Summary --interval 2
...
PkgWatt  CorWatt  RAMWatt   Avg_MHz  Busy%  Bzy_MHz  CPU%c1  CPU%c6
12.34    8.21     1.05      1420     68.2   2080     3.10   24.80
19.10    12.80    1.10      980      75.5   1300     2.50   40.20

Ce que la sortie signifie : Une chute d’Avg_MHz et Bzy_MHz alors que Busy% reste élevé indique souvent des limites de puissance/thermiques. Des états C élevés pendant la charge peuvent signaler des bizarreries de planification.

Décision : Si le MHz s’effondre après un court pic, traitez ça comme un problème thermique/power. Améliorez le refroidissement, le plan d’alimentation et les limites de soutenance.

Task 3: Check GPU presence and driver binding

cr0x@server:~$ lspci -nnk | egrep -A3 'VGA|3D|Display'
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf]
	Subsystem: Lenovo Device [17aa:3a6f]
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu

Ce que la sortie signifie : Confirme quel driver kernel est actif. Un driver générique ou un module manquant signifie souvent pas d’accélération.

Décision : Si le driver n’est pas celui attendu, arrêtez les benchmarks. Corrigez les drivers d’abord.

Task 4: Measure GPU utilization during inference

cr0x@server:~$ radeontop -d - -l 3
Dumping to stdout.  Press Ctrl+C to exit.
gpu  72.11%  ee  0.00%  vgt  41.20%  ta  55.90%  sx  36.10%  sh  68.30%
gpu  10.02%  ee  0.00%  vgt  2.10%   ta  3.90%   sx  1.80%   sh  8.20%
gpu  69.44%  ee  0.00%  vgt  39.00%  ta  51.00%  sx  31.50%  sh  64.10%

Ce que la sortie signifie : Les pics d’utilisation GPU corrèlent avec le calcul d’inférence sur GPU. Si c’est proche de zéro, vous êtes probablement sur CPU/NPU ou bloqué ailleurs.

Décision : Si le GPU est inactif alors que le CPU est chaud, confirmez la sélection du dispositif dans votre runtime/config app.

Task 5: Identify NPU device nodes (presence is not usage)

cr0x@server:~$ ls -l /dev | egrep 'accel|dri|kfd'
drwxr-xr-x  2 root root      120 Jan 13 09:12 dri
crw-rw----  1 root render 236,   0 Jan 13 09:12 kfd

Ce que la sortie signifie : Sur de nombreux systèmes, les accélérateurs exposent des nœuds de périphériques (par ex. /dev/dri, /dev/kfd). Cela prouve seulement que la plomberie existe.

Décision : Si les nœuds de périphérique manquent, n’attendez pas du runtime qu’il « trouve le NPU ». Corrigez le kernel/stack driver.

Task 6: Check memory pressure and swap activity

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        26Gi       1.2Gi       1.1Gi       4.8Gi       3.9Gi
Swap:          8.0Gi       2.6Gi       5.4Gi

Ce que la sortie signifie : Peu de mémoire disponible et usage du swap indiquent de la pagination. Pour l’inférence interactive, c’est généralement catastrophique pour la latence.

Décision : Si le swap est non négligeable pendant l’inférence, réduisez la taille du modèle, augmentez la RAM, ou changez les attentes du workload. Ne bricolez pas autour.

Task 7: Detect major page faults while running inference

cr0x@server:~$ pidstat -r -p 24531 1 5
Linux 6.5.0 (ai-laptop)  01/13/2026  _x86_64_  (16 CPU)

09:20:01 PM   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
09:20:02 PM  1000     24531   1200.00     45.00  2600M  1800M   5.6   llama-run
09:20:03 PM  1000     24531    950.00     60.00  2600M  1820M   5.7   llama-run

Ce que la sortie signifie : majflt/s sont des fautes majeures nécessitant de l’IO disque. Si ce nombre est non nul pendant la génération, vous êtes bloqué sur le stockage.

Décision : Des fautes majeures pendant l’inférence en régime permanent signifient « le modèle ne tient pas » ou « le système subit une pression mémoire ». Corrigez la mémoire d’abord.

Task 8: Measure disk latency under mixed load

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (ai-laptop)  01/13/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          32.14    0.00    5.12    9.80    0.00   52.94

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         85.0   92160.0     2.0    2.3   18.40  1084.2     44.0   16384.0   22.10   372.4    2.10   88.0

Ce que la sortie signifie : r_await et w_await montrent la latence moyenne. Await élevé avec %util élevé signifie que le disque est saturé ou bloqué par la contention.

Décision : Si l’await saute pendant l’inférence/chargement du modèle, cherchez des IO en arrière-plan (clients de sync, scans AV) et envisagez de déplacer les caches ou de pré-stager les modèles.

Task 9: Identify which processes are hitting the disk

cr0x@server:~$ sudo iotop -b -n 3 -o
Total DISK READ: 95.20 M/s | Total DISK WRITE: 18.10 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
1832  be/4  root       0.00 B/s  12.40 M/s   0.00 %  9.20 %  updatedb.mlocate
24531 be/4  cr0x      92.10 M/s   1.20 M/s   0.00 %  6.10 %  llama-run --model /data/models/...

Ce que la sortie signifie : Montre les processus qui monopolisent l’IO. Si des jobs d’indexation ou des outils de sync concurrencent les chargements de modèles, les utilisateurs le ressentiront.

Décision : Si des « tâches utiles en arrière-plan » chevauchent l’inférence, planifiez/limitez-les. Ne dites pas aux utilisateurs « attendez juste ».

Task 10: Confirm filesystem type and mount options (performance + reliability)

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /data
/dev/nvme0n1p3 ext4 rw,relatime,discard,errors=remount-ro

Ce que la sortie signifie : Vous voyez le FS et les options. Certaines options (comme discard agressif) peuvent affecter la latence sur certains disques et noyaux.

Décision : Si vous observez des pics de latence et que discard est activé, testez avec fstrim planifié à la place. Mesurez, n’écoutez pas les légendes urbaines.

Task 11: Check NVMe health and wear indicators

cr0x@server:~$ sudo smartctl -a /dev/nvme0 | egrep 'Percentage Used|Data Units Written|Media and Data Integrity Errors|Power Cycles'
Percentage Used:                    6%
Data Units Written:                 18,442,113 [9.44 TB]
Media and Data Integrity Errors:    0
Power Cycles:                       122

Ce que la sortie signifie : « Percentage Used » est un indicateur d’usure approximatif. Une montée rapide sur une flotte peut indiquer un churn de cache ou un mauvais comportement des outils.

Décision : Si l’usure augmente de façon inattendue, auditez caches/logs, déplacez les chemins à forte écriture, et définissez des politiques de rétention.

Task 12: Verify thermal headroom and throttling flags

cr0x@server:~$ sudo sensors
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +92.5°C

amdgpu-pci-0300
Adapter: PCI adapter
edge:         +88.0°C
junction:     +101.0°C

Ce que la sortie signifie : Des températures proches des limites de la plateforme déclencheront du throttling. Les températures de jonction comptent pour les workloads GPU soutenus.

Décision : Si les températures sont élevées pendant l’inférence, validez la stabilité de la performance dans le temps. Envisagez des politiques de refroidissement, un dock, ou des limites de workload.

Task 13: Observe per-process CPU usage and scheduling weirdness

cr0x@server:~$ top -H -p 24531 -b -n 1 | head -n 15
top - 21:23:10 up  3:41,  1 user,  load average: 12.44, 10.90, 8.12
Threads:  42 total,  16 running,  26 sleeping,   0 stopped,   0 zombie
%Cpu(s):  72.0 us,  6.0 sy,  0.0 ni,  9.0 id,  13.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
24531 cr0x      20   0 2620.0m   1.8g  12800 R  340.0  5.8   3:12.11 llama-run
24560 cr0x      20   0 2620.0m   1.8g  12800 R  195.0  5.8   1:28.32 llama-run

Ce que la sortie signifie : Un wa élevé (IO wait) indique une contention de stockage. Plusieurs threads chauds suggèrent une inférence limitée par le CPU.

Décision : Si l’IO wait est élevé, suivez le stockage. Si le CPU est saturé sans activité GPU/NPU, corrigez l’utilisation du dispositif ou acceptez les limites CPU.

Task 14: Time model load and first-token latency (cheap but revealing)

cr0x@server:~$ /usr/bin/time -f "elapsed=%e user=%U sys=%S" ./llama-run --model /data/models/q4.gguf --prompt "hello" --tokens 1
hello
elapsed=7.82 user=1.21 sys=0.88

Ce que la sortie signifie : Si elapsed est élevé mais que le temps CPU utilisateur est faible, vous attendez de l’IO ou des surcoûts d’initialisation (compilation de kernels, warmup de cache).

Décision : Si le premier lancement est lent et le second rapide, préchauffez les caches ou expédiez des artefacts précompilés. Si chaque exécution est lente, corrigez le stockage/la contention AV.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« NPU signifie rapide »)

Une entreprise de taille moyenne a déployé un assistant de « notes de réunion » local sur les portables des cadres. Le pitch : l’audio reste sur l’appareil, la transcription et le résumé s’exécutent localement, et rien de sensible ne touche le cloud. La sécurité a adoré. Les achats ont adoré. La démo a adoré.

Semaine une, les tickets support sont arrivés en motif régulier : « L’assistant fige mon portable pendant les appels. » Certains utilisateurs signalaient des ventilateurs hurlants, d’autres que l’app « marche parfois, parfois rampe ». L’équipe a supposé que le NPU faisait le gros du travail et s’est concentrée sur des bugs UI.

Un SRE a finalement profilé une machine en reproduisant le problème. Le runtime basculait silencieusement vers le CPU parce qu’un opérateur de prétraitement n’était pas supporté par le backend NPU. Le NPU existait, mais le pipeline non. Pendant ce temps, le CPU était déjà occupé par la conférence et la protection endpoint.

La correction n’a pas été héroïque. Ils ont scindé le pipeline : opérations supportées sur NPU, opérations non supportées sur GPU, et le CPU uniquement pour l’orchestration. Ils ont aussi ajouté un autotest de démarrage qui rapportait quel dispositif était sélectionné et pourquoi. Les tickets ont chuté vite, non pas parce que le NPU s’était amélioré, mais parce que l’hypothèse avait été supprimée.

La leçon : « a un NPU » n’est pas la même chose que « votre charge utilise le NPU ». Si vous ne vérifiez pas la sélection du dispositif en production, vous faites de l’informatique basée sur la foi.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (cache de modèles en amplificateur d’écritures)

Une autre organisation a construit un assistant développeur interne qui récupérait des modèles et des embeddings localement pour réduire les coûts serveurs. Un ingénieur bien intentionné a introduit une fonction de « cache agressif » : préfetcher plusieurs variantes de modèle et les maintenir à jour en arrière-plan pour que les devs aient toujours la dernière version.

Ça fonctionnait — sur une seule machine dev. Dans la flotte, les portables ont commencé à montrer des taux de panne plus élevés « problèmes de performance du stockage », et la batterie s’est mise à fondre. Quelques machines ont même atteint tôt des seuils d’usure SMART. Personne n’a relié cela à l’assistant car l’assistant « ne tournait pas » quand les pannes se produisaient.

Le coupable était le gestionnaire de cache. Il tournait en service d’arrière-plan, se réveillant sur les changements réseau, vérifiant des hashes, réécrivant de gros blobs, et produisant une tempête de petites mises à jour metadata. Ce n’était pas seulement la bande passante ; c’était la latence et les réveils constants empêchant les états de sommeil profond.

Le rollback a été simple : arrêter les mises à jour en arrière-plan, ne cacher qu’un modèle par classe cible, et implémenter un store adressé par contenu avec déduplication et politiques de rétention. Ils ont aussi déplacé les caches vers un emplacement exclu de certaines opérations d’indexation, en coordination avec la sécurité.

La leçon : « Optimiser par la mise en cache » peut être un piège sur les endpoints. Vous pouvez troquer le coût serveur contre l’usure SSD, la consommation batterie et la colère des utilisateurs. La facture arrive plus tard, avec intérêts.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (rollouts drivers par paliers)

Une entreprise globale s’est standardisée sur un ensemble de portables capables d’IA. La performance était acceptable, et quelques apps étaient explicitement réglées pour GPU et NPU. Puis une mise à jour de driver est arrivée — en silence — via le pipeline normal de mises à jour. Le lendemain matin, une région a rapporté que l’inférence locale plantait de manière intermittente.

Dans une org moins disciplinée, c’est le chaos : tout le monde met à jour, tout le monde casse, et le canal d’incidents devient une reconstitution en direct du déni. Cette équipe avait une pratique terne et belle : des rollouts par paliers avec canaris, plus un tableau de bord corrélant les pannes d’app avec les versions de drivers.

L’anneau canari s’est illuminé en quelques heures. Ils ont gelé le déploiement, épinglé le driver précédent, et poussé une politique bloquant la version problématique jusqu’à validation d’une release corrigée. La plupart des employés n’ont jamais remarqué ; le seul drame a été un chef de produit légèrement agacé.

Le postmortem a trouvé une régression dans un chemin de compilation kernel pour un opérateur quantifié. Le résultat clé n’a pas été un contournement élégant — c’est la discipline de versioning qui a évité la douleur à l’échelle de la flotte.

La leçon : l’IA sur endpoint dépend des drivers comme les serveurs dépendent des kernels. Traitez-les avec le même respect : anneaux, métriques, rollback, et trace écrite.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: « First token takes forever; subsequent tokens are fine »

Cause racine : Chargement et initialisation du modèle (IO, décompression, compilation de kernels, warmup de cache).
Correctif : Pré-warmez à l’inactivité, fournissez des kernels précompilés quand possible, gardez les modèles locaux avec un cache raisonnable, et mesurez explicitement runs froids vs chauds.

2) Symptom: « Fast for 30 seconds, then gets slower and slower »

Cause racine : Throttling thermique ou application de limites de puissance sous charge soutenue.
Correctif : Validez la performance soutenue ; ajustez le profil d’alimentation ; assurez un refroidissement adéquat ; considérez des modèles plus petits ou des taux de tokens/batch plus faibles.

3) Symptom: « CPU pegged, GPU idle, NPU allegedly present »

Cause racine : Fallback backend dû à des ops non supportées, mauvais dtype, support driver/runtime manquant, ou mauvaise configuration.
Correctif : Loggez la sélection du dispositif, refusez l’exécution pour les backends non supportés, ajoutez des checks de capacité runtime, et épinglez des versions connues bonnes.

4) Symptom: « System stutters, audio cracks during local inference »

Cause racine : Contention de ressources partagées (planification CPU, bande passante mémoire, contention des files GPU) avec des workloads temps réel.
Correctif : Réservez des cœurs, priorisez les threads audio, limitez l’utilisation d’inférence, ou déchargez sur un moteur différent ; évitez d’exécuter une inférence lourde pendant les appels.

5) Symptom: « Model loads are wildly inconsistent across identical machines »

Cause racine : IO en arrière-plan (scans AV/EDR, indexation, sync), versions de firmware/driver différentes, ou niveaux de remplissage du disque différents affectant le comportement SSD.
Correctif : Contrôlez les tâches en arrière-plan, standardisez les versions, surveillez la santé SSD, et gardez suffisamment d’espace libre pour le GC SSD.

6) Symptom: « Quality regressions after ‘performance upgrade’ »

Cause racine : Quantification plus agressive, kernels différents, ou variante de modèle/tokenization modifiée.
Correctif : Traitez la quantification comme un changement produit : test A/B, suites de régression, et bascule « mode qualité ».

7) Symptom: « Battery life tanks when AI features enabled, even idle »

Cause racine : Services modèles en arrière-plan se réveillant fréquemment, boucles de vérification de cache, télémetrie, ou traitement continu de capteurs.
Correctif : Ajoutez un backoff, regroupez le travail, désactivez les mises à jour en arrière-plan sur batterie, et mesurez les réveils et l’IO dans le temps.

8) Symptom: « SSD wear increases faster than expected »

Cause racine : Churn de cache, téléchargements/extractions répétées de modèles, stores d’embeddings sans rétention, logging excessif.
Correctif : Caches adressés par contenu avec déduplication, limites de rétention, moins de réécritures, et nettoyage périodique. Surveillez SMART à l’échelle de la flotte.

Checklists / plan étape par étape

Checklist A: Acheter ou standardiser des « PC IA » pour une entreprise

Définissez les workloads cibles (transcription, résumé, assistance code, amélioration d’image) et s’ils sont interactifs ou batch.
Fixez une politique RAM minimale basée sur les tailles de modèles que vous déploierez réellement, pas sur ce qui rentre dans une diapositive.
Exigez des tests de performance soutenue (runs de 10–20 minutes) sous charge utilisateur réaliste, pas seulement un passage de benchmark.
Validez le comportement stockage : temps de chargement cold, latence IO mixte, et disponibilité des rapports santé SSD.
Exigez une gouvernance de versions : capacité d’épingler et de revenir sur drivers/firmware, et de déployer par anneaux.
Revoyez le modèle de sécurité : où résident modèles, invites/caches/logs, exigences de chiffrement, et comment purger les données lors du offboarding.

Checklist B: Livrer une fonctionnalité d’inférence sur appareil

Rendez la sélection du dispositif explicite et loggez-la : CPU/GPU/NPU, dtype, et raisons de fallback.
Construisez une sonde de capacité au démarrage : ops supportées, disponibilité mémoire, versions driver/runtime.
Mesurez chemins cold et warm : latence du premier token et tokens/sec soutenu, séparément.
Concevez les caches intentionnellement : quoi mettre en cache, où, politique d’éviction, et budget d’écriture.
Prévoyez les échecs : cache corrompu, téléchargements partiels, régressions driver — gérez gracieusement.
Respectez la concurrence : limitez l’inférence, cédez aux tâches temps réel, et comportez-vous correctement sur batterie.

Checklist C: Opérations de flotte pour PC IA (ennuyeux, correct, efficace)

Inventaire : RAM, type de stockage, firmware, versions drivers, présence d’accélérateurs.
Rollouts par anneaux pour mises à jour OS, drivers, et changements runtime d’inférence.
Télémétrie actionnable : dispositif utilisé, tokens/sec, latence premier token, événements OOM, compteurs d’étranglement thermique si disponibles.
Checks santé stockage endpoint : usure SMART, seuils d’espace libre, échantillonnage latence IO.
Runbooks : étapes claires pour « lent », « plantage », « drain batterie », « modèle ne charge pas ».

FAQ

1) Un NPU est-il toujours plus rapide qu’un GPU pour les LLM locaux ?

Non. Les NPUs peuvent être plus efficients en énergie pour des modèles et précisions supportés, mais les GPU gagnent souvent en débit et en maturité des outils. Mesurez votre pipeline exact.

2) Pourquoi les TOPS ne corrèlent pas avec les tokens/sec ?

Les TOPS mesurent le pic mathématique dans des conditions idéales. Les tokens/sec dépendent de la bande passante mémoire, du comportement du cache, de l’efficacité des kernels, de la longueur de séquence, et du throttling. Votre goulet n’est généralement pas le « calcul ».

3) Quelle spécification matérielle prioriser pour un standard « PC IA » en entreprise ?

La capacité RAM et le comportement de puissance soutenue d’abord, puis la latence de stockage sous charge, puis la capacité GPU/NPU. Un accélérateur rapide avec mémoire insuffisante est un générateur de déceptions.

4) Si le modèle tient en RAM, suis-je à l’abri des chutes de performance ?

Plus sûr, pas à l’abri. Vous pouvez toujours rencontrer de la contention de bande passante, du throttling thermique, ou de la contention des files GPU. « Tient en RAM » évite les pires pics de latence dus à la pagination.

5) Devrait-on exécuter les modèles depuis un stockage réseau pour économiser l’espace disque ?

Évitez-le pour l’inférence interactive. La latence réseau et le jitter se répercuteront directement sur l’expérience utilisateur. Si vous devez, pré-stager localement avec vérifications d’intégrité et limites de rétention.

6) L’inférence locale améliore-t-elle automatiquement la confidentialité ?

Elle réduit l’exposition à l’exfiltration réseau, mais augmente l’empreinte de données sur l’endpoint. Les invites, caches et artefacts dérivés nécessitent toujours politique, chiffrement et nettoyage.

7) Pourquoi des portables identiques performent-ils différemment ?

Versions de firmware et drivers, services en arrière-plan, niveau de remplissage du SSD, variance de pâte thermique, et profils d’alimentation. « Même SKU » n’est pas « mêmes conditions d’exécution ».

8) Quelle est la raison la plus courante pour laquelle l’« accélération NPU » n’a pas lieu silencieusement ?

Opérateurs non supportés ou dtypes non supportés, suivis d’une mauvaise configuration runtime. Si votre télémétrie n’enregistre pas les raisons de fallback, vous ne le trouverez pas rapidement.

9) La quantification vaut-elle toujours la peine ?

Pour de nombreux scénarios sur appareil, oui — car elle réduit l’empreinte mémoire et permet les accélérateurs. Mais elle peut nuire à la qualité. Traitez-la comme un compromis produit, pas un réglage par défaut.

10) Quelle est la façon la plus simple de savoir si je suis IO-bound pendant l’inférence ?

Surveillez les fautes de page majeures (pidstat -r) et l’IO wait (iostat/top). Si l’un ou l’autre est élevé pendant la génération en régime permanent, vous n’êtes pas lié par le calcul.

Conclusion : que faire ensuite (et arrêter de faire)

La catégorie PC IA n’est pas fictive. Le battage vise juste la mauvaise couche. Le changement d’architecture n’est pas « il y a un NPU ». Le changement est que les endpoints exécutent désormais des workloads soutenus et gourmands en mémoire qui redonnent de l’importance aux thermiques, à l’IO et à la discipline des drivers.

Étapes pratiques :

Arrêtez d’acheter sur la base des TOPS. Achetez sur la base de la performance soutenue, de la RAM, et de workloads validés.
Instrumentez la sélection du dispositif. Si vous ne pouvez pas prouver l’usage CPU vs GPU vs NPU, vous ne pouvez pas l’exploiter.
Exécutez des benchmarks cold/warm. Le chargement du modèle est l’expérience utilisateur. Traitez-le comme une métrique de première classe.
Mesurez et gérez l’IO. Les services en arrière-plan et le churn de cache vous saboteront silencieusement.
Adoptez des rollouts par anneaux pour drivers/firmware. C’est la différence entre « petite régression » et « incident de flotte ».
Budgetez la mémoire. Si votre feuille de route suppose des modèles locaux plus gros, la RAM n’est pas optionnelle. C’est l’architecture.

Si vous déployez de l’IA sur appareil dans le monde réel, votre travail est de la rendre ennuyeuse. Ennuyeux signifie latence prévisible, performance stable après dix minutes, et une machine qui se comporte encore comme un ordinateur portable. Voilà la vraie fonctionnalité « PC IA ».