Intelligence per Watt : ce que le papier Stanford dit vraiment sur l'IA locale (et ce qu'il ne dit pas)
🎙️ Podcast : Écouter
Il y a quelques jours, une équipe de Stanford publiait la quatrième version d'un papier qui mérite une lecture plus lente que ce que j'en ai fait la première fois. Intelligence per Watt: Measuring Intelligence Efficiency of Local AI — signé Jon Saad-Falcon, Avanika Narayan, Christopher Ré et John Hennessy — n'est pas un papier de plus. C'est une tentative de poser une métrique standard pour une question que l'industrie préfère traiter par intuitions: est-ce que l'IA locale est devenue une alternative crédible au cloud?
La réponse courte est oui, mais c'est dans les détails que le papier devient intéressant. Et dans ce qu'il ne mesure pas.
L'IPW comme métrique: élégant sur le papier, bosselé en pratique
L'Intelligence per Watt — task accuracy divisée par la puissance consommée — a une élégance intuitive. Un modèle qui répond correctement en consommant peu d'énergie a un meilleur IPW qu'un modèle qui répond aussi bien mais pompe le double. C'est propre, c'est simple, et ça capture bien le compromis fondamental de l'inférence locale: tu n'as pas accès à 700 watts, tu as une batterie et un ventilateur.
Mais le diable est dans la normalisation. L'IPW est un ratio, et les ratios ont un problème connu: ils peuvent être trompeurs quand les dénominateurs sont très petits. Un modèle minuscule qui répond parfois juste sur quelques watts peut avoir un IPW spectaculaire sans être utile. Les auteurs contournent ça en mesurant accuracy plutôt que performance brute — ce qui est un bon choix — mais ça ne capture pas la latence. Un modèle qui met 30 secondes à répondre mais a un bon IPW n'est pas utilisable dans un contexte interactif. Le papier le reconnaît en mesurant la latence séparément, mais du coup l'IPW seul ne suffit pas comme métrique unifiée. Il faut un panier de métriques, pas une.
Autre limite: l'IPW mesure à un instant T, pas sur une session. Un laptop qui fait de l'inférence par à-coups consomme en idle entre les requêtes — et cette consommation idle, qui peut représenter 50 à 70% de l'énergie totale sur une journée, n'est pas capturée par une métrique qui regarde chaque requête isolément. Les auteurs mesurent en batch size 1, ce qui est correct pour isoler l'efficacité intrinsèque du hardware, mais ne reflète pas le coût réel d'opérer une machine locale.
Le 88.7%: un chiffre robuste mais circonscrit
Le résultat le plus cité est que les modèles locaux (≤20B paramètres) répondent correctement à 88.7% des requêtes. C'est un chiffre frappant, mais il faut regarder ce qui est dedans.
Les auteurs ont constitué un dataset d'un million de requêtes réelles — du chat, du raisonnement, du question-réponse — et mesuré si un modèle local pouvait égaler la performance d'un modèle frontier. Le 88.7% est une moyenne. Par domaine, ça varie. Les auteurs le disent: l'accuracy varie "significativement" selon le domaine. Et c'est du single-turn — une question, une réponse. Pas de multi-tour, pas de RAG, pas de code à contexte long, pas d'agentic workflow.
C'est là que la prudence s'impose. Les usages réels de l'IA générative sont de plus en plus multi-tours et agentiques. Un assistant de code qui doit comprendre tout un repo, un agent qui exécute un plan en plusieurs étapes, une conversation qui dure 20 échanges — ce sont des charges de travail qui demandent du contexte long, de la planification et du raisonnement séquentiel. Le papier n'a pas mesuré ça. Les 88.7% sont vrais pour ce qui a été mesuré, mais ce périmètre ne couvre probablement pas la majorité des usages agentiques émergents.
Ceci dit, la tendance est indiscutable: la couverture locale est passée de 23.2% en 2023 à 71.3% en 2025. C'est un triplement en deux ans. Les progrès architecturaux — MoE, quantification, distillation — rendent les petits modèles plus intelligents plus vite que les grands modèles ne deviennent plus grands. Si la tendance continue, le 88.7% sera rapidement un plancher, pas un plafond.
Les 5.3x: où va vraiment l'efficacité
L'IPW s'est amélioré de 5.3x entre 2023 et 2025. La décomposition est instructive: 3.1x vient des modèles, 1.7x du hardware.
Les modèles progressent plus vite que le silicium. C'est une observation importante dans le débat sur la fin du scaling law: les scaling laws de performance ralentissent peut-être (les gros modèles plafonnent), mais les scaling laws d'efficacité sont en plein régime. DeepSeek V4, Qwen3, Llama 4 — tous montrent qu'on peut atteindre des performances de classe frontier avec un dixième des paramètres si on conçoit l'architecture pour ça. Les modèles MoE, l'attention optimisée, la quantification intelligente: ce sont des multiplicateurs d'efficacité qui n'ont pas fini de donner.
Le 1.7x hardware, lui, raconte l'histoire des NPU, des architectures unifiées (Apple M4, Qualcomm Snapdragon X) et des optimisations mémoire. Mais c'est le plus lent des deux leviers, et de loin.
Le 1.4x gap: pourquoi le local n'est pas encore un data center
En comparant le même modèle (Qwen3-32B) sur un M4 Max et sur un NVIDIA B200, les auteurs trouvent que le local a 1.4x moins d'IPW — il consomme 40% de plus par unité d'intelligence.
Ce gap est présenté comme une marge de progression, et c'est vrai. Mais il faut comprendre d'où il vient. Le B200 est une bête de somme de 700 watts avec un bus mémoire de 1.8 To/s et un écosystème logiciel (CUDA, cuDNN, TensorRT) qui a 15 ans d'optimisation. Le M4 Max est un processeur grand public de 60-90 watts avec MLX, un framework qui a deux ans. Que le gap ne soit que de 1.4x dans ces conditions, c'est presque un exploit pour Apple.
À l'envers, ça veut dire qu'une partie du gap se refermera mécaniquement à mesure que les frameworks locaux maturent. MLX, llama.cpp, la couche Vulkan — toutes ces couches logicielles ont 5-10x de gain potentiel avant d'atteindre le niveau d'optimisation de CUDA. Si même la moitié de ce gain se concrétise, le gap disparaît purement et simplement.
Le scénario oracle: 80% d'économie ou rêve de physicien
Les auteurs calculent qu'un routeur parfait — qui enverrait chaque requête au modèle le plus juste — pourrait réduire la consommation d'énergie de 80.4% et les coûts de 73.8%.
Ces chiffres doivent être lus comme une borne supérieure théorique, pas comme un objectif réaliste. En pratique, le routage lui-même coûte du compute — ou un appel API si c'est fait par un service externe. Et surtout, dans un environnement local, tu n'as pas un data center de modèles à disposition. Tu as ce qui tient sur ta machine. Le scénario oracle suppose que tu peux appeler un petit modèle pour les questions simples et un gros pour les questions complexes, mais sur une machine de capacité fixe, le gros modèle prend de la place mémoire qui pourrait servir au petit.
Ce qui est intéressant, c'est que le scénario n'est pas complètement irréaliste — il décrit ce que font déjà les systèmes de model routing comme ceux qu'explorent Together AI ou Martian. La différence c'est que l'oracle de Stanford est global (tous les modèles disponibles), alors qu'un routeur réel fonctionne avec un budget mémoire contraint.
La vraie question: le TCO, pas l'IPW
Le papier ne parle presque pas d'argent, mais c'est la conversation qu'il alimente directement. Les analyses de Total Cost of Ownership en 2026 commencent à donner des chiffres concrets.
En deçà de 500 000 tokens par jour, le cloud est moins cher, point barre. Entre 1 et 5 millions de tokens par jour, le break-even commence à apparaître — un hybride local-cloud devient rentable. Au-delà de 10 millions de tokens par jour, le local gagne massivement: à 50M tokens par jour, la facture cloud OpenAI tourne autour de 126 000 dollars par an, contre zéro d'API si tu fais tourner sur ton propre hardware (amorti sur 36 mois).
C'est là que le 88.7% du papier Stanford devient un argument commercial. Si un modèle local peut répondre à 9 requêtes sur 10 aussi bien qu'un frontier, et que les 10% restants peuvent être routés vers le cloud en cas de besoin, le coût effectif par token devient imbattable. Une architecture hybride — local pour le gros du volume, cloud pour les cas difficiles — est probablement le modèle dominant de 2027.
Qui gagne à l'IPW?
Si l'IPW devient la métrique standard, ça favorise structurellement certaines approches. Apple est le grand bénéficiaire implicite: sa mémoire unifiée lui permet de faire tourner des modèles que les GPU discrets ne peuvent même pas charger (un Llama 70B quantifié tient dans un M4 Max 128Go, alors qu'il dépasse les 24Go d'un RTX 4090). Et sa consommation de 60-90W système contre 450W pour un GPU seul rend le ratio IPW très favorable.
Le perdant implicite, c'est NVIDIA — non pas que ses puces soient inefficaces (elles sont excellentes en performance brute), mais le ratio IPW les désavantage face à des architectures plus intégrées. La réponse de NVIDIA, c'est les puces à refroidissement passif et les Jetson, mais ce n'est pas encore comparable à l'écosystème Apple en termes de déploiement grand public.
Les gagnants architecturaux sont les modèles qui maximisent l'intelligence par paramètre: architectures MoE, modèles distillés, quantification agressive. DeepSeek, Qwen, Llama 4 — tous ceux qui compressent beaucoup d'intelligence dans peu de paramètres sortent gagnants d'un monde qui regarde l'IPW.
Les questions ouvertes
Le papier laisse plusieurs choses en suspens. La première, c'est l'impact de la mémoire partagée sur les workloads réels. Un M4 Max a 128Go de mémoire unifiée, ce qui est exceptionnel, mais cette mémoire sert aussi au reste du système. Lancer un OS, un navigateur, un IDE et un modèle 70B simultanément, ça crée de la pression mémoire que le benchmark n'a pas mesurée.
La deuxième, c'est le Jevons paradox de l'IA locale. Si rendre l'IA locale gratuite et privée augmente le nombre total de requêtes, la consommation d'énergie globale peut augmenter même si chaque requête individuelle coûte moins. C'est un effet bien documenté en économie de l'énergie, et l'IA n'y échappera probablement pas.
La troisième, c'est la durabilité des tendances d'efficacité. Le 5.3x sur deux ans est impressionnant, mais combien de ces gains sont faciles (low-hanging fruit de la quantification et de l'attention optimisée) et combien viendront de percées plus difficiles? Si les gains d'efficacité ralentissent, la fenêtre pour le local pourrait se refermer avant que le hardware ait rattrapé le software.
Ce que ça change, concrètement
Le papier Stanford n'annonce pas une révolution immédiate. Il fournit le langage pour en parler. L'IPW comme métrique, c'est utile. Le profiling harness open source, c'est plus utile — il permet à n'importe qui de mesurer l'efficacité de sa propre config. Les 88.7% et les 5.3x sont des repères, pas des prophéties.
Le takeaway, c'est que la question du local n'est plus une question de capacité technique. Le local peut. La question est devenue économique, et la réponse penche de plus en plus vers le local pour les usages à volume. Le papier de Stanford donne les outils pour mesurer cette transition. Reste à voir qui les utilisera pour justifier un changement, et qui les utilisera pour le retarder.