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 a couvert le problème à deux boîtes pour un robot et un serveur. K03 Nous avons expliqué comment vLLM répartit un modèle entre les GPU. R08 Cet article explique pourquoi une infrastructure sur site est nécessaire. Il complète les trois précédents et répond à la question suivante : si vous souhaitez 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 chiffre qui devrait guider votre dimensionnement est Requêtes VLM simultanées par seconde et par robotIl ne s'agit pas d'un nombre fixe 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 n'est pas équivalente à une tâche de navigation à 0.5 Hz, qui elle-même n'est pas équivalente à un agent de dialogue à 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'enveloppes, 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 les contextes de flottes, car les robots d'un même bâtiment partagent le même environnement) et de la combinaison exacte de préremplissage et de décodage. Le motif qui importe est sa forme. Les charges de travail VLM de petite taille desservent de nombreux robots par serveur ; les charges de travail VLM importantes en boucle en desservent peu.

Une installation réelle utilise rarement un seul modèle. 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 seul serveur est de 4 à 6 humanoïdes effectuant des tâches VLM en boucle ferméeC’est ce chiffre-là qu’il faut prendre en compte dans la planification, et non le chiffre optimiste « nous avons mesuré 24 requêtes simultanées de 7 milliards de dollars ».

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

La raison pour laquelle un seul gros serveur surpasse plusieurs petits serveurs est la suivante : dosage continuvLLM gère un lot continu 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 les robots pas Le coût de calcul double lorsqu'ils partagent un 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 l'argument des dépenses d'investissement (un système composé de 8 processeurs 5090 est environ 15 à 25 % moins cher que deux systèmes composés de 4 processeurs 5090 sur la base du coût de la nomenclature) et l'argument des coûts d'exploitation (un seul serveur à surveiller, au lieu de deux), le calcul devient clairement avantageux pour les flottes allant jusqu'à huit robots environ.

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 avions, pas une seule boîte. avion de gestion de flotte Il s'agit de la couche accessible à l'opérateur — inventaire des robots, télémétrie, mises à jour OTA, alertes. plan de coordination Il s'agit de la couche inter-robots — cartes partagées, répartition des tâches, mémoire des scènes. plan d'inférence Il s'agit de la couche de service des modèles (vLLM) située derrière un routeur. Les flottes de moins de 8 robots environ s'exécutent sur le même serveur physique Kentino AI, tandis que les flottes plus importantes utilisent des serveurs distincts.

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 native. Surdimensionnée dans tous les autres cas.

L'affinité de session est une question subtile. Un robot conversant avec un agent de planification bénéficie d'un routage persistant vers la même réplique (cache de préfixe). Un robot envoyant des balises de scène VLM ponctuelles n'en bénéficie pas : celles-ci sont sans état et sont routées de manière cyclique. La bonne réponse est : Acheminement par type de requête, et non par client: planification de la gestion du cache, étiquetage des scènes et répartition circulaire. Le routeur vLLM prend en charge les deux 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 où il a laissé la clé à molette hier, qui est passé il y a une heure, 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 où est l'une des décisions cruciales 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 partagée Postgres+pgvector. La mémoire est persistante, interrogeable côté serveur et accessible à la gestion de flotte. Simple, elle peut gérer des dizaines de robots sur une seule instance Postgres. Son point faible réside dans la centralisation de la confidentialité : chaque octet de la mémoire de chaque robot est centralisé.

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

Option C — magasin de scènes partagé avec espace de noms. Tous les robots écrivent et lisent 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 permettant de réaliser de véritables tâches collaboratives. Cependant, c'est aussi l'option où une écriture erronée d'un robot perturbe l'interprétation des données par les autres.

La valeur par défaut raisonnable pour une flotte de 3 à 8 robots est Option C avec contrôle d'accès strict Les robots écrivent dans leur propre espace de noms et lisent depuis un espace de noms partagé, dit « mondial », géré par le gestionnaire de flotte (qui y transfère les observations après validation). Pour les déploiements sensibles à la confidentialité, privilégiez l'option B. L'option A, la plus simple, convient 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.

Modèles spécialisés par catégorie de tâches. Un différent modèle Par tâche : Qwen2.5-VL pour le raisonnement général sur la scène, 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 traitement par lots par modèle, et donc une surface d'exécution plus importante. La réponse optimale est fournie uniquement après avoir vérifié qu'un modèle ne peut pas accomplir la tâche.

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.

Le défaut honnête : Open-RMF pour les environnements sur site multi-fournisseurs, Formant pour les environnements hébergés nécessitant une observabilité poussée, Orbit pour les environnements Boston Dynamics uniquement. Créer son propre RFM est une erreur, sauf si vous vendez explicitement RFM en tant que 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 activé pour la télémétrie, désactivé pour les commandes. ROS 2 / DDS est idéal pour la communication 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 paquets, des niveaux de QoS pour une livraison garantie et une prise en charge native par toutes les plateformes de gestion de flotte. La configuration typique est la suivante : 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 fluides, la récupération doit être automatique. Les modèles pratiques :

Un robot meurt, les autres continuent de fonctionner. Chaque robot est autonome grâce à son système de calcul embarqué, garantissant ainsi sécurité et perception réactive. La perte d'un robot est considérée comme telle : ses collègues ne l'attendent pas. Le gestionnaire de flotte le signale, réaffecte ses tâches et alerte un opérateur.

Le serveur d'inférence a échoué. Chaque robot devrait pouvoir se replier sur mode embarqué uniquement En cas d'indisponibilité du serveur : les tâches complexes de grande envergure et la planification à long terme sont impossibles, 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 délibérément l'accès au serveur via le pare-feu.

Mise à jour progressive du serveur d'inférence. Deux répliques derrière le routeur vLLM ; vider l’une, la redéployer, vérifier, vider l’autre, la redéployer. Les robots ne perçoivent aucune interruption visible car le routeur ne vide que les répliques sans requête en cours. Le signal bleu/vert est également approprié pour les changements de modèle : charger le nouveau modèle sur la réplique B, basculer le pointeur du routeur, vérifier quelques requêtes, puis mettre hors service la réplique A. Omettre l’étape de préchauffage pénalise tout le monde une seule fois (voir I02 (sur l'échauffement, piège).

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

Les arguments économiques en faveur de l'informatique plaident fortement en faveur de un serveur d'IA Kentino de grande taille desservant 4 à 8 robots Sur plusieurs serveurs plus petits, deux boîtiers Kentino AI 256 sont moins performants qu'un seul Kentino AI 256 associé à huit 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 nécessitant une analyse VLM intensive.

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 se fait par le biais du parallélisme des données (plusieurs serveurs derrière le routeur) — comme expliqué dans K03Les difficultés majeures pour les flottes de plus de 5 personnes sont d'ordre opérationnel, et non architectural.

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.