Aller au contenu principal
Le Fil Robotique
Le Fil RobotiqueHumanoïdes · IA physique · Industriel
Embodied.cpp : un moteur d'inférence portable pour modèles d'IA incarnée sur robots hétérogènes
InfrastructurearXiv cs.RO 

Embodied.cpp : un moteur d'inférence portable pour modèles d'IA incarnée sur robots hétérogènes

1 source couvre ce sujet·Source originale ↗·
Résumé IASource uniqueImpact UE

Des chercheurs publient sur arXiv (référence 2607.02501v1) un runtime d'inférence baptisé Embodied.cpp, conçu pour exécuter des modèles d'IA incarnée directement sur des robots physiques. Écrit en C++, il cible spécifiquement les modèles vision-langage-action (VLA) et les modèles monde-action (WAM), deux familles d'architectures qui équipent aujourd'hui la plupart des humanoïdes et bras robotiques pilotés par apprentissage. Le système s'organise en cinq couches, des adaptateurs d'entrée jusqu'aux adaptateurs de déploiement, en passant par la construction de séquences, l'exécution du backbone et des modules de tête interchangeables. Les auteurs l'ont testé sur deux modèles VLA, HY-VLA et pi0.5, obtenant des taux de réussite de tâches en boucle fermée de 100,0% et 91,0% respectivement. Sur un benchmark préliminaire de modèle WAM utilisant un bloc Transformer LingBot-VA, la mémoire consommée par bloc chute de 312,2 MiB à 88,1 MiB.

Cette publication s'attaque à un problème très concret pour les intégrateurs robotiques: le déploiement des modèles d'IA incarnée reste aujourd'hui fragmenté entre piles Python spécifiques à chaque modèle, hypothèses matérielles disparates et code de liaison écrit à la main pour chaque robot. Les runtimes d'inférence existants sont pensés pour du serving requête-réponse classique, pas pour les contraintes réelles du contrôle robotique: exécution multi-fréquence dans une boucle fermée, inférence batch-1 en priorité latence sur du matériel hétérogène, et interfaces au-delà du simple flux de tokens. Si les résultats se confirment à plus grande échelle, un runtime portable unique capable de faire tourner plusieurs familles de VLA et de WAM sur des appareils edge variés réduirait significativement le travail d'ingénierie nécessaire pour passer d'un prototype en simulation à un déploiement réel sur robot, un des goulots d'étranglement les plus cités du secteur.

Le travail s'inscrit dans la course actuelle autour des modèles génériques de contrôle robotique, aux côtés d'architectures comme Pi-0 de Physical Intelligence ou GR00T N2 de Nvidia, qui cherchent toutes à unifier perception, langage et action dans un seul modèle déployable sur du matériel varié. En proposant une couche d'abstraction backend commune plutôt qu'un modèle de plus, Embodied.cpp se positionne comme brique d'infrastructure plutôt que comme concurrent direct, un signe que la standardisation de l'inférence embarquée devient un enjeu aussi important que la performance des modèles eux-mêmes.

Dans nos dossiers

IA physique & VLANVIDIA GR00TPhysical Intelligence — π0arXiv cs.RO

À lire aussi

ROSA : un système d'inférence de modèles fondation pour usines de robots
1arXiv cs.RO 

ROSA : un système d'inférence de modèles fondation pour usines de robots

Une équipe de recherche propose ROSA, un système de service d'inférence pour les modèles fondation de robotique (RFM), décrit dans un preprint publié sur arXiv (2607.01088, 1er juillet 2026). Contrairement aux systèmes existants qui traitent l'inférence comme un problème de calcul en périphérie, avec un GPU embarqué ou dédié par robot, ROSA repose sur trois principes: un pool de GPU partagé accessible en réseau par toute une flotte de robots, une abstraction de programmation "robotics-aware" gérant des pipelines multi-modèles avec exigences de performance par tâche et gestion des échecs, et un ordonnancement piloté par l'objectif global de l'usine plutôt que par la latence d'une seule requête. L'équipe l'a implémenté sur Ray Serve pour l'orchestration distribuée, avec vLLM, PyTorch et JAX comme moteurs d'inférence, et l'a évalué sur des robots réels ainsi que sur des charges de travail synthétiques à grande échelle. Résultat annoncé: jusqu'à 12,06 fois plus de productivité d'usine qu'avec des systèmes de service dédiés classiques, un chiffre qui reste à confirmer sur des déploiements industriels réels plutôt que sur les scénarios de test choisis par les auteurs. L'intérêt de ROSA est de remettre en cause l'hypothèse dominante selon laquelle l'inférence d'un modèle de robot doit tourner localement, robot par robot. En mutualisant des GPU de classe serveur sur le réseau, l'approche promet de meilleures performances d'inférence, une autonomie de batterie accrue et un taux d'utilisation GPU plus élevé, des enjeux critiques pour les industriels qui envisagent des flottes de robots humanoïdes ou mobiles plutôt que des unités isolées. Cela rapproche l'infrastructure de service robotique du modèle déjà adopté pour les grands modèles de langage en cloud, un signal utile pour les intégrateurs et décideurs qui raisonnent en coût par flotte plutôt qu'en coût par robot. Le travail s'inscrit dans la vague plus large des modèles fondation de robotique (VLA) qui rendent les robots généralistes envisageables en usine, où l'inférence reste souvent le goulot d'étranglement plutôt que l'apprentissage lui-même. Il s'agit ici d'une contribution académique, pas d'un produit commercialisé: aucun acteur français ou européen n'est cité, et le passage à l'échelle en production reste à démontrer au-delà des bancs d'essai présentés.

InfrastructureActu
1 source
EVA-Client : framework unifié de collecte, d'inférence et de déploiement pour politiques incarnées sur robots réels
2arXiv cs.RO 

EVA-Client : framework unifié de collecte, d'inférence et de déploiement pour politiques incarnées sur robots réels

Un nouveau framework open-source baptisé EVA-Client vient formaliser une brique jusqu'ici bricolée maison par chaque laboratoire de robotique manipulatrice : le pont entre un serveur d'inférence de politique et le robot physique. Publié sur arXiv début juillet 2026, l'outil unifie en un seul code base les trois étapes critiques de la boucle d'itération sur robot réel, déploiement, collecte de données et évaluation. Son architecture découple explicitement trois couches orthogonales, les backends robots, les stratégies d'inférence et les middlewares de transport, de sorte qu'ajouter un nouveau bras ou un nouvel algorithme ne touche qu'une seule couche du système. EVA-Client propose aussi trois modes d'exécution inspectables, Debug, Collect et Eval, allant de la simulation en boucle ouverte au contrôle temps réel continu. Surtout, chaque run d'évaluation enregistre automatiquement des rollouts complets au format prêt pour l'entraînement, avec logs exhaustifs et un visualiseur de comparaison côte à côte, transformant chaque test en donnée réutilisable plutôt qu'en simple observation perdue. Le framework consolide enfin les principales stratégies d'inférence temps réel du secteur, exécution synchrone et asynchrone, lissage temporel façon ACT, Real-Time Chunking, et une base asynchrone naïve servant de référence, derrière une seule interface de configuration. Pour les équipes qui entraînent des politiques d'imitation ou des modèles VLA (vision-language-action), ce type d'infrastructure comble un angle mort réel : la littérature regorge de nouvelles architectures de politiques, mais la mise en production sur robot réel reste souvent un patchwork non reproductible, ce qui complique les comparaisons équitables entre méthodes et ralentit le passage du prototype au déploiement en série. En traitant chaque évaluation comme une collecte de données, EVA-Client attaque directement le problème du volume de données réelles, goulot d'étranglement classique face aux modèles génératifs entraînés sur des corpus web massifs. Ce travail s'inscrit dans une vague plus large d'outillage d'infrastructure pour l'IA incarnée, à mesure que des modèles fondation comme Pi-0, GR00T N2 ou Helix gagnent en maturité et que le goulot se déplace de l'algorithme vers l'ingénierie de déploiement. Contrairement aux piles propriétaires fermées de certains acteurs commerciaux, une approche ouverte et modulaire pourrait faciliter les comparaisons inter-laboratoires et accélérer l'adoption par des équipes académiques ou industrielles ne disposant pas de stack maison.

InfrastructureOpinion
1 source
ORICF : un framework ouvert pour l'inférence et le contrôle en robotique
3arXiv cs.RO 

ORICF : un framework ouvert pour l'inférence et le contrôle en robotique

Des chercheurs ont publié le 12 mai 2026 sur arXiv (identifiant 2605.09656v1) un framework open source baptisé ORICF (Open Robotics Inference and Control Framework), conçu pour réduire le coût computationnel du déploiement de modèles d'IA sur robots mobiles. La plateforme, modulaire et agnostique aux modèles, permet de composer des pipelines d'inférence multimodaux via de simples fichiers de configuration YAML, sans modification du code source. Son mécanisme central, l'edge offloading, consiste à délocaliser les tâches d'inférence vers des machines externes proches du robot plutôt que de les exécuter en embarqué. Validé sur un robot mobile équipé de ROS2, le système combinait reconnaissance automatique de la parole (ASR), un grand modèle de langage (LLM) et un réseau de neurones convolutif (CNN) pour répondre à des questions orales sur les personnes détectées par sa caméra. Par rapport à une exécution entièrement embarquée, ORICF réduit l'utilisation des ressources de calcul côté robot de 83,16% et la consommation énergétique estimée de 65,8%, tout en préservant la modularité et la reproductibilité du pipeline. Ces résultats adressent l'un des freins les plus concrets au déploiement de modèles fondamentaux sur robots de service ou industriels : la contrainte matérielle embarquée. En déchargeant dynamiquement l'inférence sur des serveurs edge locaux ou des postes de travail voisins, ORICF rend envisageable l'utilisation de modèles lourds (LLM, VLM) sur plateformes à faible puissance de calcul. La spécification déclarative YAML simplifie également les changements de modèles ou de cibles matérielles, avantage concret pour les équipes intégration qui gèrent plusieurs configurations de déploiement. À noter cependant : la validation ne porte que sur un prototype unique en laboratoire, et les métriques de latence de bout en bout en conditions réelles ne sont pas détaillées dans le preprint, ce qui limite l'extrapolation aux environnements industriels. ORICF s'inscrit dans un mouvement plus large d'outillage de la robotique embarquée avec des modèles fondamentaux, alors que ROS2 s'est imposé comme infrastructure standard pour les robots de recherche et de plus en plus industriels. Plusieurs approches concurrentes ciblent le même problème : Isaac ROS de NVIDIA propose une pile d'inférence optimisée pour hardware Jetson, tandis que des acteurs comme Hailo adressent le déploiement sur puces dédiées. Le preprint ne cite pas d'affiliation universitaire ni d'entreprise sponsor visible, ce qui reste un signal à surveiller pour évaluer la maturité et la continuité du projet. Les prochaines étapes logiques seraient une validation sur des plateformes robotiques hétérogènes et une évaluation de latence en conditions opérationnelles réelles.

InfrastructureOpinion
1 source
Le marché des puces pour l'IA incarnée s'intensifie, plusieurs acteurs en lice pour la domination
4Pandaily 

Le marché des puces pour l'IA incarnée s'intensifie, plusieurs acteurs en lice pour la domination

Le marché des puces pour l'IA embarquée (dite "embodied AI") connait une intensification brutale de la concurrence, avec plusieurs acteurs majeurs qui lancent ou annoncent des processeurs capables de faire tourner de l'IA directement sur des robots, véhicules autonomes et appareils connectés. Nvidia occupe actuellement le haut du spectre avec son module Jetson Thor : jusqu'à 2 070 TFLOPS en FP4, 128 Go de mémoire, et une enveloppe thermique configurable entre 40 W et 130 W. Qualcomm attaque le milieu de gamme industriel avec son Dragonwing IQ10, qui affiche 700 TOPS, 18 coeurs CPU Oryon, et le support de 12 caméras GMSL2 simultanées -- l'entreprise mise sur une conception de référence complète (capteurs, contrôle moteur, réseau, stack logiciel) pour séduire les fabricants de robots mobiles autonomes (AMR) et de robots de service. Côté chinois, RoboRobot, filiale d'Horizon Robotics, a lancé le Sunrise S600 avec 560 TOPS (INT8) sur une architecture hétérogène BPU Nash à 4 blocs, déjà optimisé pour les modèles Qwen3 et YOLO26x. Muxi, fabricant de GPU chinois, a formé une coentreprise avec le constructeur de robots humanoïdes Ubtech, baptisée Xixuan Chuangzhi Technology, avec un tape-out prévu au second semestre 2027 et une production en volume en 2028. Cette ruée vers la puce robotique révèle un glissement structurel : l'IA migre des datacenters vers la périphérie, avec des contraintes sévères en puissance, thermique et coût que les GPU datacenter ne peuvent pas absorber. La stratégie de Qualcomm illustre une tendance de fond -- il ne suffit plus d'offrir des TOPS bruts, il faut livrer un système intégré et certifié, réduisant le time-to-market pour les intégrateurs industriels. La bataille sino-américaine est particulièrement significative : Horizon Robotics capitalise sur son expérience automotive (déploiements en série dans l'industrie automobile chinoise) pour attaquer la robotique avec une toolchain déjà battle-tested. La coentreprise Muxi-Ubtech vise explicitement la production de masse dès 2028, ce qui en ferait un acteur crédible au moment où le marché des humanoïdes devrait atteindre les premiers déploiements commerciaux à grande échelle. La convergence entre automotive et robotique n'est pas anodine. SemiDrive propose une architecture à trois niveaux -- puce R1 pour la perception et la planification, D9 pour la coordination motrice, E3-R pour l'exécution au niveau des articulations -- calquée sur les architectures centralisation/zonale des véhicules électriques. Black Sesame, avec sa série SesameX, et les divisions silicium de Li Auto (puce Mach M100) et XPeng (puce Turing) démontrent que les constructeurs automobiles chinois développent leur propre silicon pour le physical AI. Nvidia conserve un avantage d'écosystème considérable via CUDA, Isaac et Cosmos, mais sa dépendance aux contrôles à l'export américains laisse un espace que les acteurs chinois entendent occuper avant 2029.

UEL'absence d'acteur européen dans cette course au silicon embarqué expose les fabricants de robots FR/EU à une dépendance structurelle vis-à-vis des écosystèmes américain et chinois, sans alternative locale en vue.

InfrastructureOpinion
1 source