Calcul embarqué vs calcul hors appareil pour les robots

Chaque charge de travail sur un robot réside à deux endroits : soit à bord, alimentée par la batterie et les ventilateurs thoraciques, soit à l’extérieur, sur un serveur alimenté par le réseau local. La question difficile n’est pas… que Il vous faut les deux — c'est presque toujours le cas — mais Quelle charge de travail est répartie où, et pourquoi ?. R08 Cet article démontre la nécessité même d'une couche de périphérie dédiée. Il s'agit d'une décision adaptée à chaque charge de travail : contrôle moteur ici, VLM là, STT dépend, 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 à bord si et seulement si elle s'inscrit simultanément dans deux budgets : power et MémoireLa latence est la troisième contrainte, mais elle vous indique généralement… dans quel sens pousser Une charge de travail adaptée, et non pas une charge de travail adaptée 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 couple de maintien est peu coûteux, le maintien de la posture est énergivore). Il reste donc environ 60 à 120 W pour… tout le reste — Calcul, capteurs, ventilateurs, radio — si vous souhaitez une autonomie utilisable de deux heures. La consommation de calcul dans cette enveloppe est de 30 à 80 W en continu. Faire fonctionner le Jetson à sa puissance MAX_N (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 correspond à 64 Go de LPDDR5 partagé entre le CPU et le GPUSoustrayez le système d'exploitation (4 à 6 Go), ROS 2 et le kit de développement logiciel 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 de 128 Go, ce budget atteint environ 96 Go. Sur un module Orin NX de 16 Go, il se réduit à environ 8 à 10 Go, soit suffisamment pour un petit modèle.

Hors du cadre officiel, les deux budgets posent des problèmes différents. Une K-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 K-AI 256 (8 × RTX 5090) double ces deux valeurs. La consommation et la mémoire ne sont plus des contraintes : vous investissez désormais dans les dépenses d'investissement, 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, génération continue de légendes de scènes, planificateurs LLM de taille moyenne) deviennent désormais possibles. candidats à bord en 2026 si la solution thermique du robot peut supporter 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 K-AI comme référence

La plateforme externe mentionnée dans cette série est la gamme K-AI : alimentation secteur, 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 à bord, à bord préféré, non plus, hors-bord préféré, hors-bord uniquementLa raison de chaque placement est liée au budget alloué : puissance, mémoire ou latence.

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

Les règles "toujours à bord" relèvent de la physique. Aucune quantité de bande passante ne peut corriger une boucle de contrôle nécessitant une réponse de 1 kHz. Ces boucles restent immuables, quelles que soient les performances du réseau ou des capacités de calcul externes.

C’est dans les lignes « soit l’un, soit l’autre » que le véritable jugement technique intervient. C'est ici que se situent la plupart des compromis intéressants. Le fait qu'un VLM 7B soit exécuté à bord ou hors bord détermine une part importante du comportement du système. Il n'existe pas de solution universellement idéale.

Les rangées « hors-bord uniquement » avancent lentement. Le modèle 72B restera probablement hors-bord jusqu'en 2027. Le modèle 32B sera embarqué à mesure que les livraisons de Thor augmenteront en série. La capacité de stockage des appareils progresse d'environ une catégorie de taille tous les 18 à 24 mois.

Cartographie des niveaux de latence

Le budget de latence à quatre niveaux de I01 cartes pour le placement direct :

C’est au niveau des deux couches intermédiaires que se situent les véritables décisions d’architecture. Une charge de travail réflexive qui juste Une donnée qui tient en 50 ms pourrait être transmise 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 dépasserait largement le budget alloué via Wi-Fi 6E en cas de charge (8 ms × 2 + 40 ms = 56 ms, plus la gigue). C'est pourquoi les connexions filaires sont importantes pendant le développement : elles permettent de vérifier si une charge de travail est suffisante. fondamentalement Installez-le hors du bateau avant de vous attaquer 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 prévus pour 2026 est le suivant : VLM fractionné rapide/lent: 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.

Charges de travail qui Nous ne Migration : tout ce qui dépasse 70 milliards de bits, la mémoire de scènes à l’échelle de la flotte, la formation et la simulation, la fusion VLM multi-flux. Ces éléments resteront hors bord au moins jusqu’en 2027. La bande passante mémoire et l’autonomie des batteries ne diminuent pas aussi rapidement.

Deux configurations concrètes

Unité G1 EDU, laboratoire de recherche. Le processeur graphique embarqué AGX Orin exécute ROS 2, YOLOv11-s à 30 FPS, Whisper-distil STT et Qwen2.5-VL 7B INT4 à 5–8 FPS (variable). Le processeur graphique externe K-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.

Petite flotte, 3 humanoïdes, un vaisseau de classe Thor à bord. Chaque unité intègre un SoC de vision Hailo-15 pour une détection multicaméra permanente, le traitement Whisper-small embarqué et Qwen2.5-VL 32B INT4 à 10-15 FPS nativement, une performance désormais nettement supérieure. Le contrôleur K-AI 256 externe (8 cartes graphiques RTX 5090, 256 Go de VRAM) héberge un Qwen2.5-VL 72B et un 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 de LoRa.

Là où les déploiements monocouches purs fonctionnent

Pure on-board fonctionne pour quadrupèdes à tâche étroite (patrouille périmétrique avec YOLO + caméra thermique), robots téléopérés (l'opérateur est le planificateur, pas de VLM dans la boucle), 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 fonctionne pour assistants robotiques vocaux uniquement sans boucle de perception fermée, prototypes où la rapidité d'installation prime sur tout, et déploiements où les données sont de toute façon intentionnellement acheminées vers une charge de travail cloud.

L'hybride est la solution pour Tout ce qui se situe entre les deux – soit environ 90 % de la robotique de pointe en 2026 – sera concerné. Si vous développez un système de perception basé sur la technologie VLM, vous rencontrerez forcément les deux niveaux. Prévoyez-le dès le départ.

---

Ceci 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.