Déploiement de flottes : plusieurs robots, calcul partagé

Un robot représente un projet. Cinq robots constituent un système. Vingt robots forment une opération. Toute équipe ayant dépassé le stade de la première unité constate que le problème d'ingénierie évolue à deux reprises : une première fois autour de trois robots, puis une seconde fois autour de dix. Cet article explique ces changements, pourquoi les serveurs d'IA Kentino déployés par Kentino offrent une évolutivité supérieure aux attentes, et la rigueur opérationnelle nécessaire dès le premier jour de déploiement de la deuxième flotte ou du troisième robot.

I01 traitait du problème à deux boîtiers (un robot et un serveur). K03 expliquait comment vLLM répartit un modèle entre les GPU. R08 justifiait le choix d'une solution sur site. Cet article s'appuie sur les trois précédents et répond à la question suivante : si l'on souhaite répéter l'opération N fois, quels sont les problèmes rencontrés ?

Les trois régimes

Il existe trois régimes significatifs de taille de flotte. Les transitions entre eux sont opérationnelles, non techniques : le matériel est similaire, mais son exploitation diffère.

En clair : prévoyez une personne dédiée à la maintenance du robot 3. Le problème, ce n’est ni le réseau ni le serveur GPU ; c’est l’attention humaine. Un opérateur peut gérer deux robots ponctuellement. Avec cinq robots, jongler avec les pannes (« la batterie de celui-ci est à plat, le lidar de celui-là a dévié, le réseau du troisième a des ratés ») représente un travail à temps plein, et faire comme si de rien n’était ne fait que surcharger le premier employé, qui n’aura plus qu’à y consacrer du temps partiel.

L'économie du calcul — à quoi sert réellement une IA Kentino à 8 GPU

Le critère déterminant pour le dimensionnement est le nombre de requêtes VLM simultanées par seconde et par robot , et non le nombre de robots par serveur. Un robot ne représente pas une charge fixe ; il s'agit d'une classe de charge de travail. Une tâche de prélèvement à 2 Hz est différente d'une tâche de navigation à 0.5 Hz, qui elle-même est différente d'un agent conversationnel à 0.2 Hz.

Enveloppes approximatives pour un Kentino AI 256 à 8 GPU avec 8 × RTX 5090 (FP8 / INT4 vLLM, modèle unique, traitement par lots continu activé, cache de préfixe activé ; voir I02 et K03 ) :

Il s'agit d'estimations, pas de promesses. Les valeurs varient en fonction de la longueur de l'invite, de la résolution de l'image, du taux d'accès au cache de préfixes (beaucoup plus élevé dans un contexte de flotte, car les robots d'un même bâtiment partagent le même environnement) et de la proportion exacte de préremplissage et de décodage. Ce qui importe, c'est la structure : les charges de travail VLM de petite taille desservent de nombreux robots par serveur ; les charges de travail VLM importantes, avec traitement intégré, en desservent peu.

Dans une installation réelle, il est rare qu'un seul modèle soit exécuté. Une flotte effectuant des tâches utiles nécessite généralement un VLM de 72 octets pour le raisonnement sur les scènes, un LLM de 32 octets pour la planification et un petit VLA pour la gestion précise des intentions de mouvement. L'IA Kentino 8× exécute les trois simultanément. Avec cette configuration, la limite réaliste sur un serveur est de 4 à 6 humanoïdes effectuant des tâches VLM en boucle fermée . C'est ce nombre qu'il faut prendre en compte dans la planification, et non l'optimisme du type « nous avons mesuré 24 requêtes simultanées de 7 octets ».

Le levier du traitement par lots (et pourquoi les flottes sont bon marché)

La supériorité d'un serveur unique et puissant sur plusieurs serveurs plus petits réside dans le traitement par lots continu . vLLM gère un lot glissant de requêtes en cours ; à chaque itération, les requêtes terminées sont supprimées et de nouvelles requêtes sont ajoutées. Des tests de performance publics montrent que vLLM atteint un débit 2.3 fois supérieur à celui de Text Generation Inference et 14 à 24 fois supérieur à celui de PyTorch classique sur le même matériel, précisément grâce à ce mécanisme.

Pour une flotte, l'effet est cumulatif. Cinq robots interrogeant le même point de terminaison VLM avec des invites similaires produisent un modèle de traitement par lots quasi idéal : la plupart des requêtes partagent une invite système longue (taux d'accès au cache de préfixes de 80 à 95 %), les temps d'arrivée sont suffisamment décomposés pour que le lot reste plein, et le coût par requête est amorti par le travail de préremplissage partagé.

1 robot   = 1.00× compute baseline
2 robots  = ~1.6× compute (batching helps)
4 robots  = ~2.5× compute
8 robots  = ~4.0× compute

Doubler le nombre de robots ne double pas les coûts de calcul lorsqu'ils partagent un même serveur dorsal. C'est l'argument principal en faveur d'un serveur unique et puissant plutôt que de plusieurs serveurs plus petits. Si l'on ajoute à cela les coûts d'investissement (un serveur équipé de 8 processeurs 5090 coûte environ 15 à 25 % moins cher que deux serveurs équipés de 4 processeurs 5090 sur la nomenclature) et les coûts d'exploitation (un seul serveur à surveiller, au lieu de deux), le calcul devient clairement avantageux pour les flottes allant jusqu'à huit robots.

Au-delà de huit heures, vous avez de toute façon besoin d'un deuxième serveur, et la question devient celle de la répartition du trafic — sujet abordé ci-dessous.

Architecture d'une flotte de 3 à 8 robots

Trois plans de gestion sur un hôte physique (moins de 8 robots environ) : gestion de flotte, coordination et inférence. Chacun est logiquement distinct ; au-delà de cette taille, ces plans sont répartis entre les hôtes.

Trois plans, pas un seul boîtier. Le plan de gestion de flotte est l'interface utilisateur : inventaire des robots, télémétrie, mises à jour OTA, alertes. Le plan de coordination est la couche inter-robots : cartes partagées, répartition des tâches, mémoire des scènes. Le plan d'inférence est la couche de déploiement des modèles : vLLM derrière un routeur. Ces plans fonctionnent sur le même serveur physique Kentino AI pour les flottes de moins de 8 robots environ, et sur des serveurs distincts au-delà.

Routage des requêtes : ce qui se trouve devant vLLM

Une configuration simple avec un seul point de terminaison vLLM, quatre robots et une répartition de charge TCP fonctionne pendant une semaine, puis tombe en panne dès qu'une requête prend 8 secondes et que les quatre suivantes se retrouvent en file d'attente. C'est le routeur qui empêche cela.

Trois options, par ordre de complexité :

nginx simple avec least_conn. L'algorithme Round-Robin est inadapté ; il faut privilégier les connexions les moins actives afin qu'une requête lente ne monopolise pas l'ensemble du parc de serveurs. Cinq lignes de configuration suffisent. Solution optimale pour un modèle, un point de terminaison et deux réplicas. N'a aucun impact sur le cache clé-valeur ni sur la localité des préfixes.

Routeur vLLM (Rust, sortie fin 2025). Hachage cohérent sur le préfixe d'invite, afin que chaque conversation aboutisse sur la même réplique et que le cache de préfixes reste actif. Pour une flotte où chaque robot gère sa propre conversation mais partage une invite système longue, c'est la solution idéale. Les politiques sont les suivantes : cache_aware, power_of_two et round_robin; la prise en compte du cache est le comportement par défaut pour les flottes de production.

llm-d sur Kubernetes. Préremplissage/décodage, désagrégation, planification multi-réplicas, extensions d'inférence de passerelle. Solution idéale avec au moins 4 réplicas, des types de modèles variés et une équipe d'exploitation Kubernetes. Surdimensionné dans tous les autres cas.

L'affinité de session est une question délicate. Un robot dialoguant avec un agent de planification bénéficie d'un routage persistant vers la même réplique (cache de préfixe). En revanche, un robot envoyant des balises de scène VLM ponctuelles n'en bénéficie pas : ces dernières étant sans état, elles sont routées selon un système de répartition circulaire. La solution optimale consiste à router par type de requête, et non par client : la planification vers une instance prenant en compte le cache, tandis que le balisage de scène est routé selon un système de répartition circulaire. Le routeur vLLM prend en charge les deux approches via une politique par point de terminaison.

Mémoire de scène : lieu où réside le contexte de chaque robot

Un robot n'est pas un client sans état. Il se souvient de l'endroit où il a laissé la clé à molette hier, de qui est passé il y a une heure, et que le carton dans l'allée 7 est là depuis trois jours. Cette mémoire doit être stockée quelque part, et le choix de cet emplacement est une décision cruciale dans la conception d'une flotte.

Trois modèles :

Option A — pgvector par robot sur le serveur. Chaque robot dispose de sa propre collection dans une instance Postgres+pgvector partagée. La mémoire est persistante, interrogeable côté serveur et accessible à la gestion de flotte. Simple, cette solution peut gérer des dizaines de robots sur une seule instance Postgres. Son point faible réside dans la confidentialité : chaque octet de la mémoire de chaque robot est centralisé.

Option B — Mémoire de scène embarquée avec RAG vers le serveur. Le robot stocke ses propres représentations dans une base de données locale (sqlite-vss ou DuckDB). Lorsqu'il interroge le serveur VLM, il transmet les fragments pertinents récupérés avec la requête. La mémoire est locale et privée ; le réseau ne voit que ce que le robot a choisi d'envoyer. Cette option est plus adaptée aux déploiements sensibles (médical, défense, ou tout autre environnement où l'opérateur ne souhaite pas que les données brutes quittent le robot). Elle consomme davantage de bande passante réseau par appel.

Option C — Espace de stockage de scènes partagé avec gestion des espaces de noms. Tous les robots lisent et écrivent dans un seul espace de stockage pgvector, organisé par site ou tâche. Le robot 2 peut interroger le robot 1 sur ce qu'il a vu dans le quai de chargement ce matin et obtenir une réponse utile. C'est la seule option qui permette de réaliser de véritables tâches collaboratives. C'est également l'option où une écriture erronée d'un robot perturbe l'espace de stockage des autres.

Pour une flotte de 3 à 8 robots, la solution par défaut la plus fiable est l'option C avec un contrôle d'accès strict : chaque robot écrit dans son propre espace de noms et lit les données depuis un espace de noms partagé (« monde ») géré (le gestionnaire de la flotte y transfère les observations après validation). Pour les déploiements où la confidentialité est primordiale, privilégiez l'option B. L'option A est la solution la plus simple et convient parfaitement si la collaboration n'est pas indispensable.

stratégies de partage de modèles

La configuration par défaut (un modèle unique pour N robots) convient à la plupart des flottes. Les robots effectuent des tâches similaires ; le modèle de base est identique ; les différences résident dans les instructions et le contexte récupéré, et non dans les pondérations. C’est la solution la plus économique et celle qui offre la meilleure efficacité de traitement par lots.

Deux cas où cela ne fonctionne pas :

Têtes à réglage fin par robot. Le robot 1 se trouve dans l'entrepôt et est optimisé pour la manutention de palettes. Le robot 2 se trouve dans le laboratoire et est optimisé pour la manipulation d'instruments. Vous utilisez le même VLM de base avec différents adaptateurs LoRA chargés selon la requête. vLLM prend en charge la gestion multi-LoRA (--enable-lora --max-loras N) avec une faible surcharge par requête et un regroupement par lots du modèle de base partagé. Utile lorsque les ajustements fins représentent 0.1 à 1 % des poids de base (typique pour LoRa) et que vous avez de 2 à 10 adaptateurs distincts.

Des modèles spécialisés par classe de tâches. Un modèle différent pour chaque tâche : Qwen2.5-VL pour le raisonnement général sur les scènes, OpenVLA pour la préhension, et une version optimisée de 7B pour le dialogue. Chaque modèle dispose de son propre point de terminaison vLLM sur sa propre tranche de GPU. Les requêtes sont acheminées selon leur type. Plus de VRAM, moins de regroupement par modèle, et donc une surface d'exécution plus importante. La bonne réponse n'est fournie qu'après avoir validé qu'un modèle ne peut pas accomplir la tâche, et pas avant.

Commencez par un seul modèle. Ajoutez des adaptateurs LoRa lorsque vous constatez un écart de qualité entre les robots. Ajoutez des modèles spécialisés lorsque vous constatez un écart de performance par tâche que LoRa ne permet pas de combler.

Gestion de flottes de robots (RFM) — choisissez un produit

Développer sa propre solution RFM est un piège dans lequel la plupart des équipes tombent au moins une fois. Les fonctionnalités semblent évidentes sur le papier, mais leur coût est en réalité élevé : inventaire, ingestion de données télémétriques, stockage de séries temporelles, pipeline OTA, routage des alertes, contrôle d'accès basé sur les rôles, journaux d'audit, multi-tenant si vous avez des clients. Une petite équipe développera une version fonctionnelle pour une flotte, mais qui dysfonctionnera avec une autre. Mieux vaut acheter une solution existante et la personnaliser.

Open-RMF est géré par l'Open Source Robotics Alliance depuis 2024 et prend en charge l'attribution des tâches, la résolution des conflits et l'arbitrage des infrastructures partagées (ascenseurs, portes, couloirs). Pour un déploiement sur site de type Kentino avec des robots de différents fournisseurs (par exemple, un Unitree G1, un Booster T1 et un quadrupède Go2, tous sur le même site), Open-RMF est la seule solution ouverte crédible. Formant et Orbit sont d'excellentes solutions, mais ce sont des logiciels en tant que service (SaaS) et elles privilégient leur propre écosystème.

Les solutions par défaut recommandées : OpenRMF pour les environnements sur site multi-fournisseurs, Formant pour les solutions hébergées nécessitant une observabilité poussée, et Orbit pour les environnements Boston Dynamics uniquement. Développer sa propre solution RFM est une erreur, sauf si vous commercialisez explicitement RFM comme un produit.

Coordination multi-robots sur le câble

Espace de noms ROS 2. Chaque robot exécute sa pile ROS 2 sous un espace de noms unique (/r01/, /r02/, …). Les sujets, services et paramètres DDS sont également organisés en espaces de noms. Les robots s'abonnent aux sujets d'état de leurs pairs (/r02/pose, /r03/pose) directement via DDS, sans intermédiaire. Le DDS de ROS 2 est de type pair à pair et s'adapte parfaitement à des dizaines de robots sur un réseau local ; au-delà d'une cinquantaine de robots, le trafic de découverte devient saturé et il est préférable soit de partitionner par ID de domaine DDS, soit de passer au mode serveur de découverte de ROS 2.

MQTT est utilisé pour la télémétrie, mais pas pour les commandes. ROS 2 / DDS est idéal pour la transmission d'informations d'état des pairs à faible latence sur le réseau local. En revanche, il n'est pas adapté à l'envoi de données de télémétrie à 0.5 Hz vers le cloud de gestion de flotte via une liaison LTE instable. MQTT est la solution idéale : léger, avec un courtier de protocoles, des niveaux de QoS pour une livraison garantie et une prise en charge native par toutes les plateformes de gestion de flotte. La configuration classique : DDS sur le réseau local et MQTT (ou HTTPS) sur le réseau étendu.

Répartition des tâches. Deux approches ont été effectivement utilisées dans les flottes de 2026 :

1. Planificateur central. Le gestionnaire de flotte attribue les tâches en fonction de la disponibilité des robots, de leur batterie, de leur emplacement et de leurs capacités. Simple, prévisible et adapté à 90 % des cas. Open-RMF propose cette fonctionnalité nativement.
2. Vente aux enchères. Les robots enchérissent sur les tâches en fonction d'une fonction de coût (distance, batterie, consommation électrique). L'offre la plus basse est retenue. Ce système est plus adapté aux flottes hétérogènes ou aux environnements dynamiques. Des travaux récents montrent que les méthodes d'enchères permettent de réaliser des économies d'énergie d'environ 12 % par rapport à l'attribution des tâches au plus proche voisin pour des flottes de 2 à 20 robots. La complexité est justifiée pour des flottes de plus de 10 robots ; elle est superflue en dessous de cette taille.

Évitement des collisions. Chaque robot publie sa position à 10 Hz et s'abonne aux positions des autres robots. Les planificateurs locaux prennent en compte les trajectoires des autres robots. Pour les flottes où deux robots partagent régulièrement un espace de travail de 1 m², une couche de coordination est également nécessaire (la gestion du trafic d'Open-RMF est la solution de référence).

Gestion des pannes à l'échelle de la flotte

Le principe est simple : les pannes doivent être isolées, les modes dégradés doivent être gérés avec élégance et la reprise automatique. Exemples pratiques :

Si un robot tombe en panne, les autres continuent de fonctionner. Chaque robot est autonome grâce à son système de calcul embarqué, garantissant sécurité et perception réactive. La perte d'un robot est considérée comme telle : les autres robots ne sont pas bloqués en attendant son remplacement. Le gestionnaire de flotte le signale, réaffecte ses tâches et alerte un opérateur.

Le serveur d'inférence tombe en panne. Chaque robot doit pouvoir basculer en mode embarqué uniquement lorsque le serveur est inaccessible : les tâches complexes et la planification à long terme sont désactivées, mais le contrôle local, l'évitement d'obstacles et les étapes de mission préchargées restent fonctionnels. Le robot devient alors insensible au langage, mais ne plante pas. Prévoyez cette situation et effectuez des tests mensuels en bloquant l'accès au serveur via le pare-feu.

Mise à jour progressive du serveur d'inférence. Deux réplicas sont placés derrière le routeur vLLM : vider le premier, le redéployer, vérifier, vider le second, puis le redéployer. Les robots ne constatent aucune interruption visible car le routeur ne vide que les réplicas sans requête en cours. Le comportement bleu/vert est également approprié pour les changements de modèle : charger le nouveau modèle sur le réplica B, modifier le pointeur du routeur, vérifier quelques requêtes, puis mettre hors service le réplica A. Omettre l'étape de préchauffage a des conséquences néfastes pour tous les utilisateurs (voir I02 concernant ce problème).

La règle du 1 sur N. À tout moment, dans une flotte de N robots, supposons qu'un robot soit dégradé, un autre hors ligne et le dernier effectuant une action imprévue. Prévoyez une capacité suffisante pour N-2 des robots efficaces. Si N-2 La flotte est insuffisante pour la charge de travail, elle est mal dimensionnée.

Observabilité à l'échelle de la flotte

Le tableau de bord que vous souhaitez réellement, par ordre de priorité :

1. Santé par robot. État de la batterie, température du GPU intégré, dernière connexion établie, tâche en cours, dernière erreur. Une ligne par robot, actualisation toutes les 5 secondes, code couleur (rouge/jaune/vert). C'est la première chose que l'opérateur consulte chaque matin.
2. Latence par robot vers le serveur d'inférence. P50, P95 et P99 correspondent aux temps d'aller-retour des appels VLM de chaque robot. Une augmentation soudaine du temps P99 indique une dégradation du Wi-Fi, une surcharge du serveur ou un changement de modèle n'ayant pas atteint sa température de fonctionnement initiale.
3. Profondeur de file d'attente du modèle. vllm_num_requests_waiting par point de terminaison. Une valeur non nulle persistante indique que la flotte dépasse la capacité du serveur. Alerte à partir de 10 pendant plus d'une minute.
4. Carte thermique d'utilisation de la flotte. Quels robots sont en service, où dans le bâtiment et quelles tâches effectuent-ils ? Vue opérationnelle : elle indique au responsable si le parc de robots est équilibré.
5. Échantillonnage des résultats du modèle. Une faible proportion (1 à 5 %) des réponses du modèle a été placée dans une file d'attente de révision. Un contrôle manuel ponctuel est effectué chaque semaine. C'est le seul moyen de détecter les régressions de qualité silencieuses.

Prometheus et Grafana sont utilisés pour les métriques ; la vue d'état de chaque robot est généralement fournie par le RFM (Formant, Orbit ou votre propre version de Grafana). Les séries vLLM concernées sont : vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds — Il s'agit là de l'aspect inférence et santé ; l'exportateur DCGM couvre l'aspect GPU.

Réalité de l'échelle des coûts

Deux observations :

• Les dépenses d'investissement par robot restent à peu près constantes à partir de 4 robots. En dessous de 4, le coût fixe du serveur est prépondérant. Au-dessus de 4, le coût de calcul est linéaire et proportionnel à la charge. Le point optimal pour… premier Le serveur comprend 4 à 6 robots.
• Les dépenses d'investissement liées aux robots (qui sont distinctes et prédominantes) augmentent de manière linéaire. Les coûts de calcul représentent un poste de dépense mineur une fois que la flotte dépasse environ 3 robots. Le principal levier de coût est de savoir si une infrastructure sur site est réellement nécessaire (voir R08), et non « quelle taille de serveur ».

L'analyse économique plaide fortement en faveur d'un serveur Kentino AI dédié à 4 à 8 robots, plutôt que de plusieurs serveurs plus petits. Deux serveurs Kentino AI 256 sont moins performants qu'un seul serveur Kentino AI 256 équipé de 8 processeurs Pro 6000 pour une même flotte, jusqu'à atteindre un plafond de capacité serveur déclenchant un DP=2. Le seuil de performance dépend de la charge de travail, mais se situe généralement autour de 7 à 9 robots pour les tâches exigeantes de modélisation du langage naturel (VLM).

Le point de vue honnête

Les flottes de plus de cinq robots relèvent d'une discipline opérationnelle différente de celle des unités individuelles. Il ne s'agit pas d'un projet « cinq fois plus grand qu'un projet à un seul robot ». C'est un projet d'une autre nature où :

• Le calcul est un petit poste de dépense ; Les opérations sont le plus important
• Le goulot d'étranglement est généralement d'ordre humain (l'attention du manager) avant d'être d'ordre technique.
• La gestion du Wi-Fi et de l'alimentation électrique est trois fois plus coûteuse qu'avec une flotte de taille 1.
• Le coût d'un réglage fin pour chaque robot est réel ; le coût de la dégradation du modèle à l'échelle de la flotte l'est encore plus.
• Créer son propre RFM est presque toujours une erreur ; choisissez-en un et personnalisez-le.

La partie calcul du problème sera véritablement résolue d'ici 2026. vLLM, un routeur et un serveur Kentino AI correctement dimensionné permettent de gérer des flottes allant jusqu'à environ 8 humanoïdes sur une seule machine. Au-delà, la mise à l'échelle s'effectue par le biais du parallélisme des données (plusieurs serveurs derrière le routeur) – comme expliqué dans K03 . Les difficultés rencontrées au-delà d'une flotte de 5 humanoïdes sont d'ordre opérationnel, et non architectural.

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.