En bref

Depuis 2024, les smartphones haut de gamme embarquent des puces capables de faire tourner un petit modèle de langage localement, sans passer par le cloud. Le Galaxy S25 traduit des appels en direct sur l’appareil. Apple Intelligence résume des messages sans envoyer quoi que ce soit à un serveur. C’est de l’inférence embarquée — ou edge inference. Ce n’est pas une promesse. C’est déjà en production, sur des centaines de millions d’appareils.

Mais les contraintes sont réelles. Mémoire limitée, batterie, chaleur, puissance de calcul réduite par rapport à un datacenter : chaque compromis se paie quelque part. Cet article détaille ce qui se passe concrètement à l’intérieur.

La puce IA de votre téléphone : qu’est-ce que c’est ?

Tout smartphone récent contient plusieurs types de processeurs. Le CPU gère les tâches générales. Le GPU s’occupe des graphismes. Et depuis quelques années, un troisième composant est apparu : le NPU (Neural Processing Unit), conçu spécifiquement pour les calculs matriciels que nécessite l’inférence de réseaux de neurones.

Les NPUs ne sont pas nés avec les LLMs. Apple en intègre dans ses iPhone depuis l’A11 Bionic en 2017. Google en met un dans ses Pixel via la puce Tensor. Qualcomm a son Hexagon dans les Snapdragon. MediaTek suit sur les appareils milieu de gamme.

Ce qui a changé en 2024-2025, c’est leur puissance. Le NPU Hexagon de Qualcomm affiche des gains annoncés de ×3 sur l’inférence IA par rapport à la génération précédente. L’Apple Neural Engine sur les puces M-series domine les benchmarks de performance par watt. Ces puces peuvent maintenant faire tourner, localement, des modèles qui auraient nécessité un serveur il y a trois ans.

Mais “faire tourner” ne veut pas dire “faire tourner n’importe quoi”.

La mémoire : la contrainte structurante

Un LLM, c’est essentiellement une collection de nombres — des milliards de paramètres. GPT-4 ou Llama 3 70B pèsent des dizaines à des centaines de gigaoctets en précision complète (FP32). Un smartphone haut de gamme dispose de 8 à 12 Go de RAM partagée entre le système, les applications et le modèle.

Pour rentrer dans cette enveloppe, les modèles embarqués doivent être quantifiés : au lieu de stocker chaque paramètre sur 32 bits ou 16 bits, on le compresse sur 8 bits (INT8) ou 4 bits (INT4). Une quantification INT4 réduit l’empreinte mémoire de 75 % par rapport au FP16. Un modèle de 7 milliards de paramètres qui pesait 14 Go passe à moins de 4 Go.

La perte de qualité est généralement limitée pour INT4 et INT8. Elle devient significative en dessous : INT2 et INT3 permettent de faire tenir des modèles de 20 milliards de paramètres dans 8 Go, mais la dégradation est documentée — et un risque additionnel est identifié dans la littérature : la compression agressive peut détériorer les filtres de modération et augmenter la probabilité d’outputs problématiques.

Il n’existe pas encore de benchmark standardisé pour mesurer cette dégradation du point de vue de l’utilisateur réel, plutôt que des benchmarks académiques. C’est un angle mort du domaine.

Les modèles compacts : quels LLMs pour l’edge ?

Plusieurs modèles sont conçus ou optimisés pour les déploiements embarqués :

Llama 3.2 de Meta existe en version 1B et 3B paramètres. Le modèle 1B tient sur des appareils bas de gamme. Le 3B surpasse des modèles plus lourds (Gemma 2 2.6B, Phi 3.5-mini) sur l’instruction-following et l’utilisation d’outils — ce qui en fait la référence pratique pour les déploiements edge en 2025.

Phi-4 mini de Microsoft (3,8 milliards de paramètres) atteint des performances comparables à des modèles de 7 à 9 milliards sur les tâches de raisonnement, avec une couverture de plus de 20 langues. Son avantage : polyvalence + légèreté.

Gemma 3n de Google est architecturalement pensé pour le mobile. Il intègre des encodeurs vision et audio optimisés pour le temps réel, avec des variantes E2B (2 milliards de paramètres effectifs) et E4B (4 milliards).

SmolLM2 de HuggingFace descend jusqu’à 135 millions de paramètres — le segment ultra-léger, adapté aux objets connectés et aux microcontrôleurs.

Une tendance s’affirme en 2026 : les modèles multimodaux natifs pour l’edge, capables de traiter texte, image et audio dans un même modèle compact, sans avoir besoin d’orchestrer trois composants séparés.

Les frameworks : un écosystème fragmenté

Faire tourner un modèle sur un NPU ne s’improvise pas. Il faut un runtime — une couche logicielle qui traduit les opérations du modèle en instructions optimisées pour la puce cible. Plusieurs frameworks coexistent, sans interopérabilité native entre eux.

ExecuTorch (Meta, octobre 2025) est le runtime PyTorch officiel pour l’edge. Il supporte plus de 12 backends hardware — Apple, Qualcomm, Arm, MediaTek, Vulkan — avec une empreinte de base de 50 kilooctets. Plus de 80 % des LLMs edge populaires sur HuggingFace sont supportés.

MLX (Apple) offre les meilleures performances brutes sur Apple Silicon : environ 230 tokens par seconde sur M2 Ultra dans une étude comparative (arXiv 2511.05502). Limitation : exclusif macOS/iOS.

MLC-LLM atteint environ 190 tokens par seconde sur M2 Ultra avec un temps de premier token (TTFT) plus faible que MLX, au prix d’une consommation mémoire plus élevée.

llama.cpp est le moteur de référence de l’écosystème ouvert. Écrit en C++, léger, optimisé CPU, avec une empreinte mémoire minimale. Moins performant pour le prefill GPU mobile, mais porté sur presque tout.

Core ML (Apple), ONNX Runtime (Microsoft), LiteRT (Google, ex-TensorFlow Lite) complètent le tableau. Cinq runtimes majeurs, peu d’interopérabilité. Un modèle optimisé pour Core ML peut nécessiter une re-optimisation significative pour tourner sur ONNX Runtime. C’est un frein réel pour les développeurs qui veulent déployer sur plusieurs plateformes.

Ce qui se passe pendant l’inférence

Quand le modèle génère du texte, il produit un token à la fois. Chaque token requiert de lire l’ensemble des paramètres du modèle et de calculer des vecteurs d’attention sur le contexte déjà produit. Ce contexte — le KV-cache (Key-Value cache) — grossit à chaque token généré et consomme de la mémoire à mesure que la conversation s’allonge.

C’est le deuxième goulot d’étranglement après les paramètres du modèle. Pour un contexte de plusieurs milliers de tokens, le KV-cache peut dépasser la mémoire disponible. Des techniques spécialisées existent : quantification du cache (KVTuner atteint 3,25 bits en mixed-precision quasi-lossless sur Llama-3.1-8B), allocation adaptative par couche (DynamicKV : 85 % des performances full-KV avec 1,7 % de la mémoire KV originale). Ces techniques permettent d’étendre la longueur de contexte utilisable sur des appareils à mémoire contrainte.

Le speculative decoding est une autre approche : un modèle léger propose plusieurs tokens à l’avance, un modèle principal vérifie et accepte ou rejette. Les gains peuvent atteindre ×2,8 sur certaines configurations. Mais sur smartphone sans GPU dédié, le bilan n’est pas évident : le speculative decoding augmente le nombre total d’opérations, ce qui peut aggraver la consommation batterie et la chaleur. Le problème reste ouvert pour les déploiements purement on-device.

Le modèle hybride : entre l’appareil et le cloud

Toutes les requêtes ne nécessitent pas la même puissance. Résumer un SMS court : un modèle 1B suffit. Répondre à une question de droit complexe : le modèle local ne sera pas à la hauteur.

Le routage adaptatif — décider dynamiquement si une requête reste on-device ou part dans le cloud — est une piste active en recherche (arXiv 2507.16731). Apple en fait déjà une implémentation partielle avec Private Cloud Compute : les tâches légères restent sur l’appareil, les tâches lourdes partent vers des serveurs Apple avec des garanties de confidentialité spécifiques.

Mais les critères de routage — à quel seuil de complexité basculer ? quelle information envoyer côté cloud sans compromettre la vie privée ? — ne font pas l’objet d’un standard. Chaque acteur implémente sa propre logique.

Ce que l’inférence embarquée ne résout pas

Deux limitations structurelles subsistent.

La fraîcheur des données. Un modèle on-device a une date de coupure. Il ne peut pas se mettre à jour seul. Sur un appareil majoritairement hors ligne, il ne sait pas ce qui s’est passé après sa dernière mise à jour. Le fine-tuning on-device via LoRA existe expérimentalement, mais son déploiement à l’échelle — impact batterie, confidentialité des données d’adaptation — reste non résolu dans la littérature.

La comparaison entre appareils. Il n’existe pas de benchmark cross-hardware standardisé pour les LLMs sur mobile. Les chiffres publiés en tokens par seconde, en TTFT ou en consommation mémoire varient selon les conditions de mesure. Comparer un Snapdragon 8 Elite à un Apple A18 Pro sur une tâche d’inférence LLM n’est pas trivial.

Ce qu’il faut retenir

  • Les smartphones récents ont des puces (NPU) conçues pour l’inférence de réseaux de neurones. Ce n’est pas une option, c’est intégré dans la quasi-totalité des appareils haut de gamme sortis depuis 2024.
  • L’inférence embarquée repose sur des modèles compacts (1B à 4B paramètres) et des techniques de compression (quantification INT4/INT8) pour tenir dans les contraintes mémoire des appareils.
  • Le KV-cache est le second goulot d’étranglement : sa gestion détermine la longueur de contexte utilisable.
  • L’écosystème de frameworks est fragmenté (ExecuTorch, MLX, llama.cpp, Core ML, LiteRT) sans interopérabilité native.
  • Les limites réelles sont la fraîcheur du modèle (pas de mise à jour continue), la dégradation qualité en compression agressive, et l’absence de benchmarks cross-hardware comparables.
  • Le modèle hybride edge-cloud est en développement mais sans standard de routage établi.

Sources

  1. On-Device LLMs in 2026: What Changed, What Matters, What’s Next — Edge AI and Vision Alliance. https://www.edge-ai-vision.com/2026/01/on-device-llms-in-2026-what-changed-what-matters-whats-next/
  2. On-Device LLMs: State of the Union, 2026 — Vikas Chandra, Meta AI Research. https://v-chandra.github.io/on-device-llms/
  3. Production-Grade Local LLM Inference on Apple Silicon: A Comparative Study — arXiv 2511.05502. https://arxiv.org/abs/2511.05502
  4. Efficient Inference for Edge Large Language Models: A Survey — TST/SciOpen. https://www.sciopen.com/article/10.26599/TST.2025.9010166
  5. Deploying LLM Transformer on Edge Computing Devices: A Survey — MDPI AI 7(1):15. https://www.mdpi.com/2673-2688/7/1/15
  6. Unlocking on-device generative AI with an NPU — Qualcomm whitepaper. https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/Unlocking-on-device-generative-AI-with-an-NPU-and-heterogeneous-computing.pdf
  7. Ethos-U and Beyond: How ExecuTorch 1.0 powers AI at the edge — Arm Developer. https://developer.arm.com/community/arm-community-blogs/b/ai-blog/posts/ethos-u-and-beyond-how-executorch-1-0-powers-ai-at-the-edge
  8. KVTuner: Mixed-Precision KV Cache Quantization — ICML 2025. https://icml.cc/virtual/2025/poster/43487
  9. Optimizing LLMs with Post-training Quantization — Edge AI and Vision Alliance. https://www.edge-ai-vision.com/2025/08/optimizing-llms-for-performance-and-accuracy-with-post-training-quantization/
  10. SLED: Speculative LLM Decoding Framework for Edge Serving — arXiv 2506.09397. https://arxiv.org/abs/2506.09397
  11. Collaborative Inference Edge SLMs and Cloud LLMs: Survey — arXiv 2507.16731. https://arxiv.org/html/2507.16731v1
  12. Generative AI at the Edge: Challenges and Opportunities — ACM Queue. https://queue.acm.org/detail.cfm?id=3733702
  13. Best Open-Source Small Language Models 2026 — BentoML. https://www.bentoml.com/blog/the-best-open-source-small-language-models