Calcul embarqué vs calcul hors appareil pour les robots

Chaque charge de travail d'un robot réside soit à bord, alimentée par la batterie et les ventilateurs thoraciques, soit à l'extérieur, sur un serveur externe alimenté par le réseau local. La question cruciale n'est pas de savoir si les deux sont nécessaires (c'est presque toujours le cas), mais plutôt quelle charge de travail est exécutée où et pourquoi . La norme R08 justifie l'existence même d'une couche périphérique dédiée. Cet article présente les décisions relatives à chaque charge de travail : contrôle moteur ici, VLM là, STT dépend du contexte, etc.

Ce cadre est subjectif. Il existe une solution optimale pour chaque type de charge de travail, et cette solution évolue au fur et à mesure que les puces embarquées progressent. Nous indiquerons l'évolution de chaque élément en 2026-2027.

Les deux budgets qui décident de tout

Une charge de travail peut s'exécuter sur le système si et seulement si elle respecte simultanément deux contraintes : la puissance et la mémoire . La latence est la troisième contrainte, mais elle indique généralement comment acheminer une charge de travail compatible, et non si elle est compatible tout court.

Bilan énergétique d'un humanoïde. Un humanoïde de 30 à 50 kg embarque une batterie de 700 à 900 Wh. La marche continue consomme entre 200 et 500 W des actionneurs, avec des pics à plus de 800 W lors de mouvements dynamiques. Rester immobile et réfléchir consomme entre 80 et 150 W des actionneurs (le maintien du couple est peu énergivore, mais le maintien de la posture est coûteux). Il reste donc environ 60 à 120 W pour le reste : calcul, capteurs, ventilation, radio, pour une autonomie utile de deux heures. Le budget alloué au calcul, dans cette enveloppe, est de 30 à 80 W en continu. Faire fonctionner le Jetson à sa puissance maximale (60 W) en permanence divise par deux l'autonomie du robot. C'est une contrainte physique incontournable, et non un choix de conception.

Budget mémoire. Un Jetson AGX Orin 64 Go dispose de 64 Go de LPDDR5 partagés entre le CPU et le GPU . Soustrayez le système d'exploitation (4 à 6 Go), ROS 2 et le kit de développement logiciel (SDK) du fabricant (2 à 4 Go), les tampons de perception (2 à 4 Go pour la profondeur stéréo et les nuages ​​de points), ainsi que le code applicatif. Le budget utilisable réaliste pour les modèles LLM/VLM est de 40 à 48 Go. Sur un module Jetson Thor 128 Go, ce budget atteint environ 96 Go utilisables. Sur un Orin NX 16 Go, il se réduit à environ 8 à 10 Go utilisables, soit suffisamment pour un petit modèle.

En dehors de la configuration matérielle, les deux budgets posent des problèmes différents. Une Kentino AI 96 (4 × RTX 5090) dispose de 128 Go de VRAM dédiée et d'une puissance GPU de 1.0 à 1.5 kW sous tension. Une Kentino AI 256 (8 × RTX 5090) double ces deux caractéristiques. La consommation et la mémoire ne sont plus des contraintes ; elles sont désormais investies dans les dépenses d'équipement, la climatisation de la salle et le réseau câblé.

Silicium embarqué, réalité de 2026

Les options embarquées qui équipent aujourd'hui les humanoïdes et quadrupèdes de taille réelle :

Thor représente une avancée majeure, et non une simple évolution. La capacité mémoire maximale de 128 Go et les cœurs tenseurs Blackwell natifs FP4 repoussent les limites du traitement embarqué, passant de « 7 milliards de VLM, péniblement » à « 32 milliards de VLM, efficacement » en une seule génération. Les charges de travail qui, en 2025, étaient structurellement réservées aux systèmes externes (VLM de taille moyenne, description continue de scènes, planificateurs LLM de taille moyenne) peuvent désormais être exécutées à bord en 2026 si le système de refroidissement du robot est capable de supporter une consommation de 100 à 130 W.

Hailo et la classe NPU dédiée ne sont pas des accélérateurs LLM. Ils permettent de décharger le pipeline de vision : ils libèrent le Jetson principal pour le modèle plus volumineux et exécutent la vision par ordinateur (détection d'objets, suivi, VLM simplifié) sur une puce de 3 W.

La gamme Snapdragon QRB est la solution idéale pour les robots à commande vocale (mot d'activation, formation de faisceaux, STT), là où un Jetson est surdimensionné et un Cortex-M sous-dimensionné. Utile, spécialisée et de plus en plus répandue.

Hors-forum : le niveau d'IA de Kentino comme référence

La solution externe mentionnée tout au long de cette série est la gamme Kentino AI : alimentation murale, rack 4U ou 5U, 4 ou 8 GPU EPYC ou Xeon, sur un commutateur 10 GbE à un saut du robot. Les trois niveaux importants pour la robotique :

La matrice de décision

Chaque charge de travail robotique se répartit clairement dans l'une des cinq catégories suivantes : toujours embarquée , embarquée de préférence , les deux , hors-bord de préférence , hors-bord uniquement . Le classement de chaque catégorie est déterminé par les ressources disponibles : puissance, mémoire ou latence.

Trois lectures de ce tableau méritent d'être mises en avant.

Les lignes « toujours présentes » sont régies par des contraintes physiques. Aucune quantité de bande passante ne peut compenser une boucle de contrôle nécessitant une réponse de 1 kHz. Ces lignes restent immuables, quelles que soient les performances du réseau ou des capacités de calcul externes.

C’est dans les lignes « soit » que le véritable choix technique intervient. C’est là que se trouvent la plupart des compromis intéressants. Le fait qu’un module VLM 7B soit embarqué ou externe détermine une part importante du comportement du système. Il n’existe pas de solution universelle.

Les modèles « hors-bord uniquement » évoluent lentement. Un modèle 72B restera probablement hors-bord uniquement en 2027. Un modèle 32B sera embarqué à mesure que les livraisons de Thor augmenteront en volume. La capacité d'emport des appareils progresse d'environ une catégorie de modèle tous les 18 à 24 mois.

Cartographie des niveaux de latence

Le budget de latence à quatre niveaux de I01 est directement lié au placement :

C'est au niveau des deux couches intermédiaires que se jouent les véritables décisions d'architecture. Une charge de travail réflexe qui tient tout juste en 50 ms peut fonctionner hors carte via un réseau local câblé (0.5 ms de transit + 40 ms d'inférence + 0.5 ms de retour = 41 ms), mais saturer le budget sur Wi-Fi 6E en cas de forte charge (8 ms × 2 + 40 ms = 56 ms, plus la gigue). C'est pourquoi les connexions câblées sont importantes pendant le développement : elles permettent de vérifier si une charge de travail est fondamentalement adaptée au hors carte avant de se confronter au réseau sans fil.

Réalité du réseau

Le mode hors-bord ne fonctionne que si le réseau le permet. Voici les chiffres exacts :

Pour les charges de travail délibératives (budget de 100 ms à 1 s), le Wi-Fi 6E sur un SSID dédié et un point d'accès en visibilité directe convient parfaitement. Pour les charges de travail réflexes (10 à 50 ms), une connexion filaire est la solution la plus sûre et le Wi-Fi 6E la plus performante. Prévoyez en conséquence : si la tâche d'un robot comporte un composant externe réflexe, prévoyez une option de connexion filaire pour le développement et un mode de secours en cas de dégradation du Wi-Fi.

Le modèle hybride — division rapide/lente

Le modèle sur lequel convergent la plupart des déploiements sérieux de 2026 est celui d'un VLM divisé en deux phases : un petit VLM embarqué pour un retour d'information instantané, un grand VLM externe pour des décisions réfléchies, les deux alimentant le même planificateur.

Forme concrète :

Division rapide/lente : le 7B embarqué gère la réponse immédiate ; le 72B externe gère le raisonnement réfléchi et les mises à jour du plan.

Le modèle rapide gère la situation suivante : « Une personne s’approche, ralentissez. » Le modèle lent gère la situation suivante : « La personne qui s’approche est l’opérateur, qui m’a demandé de m’arrêter si elle s’approche avec le bloc-notes rouge, et comme il s’agit d’un bloc-notes rouge, je m’arrête. » Le modèle rapide privilégie d’abord un comportement sûr ; le modèle lent l’affine progressivement.

L’histoire des migrations — qui embarquera en 2026-2027

Trois forces compriment la partie hors carte : Thor arrive en volume (2070 TFLOPS FP4, 128 Go de mémoire unifiée, enveloppe de 130 W — un saut structurel par rapport à Orin) ; l’efficacité VLM continue de s’améliorer (une perception « suffisante » : le VLM était de plus de 70 milliards en 2024, est de 32 milliards en 2026, sera vraisemblablement de 13 à 20 milliards en 2027) ; et le décodage spéculatif avec de petits modèles de dessin permet de fournir la qualité d’un grand modèle avec la latence d’un petit modèle.

Charges de travail les plus susceptibles d'être intégrées au cours des 18 prochains mois : VLM de scène de classe 7B (déjà en cours de migration), planificateur LLM 13B (Thor facilite la tâche), STT-LLM-TTS à contexte court pour la voix, VLM 7B finement paramétrés spécifiques au domaine.

Les charges de travail suivantes ne migreront pas : celles de plus de 70 octets, la mémoire de scènes à l’échelle de la flotte, la formation et la simulation, ainsi que la fusion VLM multi-flux. Elles resteront hors bord au moins jusqu’en 2027. La bande passante mémoire et l’autonomie des batteries ne peuvent pas être affectées aussi rapidement.

Deux configurations concrètes

Un seul G1 EDU, laboratoire de recherche. La carte graphique embarquée AGX Orin exécute ROS 2, YOLOv11-s à 30 FPS, Whisper-distil STT et Qwen2.5-VL 7B INT4 à 5–8 FPS (à titre indicatif). La carte graphique externe Kentino AI 96 (4 × RTX 5090, 128 Go de VRAM) exécute vLLM avec Qwen2.5-VL 72B et Qwen2.5 32B (texte uniquement), la mémoire de scène pgvector et Isaac Sim sur les GPU inactifs.

Flotte réduite, 3 humanoïdes, robots de classe Thor embarqués. Chaque unité intègre un SoC de vision Hailo-15 pour une détection multicaméra permanente, le système Whisper-small et un processeur graphique Qwen2.5-VL 32B INT4 cadencé nativement à 10-15 FPS (performances désormais optimales). Un système d'intelligence artificielle externe Kentino AI 256 (8 cartes graphiques RTX 5090, 256 Go de VRAM) héberge un processeur graphique Qwen2.5-VL 72B et un processeur graphique Llama-3.1 70B partagés pour la planification, un espace de stockage pgvector partagé entre les trois robots et deux GPU réservés à l'optimisation nocturne du protocole LoRa.

Là où les déploiements monocouches purs fonctionnent

Les systèmes embarqués purs sont destinés aux quadrupèdes à tâches spécifiques (patrouille périmétrique avec YOLO + caméra thermique), aux robots téléopérés (l'opérateur est le planificateur, pas de VLM dans la boucle), aux robots de démonstration/éducation avec les plus petits modèles et à tout déploiement sans aucun réseau (inspection extérieure, sites distants).

Le cloud pur convient aux assistants robotiques vocaux sans boucle de perception fermée, aux prototypes où la rapidité de configuration prime sur tout, et aux déploiements où les données sont de toute façon intentionnellement dirigées vers une charge de travail cloud.

L'approche hybride est la solution pour tous les cas intermédiaires, soit environ 90 % de la robotique de pointe en 2026. Si vous développez un système de perception basé sur la technologie VLM, vous aurez besoin des deux niveaux de conception. Anticipez-le dès le départ.

---

Cet article fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus à info@kentino.com.