LLM et modèles VLA embarqués sur robot 2026 : ce qui tient, ce qui ne tient pas

La pile logicielle d'un robot compte au moins cinq tâches distinctes, et seules deux d'entre elles constituent aujourd'hui un terrain plausible pour un LLM ou un VLA. Traiter « l'IA en robotique » comme un bloc indifférencié est l'erreur de cadrage la plus fréquente dans la couverture de ce domaine — elle conduit à poser la mauvaise question (« peut-il exécuter un LLM ? ») au lieu de la question utile (« laquelle de ces cinq tâches le modèle assure-t-il réellement, et à quelle fréquence ? »).

Les cinq tâches, dans l'ordre du flux de données : perception (transformer les données caméra/lidar/IMU en une représentation structurée du monde), estimation d'état (fusionner ces données dans le temps en une estimation stable de la propre pose du robot et de l'état du monde), planification de tâche (décider *quoi* faire ensuite — « saisir la tasse bleue », « rejoindre le quai de chargement »), planification de mouvement (traduire une tâche en trajectoire réalisable — angles articulaires, chemin, approche de préhension) et contrôle (convertir la trajectoire planifiée en commandes moteur, instant par instant, en rejetant les perturbations).

La perception est le domaine où les VLM et les modèles de vision légers accomplissent déjà un vrai travail — détection d'objets, description de scène, étiquetage sémantique — généralement dans la plage de 5 à 30 Hz qu'un flux caméra produit. La planification de tâche est le domaine où un VLA ou un LLM apporte une vraie valeur ajoutée : traduire un objectif en langage naturel ou visuel en un sous-objectif symbolique qu'un système en aval peut exécuter. Ce sont les deux tâches que cet article considère comme un terrain légitime pour un VLA/LLM.

L'estimation d'état, la planification de mouvement et le contrôle sont d'une nature différente. L'estimation d'état repose généralement sur un filtre de Kalman ou un filtre particulaire — des mathématiques déterministes et bien comprises qu'un réseau de neurones n'améliore pas sur le problème d'estimation central. La planification de mouvement est dominée par des optimiseurs de trajectoire classiques (CHOMP, RRT*, planificateurs basés MPC) précisément parce qu'ils offrent une satisfaction de contraintes vérifiable — une propriété que la sortie d'un modèle de langage n'a pas. Le contrôle est le plus rapide et le moins adapté aux modèles de tous : il exécute une boucle de rétroaction contre l'erreur des capteurs à des fréquences qu'un passage avant de transformeur ne peut approcher.

La contrainte déterminante de ce qu'un robot peut faire avec un VLA est le nombre de décisions par seconde atteignable par le modèle — pas la note de TOPS crête de l'accélérateur. Une fiche technique matérielle annonçant 100 TOPS ne dit rien du nombre de fois par seconde qu'un VLA de 2 à 7 milliards de paramètres peut exécuter un passage avant complet et produire une action utilisable ; ce chiffre dépend conjointement de la taille du modèle, de la quantification, de la taille de lot, du nombre de caméras et de la bande passante mémoire, et il est généralement bien inférieur à ce que suggère le chiffre de TOPS pour une charge à flux unique et faible latence.

Différentes boucles tolèrent des latences très différentes. Une boucle d'équilibre en locomotion sur un robot marcheur ou auto-équilibré a besoin de corrections de l'ordre de la milliseconde — c'est une boucle de contrôle à 100–1 000 Hz, et aucune architecture VLA publiée ne fonctionne à cette fréquence. Une boucle de planification de tâche en manipulation (décider « atteindre la tasse » plutôt que « atteindre le bol ») tolère 100 à 1 000 ms de latence sans dégrader visiblement le comportement — c'est la plage de 1 à 10 Hz dans laquelle un VLA opère réellement. Une boucle de replanification au niveau de la navigation (contourner un obstacle) tolère souvent plusieurs secondes.

C'est pourquoi le débit de sortie du modèle, et non les FLOPs sous-jacents, est le chiffre sur lequel budgétiser. Deux VLA de tailles de paramètres similaires peuvent atteindre des fréquences Hz très différentes selon la part du pipeline (encodeur visuel, décodeur d'action, tokenisation) qui se trouve sur le chemin critique par décision — et selon le nombre de flux caméra alimentant le même passage avant, la plupart des architectures VLA traitant chaque caméra supplémentaire comme du contexte additionnel, pas comme du parallélisme additionnel.

Un modèle dans la boucle de contrôle est un risque de sécurité, pas seulement de performance. Les sorties de réseaux de neurones ne sont pas formellement vérifiables comme le sont les marges de stabilité d'un contrôleur PID ou MPC — rien ne prouve qu'un transformeur ne produira jamais d'action dangereuse pour une distribution d'entrée inédite. C'est la raison fondamentale pour laquelle les arrêts certifiés, les limites de couple et les verrouillages anti-collision restent dans du code de contrôle déterministe dans toutes les piles robotiques de production que nous connaissons, quelle que soit la capacité du modèle de raisonnement : une fonction de sécurité certifiable exige un comportement caractérisable de manière exhaustive, une garantie qu'un grand réseau de neurones ne peut actuellement pas offrir.

Utilisez le calculateur ci-dessous pour estimer quelle fréquence de décision une combinaison donnée de matériel et de nombre de caméras peut réellement atteindre, avant de vous engager sur un modèle ou une carte. Ces estimations sont des approximations techniques pour un budget préliminaire, pas des benchmarks constructeur — validez-les par rapport au modèle et au matériel réels avant de finaliser une conception.

Cinq modèles VLA couvrent l'essentiel du paysage ouvert et semi-ouvert que les équipes de robotique évaluent en 2026, plus un modèle à accès restreint qui mérite d'être suivi pour comprendre où va le domaine. Les nombres de paramètres marqués d'un « ~ » ci-dessous proviennent de sources secondaires plutôt que d'une fiche technique constructeur primaire — considérez-les comme indicatifs, pas exacts.

NVIDIA Isaac GR00T N1 et sa révision N1.5 sont des modèles VLA orientés humanoïdes, publiés ouvertement, à environ ~2,2 Md de paramètres (chiffre issu d'une source secondaire). NVIDIA indique explicitement que GR00T N1.5 tourne sur sa carte Jetson Thor — une cible de déploiement embarqué confirmée par le constructeur, pas déduite.

π0 (pi-zero) de Physical Intelligence est un VLA à correspondance de flux (flow-matching), d'environ ~3 Md de paramètres (source secondaire), publié avec des poids ouverts, construit sur un socle vision-langage de classe PaliGemma (détail issu d'une source secondaire). Il a attiré l'attention pour une génération d'actions fluide et à haute fréquence par rapport aux conceptions VLA antérieures.

OpenVLA, à 7 milliards de paramètres, est la référence académique courante pour la recherche VLA — ouvert, bien documenté, largement utilisé comme point de comparaison. Sa taille en fait le point de référence pour « quelle taille doit avoir un VLA capable », mais ce n'est généralement pas le premier choix pour un budget de latence embarqué serré.

Gemini Robotics On-Device de Google DeepMind a un nombre de paramètres non divulgué et un accès restreint/partenaire — ce n'est pas une option accessible à la plupart des équipes aujourd'hui. Ce qui le rend digne d'intérêt malgré tout : Google DeepMind indique qu'il a été explicitement conçu pour tourner localement sur le robot sans connexion internet. C'est le signal le plus clair d'un grand laboratoire que l'inférence embarquée est désormais une cible de déploiement à part entière, pas une réflexion après-coup greffée sur un système conçu pour le cloud.

SmolVLA est un VLA compact et ouvert d'environ ~450 M de paramètres (source secondaire) — l'option réaliste quand le matériel cible est réellement à faible puissance (un petit accélérateur plutôt qu'une carte de la classe Jetson complète), où l'empreinte mémoire et la latence de passage avant d'un modèle de 2 à 7 milliards ne rentrent tout simplement pas dans le budget.

Octo et RT-2 sont des architectures VLA de générations antérieures, utiles principalement pour situer historiquement comment le domaine est arrivé aux conceptions actuelles de flow-matching et d'action tokenisée — pas une recommandation actuelle pour une décision de déploiement 2026.

Au-delà de la catégorie VLA, NVIDIA indique que les modèles généralistes Llama, Qwen et DeepSeek (LLM), ainsi que Qwen2.5-VL et Llama 3.2 Vision (VLM), tournent sur Jetson Thor. Ils prennent en charge la couche de compréhension du langage et de description de scène dans une pile robotique où un VLA complet est superflu — un robot de service répondant à une question orale, ou un bras de manipulation lisant une étiquette texte, n'a besoin d'aucun modèle à sortie d'action.

ROS 2 est la frontière pratique entre le niveau de raisonnement lent et le niveau de contrôle rapide dans la plupart des piles robotiques de production. Un nœud VLA publie une intention au niveau de la tâche — une pose cible, un sous-objectif, un point de préhension — sous forme de message ROS 2, et un nœud de contrôle classique distinct s'y abonne et l'exécute aux fréquences de la boucle de contrôle. Le VLA ne parle jamais directement aux moteurs ; il parle à un topic, et un nœud déterministe possède tout ce qui se trouve en aval de ce topic.

Sur du matériel NVIDIA (paliers Jetson Orin et Thor), TensorRT et TensorRT-LLM constituent le chemin d'exécution standard pour amener un VLA ou un LLM quantifié à sa fréquence d'inférence atteignable — ils gèrent la fusion de noyaux, la calibration de précision (FP8/INT8/INT4) et l'optimisation spécifique au matériel qu'une boucle d'inférence PyTorch naïve laisse de côté. Sauter cette étape est la raison la plus fréquente pour laquelle un modèle qui « devrait » atteindre une fréquence Hz cible sur le papier ne l'atteint pas en pratique.

Pour des cibles embarquées plus petites qui ne sont pas basées sur NVIDIA — un accélérateur Hailo-10H, ou une carte ARM compacte — ExecuTorch et llama.cpp sont les chemins d'exécution pertinents pour les composants langage/perception. Aucun des deux n'est aujourd'hui un environnement d'exécution VLA prêt à l'emploi ; les équipes visant ces cartes plus petites font plus souvent tourner un VLM compact (pour la perception/description de scène) qu'un VLA complet, la planification de tâche étant soit simplifiée en logique à base de règles, soit exécutée moins fréquemment à une cadence que l'accélérateur plus petit peut soutenir.

Le schéma d'intégration pratique, dans l'ordre : (1) le nœud VLA/VLM tourne de manière asynchrone à sa fréquence Hz atteignable, publiant l'intention vers un topic ROS 2 ; (2) un planificateur classique s'y abonne, convertissant l'intention en trajectoire ; (3) un nœud de contrôle exécute la trajectoire à 100–1 000 Hz, avec sa propre boucle de rétroaction capteur — sans jamais attendre la prochaine sortie du VLA pour agir. Si le nœud VLA bloque ou prend du retard, le nœud de contrôle continue d'exécuter la dernière trajectoire valide ou maintient sa position en sécurité ; il ne bloque pas sur le niveau lent.

Les robots mobiles autonomes (AMR) en entrepôt et les machines agricoles représentent la réalité déployée de l'autonomie robotique aujourd'hui — les humanoïdes attirent la couverture médiatique mais restent la classe de machine la moins déployée traitée dans cet article. Cet écart compte pour quiconque doit décider où investir du temps d'ingénierie : la catégorie robotique la plus gourmande en calcul et la plus discutée est aussi celle qui compte le moins d'unités réellement en production aujourd'hui.

Les humanoïdes constituent la classe la plus gourmande en calcul et la moins déployée : ils embarquent le plus de capteurs, le plus de degrés de liberté, et donc la charge de niveau de raisonnement la plus lourde (flux caméra multiples, planification de tâche pour le corps entier) — c'est précisément pourquoi ils sont la cible principale du silicium embarqué le plus récent et le plus capable (Jetson Thor) et des architectures VLA les plus récentes (GR00T N1.5). Leur volume de déploiement actuel reste faible au regard de l'attention qu'ils reçoivent.

Les robots mobiles autonomes (AMR) — les robots à roues déplaçant l'inventaire en entrepôt — sont déployés commercialement à une échelle significative depuis des années, exécutant des piles classiques de navigation et d'évitement d'obstacles. Ce qui change en 2026, c'est l'ajout d'une couche d'interface langage/vision par-dessus une pile d'autonomie déjà mature : un VLM pour la description de scène ou une couche de planification de tâche légère permettant à un humain de donner une instruction en langage naturel — pas un remplacement complet de la logique de navigation sous-jacente.

Les bras industriels dans des cellules de fabrication fixes se situent entre ces deux extrêmes : la planification de mouvement et le contrôle sont typiquement entièrement classiques depuis des décennies (un bras de soudage ou de préhension-dépose n'a pas besoin d'un VLA pour répéter une trajectoire enseignée), mais les couches de perception — détection de défauts, identification de pièces — utilisent de plus en plus des modèles de vision légers, une position caméra fixe et une tâche contrainte rendant suffisant un modèle plus petit et spécialisé, sans VLA complet.

Les machines agricoles constituent la classe de déploiement la plus souvent négligée dans la couverture de « l'IA en robotique », malgré une autonomie commerciale déployée — direction guidée par GPS, détection d'obstacles sur tracteurs et moissonneuses — à grande échelle depuis des années, bien avant la vague VLA actuelle. Ce qui s'ajoute aujourd'hui suit le même schéma que pour les AMR : une couche d'interface langage/vision (identification de cultures ou de mauvaises herbes, commandes opérateur en langage naturel) par-dessus des systèmes de navigation et de contrôle déjà autonomes et déjà classiques.

Trois catégories de matériel couvrent l'essentiel d'une construction d'inférence embarquée sur robot : un kit de développement de la classe Jetson pour le niveau de raisonnement, une ou plusieurs caméras de profondeur/stéréo pour l'entrée de perception, et une plateforme de développement robotique pour tout monter. Cette section nomme des catégories, pas des références précises, des prix ou des affirmations constructeur — vérifiez les spécifications et prix actuels directement auprès de chaque fournisseur avant d'acheter, les deux évoluant plus vite qu'un article ne peut le suivre.

Les kits de développement Jetson Orin et Jetson Thor sont le point de départ standard pour évaluer un VLA ou un VLM embarqué — voir Matériel Edge AI pour LLM locaux pour la répartition palier par palier (Orin Nano à AGX Thor) couvrant l'enveloppe de puissance et le calcul relatif.

Les caméras de profondeur ou stéréo constituent l'entrée de perception standard pour un VLA — la plupart des recherches VLA publiées et des designs de référence constructeur supposent une entrée RGB-D ou stéréo plutôt qu'une simple RGB monoculaire, la profondeur simplifiant l'estimation du point de préhension et de la distance aux obstacles dont dépend la couche de sortie d'action.

Une plateforme de développement robotique — une plateforme de référence à roues ou à bras plutôt qu'une construction mécanique de zéro — constitue le point de départ pratique pour une équipe validant une intégration VLA avant de s'engager sur du matériel sur mesure.

Quatre charges de travail restent hors du robot même dans une architecture agressivement local-first : l'apprentissage de flotte, les mises à jour de modèle, le partage de contexte inter-robots et la simulation lourde. Aucune n'est sensible à la latence comme le sont la perception ou la planification de tâche, et toutes bénéficient d'un calcul et de données qu'aucun robot seul ne possède.

L'apprentissage de flotte — agréger l'expérience de nombreux robots déployés pour améliorer une politique ou un modèle partagé — nécessite intrinsèquement des données de plus d'unités qu'un seul robot n'en porte, et le calcul d'entraînement impliqué dépasse largement le budget ou l'usage d'un accélérateur embarqué.

Les mises à jour de modèle (un nouveau checkpoint VLA, un modèle de perception affiné) sont poussées vers le robot plutôt qu'entraînées sur lui ; le robot est une cible d'inférence, pas un nœud d'entraînement, dans pratiquement tous les schémas de déploiement de production actuellement utilisés.

Le contexte inter-robots — un robot bénéficiant de ce qu'un autre robot de la même flotte vient d'observer — nécessite un backend partagé, puisqu'il n'existe pas de mécanisme embarqué utile permettant à un robot d'accéder directement à l'historique capteur d'un autre.

La simulation lourde — les charges de calcul physique et de rendu à grande échelle utilisées pour générer des données d'entraînement ou valider une politique avant déploiement — tourne sur du calcul de classe data center pour la même raison que l'apprentissage de flotte : le budget de calcul n'a pas d'équivalent embarqué.

Dans l'UE, un composant d'IA fonctionnant comme composant de sécurité d'une machine est traité comme à haut risque au titre de l'AI Act, et le Règlement Machines de l'UE (2023/1230) — applicable à partir de janvier 2027 — exige séparément une évaluation de conformité pour les machines dotées d'une fonction de sécurité pilotée par IA. Un robot dont un modèle intervient dans le chemin d'une fonction de sécurité peut devoir satisfaire les deux cadres, pas un seul.

Voici notre propre analyse raisonnée, et non une directive réglementaire publiée : l'architecture à deux niveaux décrite tout au long de cet article — conserver les fonctions de sécurité (arrêts d'urgence, limites de couple, verrouillages anti-collision) dans du code de contrôle classique et déterministe, et cantonner le niveau de raisonnement VLA/LLM à des rôles consultatifs ou de niveau tâche qui ne conditionnent jamais directement une fonction de sécurité — réduit vraisemblablement la charge d'évaluation de conformité, car une fonction de sécurité certifiable exige un comportement caractérisable de manière exhaustive à l'avance, ce que du code déterministe peut offrir et qu'un grand réseau de neurones ne peut actuellement pas offrir. Nous n'avons connaissance d'aucun régulateur ayant publié de directive spécifique confirmant ce cadrage ; considérez-le comme un argument technico-réglementaire à évaluer avec votre propre conseil juridique, et non comme une garantie de conformité.

Ceci ne constitue pas un conseil juridique. Le périmètre de l'évaluation de conformité, les normes harmonisées applicables et la classification précise des fonctions de sécurité d'un robot donné dépendent de la conception réelle du système et de la juridiction de vente — consultez un conseil juridique et réglementaire qualifié avant de déterminer la conformité d'un produit spécifique. La CNIL recommande par ailleurs, pour le traitement de données professionnelles sensibles (financières, médicales, juridiques), de privilégier l'IA locale lorsque c'est pertinent — cette section traite uniquement de sécurité machine et de certification produit, pas de droit des données.