La nouvelle pile d’exécution de l’IA embarquée : de ML Drift à TensorRT Edge-LLM

L’IA embarquée ne se résume plus à une affaire de puces. Le moteur d’exécution partagé qui charge, accélère et met à jour les modèles devient la véritable surface de produit que livrent les développeurs.

Pendant l’essentiel des années 2020, les discussions sur l’IA embarquée commençaient par des tableaux de TOPS. Ces chiffres comptent toujours (voir notre guide de l’IA embarquée et des NPU), mais la fin d’octobre 2026 a mis en lumière un point plus discret : le choix du runtime d’IA embarquée, c’est-à-dire de l’environnement d’exécution des modèles, détermine désormais si un modèle est portable, s’il peut être mis à jour et s’il est assez rapide pour donner le sentiment d’un traitement local.

Trois annonces se sont succédé en trois semaines. L’équipe Google AI Edge a publié en open source ML Drift, son moteur de calcul GPU de nouvelle génération pour l’appareil (8 octobre 2026). Cette même brique a ensuite été intégrée comme accélération GPU dans LiteRT dans les services Google Play, Google revendiquant une inférence GPU environ 1,4 fois plus rapide qu’avec l’ancien délégué GPU et des applications allégées d’environ 8 Mo lorsque le runtime est partagé plutôt qu’intégré à chaque application (28 octobre 2026). NVIDIA a suivi avec une filière de développement pour TensorRT Edge-LLM, un runtime d’inférence léger écrit en C++ qui va du prototypage sur DGX Spark au déploiement sur Jetson Thor, DRIVE AGX Thor et IGX Thor (30 octobre 2026).

Cet article s’en tient à l’angle du runtime : ce qu’est une pile d’inférence sur l’appareil, pourquoi la fragmentation a imposé la réécriture des délégués GPU, ce que le modèle des services Play de LiteRT change à la distribution des applications Android et comment TensorRT Edge-LLM structure les flux de travail des LLM embarqués. Il ne s’agit pas d’un catalogue de puces.

Ce que fait réellement un runtime d’IA embarquée

Un runtime s’intercale entre un fichier de modèle figé et le silicium. Concrètement, il assume cinq fonctions :

1. Charger et valider un graphe de modèle (par exemple un fichier .tflite, des moteurs dérivés d’ONNX ou des caches HEF ou de moteurs propres à un fabricant).
2. Répartir le travail entre le CPU, le GPU et, lorsqu’ils sont disponibles, le NPU ou d’autres accélérateurs, avec des solutions de repli judicieuses.
3. Traduire les opérateurs en noyaux de calcul pour OpenCL, OpenGL ES, Metal, WebGPU, CUDA et TensorRT, ou pour les NPU des fabricants.
4. Gérer la mémoire : tampons de tenseurs, caches clé-valeur (KV) pour le décodage génératif et empreinte maximale lorsque plusieurs applications tournent simultanément.
5. Servir le modèle au code applicatif, par des API natives ou, de plus en plus, par une interface HTTP locale compatible avec celle d’OpenAI pour le prototypage d’agents.

Lorsque l’une de ces couches est défaillante, l’utilisateur le perçoit sous forme d’images perdues par l’appareil photo, de saccades au démarrage, ou d’une « IA locale » qui continue d’interroger un serveur distant parce que le traitement sur l’appareil n’a jamais été jugé fiable.

ML Drift : un moteur GPU ouvert pour un parc d’appareils fragmenté

L’annonce de Google du 8 octobre 2026 présente ML Drift comme un moteur de calcul GPU multiplateforme et performant, conçu spécifiquement pour l’inférence IA et ML sur l’appareil et publié sous licence Apache 2.0. Google le positionne à la fois comme le cœur de l’accélération GPU de LiteRT et comme une bibliothèque autonome destinée aux moteurs graphiques et aux runtimes d’inférence sur mesure.

Pourquoi l’ancien délégué GPU ne suffisait plus

Contrairement à l’inférence en centre de données, qui s’exécute sur des grappes homogènes, les GPU des appareils forment une véritable ménagerie d’architectures, de pilotes et d’API. Google rappelle que le délégué GPU de TensorFlow Lite a posé les bases de l’accélération, mais que les charges actuelles, de la vision et de l’audio en temps réel jusqu’aux modèles génératifs à grand nombre de paramètres, créent des goulets d’étranglement de calcul et de mémoire pour lesquels les anciens runtimes n’avaient pas été conçus.

D’après le billet de Google, les réponses structurelles de ML Drift sont les suivantes :

• La virtualisation des tenseurs : la disposition logique d’un tenseur est découplée des objets GPU physiques, ce qui permet d’unifier les shaders pour OpenGL ES, OpenCL, Metal et WebGPU au lieu de maintenir des bases de code distinctes pour chaque interface.
• Des opérations personnalisées extensibles : des API d’enregistrement donnant accès au langage de shading de bas niveau, y compris des outils destinés aux agents de programmation qui rédigent des shaders sur mesure.
• La prise en charge des tenseurs à cinq dimensions : elle lève une limite stricte de l’ancien délégué GPU de TFLite, centré sur quatre dimensions, pour les modèles spatio-temporels et volumétriques.
• Des noyaux LLM adaptés à chaque phase : la disposition des données et les noyaux changent entre le préremplissage, limité par le calcul, et le décodage, limité par la mémoire, avec notamment une disposition du cache KV alignée sur la convolution et une quantification des activations au sein du noyau pendant le décodage.

Google indique également que, dans ses tests sur Gemma, ML Drift présente une surconsommation de mémoire inférieure de 12 % au maximum à celle d’autres frameworks. C’est l’affirmation de Google, mais elle compte : un débit maximal de jetons par seconde ne sert à rien si le processus ne peut pas cohabiter avec la chaîne de traitement de l’appareil photo.

Des preuves en production (toujours selon Google)

Google affirme que ML Drift fonctionne déjà en production, chaque jour, sur des millions d’appareils, au sein de produits comme Chrome, YouTube Shorts, Photos et Meet. Le même billet rapporte les résultats suivants, communiqués par les équipes produit :

• YouTube Shorts : une réduction de la latence moyenne par image pouvant atteindre 40 % pour les effets fondés sur la segmentation, sur Android et iOS, après la migration vers ML Drift.
• Google Photos : un gain pouvant atteindre 2 secondes par rapport à l’ancien délégué GPU sur les traitements de photographie computationnelle et de segmentation (selon la formulation de Google).
• Fonctions mobiles d’Adobe Lightroom et Photoshop : des performances sur l’appareil jusqu’à 30 % supérieures pour certaines fonctions de retouche nommément citées, après le passage à ML Drift (selon Google).
• Snap : une amélioration de 30 % de la latence des modèles qui animent les effets de visage et de style des lentilles Snapchat, grâce à l’accélérateur GPU ML Drift de LiteRT (selon Google).

Il faut y voir des écarts communiqués par l’éditeur et ses partenaires, non des résultats de laboratoires indépendants. La tendance n’en est pas moins nette : c’est le runtime, et non une nouvelle puce, qui a permis ces gains.

Avec le lancement de ML Drift, Google annonce que l’ancien délégué GPU de TFLite ne recevra plus de nouvelles fonctionnalités et encourage la migration vers l’accélérateur GPU ML Drift de LiteRT, rétrocompatible avec les modèles existants.

LiteRT dans les services Google Play : livrer le modèle, partager le runtime

Si ML Drift est le moteur, LiteRT dans les services Google Play constitue la stratégie de distribution des modèles personnalisés sur Android. Le billet de Google du 28 octobre 2026 le présente comme le runtime d’inférence sur l’appareil d’Android pour les modèles personnalisés, qui « traite plus de mille milliards d’inférences par jour sur des milliards d’appareils », et qualifie cette mise à jour de plus importante à ce jour : une inférence GPU animée par ML Drift, via l’API CompiledModel, successeur moderne de l’ancienne API Interpreter de LiteRT.

Les principales affirmations de Google (à attribuer avec soin)

• L’inférence GPU, animée par ML Drift, est environ 1,4 fois plus rapide qu’avec l’ancien délégué GPU de TensorFlow Lite.
• Selon les tests de Google, les applications passées à LiteRT dans les services Google Play sont allégées d’environ 8 Mo, car le runtime, accélérateur GPU compris, est livré une seule fois avec les services Play au lieu d’être intégré à chaque APK.
• Google relève que plus de 100 000 applications Android embarquent encore leur propre copie de LiteRT ou de TensorFlow Lite : les économies permises par le runtime partagé se cumulent donc à mesure que les applications migrent.

Ces chiffres sont des affirmations de Google, issues de ses propres tests et de sa lecture de la télémétrie, et non des mesures réalisées par des tiers.

Pourquoi le mode de distribution compte

Intégrer un runtime GPU dans chaque application duplique des mégaoctets et suspend les correctifs de sécurité et de performance au calendrier de publication de chaque développeur. La distribution par les services Play apporte, selon Google, les avantages suivants :

• des téléchargements plus légers ainsi qu’un stockage et une mémoire partagés ;
• des mises à jour automatiques via les déploiements échelonnés des services Play ;
• une couverture élargie : les téléphones jusqu’à Android 7 (API 24), ainsi que Wear OS 4 et versions ultérieures et Android Automotive OS (à partir d’Android 11), selon Google ;
• la réutilisation de l’infrastructure qui fait déjà fonctionner à grande échelle les API Vision et Text de ML Kit.

CompiledModel se présente comme un flux de travail unique pour l’accélération CPU et GPU (OpenCL lorsqu’il est disponible, OpenGL à défaut, avec repli sur le CPU), qui conserve le format de modèle .tflite familier. Google prévient aussi que les API de l’ancien délégué GPU et des délégués personnalisés sont dépréciées au profit de l’accélération GPU de CompiledModel et des API de plug-in et de répartition associées, et que NNAPI sera supprimé à partir de 2027. C’est un signal de planification pour toute équipe qui s’appuie encore sur des chaînes héritées de l’ère Interpreter. Quant à la prise en charge des NPU dans les services Play, Google indique qu’elle « fait l’objet de travaux actifs ».

TensorRT Edge-LLM : un même framework, du bureau à l’appareil

Les délégués GPU mobiles ne représentent que la moitié du sujet. L’IA physique et les agents intégrés aux habitacles ou aux robots exigent de servir des modèles de la classe des LLM sous de fortes contraintes de mémoire, de consommation et de latence, souvent sur la gamme embarquée de NVIDIA plutôt que sur une puce de smartphone.

Le blog technique de NVIDIA du 30 octobre 2026 présente TensorRT Edge-LLM comme un runtime d’inférence léger en C++ pour les charges embarquées, qui applique le même framework d’inférence au développement sur DGX Spark (y compris dans une configuration à 64 Go) et au déploiement sur des plateformes telles que Jetson Thor, DRIVE AGX Thor et IGX Thor.

Un outil de développeur, non une brochure de silicium

Le billet met l’accent sur l’opérationnel :

• installer tensorrt-edgellm et utiliser l’interface en ligne de commande trtedge pour télécharger un modèle et construire des moteurs TensorRT optimisés ;
• dialoguer en local avec des modèles comme NVIDIA Nemotron-3.5 Lightning ;
• servir le modèle par une API locale compatible avec celle d’OpenAI pour le prototypage d’applications ;
• activer, si on le souhaite, le décodage spéculatif DSpark à l’aide d’un modèle de brouillon.

Cette promesse de « quelques commandes » est le produit lui-même : réduire l’écart entre un point de contrôle Hugging Face et un moteur capable de fonctionner derrière un agent d’habitacle ou d’usine.

Les chiffres publiés par NVIDIA sur Spark (mesures de NVIDIA)

Sur un DGX Spark de 64 Go, NVIDIA publie les résultats de TensorRT Edge-LLM pour Nemotron-3.5 Lightning (NVFP4, raisonnement activé, taille de lot de un, une requête en flux à la fois, sortie limitée à 128 jetons). La vitesse moyenne de génération sur les requêtes HumanEval passe de 73,4 jetons par seconde sans DSpark à 126,9 jetons par seconde avec DSpark (trois jetons de brouillon), tandis que la consommation maximale de mémoire système pendant l’inférence avec DSpark atteint 27,9 Go, système d’exploitation compris, d’après le tableau et les notes de NVIDIA. Les délais médians d’obtention du premier jeton (TTFT) figurant dans ce même tableau (environ 98 ms sur HumanEval, avec ou sans DSpark) sont également communiqués par NVIDIA dans cette configuration.

L’enjeu, pour cet article, est architectural : Edge-LLM est un runtime d’IA embarquée qui cherche à conserver le même chemin optimisé, du poste de travail du développeur jusqu’aux cibles de déploiement de la classe Thor, au lieu d’inventer une pile de démonstration mobile sans lendemain.

Comment les briques s’articulent (et où elles divergent)

Ces offres sont plus complémentaires que concurrentes. Un effet d’appareil photo sur smartphone appelle LiteRT et ML Drift. Le prototype d’un agent pour robot ou véhicule peut nécessiter TensorRT Edge-LLM sur Spark avant de figer un moteur embarqué. Les équipes qui traitent « l’embarqué » comme une catégorie unique passent à côté de cette distinction.

Liste de contrôle pratique pour les équipes

1. Cesser d’intégrer par défaut des runtimes en double. Sur Android, avec des modèles .tflite personnalisés, il convient d’évaluer LiteRT dans les services Play : le gain d’environ 8 Mo revendiqué par Google tient précisément au fait de ne pas embarquer le runtime.
2. Planifier la migration d’Interpreter vers CompiledModel. Les calendriers de dépréciation (y compris la suppression de NNAPI à partir de 2027, selon Google) sont des échéances, non des effets d’annonce.
3. Profiler séparément le préremplissage et le décodage pour les LLM locaux. La conception par phase de ML Drift comme les réglages de décodage spéculatif d’Edge-LLM supposent de savoir quelle phase domine.
4. Considérer les gains des partenaires comme indicatifs. Les exemples de 30 à 40 % cités par Google et le tableau de débit sur Spark de NVIDIA sont utiles, mais ce sont explicitement leurs mesures, réalisées dans leurs conditions.
5. Garder une culture du silicium, mais contractualiser sur les runtimes. Les API, les caches de moteurs et les canaux de mise à jour survivent à une génération de NPU : c’est une raison supplémentaire pour laquelle le décryptage des NPU de notre guide de l’IA embarquée et des NPU complète cet article sur les runtimes plutôt qu’il ne le remplace.

En résumé

Octobre 2026 n’a pas inventé l’inférence sur l’appareil, mais il a rendu le runtime d’IA embarquée impossible à ignorer. ML Drift a ouvert le code d’un moteur GPU conçu pour les modèles génératifs et classiques exécutés sur l’appareil, compatible avec OpenGL ES, OpenCL, Metal et WebGPU. LiteRT a fait entrer ce moteur dans une voie de distribution partagée sur Android, Google revendiquant une accélération GPU d’environ 1,4 fois par rapport à l’ancien délégué et des applications allégées d’environ 8 Mo lorsque le runtime réside dans les services Play. TensorRT Edge-LLM a illustré le versant embarqué de la même idée : un chemin unique en C++ et en ligne de commande, du prototypage sur Spark au déploiement sur la classe Thor, NVIDIA publiant des chiffres de débit concrets sur Spark avec DSpark.

Les puces fixent toujours le plafond. Les runtimes déterminent si on l’atteint un jour, et si l’on peut relever le plancher sans attendre un nouveau téléphone, une nouvelle voiture ou un nouveau robot.

À lire aussi

• L’IA embarquée en 2026 : NPU, modèles locaux et ce qui exige encore le cloud
• IA toujours active : quand l’inférence doit tenir sur une pile bouton
• IA hors ligne : quand robots et véhicules doivent penser sans le cloud

Images : illustrations originales créées pour AndBeyond.Tech ; aucun logo ni aucune personne réelle n’y figurent.