Couverture tech bleu nuit comparant les architectures de calcul embarqué et déporté (cloud/edge) pour les robots.

Calcul embarqué ou déporté pour les robots

Sur un robot, chaque charge de travail s'exécute à l'un de deux endroits : embarquée, sur la batterie et les ventilateurs du torse, ou déportée, sur un serveur alimenté par le secteur à un saut de réseau local. La vraie question n'est pas de savoir si vous avez besoin des deux — c'est presque toujours le cas — mais quelle charge de travail va où, et pourquoi. R08 défend l'existence même d'un étage edge dédié. Cet article traite de la décision charge par charge : le contrôle moteur ici, le VLM là-bas, la reconnaissance vocale selon les cas, et ainsi de suite.

Le propos est assumé. Il existe une bonne réponse par charge de travail, et cette réponse évolue à mesure que le silicium embarqué rattrape son retard. Nous indiquerons dans quel sens chaque élément se déplace 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 tient simultanément dans deux budgets : la puissance et la mémoire. La latence est la troisième contrainte, mais elle vous dit surtout dans quel sens pousser une charge qui tient déjà, pas si elle tient ou non.

Budget de puissance sur un humanoïde. Un humanoïde de 30–50 kg embarque 700–900 Wh de batterie. La marche soutenue consomme 200–500 W au niveau des actionneurs, avec des pics au-delà de 800 W en mouvement dynamique. À l'arrêt, en phase de réflexion, les actionneurs consomment encore 80–150 W (maintenir le couple coûte peu, maintenir la posture coûte cher). Il reste donc environ 60–120 W pour tout le reste — calcul, capteurs, ventilateurs, radio — si vous visez une autonomie exploitable de deux heures. Dans cette enveloppe, le budget de calcul est de 30–80 W en continu. Faire tourner le Jetson en permanence en MAX_N (60 W) divise par deux l'autonomie du robot. C'est de la physique non négociable, pas un choix de conception.

Budget mémoire. Un Jetson AGX Orin 64 GB, ce sont 64 GB de LPDDR5 partagés entre le CPU et le GPU. Retranchez le système d'exploitation (4–6 GB), ROS 2 et le SDK du fabricant (2–4 GB), les tampons de perception (2–4 GB pour la profondeur stéréo et les nuages de points), ainsi que le code applicatif. Le budget réellement exploitable pour un LLM/VLM est de 40–48 GB. Sur un module Jetson Thor 128 GB, le plafond monte à environ 96 GB utilisables. Sur un Orin NX 16 GB, il s'effondre à 8–10 GB utilisables — de quoi loger un seul petit modèle.

En déporté, les deux budgets deviennent d'autres problèmes. Un Kentino AI 96 (4× RTX 5090) dispose de 128 GB de VRAM dédiée et de 1.0–1.5 kW de puissance GPU sur le secteur. Un Kentino AI 256 (8× RTX 5090) double les deux. La puissance et la mémoire cessent tout simplement d'être des contraintes — vous les échangez contre du capex, de la climatisation et du réseau filaire.

Le silicium embarqué, réalité 2026

Les options embarquées que l'on retrouve réellement aujourd'hui dans les humanoïdes et quadrupèdes sérieux :

SoC TOPS INT8 (sparse) Mémoire utilisable Enveloppe de puissance Ce qu'il peut exécuter
Jetson Orin NX 16 GB 100 ~10 GB partagés 10–25 W YOLO, petit VLM 3B Q4, mot-clé d'activation
Jetson AGX Orin 64 GB 275 ~40 GB partagés 15–60 W YOLO, VLM 7B Q4 à des cadences exploitables, LLM 13B
Jetson AGX Thor 128 GB (2026) 2070 TFLOPS FP4 ~96 GB partagés 40–130 W VLM 32B Q4 avec de la marge, perception en double flux
Snapdragon 8 Gen 3 / classe QRB 45–75 ~6–10 GB partagés 5–15 W Voix, mot-clé d'activation, vision légère
Hailo-8 (carte M.2) 26 TOPS INT8 2–4 GB sur puce 2.5 W typique Déchargement du pipeline vision, MobileNet/YOLO
Hailo-15 (SoC vision) 20 TOPS Résidente dans le pipeline 2–5 W Vision multi-caméra en continu
Co-processeur Intel N97 / i7-1370P s.o. (CPU + iGPU) DDR5 de l'hôte 6–45 W Orchestration haut niveau, ROS 2, logique de liaison

Thor marque une rupture, pas une simple itération. Le plafond mémoire de 128 GB et les cœurs tensoriels Blackwell nativement FP4 font passer la frontière embarquée de « VLM 7B, péniblement » à « VLM 32B, utilement » en une seule génération. Des charges structurellement déportées en 2025 — VLM de taille moyenne, description continue de scène, planificateurs LLM intermédiaires — deviennent des candidates à l'embarqué en 2026, à condition que la solution thermique du robot tienne 100–130 W.

Hailo et la classe des NPU dédiés ne sont pas des accélérateurs de LLM. Ce sont des déchargeurs de pipeline vision : ils laissent le Jetson principal libre pour le gros modèle et exécutent la vision caméra permanente (détection d'objets, suivi, VLM allégé) sur une puce de 3 W.

La classe Snapdragon QRB est la réponse pour les robots pensés pour la voix — mot-clé d'activation, formation de faisceaux, reconnaissance vocale — là où un Jetson est surdimensionné et un Cortex-M trop juste. Utile, ciblée, de plus en plus répandue.

En déporté : la gamme Kentino AI comme référence

La cible déportée évoquée tout au long de cette série est la gamme Kentino AI — alimentée par le secteur, en rack 4U ou 5U, 4 ou 8 GPU sur EPYC ou Xeon, reliée à un commutateur 10 GbE à un saut du robot. Les trois niveaux qui comptent en robotique :

Niveau GPU VRAM cumulée Puissance soutenue Plus gros VLM réaliste (INT4)
Kentino AI 64 / 96 (4 GPU) 4× RTX 5090 ou 4× Pro 6000 128–384 GB 1.8–2.4 kW 72B avec de la place pour le cache KV
Kentino AI 128 (4× Pro 6000 Blackwell) 4× RTX Pro 6000 96 GB 384 GB 2.0–2.6 kW 72B avec le contexte complet
Kentino AI 256 (8 GPU) 8× RTX 5090 ou 8× Pro 6000 256–768 GB 3.5–4.5 kW 70B + 32B + 7B simultanément

La matrice de décision

Chaque charge de travail robotique se range nettement dans l'une de cinq catégories : toujours embarquée, embarquée de préférence, indifférente, déportée de préférence, uniquement déportée. La raison de chaque placement, c'est le budget contraignant — puissance, mémoire ou latence.

Charge de travail Placement Contrainte déterminante Pourquoi
Boucle de contrôle moteur (500 Hz–1 kHz) Toujours embarquée Latence (< 1 ms) Un saut réseau représente 100 à 10000× le budget de la boucle. Sans exception.
Réflexes de sécurité articulaire / arrêt d'urgence Toujours embarquée Latence (< 5 ms) Même raison ; doit aussi fonctionner réseau local coupé.
Fusion des capteurs IMU Toujours embarquée Latence (< 5 ms) Alimente directement la boucle de contrôle.
Profondeur stéréo / RGB-D Toujours embarquée Bande passante + latence Le flux caméra brut est trop lourd à transmettre ; la sortie de profondeur est légère mais attendue vite.
Détection d'objets de classe YOLO Embarquée de préférence Latence (10–30 ms, réflexe) Tient sur un Jetson à plus de 30 FPS. Aucune raison de passer par le réseau.
Détection du mot-clé d'activation Embarquée de préférence Puissance + latence Permanente, sous le watt sur QRB ou Hailo. En déporté, elle consomme de la bande passante 24h/24 et 7j/7.
Reconnaissance vocale de classe Whisper (petit modèle) Indifférente Tolérance à la latence 100–250 ms sur Jetson AGX Orin. En déporté, 30–80 ms sur une 5090. L'utilisateur ne voit pas la différence.
Petit LLM (≤ 8B Q4) pour le dialogue Indifférente Latence contre concurrence 15–25 tok/s sur Orin AGX, 80–150 tok/s sur une 5090. Le déporté l'emporte s'il vous faut du volume.
VLM 3B Q4 (description de scène) Embarquée de préférence Puissance + latence Tient facilement sur Orin, aucun réseau nécessaire, ~10 FPS exploitables.
VLM 7B Q4 (Qwen2.5-VL, OpenVLA) Indifférente Puissance contre fréquence d'images Orin AGX tourne à 5–8 FPS sous 30 W. Un Kentino AI dépasse 30 FPS. À choisir selon la tâche.
VLM 32B Q4 Déportée de préférence (Thor : embarquement limite) Mémoire + puissance Ne tient pas sur Orin AGX. Limite sur Thor 128 GB. Confortable sur Kentino AI 96.
VLM 70B+ Q4 Uniquement déportée Mémoire 45–50 GB de poids + 10–20 GB de cache KV. Aucun module embarqué n'héberge cela en 2026.
Planificateur de mouvement (horizon court, < 1 s) Embarquée de préférence Latence Boucle serrée avec le contrôle. Le local est la bonne réponse.
Planificateur de mouvement (horizon long, plusieurs secondes) Déportée de préférence Mémoire + taille du modèle Basé sur un VLM ou sur la diffusion, contexte large : le déporté l'emporte.
Mémoire de scène / RAG Uniquement déportée Persistance + mémoire Doit survivre au redémarrage du robot ; la base vectorielle réclame du vrai stockage et de la RAM CPU.
Fusion VLM multi-caméra (3–5 flux) Uniquement déportée Mémoire + calcul Le traitement par lots entre caméras exige un serveur multi-GPU.
Affinage / entraînement LoRA Uniquement déportée Mémoire + puissance 2 à 5× la mémoire d'inférence, puissance soutenue de l'ordre du kW. Impossible sur batterie.
Pré-entraînement complet Uniquement déportée Ne tient même pas sur un serveur Territoire multi-nœuds. Voir la piste K.
Itération de politiques sous Isaac Sim Uniquement déportée Rendu GPU + débit d'apprentissage par renforcement Par nature une charge de serveur.

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

Les lignes « toujours embarquée » relèvent de la physique. Aucune quantité de bande passante ne sauve une boucle de contrôle qui exige une réponse à 1 kHz. Elles ne bougeront jamais, quelle que soit la qualité du réseau ou du calcul déporté.

Les lignes « indifférente » sont celles où s'exerce le vrai jugement d'ingénierie. C'est là que vivent les arbitrages les plus intéressants. Qu'un VLM 7B tourne à bord ou en déporté détermine une part réelle du comportement du système. Il n'existe pas de bonne réponse universelle.

Les lignes « uniquement déportée » évoluent lentement. Un modèle 72B restera probablement déporté en 2027. Un modèle 32B passera à bord à mesure que Thor se diffuse en volume. La frontière de « ce qui tient sur l'appareil » avance d'environ une classe de taille de modèle tous les 18 à 24 mois.

Correspondance avec les paliers de latence

Le budget de latence à quatre paliers issu de I01 se traduit directement en placement :

Palier Budget Placement
Contrôle réactif < 10 ms Embarqué uniquement. Point.
Perception réflexe 10–50 ms Embarqué (l'aller-retour réseau local consomme à lui seul le budget)
Planification délibérative 100 ms – 1 s Indifférent. Le réseau local fonctionne, l'embarqué aussi.
Raisonnement stratégique 1 s – plusieurs s Indifférent ; le déporté l'emporte souvent sur la qualité du modèle.

C'est dans les deux paliers intermédiaires que se jouent les vraies décisions d'architecture. Une charge réflexe qui tient tout juste dans 50 ms peut passer en déporté sur un réseau local filaire (0.5 ms de transit + 40 ms d'inférence + 0.5 ms de retour = 41 ms), mais exploser le budget en Wi-Fi 6E sous charge (8 ms × 2 + 40 ms = 56 ms, plus la gigue). C'est pourquoi les liaisons filaires comptent pendant le développement : elles permettent de voir si une charge tient fondamentalement en déporté avant d'aller se battre avec le réseau sans fil.

La réalité du réseau

Le déporté ne fonctionne que si le réseau suit. Les chiffres réels :

Liaison RTT médian RTT P99 Gigue sous charge
Liaison filaire 2.5 / 10 GbE 0.2–0.5 ms 0.5–1 ms Inférieure à la ms
Wi-Fi 6E, 6 GHz, en visibilité directe, point d'accès dédié 3–10 ms 15–30 ms Gérable
Wi-Fi 6 / 6E, 5 GHz partagé, bande encombrée 8–25 ms 80–200 ms Mauvaise
Wi-Fi 6E sous charge (transfert de fichiers sur le même SSID) 10–40 ms 200 ms – 2 s Rédhibitoire pour le robot
5G cellulaire bande moyenne 20–40 ms 100–300 ms Variable
WAN vers un cloud européen 15–40 ms (médiane) 80–300 ms Dépend du BGP

Pour les charges délibératives (budget de 100 ms à 1 s), un Wi-Fi 6E sur SSID dédié avec un point d'accès en visibilité directe suffit. Pour les charges réflexes (10–50 ms), le filaire est la réponse sûre et le Wi-Fi 6E la réponse chanceuse. Prévoyez en conséquence : si la tâche d'un robot comporte la moindre composante réflexe déportée, concevez une option filaire pour le développement et un mode de repli pour les moments où le Wi-Fi se dégrade.

Le schéma hybride — répartition rapide/lent

Le schéma vers lequel convergent la plupart des déploiements sérieux de 2026 est la répartition rapide/lent du VLM : un petit VLM embarqué pour le retour instantané, un grand VLM déporté pour les décisions réfléchies, tous deux alimentant le même planificateur.

Forme concrète :

Image caméra — 30 FPS
  • Cadence de 33 ms par image
  • Alimente à la fois le chemin VLM embarqué et le chemin déporté
↓
VLM 7B Q4 embarqué
  • Qwen2.5-VL-7B sur Jetson AGX Orin / Thor
  • Sortie à 5–10 Hz
  • Résumé de scène + action immédiate
  • Alimente directement la couche réflexe
⇄
gRPC
VLM 72B Q4 déporté
  • Qwen2.5-VL-72B sur Kentino AI 96 / 256
  • Sortie à 1–3 Hz
  • Raisonnement de scène réfléchi + ajustement du plan
  • Alimente la couche délibérative, peut passer outre l'embarqué

Répartition rapide/lent : le 7B embarqué gère la réponse immédiate ; le 72B déporté gère le raisonnement réfléchi et la mise à jour des plans.

Le modèle rapide gère « une personne marche vers moi, ralentir ». Le modèle lent gère « la personne qui marche vers moi est l'opérateur, qui m'a demandé de me mettre en pause s'il approche avec le porte-bloc rouge, et c'est bien un porte-bloc rouge, donc pause ». Le modèle rapide s'engage d'abord sur un comportement sûr ; le modèle lent l'améliore ensuite.

La trajectoire de migration — ce qui passe à bord en 2026–2027

Trois forces compriment le côté déporté : Thor arrive en volume (2070 TFLOPS FP4, 128 GB de mémoire unifiée, enveloppe de 130 W — un saut structurel par rapport à Orin) ; l'efficacité des VLM continue de progresser (un VLM de perception « suffisamment bon » pesait plus de 70B en 2024, 32B en 2026, et plausiblement 13B–20B en 2027) ; et le décodage spéculatif avec de petits modèles brouillons permet de servir la qualité d'un grand modèle à la latence d'un petit.

Les charges les plus susceptibles de migrer à bord dans les 18 prochains mois : le VLM de scène de classe 7B (déjà en mouvement), le planificateur LLM 13B (Thor le rend confortable), la chaîne vocale STT-LLM-TTS à contexte court, et les VLM 7B affinés par domaine.

Les charges qui ne migrent pas : tout ce qui dépasse 70B, la mémoire de scène à l'échelle d'une flotte, l'entraînement et la simulation, la fusion VLM multi-flux. Elles resteront déportées jusqu'en 2027 au minimum. La bande passante mémoire et l'énergie des batteries ne plient pas si vite.

Deux configurations concrètes

Un seul G1 EDU, laboratoire de recherche. L'AGX Orin embarqué fait tourner ROS 2, YOLOv11-s à 30 FPS, la reconnaissance vocale Whisper-distil et Qwen2.5-VL 7B INT4 à 5–8 FPS (délibératif). En déporté, un Kentino AI 96 (4× RTX 5090, 128 GB de VRAM) fait tourner vLLM avec Qwen2.5-VL 72B et Qwen2.5 32B texte seul, la mémoire de scène pgvector et Isaac Sim sur les GPU inactifs.

Petite flotte, 3 humanoïdes, embarqué de classe Thor. Chaque unité embarque un SoC vision Hailo-15 pour la détection multi-caméra permanente, Whisper-small en local et Qwen2.5-VL 32B INT4 à 10–15 FPS — nativement, ce n'est plus limite. En déporté, un Kentino AI 256 (8× RTX 5090, 256 GB de VRAM) héberge un Qwen2.5-VL 72B et un Llama-3.1 70B partagés pour la planification, une base pgvector commune aux trois robots, et deux GPU réservés à l'affinage LoRA nocturne.

Là où un déploiement à un seul étage fonctionne vraiment

Le tout-embarqué fonctionne pour les quadrupèdes à tâche étroite (patrouille de périmètre avec YOLO et caméra thermique), les robots téléopérés (l'opérateur est le planificateur, aucun VLM dans la boucle), les robots de démonstration ou pédagogiques avec les plus petits modèles, et tout déploiement sans réseau (inspection en extérieur, sites isolés).

Le tout-cloud fonctionne pour les assistants robotiques purement vocaux sans boucle de perception fermée, les prototypes où la rapidité de mise en place prime sur tout, et les déploiements où les données partent de toute façon vers une charge de travail dans le cloud.

L'hybride est la réponse pour tout le reste — soit environ 90 % de la robotique sérieuse en 2026. Si vous construisez quoi que ce soit avec de la perception VLM dans la boucle, vous finirez avec les deux étages. Prévoyez-le dès le premier jour.

Déroulé de décision

Lorsque vous dimensionnez un déploiement :

  1. Listez les charges de travail. Contrôle moteur, perception, reconnaissance vocale, LLM, VLM, planification, mémoire, entraînement. Soyez explicite.
  2. Associez à chacune un palier de latence et une classe de mémoire (≤ 8 GB / 8–40 GB / 40–80 GB / 80 GB et plus).
  3. Appliquez la matrice ci-dessus pour obtenir un premier placement.
  4. Confrontez l'embarqué au SoC réel du robot et à son budget thermique. Un G1 équipé d'un Orin NX n'est pas la même machine qu'un T1 avec AGX Orin ou qu'une future plateforme Thor.
  5. Confrontez le déporté au niveau de Kentino AI que vous pouvez vous offrir. Le Kentino AI 96 est le minimum pour un robot au travail sérieux ; le Kentino AI 256 est le minimum pour une flotte ou pour tout besoin d'entraînement.
  6. Auditez le réseau. Liaison filaire pour le développement, SSID Wi-Fi 6E dédié pour la production. Si votre couche réflexe traverse le réseau, prévoyez du filaire ou un repli en dégradation progressive.
  7. Planifiez la migration. Quand Thor arrivera sur votre plateforme, quelles charges passeront à bord ? Abstrayez dès maintenant la frontière gRPC pour que la migration soit un changement de déploiement et non une réécriture.

Les articles qui suivent (R05, I02, I05) approfondissent les éléments esquissés ici. Les décisions de placement présentées dans cet article sont la charpente à laquelle tout le reste se rattache.

Le constat honnête : 90 % des déploiements robotiques sérieux de 2026 ont besoin des deux étages. L'embarqué est dimensionné pour la sécurité, le réflexe et la perception par petits modèles. Le déporté est dimensionné pour le VLM dans la boucle, la mémoire de scène, la planification et l'entraînement. Les déploiements à un seul étage ne conviennent qu'à des cas d'usage étroits — et à ceux-là seulement.


Cet article fait partie du Kentino Wiki, une série de référence sur le calcul IA, la robotique et les systèmes qui les relient. Commentaires et corrections bienvenus à info@kentino.com.

Retour au blog