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

Si vous achetez un robot humanoïde ou quadrupède en 2026, l'unité que vous recevez ne représente que la moitié du système. L'autre moitié, c'est la puissance de calcul qui fait tourner les grands modèles que le robot ne peut pas héberger lui-même. Cet article explique ce qui se trouve réellement où, pourquoi la voie sur site existe alors que les API cloud sont bon marché, et comment les deux moitiés sont reliées physiquement et logiquement.

Le public visé, ce sont les acheteurs et les intégrateurs qui veulent une vision claire avant de signer un bon de commande — pas encore les ingénieurs qui écriront le code de liaison.

Le problème des deux boîtes

Un humanoïde moderne comme l'Unitree G1 ou le Booster T1 embarque un module de calcul : typiquement un Jetson Orin (classe NX ou AGX) ou un SoC de classe Snapdragon, souvent associé à un petit MCU dédié à la boucle de contrôle moteur. Les quadrupèdes comme l'Unitree Go2 utilisent une architecture similaire, à plus petite échelle.

Ce calcul embarqué suffit pour :

• Le contrôle moteur en temps réel — couple articulaire, équilibre, démarche. Cela tourne entre 500 Hz et 1 kHz et ne tolère aucun saut réseau. Cela reste local, point final.
• Les réflexes de sécurité immédiats — protection contre les chutes, arrêt d'urgence, réponse au contact. Même contrainte, même réponse.
• La perception à faible latence — profondeur stéréo ou RGB-D, fusion IMU, détection d'objets de base (typiquement une petite variante de YOLO ou MobileNet).
• Le mot-clé de réveil vocal et le routage des commandes de base.

Ce que le calcul embarqué ne peut raisonnablement pas faire tourner :

• Les grands modèles vision-langage (VLM) comme Qwen2.5-VL 72B, NVIDIA Cosmos, OpenVLA. Ils réclament des dizaines de Go de VRAM et sont bien trop gourmands pour une plateforme sur batterie.
• Les grands modèles de langage (LLM) pour le dialogue ou la planification au-delà de la classe 7B–8B quantifiée.
• Les planificateurs de mouvement par diffusion ou autorégressifs qui travaillent sur des centaines de millisecondes de contexte.
• La mémoire de scène et les graphes de tâches à long horizon.

Cette répartition n'est pas un avis de Kentino. C'est la partition qu'applique aujourd'hui toute plateforme humanoïde crédible. Le module embarqué est dimensionné pour la sécurité et la latence ; la réflexion lourde part hors du robot.

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

Qui fait quoi — la répartition concrète

La répartition en deux boîtes : le contrôle local reste sur le robot ; l'inférence lourde et l'entraînement partent vers le serveur sur site, via le LAN.

Trois points à retenir :

1. Le robot n'a pas besoin d'un serveur GPU pour marcher. Si le LAN tombe, l'unité se lève encore, garde l'équilibre et évite le mur. Le pipeline déporté ajoute des capacités — langage, planification, tâches à long horizon — il 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é) tourne sur un Jetson Orin AGX. Le placer à bord ou hors bord est un arbitrage entre énergie, thermique et latence. Il n'y a pas de réponse unique.
3. Le serveur fait plus que servir de l'inférence. Un déploiement sérieux mène aussi l'entraînement (pour affiner le modèle sur un environnement précis), la simulation (Isaac Sim pour itérer sur les politiques) et la mémoire de scène / la recherche documentaire. « Serveur d'inférence » est un raccourci pour « backend de calcul GPU ».

Le budget de latence

Le seul chiffre qui décide si votre architecture va tenir, c'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 en sans-fil, la gigue du Wi-Fi. Le transport lui-même est rarement le goulot d'étranglement sur un LAN filaire. C'est pourquoi la plupart des installations robotiques sérieuses passent par une liaison filaire ou par un point d'accès Wi-Fi 6/6E dédié, en vue directe de la zone de travail.

Si votre robot doit répondre à une commande vocale en moins d'une seconde, le calcul donne à peu près ceci :

capture audio          ~ 50 ms
wake-word + STT        100–250 ms  (embarqué ou déporté, au choix)
TTFT du LLM (plan.)    200–500 ms  (côté serveur)
flux LLM, 20 tokens    600–1200 ms
TTS                    100–300 ms
restitution audio      ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

Il n'existe aujourd'hui aucun moyen de tenir « moins d'une seconde de bout en bout » avec un LLM 70B dans la boucle. Soit vous acceptez la latence, soit vous passez à un modèle plus petit sur site (classe 8B–13B), soit vous scindez la réponse (accuser réception immédiatement, planifier en arrière-plan).

C'est le genre d'arbitrage qui n'a rien à voir avec le réseau et tout à voir avec le choix du modèle. C'est aussi le genre d'arbitrage où posséder son propre serveur change la donne : vous pouvez changer de modèle, en faire tourner plusieurs à la fois, grouper les requêtes autrement. Avec une API cloud, vous prenez ce que le fournisseur sert.

Pourquoi du sur site, au fond

L'inférence cloud est bon marché, elle passe à l'échelle sans effort et ne demande aucun capex. Alors pourquoi acheter un serveur à quatre ou huit GPU quand une clé d'API OpenAI coûte cinquante dollars ?

Il y a quatre vraies raisons, dans l'ordre approximatif de leur poids réel dans la décision :

1. Les données ne sortent pas du bâtiment. Les déploiements industriels, de défense, de santé et ceux soumis au RGPD dans l'UE ne peuvent souvent pas envoyer de données capteur brutes vers un cloud tiers. Le robot voit un atelier, une chambre de patient, une paillasse de laboratoire. Cette vidéo est soit confidentielle, soit réglementée, soit concurrentiellement sensible. L'inférence sur site règle le problème proprement. Le cloud, non.

2. Le plancher de latence. Chaque appel cloud ajoute 15–40 ms de RTT WAN à la latence du modèle. Pour la plupart des tâches robotiques, cela passe. Pour du contrôle réactif en boucle fermée — prise et dépose rapide, rattrapage d'équilibre après une poussée, manipulation fine — ce plancher WAN est de trop. Le sur site le ramène sous la milliseconde.

3. Le coût à charge soutenue. Un appel unique à un VLM 70B ne coûte presque rien au fournisseur cloud ; il vous facture quelques centimes. Mais un robot qui « pense en permanence » passe des milliers d'appels par heure. Un laboratoire de recherche qui entraîne et une flotte de robots qui infèrent sur les mêmes modèles peuvent saturer 5 000–15 000 € de dépenses cloud par mois. Un serveur sur site à 4 ou 8 GPU est amorti en moins de douze mois à cette charge.

4. Le choix et la personnalisation des modèles. Vous voulez affiner un VLM sur votre environnement précis. Vous voulez faire tourner un modèle que les fournisseurs cloud n'hébergent pas. Vous voulez combiner des modèles à poids ouverts de plusieurs éditeurs dans un pipeline maison. Le sur site vous le permet. Les API cloud, non.

Si aucune de ces quatre raisons ne concerne votre déploiement, utilisez le cloud. Pour être honnête, 30 à 40 % des acheteurs en robotique ont réellement besoin de sur site ; les autres le choisissent par prestige ou parce que leur service achats est mal à l'aise avec le cloud. Ces deux motifs sont valables aussi, mais nous n'allons pas prétendre le contraire.

Topologie réseau

Topologie réseau : robot en Wi-Fi 6E → point d'accès dédié → switch 10 GbE → serveur d'inférence. La sortie et le WAN sont optionnels.

Quelques remarques pratiques qui prennent les gens de court :

• Le Wi-Fi 6E est le plancher, pas le plafond. La bande 6 GHz est la seule à offrir une latence basse et constante dans un environnement chargé d'autres appareils. Prévoyez un point d'accès par ~50 m² de zone de travail du robot, en vue directe si possible.
• Le filaire reste meilleur. Si le robot propose une liaison filaire (certains humanoïdes de recherche oui, les quadrupèdes rarement), utilisez-la pendant le développement. Travailler avec un LAN sous la milliseconde est nettement plus agréable que de se battre avec le Wi-Fi.
• La sortie est optionnelle, mais utile. Même sur un déploiement entièrement sur site, vous voudrez généralement une sortie WAN pour : mettre à jour les modèles, récupérer des données cartographiques, tirer les conteneurs NVIDIA NGC, remonter de la télémétrie vers votre propre supervision. Filtrez-la strictement ; n'exposez jamais le robot ni le serveur à Internet.
• La synchronisation horaire compte. Faites tourner un serveur NTP local. La fusion de capteurs et la planification de mouvement se dégradent de façon subtile quand les horloges dérivent entre le robot, le serveur et les éventuels équipements de périphérie.

Alimentation et refroidissement

Un serveur Kentino AI à 4 GPU (4× RTX 5090 ou 4× RTX Pro 6000 Blackwell) consomme 1.8–2.4 kW en continu sous charge. Un serveur à 8 GPU consomme 3.5–4.5 kW. Ce ne sont pas des chiffres de poste de bureau : il faut des circuits 16 A et un flux d'air de rack correct.

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

Planifiez le local avant l'installation, pas après. La plupart des laboratoires qui ont « ajouté du calcul GPU plus tard » finissent par faire sauter les disjoncteurs dès le premier mois.

Le flux d'air compte autant que les watts. Les serveurs Kentino AI utilisent un flux d'air de rack industriel d'avant en arrière avec des ventilateurs de 120 mm et sont explicitement conçus pour une charge soutenue 24h/24 et 7j/7. Ce ne sont pas des tours de bureau, et ils vont saturer la climatisation d'une petite pièce. Soit vous les mettez en rack dans un local à refroidissement dédié, soit vous les installez dans une autre pièce avec une liaison 10 GbE.

Pile logicielle — ce qui tourne vraiment

C'est là que vit l'implémentation. Vue d'ensemble :

Répartition logicielle : ROS 2 sur le robot communique en gRPC avec le serveur d'inférence qui fait tourner vLLM / SGLang.

Deux ou trois partis pris assumés :

• vLLM est la pile de service par défaut pour les VLM et LLM à base de transformers. Elle est plus rapide que l'inférence HuggingFace naïve et prend en charge le batching continu et la mise en cache de préfixes. SGLang est une solide alternative si vous faites de la sortie structurée ou des workflows façon agents.
• llama.cpp est la bonne réponse quand vous faites tourner un petit modèle (classe 7B–13B) sur un GPU que vLLM n'apprécie pas (par exemple une RTX 4090 au parallélisme tensoriel capricieux), ou sur le robot lui-même.
• NVIDIA Triton est plus lourd à mettre en place, mais c'est le bon choix si vous mélangez des types de modèles (LLM + vision + parole) et voulez une seule couche de service pour tous.
• ROS 2 Humble est la langue commune. Les SDK constructeurs (Unitree, Booster, EngineAI) livrent des wrappers ROS 2. Construisez votre intégration côté ROS 2, pas sur le protocole propriétaire du constructeur, sauf raison particulière.

Un exemple concret

Imaginons l'installation de production viable la plus simple : un humanoïde (Unitree G1), un serveur d'inférence (Kentino AI 256 Turin Dual avec 8× RTX 5090), un switch, un point d'accès, dans un laboratoire de 30 m².

Matériel :
- Unitree G1 (une unité, ~1 kW en charge)
- Kentino AI 256 Turin Dual / 8× RTX 5090 (~4 kW en continu)
- Switch 10 GbE (5 ports, ~30 W)
- Point d'accès Wi-Fi 6E (~15 W)
- Circuit triphasé 32 A ou 2× 16 A monophasé
- ~6 kW de refroidissement dédié (climatisation split)

Logiciel sur le serveur :
- Ubuntu 22.04, CUDA 13, Docker
- vLLM servant Qwen2.5-VL 72B en INT4
- vLLM servant Qwen2.5 32B (texte seul, pour la planification)
- pgvector pour la mémoire de scène
- Isaac Sim pour le travail sur les politiques
- Prometheus + Grafana

Logiciel sur le robot :
- Pilote ROS 2 d'Unitree
- Nœud ROS 2 routeur de commandes sur mesure
- Client gRPC vers les endpoints vLLM
- YOLO local pour la détection rapide d'obstacles

C'est une architecture réelle et viable, que vous pouvez acheter et mettre en service en deux à trois semaines. Le budget total côté calcul (serveur, réseau, électricité, surcoût de refroidissement) se situe entre 60 k€ et 90 k€ selon la configuration. Le robot est une ligne budgétaire à part.

Pour un laboratoire de recherche avec 2 à 4 robots, le même serveur suffit — vLLM encaisse très bien les requêtes concurrentes, et le goulot d'étranglement devient soit la mémoire GPU (si vous voulez héberger plus de modèles en parallèle), soit la puissance disponible au mur.

Ce qui casse

Liste honnête des modes de défaillance que nous avons rencontrés, dans l'ordre approximatif de leur fréquence :

• La gigue Wi-Fi sous charge. Un réseau jusque-là impeccable se congestionne quand un nouvel appareil se connecte, la latence grimpe de 5 ms à 80 ms et le comportement réactif du robot se dégrade. Correctif : un SSID dédié à la robotique, 6 GHz uniquement, point d'accès en vue directe.
• Le changement de modèle met le système à terre. Vous mettez le VLM à jour, vLLM doit recharger, le pipeline de commandes du robot part en timeout. Correctif : service blue/green, deux endpoints, bascule l'un après l'autre.
• Throttling thermique du serveur. Sous entraînement et inférence soutenus, la climatisation de la pièce ne suit plus et les GPU se brident. La latence d'inférence double en silence. Correctif : dimensionner le refroidissement à 1.3× la charge soutenue, surveiller les températures GPU, alarmer à 80 °C.
• Pannes de câbles et de connecteurs côté robot. Les robots vibrent. Les fils fatiguent. Comptez une panne de câble réseau ou capteur par robot et par trimestre sur les unités très sollicitées. Gardez des pièces de rechange.
• Incompatibilité de version entre le pilote NVIDIA et CUDA après un apt-get upgrade. Tout le monde se fait avoir exactement une fois. Figez la version du pilote, utilisez des conteneurs, ne faites pas apt-get dist-upgrade sur un serveur qui fonctionne.
• Dérive d'horloge entre le robot et le serveur. Les horodatages capteur dérivent de quelques dizaines de millisecondes, la fusion de capteurs produit n'importe quoi, et personne ne comprend pourquoi. Correctif : NTP local, supervision, alarme sur une dérive > 5 ms.

Aucune de ces pannes n'est catastrophique. Toutes sont prévisibles dès lors qu'on les a vues une fois.

Quand le sur site est la mauvaise réponse

Restons honnêtes : le serveur d'inférence sur site est la mauvaise réponse quand —

• Votre robot est purement téléopéré et votre opérateur travaille de toute façon depuis une station de travail cloud. Prenez simplement le cloud.
• Vous déployez un seul quadrupède pour une tâche d'inspection en extérieur et vous n'avez pas besoin d'inférence sur de grands modèles ; le calcul embarqué suffit.
• L'empreinte de vos modèles tient réellement sur un Jetson Orin AGX (TDP 50–70 W) et votre budget de latence autorise l'embarqué. L'Orin fait tourner un LLM 7B en INT4 à une vitesse exploitable.
• Vous montez une démo ponctuelle. Le cloud est plus rapide à mettre en place, moins cher à charge nulle, et se démonte en une après-midi.

La voie sur site est la bonne quand le déploiement est durable, les données sensibles, le budget de latence serré ou les besoins de personnalisation réels. En 2026, la plupart des projets robotiques sérieux cochent au moins l'une de ces cases.

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.