Architecture d'IA en périphérie : comment un robot communique avec un serveur d'inférence sur site

Si vous achetez un robot humanoïde ou quadrupède en 2026, l'unité que vous recevrez ne représente que la moitié du système. L'autre moitié est constituée par la puissance de calcul nécessaire à l'exécution des modèles complexes que le robot lui-même ne peut pas héberger. Cet article explique la répartition des ressources, la raison d'être de l'infrastructure sur site malgré le faible coût des API cloud, et comment ces deux composantes sont interconnectées physiquement et logiquement.

Le public cible est composé d'acheteurs et d'intégrateurs qui souhaitent avoir une vision claire avant de signer un bon de commande, et non pas encore d'ingénieurs qui écrivent le code d'interface.

Le problème des deux boîtes

Un humanoïde moderne comme l'Unitree G1 ou le Booster T1 embarque un module de calcul : généralement un Jetson Orin (classe NX ou AGX) ou un SoC de type Snapdragon, souvent associé à un petit microcontrôleur dédié à la boucle de commande des moteurs. Les quadrupèdes comme l'Unitree Go2 utilisent une architecture similaire, à une échelle réduite.

Cette puissance de calcul embarquée est suffisante pour :

• Commande de moteur en temps réel — Couple articulaire, équilibre, démarche. Ce système fonctionne à une fréquence de 500 Hz à 1 kHz et ne tolère aucun changement de réseau. Il reste exclusivement local.
• Réflexes de sécurité immédiats — Protection antichute, arrêt d'urgence, intervention en cas de contact. Même contrainte, même solution.
• Perception à faible latence — profondeur à partir de données stéréo ou RGB-D, fusion IMU, détection d'objets de base (généralement une petite variante YOLO ou MobileNet).
• Mot de réveil vocal et routage des commandes de base.

Ce que l'ordinateur de bord ne peut raisonnablement exécuter :

• Modèles vision-langage (VLM) de grande taille Par exemple, Qwen2.5-VL 72B, NVIDIA Cosmos et OpenVLA. Ces technologies nécessitent plusieurs dizaines de gigaoctets de VRAM et sont trop gourmandes en énergie pour une plateforme alimentée par batterie.
• Modèles de langage à grande échelle (LLM) pour le dialogue ou la planification au-dessus de la classe 7B–8B quantifiée.
• Planificateurs de mouvement basés sur la diffusion ou autorégressifs qui fonctionnent sur des centaines de millisecondes de contexte.
• Graphiques de mémoire de scène et de tâches à long terme.

Cette séparation n'est pas une opinion de Kentino. Il s'agit de la partition réelle présente sur toutes les plateformes humanoïdes crédibles actuelles. Le module embarqué est dimensionné pour la sécurité et la latence ; les opérations de traitement complexes sont effectuées hors du module.

La cible « hors serveur » peut être le cloud (hébergé sur OpenAI, Anthropic ou NVIDIA Cosmos) ou un serveur d'inférence sur site. La suite de cet article explique quand et pourquoi privilégier l'option sur site.

Où vivent les habitants ? – la répartition pratique

La séparation en deux compartiments : le contrôle local reste sur le robot ; les opérations d’inférence et d’entraînement lourdes sont effectuées sur le serveur local via le réseau local.

Trois points à noter :

1. Le robot n'a pas besoin d'un serveur GPU pour marcher. En cas de panne du réseau local, l'unité reste stable, conserve son équilibre et évite de heurter le mur. Le pipeline externe ajoute des fonctionnalités (langage, planification, tâches à long terme), mais ne remplace pas le contrôle local.
2. Certaines charges de travail sont négociables. Un petit VLM (par exemple, Qwen2.5-VL 7B quantifié) peut fonctionner sur un Jetson Orin AGX. Le choix de l'exécuter sur la carte ou en externe implique un compromis en termes de consommation d'énergie, de dissipation thermique et de latence. Il n'y a pas de solution unique.
3. Le serveur fait plus que simplement fournir des fonctions d'inférence. Un déploiement complet inclut également l'entraînement (pour un paramétrage précis dans un environnement spécifique), la simulation (Isaac Sim pour l'itération de politiques) et la gestion/récupération des scènes. Le terme « serveur d'inférence » désigne en réalité le « processeur de calcul GPU ».

Le budget de latence

Le seul chiffre qui détermine si votre architecture va fonctionner est le temps d'aller-retour entre le robot et le serveur.

Les chiffres qui dominent le budget sont la latence du modèle côté serveur et (si vous êtes sans fil) la gigue Wi-Fi. Le transport lui-même est rarement le facteur limitant sur un réseau local câblé. C’est pourquoi la plupart des installations de robots sérieuses utilisent un câble filaire ou un point d’accès Wi-Fi 6/6E dédié dans le champ de vision de la zone de travail.

Si votre robot doit répondre à une commande verbale en moins d'une seconde, le calcul est approximativement le suivant :

audio capture          ~ 50 ms
wake-word + STT        100–250 ms  (on-board or off-board, your choice)
LLM TTFT (planning)    200–500 ms  (server-side)
LLM stream 20 tokens   600–1200 ms
TTS                    100–300 ms
audio playout          ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

Il est impossible aujourd'hui d'atteindre une latence de bout en bout inférieure à une seconde avec un LLM de 70 milliards de dollars. Vous devez soit accepter cette latence, soit utiliser un modèle plus léger sur site (de 8 à 13 milliards de dollars), soit fractionner la réponse (accusé de réception immédiat, traitement en arrière-plan).

Ce type de compromis n'a rien à voir avec le réseau, mais tout à voir avec le choix du modèle. C'est aussi le genre de compromis où posséder son propre serveur est crucial : on peut changer de modèle, en exécuter plusieurs simultanément et effectuer des traitements par lots différemment. Avec une API cloud, on utilise ce que propose le fournisseur.

Pourquoi une solution sur site ?

L'inférence dans le cloud est économique, s'adapte facilement et ne nécessite aucun investissement initial. Alors pourquoi acheter un serveur à quatre ou huit GPU quand une clé API OpenAI coûte cinquante dollars ?

Il existe quatre raisons principales, classées approximativement par ordre de fréquence à laquelle elles influencent réellement la décision :

1. Les données ne quittent pas le bâtiment. Dans les secteurs industriel, de la défense, de la santé et pour les applications soumises au RGPD, il est souvent impossible de transférer les données brutes des capteurs vers un cloud tiers. Le robot observe une chaîne de production, une chambre de patient, une paillasse de laboratoire. Ces images sont soit confidentielles, soit soumises à une réglementation, soit considérées comme faisant partie de la concurrence. L'inférence sur site résout ce problème de manière optimale. Le cloud, en revanche, ne le permet pas.

2. Plancher de latence. Chaque appel vers le cloud induit un RTT WAN de 15 à 40 ms, en plus de la latence du modèle. Pour la plupart des tâches robotiques, cela convient. En revanche, pour le contrôle réactif en boucle fermée (prise et dépose rapides, rétablissement de l'équilibre après une poussée, manipulation précise), ce latence WAN est excessive. Une solution sur site permet de la réduire à moins d'une milliseconde.

3. Coût à charge soutenue. Un seul appel VLM de 70 milliards de VTC ne coûte quasiment rien au fournisseur de cloud ; il vous facture quelques centimes. En revanche, un robot « en veille permanente » effectue des milliers d'appels par heure. Un laboratoire de recherche effectuant des entraînements et une flotte de robots utilisant les mêmes modèles peuvent engendrer des dépenses cloud mensuelles de 5 000 à 15 000 $. À cette charge, un serveur sur site équipé de 4 ou 8 GPU est rentabilisé en moins de douze mois.

4. Choix et personnalisation du modèle. Vous souhaitez optimiser un VLM pour votre environnement spécifique. Vous souhaitez exécuter un modèle non hébergé par les fournisseurs de cloud. Vous souhaitez combiner des modèles à pondération ouverte provenant de différents fournisseurs dans un pipeline personnalisé. L'infrastructure sur site vous le permet. Les API cloud, non.

Si aucun de ces quatre points n'est pertinent pour votre déploiement, vous devriez opter pour le cloud. En réalité, seulement 30 à 40 % des acheteurs de solutions robotiques ont réellement besoin d'une infrastructure sur site ; les autres la choisissent par prestige ou parce que leur service des achats est réticent face au cloud. Ces deux raisons sont tout à fait valables, mais nous ne prétendrons pas le contraire.

Topologie du réseau

Topologie du réseau : robot en Wi-Fi 6E → point d’accès dédié → commutateur 10 GbE → serveur d’inférence. Le trafic sortant et le WAN sont optionnels.

Quelques remarques pratiques qui surprennent souvent :

• Le Wi-Fi 6E est le plancher, pas le plafond. La bande 6 GHz est la seule à garantir une faible latence constante dans les environnements comportant d'autres appareils. Prévoyez un point d'accès pour environ 50 m² de zone de travail du robot, de préférence en visibilité directe.
• Le filaire reste préférable. Si le robot dispose d'une connexion filaire (certains humanoïdes de recherche en sont équipés, contrairement aux quadrupèdes), utilisez-la pendant le développement. L'expérience de développement avec un réseau local à latence inférieure à la milliseconde est nettement plus agréable qu'avec le Wi-Fi.
• La sortie est facultative mais utile. Même pour un déploiement entièrement sur site, une sortie WAN est généralement nécessaire pour : la mise à jour des modèles, la récupération des données cartographiques, le téléchargement des conteneurs NVIDIA NGC et l’envoi des données de télémétrie à votre système de surveillance. Il est impératif de la protéger par un pare-feu strict ; ni le robot ni le serveur ne doivent être exposés à Internet.
• La synchronisation horaire est importante. Exécutez un serveur NTP local. La fusion de capteurs et la planification de mouvement sont subtilement perturbées lorsque les horloges du robot, du serveur et de tout périphérique périphérique auxiliaire dérivent.

Alimentation et refroidissement

Un serveur K-AI à 4 GPU (4 × RTX 5090 ou 4 × RTX Pro 6000 Blackwell) consomme entre 1.8 et 2.4 kW en charge continue. Un serveur à 8 GPU consomme entre 3.5 et 4.5 kW. Ces valeurs ne concernent pas les ordinateurs de bureau ; ils nécessitent des circuits de 16 A et une ventilation adéquate du rack.

Pour un laboratoire de robotique, le budget approximatif est le suivant :

Planifiez l'aménagement de la pièce avant l'installation, pas après. La plupart des laboratoires qui ajoutent du calcul GPU ultérieurement finissent par faire disjoncter le compteur dès le premier mois.

La circulation de l'air est aussi importante que la consommation électrique. Les serveurs K-AI utilisent un système de ventilation industriel frontal-arrière avec des ventilateurs de 120 mm et sont conçus spécifiquement pour un fonctionnement continu 24 h/24 et 7 j/7. Ce ne sont pas des serveurs de bureau au format tour, et ils satureront le système de climatisation d'une petite pièce. Installez-les dans une armoire avec un système de refroidissement dédié, ou placez-les dans une pièce séparée et utilisez une liaison 10 GbE.

Pile logicielle — ce qui s'exécute réellement

C'est ici que se situe la mise en œuvre. Vue d'ensemble :

Séparation logicielle : ROS 2 sur le robot communique via gRPC avec le serveur d'inférence exécutant vLLM / SGLang.

Quelques décisions qui expriment des opinions tranchées :

• vLLM est la pile de service par défaut Pour les modèles linéaires virtuels (VLM) et les modèles linéaires logiques (LLM) basés sur des transformateurs, SGLang est plus rapide que l'inférence HuggingFace classique et prend en charge le traitement par lots continu et la mise en cache des préfixes. SGLang constitue une alternative performante pour les flux de travail avec sortie structurée ou de type agent.
• lama.cpp est la bonne réponse lorsque vous exécutez un petit modèle (classe 7B–13B) sur un GPU que vLLM n'apprécie pas (par exemple RTX 4090 avec un parallélisme tensoriel particulier), ou sur le robot lui-même.
• NVIDIA Triton Il est plus lourd à configurer, mais c'est le bon choix si vous mélangez différents types de modèles (LLM + vision + parole) et que vous souhaitez une seule couche de service pour tous.
• ROS 2 Humble est la lingua franca. Les kits de développement logiciel (SDK) des fabricants (Unitree, Booster, EngineAI) incluent des wrappers ROS 2. Sauf raison particulière, développez votre intégration côté ROS 2 et non via le protocole propriétaire du fabricant.

Un exemple concret

Imaginez la configuration de production viable la plus simple : un humanoïde (Unitree G1), un serveur d'inférence (K-AI 256 Turin Dual avec 8× RTX 5090), un commutateur, un AP, dans un laboratoire de 30 m².

Hardware:
- Unitree G1 (one unit, ~1 kW charging draw)
- K-AI 256 Turin Dual / 8× RTX 5090 (sustained ~4 kW)
- 10 GbE switch (5 ports, ~30 W)
- Wi-Fi 6E AP (~15 W)
- 32 A three-phase or 2× 16 A single-phase circuit
- ~6 kW dedicated cooling (split AC)

Software on server:
- Ubuntu 22.04, CUDA 13, Docker
- vLLM serving Qwen2.5-VL 72B at INT4
- vLLM serving Qwen2.5 32B (text-only, for planning)
- pgvector for scene memory
- Isaac Sim for policy work
- Prometheus + Grafana

Software on robot:
- Unitree's ROS 2 driver
- Custom command-router ROS 2 node
- gRPC client to vLLM endpoints
- Local YOLO for fast obstacle detection

Il s'agit d'une architecture concrète et viable, disponible à l'achat et opérationnelle en deux à trois semaines. Le budget total pour la partie informatique (serveur, réseau, alimentation électrique, refroidissement) se situe entre 60 000 € et 90 000 € selon la configuration. Le robot fait l'objet d'un poste budgétaire distinct.

Pour un laboratoire de recherche avec 2 à 4 robots, le même serveur s'adapte parfaitement : vLLM gère sans problème les requêtes simultanées, et le goulot d'étranglement devient soit la mémoire GPU (si vous souhaitez héberger plus de modèles simultanément), soit la puissance du réseau électrique.

Qu'est-ce qui casse ?

Liste honnête des modes de défaillance que nous avons constatés, classés approximativement par ordre de fréquence :

• Tension Wi-Fi instable en cas de forte charge. Un réseau fonctionnant correctement auparavant se retrouve saturé lorsqu'un nouvel appareil s'y connecte ; la latence passe de 5 ms à 80 ms et la réactivité du robot se dégrade. Solution : SSID dédié à la robotique, bande 6 GHz uniquement, point d'accès en visibilité directe.
• Le changement de modèle provoque une panne du système. Lors de la mise à jour du VLM, le vLLM doit se recharger et le pipeline de commandes du robot expire. Solution : diffusion bleu/vert, deux points de terminaison, permutation séquentielle.
• Limitation thermique du serveur. Lors d'entraînements et d'inférences prolongés, la climatisation de la salle ne suffit pas et les GPU réduisent leur fréquence. La latence d'inférence double sans que cela soit perceptible. Solution : dimensionner le système de refroidissement pour un fonctionnement continu 1.3 fois supérieur, surveiller la température des GPU et déclencher une alarme à 80 °C.
• Défaillances des câbles/connecteurs côté robot. Les robots vibrent. Les câbles s'usent. Prévoyez une panne de câble réseau ou de capteur par robot et par trimestre pour les unités à usage intensif. Conservez des pièces de rechange.
• Incompatibilité entre le pilote NVIDIA et la version de CUDA après une mise à jour via apt-get. Cela arrive à tout le monde une seule fois. Épinglez votre version de pilote, utilisez des conteneurs, ne le faites pas. apt-get dist-upgrade sur un serveur fonctionnel.
• Dérive d'horloge entre le robot et le serveur. Les horodatages des capteurs dérivent de plusieurs dizaines de millisecondes, la fusion de ces capteurs produit des données erronées, et personne ne comprend pourquoi. Solution : serveur NTP local, surveillance, alarme en cas de dérive supérieure à 5 ms.

Aucun de ces événements n'est catastrophique. Ils sont tous prévisibles une fois qu'on les a vus.

Quand la solution sur site est la mauvaise réponse

Pour être honnête : le serveur d’inférence sur site n’est pas la bonne solution lorsque —

• Votre robot est une unité télécommandée et votre opérateur travaille de toute façon depuis un poste de travail dans le cloud. Autant utiliser le cloud.
• Vous déployez un quadrupède pour une mission d'inspection en extérieur et il n'est pas nécessaire de procéder à une inférence de modèle complexe ; le système de calcul embarqué s'en charge.
• L'encombrement de votre modèle est compatible avec le Jetson Orin AGX (TDP de 50 à 70 W) et votre marge de latence le permet. L'Orin peut exécuter un module LLM INT4 de 7 octets à une vitesse utilisable.
• Vous effectuez une démonstration ponctuelle. Le cloud est plus rapide à mettre en place, moins cher en l'absence de charge et vous pouvez le démonter en un après-midi.

L'approche sur site est pertinente lorsque le déploiement est durable, les données sont sensibles, la latence est un facteur critique ou les besoins de personnalisation sont réels. La plupart des projets de robotique d'envergure en 2026 répondent à au moins un de ces critères.

---

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.