2026 change la donne : l’IA locale est de série, mais tout ne s’accélère pas pareil

En 2026, les systèmes d’exploitation majeurs intègrent des fonctions d’IA sur l’appareil, et de nombreuses applis reposent sur une accélération hétérogène. Sous Windows 11, des fonctions comme Recall et Windows Studio Effects s’appuient sur la NPU pour décharger la CPU et le GPU, avec des seuils de performance minimaux bien définis. Sous macOS, Apple Silicon regroupe CPU, GPU, un Neural Engine et une mémoire unifiée qui favorise les charges mixtes. Sous Linux, la maturité des parcours CUDA/ROCm et Vulkan continue de rythmer le travail des créateurs et développeurs.

Conséquence pratique : il n’existe pas de « spécification IA » unique. Un portable très rapide en montage vidéo avec effets caméra temps réel n’est pas forcément le meilleur pour inférer un grand LLM ou générer des images par lots. Ce guide détaille, avec des critères vérifiables, le rôle de chaque accélérateur, la mémoire réellement requise par un 7B/13B/70B selon la quantification, et comment traduire cela en décisions d’achat réalistes pour les 3–6 prochains mois. Il clarifie aussi la signification des métriques courantes (TOPS, tokens/s, latences) et la façon de les relier à vos flux sans tomber dans des comparaisons peu utiles entre architectures.

CPU, GPU et NPU : qui fait quoi, et avec quelle API

- CPU : orchestre, fait le pré/post‑traitement, et suffit seule pour de petits modèles ou le tooling (tokenisation, E/S). Quand la bibliothèque n’a pas de backend accéléré, la CPU sert de filet universel. Les métriques utiles sont la performance flottante par thread et la présence d’instructions vectorielles ; au‑delà de 8–10 threads, l’échelle perd en efficacité pour les LLM à cause des goulots mémoire. La latence d’accès à la mémoire et la bande passante soutenue comptent aussi, car le prefill et la mise à jour du cache KV y sont sensibles même quand une partie du calcul tourne sur un accélérateur.

- GPU : domine sur les grands tenseurs et les lots ; c’est la voie principale pour les LLM moyens et la génération d’images. Sous Windows, la voie « agnostique » passe par Windows ML avec ONNX Runtime et sa politique de sélection de fournisseurs d’exécution ; chez NVIDIA, CUDA reste la voie la plus mûre ; chez AMD, ROCm permet les kernels HIP. Vulkan et WebGPU poussent la portabilité du calcul, surtout dans les applis et navigateurs modernes. En pratique, les GPU offrent un meilleur débit quand on peut regrouper les requêtes (batching) ou quand l’appli enchaîne plusieurs étapes tensorielles avec des opérateurs bien pris en charge par le backend choisi.

- NPU : accélère l’inférence à faible latence et faible consommation pour des modèles optimisés (vision, effets caméra, assistants du SE, certaines parties de LLM compacts). Sous Windows, certaines expériences système exigent un seuil de ~40 TOPS sur la NPU. Sous macOS, le Neural Engine coexiste avec GPU/Metal, et la conversion vers Core ML décide ce qui passe sur l’ANE ou sur le GPU. La clé avec la NPU est que le chemin d’exécution soit prévu pour l’exploiter ; sinon, la charge retombe sur le GPU ou la CPU, même si l’appareil a une NPU.

Modèles et mémoire : 7B/13B/70B en fp16, int8 et 4 bits, et pourquoi la RAM/VRAM prime

La mémoire requise se décompose en deux pièces : les poids du modèle et le cache KV. Règle rapide : poids ≈ octets_par_paramètre×nombre_de_paramètres ; fp16/bf16 ≈ 2 o/param, int8 ≈ 1 o/param, et 4 bits ≈ 0,5 o/param. Ainsi, un 7B en fp16 tourne autour de ~14 Go rien qu’en poids ; le même 7B quantifié en 4 bits tombe à ~3–4 Go, avec une légère perte de qualité. Le cache KV peut ajouter plusieurs Go avec des contextes longs ou une forte concurrence, et il sature souvent la VRAM/RAM avant les poids. Le cache KV croît avec la longueur de contexte effective et la profondeur du modèle ; dimensionnez donc selon votre usage typique (chaînes d’outils à contexte étendu vs prompts courts).

En pratique sur portable, un 7B quantifié tient et reste fluide avec 8–16 Go disponibles pour le processus ; un 13B réclame 16–24 Go pour être à l’aise ; un 70B en 4 bits atteint déjà 40 Go rien qu’en poids et demande des systèmes avec beaucoup de mémoire unifiée ou un débordement en RAM. Si votre GPU a peu de VRAM, déplacer le cache KV vers la RAM système ou scinder le modèle entre GPU et CPU/NPU peut maintenir la session, mais augmente la latence. Pensez aussi au coût du chargeur et des bibliothèques du runtime, qui ajoutent quelques centaines de Mo et peuvent faire la différence quand la VRAM est comptée.

NPU en 2026 : comment lire les TOPS et quand le GPU garde l’avantage

Les TOPS mesurent des opérations entières par seconde (généralement int8/int4) selon des hypothèses propres au constructeur. Ils servent à filtrer la compatibilité minimale du système et à estimer des classes de tâches temps réel (p. ex. effets caméra, traduction live, petits réseaux de vision), mais ne remplacent pas des métriques métier comme les tokens/s ou la latence P95 sur votre modèle cible. Sous Windows, des fonctions système comme Recall et le niveau supérieur de Studio Effects imposent des minima autour de 40 TOPS sur la NPU, en plus d’exigences de mémoire et de sécurité du dispositif. Entre machines, lisez les TOPS comme un seuil de capacité, non comme une échelle linéaire de performance entre marques ou générations.

Pour des LLM moyens ou la diffusion par lots, le GPU reste devant en débit et en couverture d’opérateurs. La NPU gagne quand l’appli est adaptée (via Windows ML/ONNX Runtime avec une politique « prefer NPU » ou via Core ML pour des couches compatibles) et quand l’autonomie prime : on observe souvent des économies d’énergie notables face au GPU sur des tâches continues à faible puissance, avec toutefois des limites côté opérateurs et taille de modèle. En scénarios mixtes, une stratégie efficace consiste à laisser le prefill lourd au GPU et à déporter vers la NPU la vision ou le post‑processing, afin de contenir la consommation sans trop dégrader la latence perçue.

Windows, macOS et Linux : état réel des toolchains et de la compatibilité

- Windows (ARM et x86) : Windows ML fournit une couche uniforme sur ONNX Runtime et permet de choisir un fournisseur d’exécution (CPU, NPU, GPU via DirectML, CUDA, etc.) ou de laisser une politique trancher entre « performance maximale » et « efficacité maximale ». DirectML s’appuie sur toute GPU compatible DirectX 12, utile pour du matériel varié et des déploiements non liés à un seul vendeur. Pour les applis déjà sous ONNX Runtime, adopter une politique comme MAX_EFFICIENCY ou PREFER_NPU est un moyen pratique d’équilibrer performance et autonomie sans réécrire les opérateurs.

- macOS (Apple Silicon) : le flux recommandé est la conversion vers Core ML (avec coremltools), puis Metal/ANE exécute selon compatibilité. La mémoire unifiée simplifie les charges mixtes (modèle sur GPU, prétraitement sur CPU/ANE) et, sur la génération M5, on trouve jusqu’à 128 Go unifiés avec davantage de bande passante, utile pour les contextes longs des LLM et les lots en création de contenu. Dans des projets mêlant vision, audio et texte, cette unification réduit les copies entre dispositifs et peut stabiliser les latences en charge.

- Linux : CUDA reste la voie la plus fluide chez NVIDIA ; ROCm active les AMD récents avec une matrice de compatibilité à vérifier avant achat. Pour des solutions portables et des environnements sans CUDA/ROCm, Vulkan propose du calcul général, et certains runtimes expérimentent des parcours via SPIR‑V. Dans l’open‑source, des projets comme llama.cpp exposent plusieurs backends (CPU/Metal/CUDA/ROCm/Vulkan) avec une maturité variable. Avant de choisir la plateforme, validez la prise en charge des opérateurs critiques de votre modèle et la compatibilité versions (drivers, kernel, bibliothèques).

Stockage, E/S et ports : pourquoi 1–2 To NVMe n’est pas un caprice

Les fichiers de modèles occupent un espace tangible même quantifiés : un 7B pèse ~3–4 Go ; un 13B, ~7–8 Go ; un 70B, ~35–40 Go en 4 bits. Si vous alternez entre familles (Llama, Mistral, embeddings, TTS, VAD) et gardez plusieurs quantifications/versions, prévoir 1–2 To NVMe évite un ménage perpétuel. La lecture séquentielle de gros modèles accélère le démarrage de session et la reprise après veille ; disposer d’espace libre aide aussi le paging et les caches du framework. Conserver un volume NVMe unique et rapide simplifie la gestion des checkpoints et réduit la tentation de déplacer des modèles vers des supports plus lents qui pénalisent ensuite le temps jusqu’au premier token.

Côté connectivité, Thunderbolt 5 et USB4 v2.0 relèvent les plafonds de bande passante pour les SSD externes ou les eGPU (si compatibles), ainsi que pour les écrans 8K/hauts taux. Pour les charges IA, l’intérêt concret est de brancher un stockage externe rapide en partageant le bus sans étrangler le GPU interne. Si vous travaillez avec châssis externes ou docks, vérifiez la certification et la version pour éviter les goulots. Et si votre flux impose de déplacer des modèles entre machines, pensez à un SSD NVMe externe en boîtier TB5/USB4 v2.0 : les temps de copie et de chargement s’améliorent nettement par rapport à l’USB hérité lorsque les projets pèsent plusieurs gigaoctets.

Mesurer la performance utile et la convertir en profils d’achat

Les métriques qui comptent : 1) tokens/s sur votre modèle et quantification cibles avec un contexte typique ; 2) latence du premier token (prefill) et en décodage ; 3) débit par lot en génération d’image/audio. Évitez de comparer des TOPS bruts ou des FLOPS théoriques sans lien avec votre pipeline (tokeniseur, cache KV, streaming). Dans la mesure du possible, utilisez des bancs reproductibles et ouverts du runtime que vous comptez employer. Complétez par des mesures d’énergie si l’autonomie est prioritaire : l’écart NPU/GPU sur des charges continues à faible puissance peut être déterminant même si le temps total est similaire.

Profils minimaux indicatifs si vous achetez en T4 2026–T1 2027 : 1) Chat local 7B (4 bits), multitâche léger : CPU moderne 8 cœurs, GPU intégré ou petite dGPU, 16 Go de RAM et NPU si vous dépendez de fonctions du SE ; 2) Assistant de code et transcription accélérés : dGPU avec ≥ 8–12 Go de VRAM ou Apple Silicon avec ≥ 24–32 Go unifiés ; 3) Diffusion d’images par lots et LLM 13B confortable : dGPU ≥ 16 Go de VRAM ou ≥ 48–64 Go de mémoire unifiée ; 4) Laboratoire local avec 70B 4 bits : systèmes ≥ 64–96 Go effectifs (unifiés ou RAM avec débordement), en acceptant des compromis de latence. En règle générale, priorisez la mémoire suffisante plutôt que de petites différences de TOPS/FLOPS, et validez le bon fonctionnement des APIs prévues (Windows ML/DirectML, Core ML, CUDA/ROCm, Vulkan/WebGPU) avec votre pile logicielle.