Pourquoi les robots ont besoin de ressources de calcul dédiées en périphérie

Un humanoïde capable de marcher est un problème résolu. Un humanoïde capable de comprendre son environnement, de planifier des tâches complexes et de se souvenir des événements des cinq dernières minutes, en revanche, est un défi. La puissance de calcul nécessaire pour combler cet écart ne tient pas sur le robot, et le cloud n'est pas la solution appropriée. Cet article présente les arguments techniques expliquant pourquoi un serveur d'inférence dédié sur site représente la solution de pointe en 2026 pour tout déploiement robotique suffisamment ambitieux pour accomplir des tâches utiles.

I01 how Le robot et le serveur sont connectés par câble. Cet article est why Vous achèteriez tout simplement le serveur. Si vous vous demandez encore si une solution sur site est judicieuse, lisez ceci d'abord.

Le budget de latence de décision

Chaque action d'un robot se situe dans l'un des quatre niveaux de latence. Chaque niveau dispose d'un budget imposé par la physique de la tâche ; s'il est dépassé, le comportement est perturbé d'une manière spécifique et reconnaissable.

Ces valeurs ne sont pas arbitraires. Elles proviennent de la bande passante de la boucle fermée dans laquelle elles se trouvent.

Le contrôle réactif fonctionne entre 500 Hz et 1 kHz au niveau articulaire, car la dynamique d'une jambe humanoïde de 30 kg l'exige ; à 100 Hz, le membre entre en résonance et la démarche diverge. La perception réflexe est tributaire de la fréquence d'images de la caméra (30 à 60 images/s = 16 à 33 ms par image) et de la durée du contact physique (la pression d'un doigt sur un objet met fin à un contact en 20 à 40 ms). La planification délibérée est limitée par les attentes conversationnelles humaines (une seconde paraît réactive, deux paraissent lentes) et par la latence du modèle d'un système de gestion de la vie virtuelle (SGV) performant. Le raisonnement stratégique est le seul niveau disposant d'une réelle marge de manœuvre, ce qui explique pourquoi on a tendance à y intégrer la planification, au risque de rencontrer des difficultés lorsque le SGV ne peut suivre.

Il ne s'agit pas d'une opinion de Kentino. Le budget à quatre niveaux est la répartition intégrée par défaut de toute pile de contrôle robotique crédible — ROS 2, Isaac, Drake, OCS2. Ce qui diffère, c'est le matériel que vous installez derrière chaque niveau.

Ce que l'ordinateur de bord peut et ne peut pas faire

Un humanoïde de 2026 embarque un NVIDIA Jetson AGX Orin en haut de sa fiche technique : 64 Go de mémoire unifiée, jusqu’à 275 TOPS INT8 (138 TOPS denses), et une consommation configurable de 15 à 60 W. Des performances impressionnantes pour un module embarqué. Mais loin des besoins d’un robot moderne piloté par VLM.

Effectuez les calculs sur trois classes de modèles que vous pourriez vouloir qu'un humanoïde utilise :

Le système Orin AGX 64 Go peut héberger un VLM de classe 32 octets à l'interface INT4 si l'on accepte une inférence lente, l'absence de traitement par lots et de charges de travail simultanées. Il ne peut pas héberger les VLM de classe 70 octets, qui constituent la pointe de la technologie pour la compréhension de scènes en 2026 : Qwen2.5-VL 72B, les variantes Cosmos plus volumineuses et les modèles propriétaires dont les pondérations ne sont pas publiées par les fournisseurs. La capacité de stockage ne permet pas de gérer la combinaison des pondérations, le cache KV pour le contexte visuel étendu ni l'espace nécessaire pour un second modèle.

Un autre chiffre est souvent négligé : la consommation énergétique. Les 275 TOPS annoncés pour l'Orin correspondent au mode MAX_N (60 W). Il s'agit d'une plateforme alimentée par batterie consommant 60 W de puissance de calcul, en plus d'une charge d'actionneurs de 200 à 800 W. Un fonctionnement continu en mode MAX_N réduit de moitié l'autonomie du robot. En pratique, l'Orin fonctionne la plupart du temps en mode 30 W, ce qui divise par deux environ les TOPS et rend l'inférence, déjà limite, inutilisable.

Traduction: Le Jetson embarqué est dimensionné pour les niveaux réactif et réflexe. Il n'est pas conçu pour héberger un VLM. Quiconque affirme que son humanoïde « exécute Qwen2.5-VL embarqué » utilise soit le modèle 3B ou 7B et s'en contente, soit le modèle plus lourd à 0.5 FPS et le présente comme une démonstration. Ces deux solutions sont valables pour des cas d'utilisation spécifiques, mais aucune ne convient à la perception robotique à usage général.

Pourquoi le cloud n'est pas la solution pour la robotique en boucle fermée

L'inférence dans le cloud est peu coûteuse, s'adapte facilement et ne nécessite aucun investissement initial. Pour un robot, elle présente quatre problèmes, classés approximativement par ordre de gravité.

1. Latence minimale du WAN. Un appel cloud bien optimisé au sein de l'UE atteint un temps d'aller-retour de 15 à 40 ms sur le WAN lui-même, auquel s'ajoutent 5 à 15 ms de surcharge TLS/HTTP/équilibreur de charge, le temps d'inférence du modèle et le temps de retour. Les appels transatlantiques ajoutent 80 à 120 ms d'aller-retour. réfléchi La requête de perception — « Y a-t-il un obstacle devant moi ? » — ajouter 30 à 50 ms avant même le démarrage du modèle constitue un dépassement de budget. délibérant Avec une planification de 200 à 500 ms, vous pourriez le tolérer, mais chaque paquet perdu, chaque retransmission, chaque basculement de tour cellulaire vous fait passer au niveau supérieur.

2. Nervosité. Le RTT WAN n'est pas constant, mais suit une distribution. La médiane est de 25 ms, le P99 de 250 ms et le P99.9 de plusieurs secondes. Un robot évoluant dans le monde réel ne peut tolérer une interruption de plusieurs secondes due à une instabilité d'une route BGP. Le P99.9 d'un réseau local sur site est de 1 à 2 ms.

3. Coût à charge soutenue. Une seule inférence VLM de 70 milliards de données ne coûte quasiment rien à un fournisseur de cloud : quelques centimes suffisent. Un robot en « perception permanente » effectue un appel VLM toutes les 100 à 500 ms lorsqu'il est actif. Cela représente 7 000 à 36 000 appels par heure et par robot. Une flotte de trois robots fonctionnant huit heures par jour à pleine capacité génère 850 000 appels. Même à 0.005 $ par appel sur un terminal hébergé de 72 milliards de données, cela représente 4 250 $ par jour, soit 125 000 $ par mois. Un serveur sur site équipé de 8 GPU est rentabilisé en moins de trois mois à cette charge.

4. Souveraineté des données. Le robot visualise une chaîne de production, une chambre de patient, un laboratoire de recherche, un entrepôt avec un plan d'inventaire confidentiel, un terrain d'entraînement militaire. Ces données vidéo sont confidentielles ou soumises à la réglementation RGPD, HIPAA, ITAR ou à des règles de confidentialité concurrentielle. Leur transfert vers un cloud tiers – même avec un accord de protection des données (DPA) signé – est soit interdit, soit implique des contraintes de conformité importantes. L'inférence sur site résout le problème de la souveraineté des données : les données ne quittent jamais l'établissement.

Il existe un cinquième problème, plus subtil : verrouillage du fournisseurLes API cloud fournissent les modèles choisis par le fournisseur, avec les quantifications et les fenêtres contextuelles qu'il a définies. Il est impossible d'exécuter un modèle VLM finement paramétré sur le point de terminaison d'OpenAI. Impossible également de figer une version spécifique d'un modèle à pondération ouverte. De plus, il est impossible de combiner des modèles de fournisseurs concurrents au sein d'un même pipeline. Ces contraintes sont acceptables pour le prototypage. En revanche, pour un déploiement robotique en production qui doit être prévisible sur plusieurs années, elles sont problématiques.

Le cas du serveur de périphérie dédié

Un serveur d'inférence dédié, installé sur le réseau local, se trouve à un ou deux sauts du robot. Pour la gamme Kentino K-AI, il s'agit d'un serveur rack 4U, équipé d'un processeur EPYC ou Xeon, de 4 ou 8 GPU et connecté à un commutateur 10 GbE. Ses performances sont les suivantes :

Les deux colonnes où l'option sur site domine sont débit soutenu et choix du modèleCe sont également les deux colonnes qui importent le plus pour les charges de travail que nous allons énumérer.

Un PC K-AI 256 Turin Dual standard équipé de 8 cartes graphiques RTX 5090 dispose de 256 Go de mémoire vidéo totale et d'une puissance GPU de 1.0 à 1.5 kW en pleine charge. Cela suffit pour faire tourner simultanément :

• Qwen2.5-VL 72B à INT4 (~45–50 Go de poids + 10–20 Go KV par paire de GPU, parallélisme tensoriel sur 4 GPU)
• Qwen2.5 32B texte uniquement (planification, dialogue) sur 2 GPU
• Un petit VLA (OpenVLA 7B ou Cosmos-Reason 7B) sur 1 GPU pour la détection de mouvement
• Mémoire de scène / stockage RAG (pgvector ou ChromaDB) sur le processeur hôte
• Capacité de réglage fin des politiques en ligne sur le GPU restant lorsque le robot est amarré

Le temps de réponse du VLM (TTFT) pour Qwen2.5-VL 72B sur ce matériel se situe entre 200 et 400 ms avec une seule requête, et peut atteindre 1 à 4 secondes en cas de forte charge simultanée. Le débit de jetons est de 25 à 50 tok/s. Cela suffit pour placer un VLM 72B dans la phase de planification (100 ms à 1 s) avec un seul robot, et dans la phase de raisonnement stratégique (1 s à plusieurs secondes) pour une petite flotte. Aucun de ces niveaux ne pose problème ; les phases réactive et réflexive restent pleinement opérationnelles.

Écart de capacités : ce que seul le niveau périphérique dédié permet

Le serveur sur site n'est pas simplement « le même robot, mais plus rapide ». Il permet de prendre en charge des charges de travail que les deux autres niveaux ne peuvent structurellement pas héberger. Voici la liste complète :

1. Retour d'information en temps réel sur la compréhension de la scène. Un module VLM de 72 octets analyse les images de la caméra du robot toutes les 200 à 500 ms et renvoie une description structurée de la scène utilisée par le planificateur. Le cloud ne peut pas assurer cette fonctionnalité à grande échelle en raison de la gigue du réseau étendu et du coût. Le système embarqué ne peut pas non plus le faire, car le modèle n'est pas adapté. Le système sur site boucle la boucle en 250 à 500 ms au total.

2. Fusion VLM multicaméra. Un humanoïde possède 3 à 5 caméras (tête, deux poignets, deux corps/thorax). L'exécution simultanée d'un VLM sur l'ensemble de ces caméras — pour l'ancrage spatial, la gestion des occlusions ou la coordination œil-main — multiplie par cinq la charge d'inférence. Le cloud impose des limites de débit ou une facturation par flux. Les systèmes embarqués prennent en charge un seul flux à petite échelle. Les systèmes sur site regroupent les cinq flux via le même point de terminaison VLM.

3. Planification des tâches à long terme avec mémoire de scène persistante. « Hier, j'ai laissé la clé à molette sur la deuxième étagère. Trouvez-la. » Cela nécessite un VLM + LLM + un stockage vectoriel fonctionnant ensemble avec un état persistant entre les sessions du robot. Cet état doit être stocké dans un emplacement stable, interrogeable et rapide. Il s'agit donc d'une base de données sur le serveur, et non d'une fenêtre de contexte cloud par appel, ni de 4 Go de RAM sur le Jetson.

4. Mise au point des politiques en ligne. Le robot collecte des démonstrations de tâches pendant la journée. La nuit, lorsqu'il est connecté à sa station d'accueil, vous effectuez des réglages LoRa sur les données de la journée à l'aide d'un réseau de neurones virtuel (VLA) de base, vous déployez l'adaptateur mis à jour, et le robot est plus performant le lendemain. Cette opération nécessite 2 à 5 fois plus de mémoire que l'inférence. Le cloud facture l'entraînement et le stockage séparément. Sur site, ces deux éléments sont intégrés dans un seul système.

5. Coordination de flottes multi-robots. Deux ou trois robots partagent une mémoire de scène, coordonnent leurs tâches et surveillent l'état des uns et des autres. La couche de coordination inter-robots exige une latence inférieure à 10 ms entre les robots. Une solution sur site, avec un serveur partagé sur le réseau local, permet d'atteindre ce niveau de latence. Le cloud, en revanche, ne le permet pas : chaque mise à jour d'un robot est envoyée à une région, puis renvoyée au robot suivant.

6. Itération de simulation à réalité. Isaac Sim s'exécute sur les mêmes GPU que ceux utilisés pour l'inférence, générant des données d'entraînement synthétiques et validant les mises à jour de la politique avant leur déploiement sur le robot réel. Sur le cloud (pour le seul déplacement des données), chaque itération prend une demi-journée, contre 30 minutes sur site.

Rien de tout cela ne relève de la science-fiction. Ce sont toutes des charges de travail que les intégrateurs de robots de 2026 exécutent aujourd'hui. Aucune ne fonctionne parfaitement sur les deux autres niveaux.

Pourquoi est-ce la réponse de pointe en 2026 ?

L'état de l'art en matière de perception robotique en 2026 est VLM dans la boucleLe modèle analyse le monde, raisonne à son sujet grâce au langage, élabore des plans structurés, et la politique les met en œuvre. Il s'agissait d'une idée de recherche en 2023, d'une démonstration de produit en 2024, et d'un modèle de production en 2025-2026.

La tendance qui impose le déploiement sur site est claire : les VLM fonctionnels sont de plus en plus volumineux. Qwen2.5-VL 7B est performant. Qwen2.5-VL 72B est nettement supérieur. Les modèles propriétaires que les laboratoires Frontier ne publient pas sont encore plus volumineux. La solution « petit VLM exécuté sur l’appareil » existe et existera toujours, mais elle accuse un retard de 12 à 18 mois et un écart de capacités significatif par rapport aux solutions Frontier. Si vous souhaitez bénéficier des performances des solutions Frontier, vous devez héberger le modèle Frontier. Or, ce dernier n’est pas compatible avec un Jetson.

En théorie, le cloud pourrait suivre le rythme. En pratique, ce n'est pas le cas, pour les quatre raisons évoquées précédemment (latence, gigue, coût, souveraineté), et parce que les laboratoires de pointe réservent l'accès aux modèles les plus complexes à des niveaux de partenariat inaccessibles aux startups de robotique. Machines virtuelles de classe 70B à poids ouvert do exister, Boite L'hébergement et le fonctionnement optimal sur des serveurs standard à 8 GPU sont essentiels. Cette convergence – des modèles de pointe à faible consommation et du matériel multi-GPU standard – explique pourquoi l'infrastructure sur site est la solution idéale aujourd'hui, contrairement à 2023.

Ce n'est pas non plus l'avis de Kentino. La couche d'inférence sur site est au cœur de la suite Isaac de NVIDIA, elle sert de base aux architectures de référence des principales plateformes robotiques et est mise en œuvre par tous les intégrateurs sérieux avec lesquels nous avons discuté ces six derniers mois. Le marché a rattrapé le matériel, qui a lui-même rattrapé les modèles, et 2026 est l'année où tout s'est éclairci.

Quand la solution sur site est la mauvaise réponse

Pour être honnête : le niveau de périphérie dédié est superflu dans plusieurs cas concrets.

• Robots télécommandés. L'opérateur est le planificateur. Le robot est une marionnette contrôlée par une liaison. Aucun VLM n'est présent ; les rares inférences effectuées (estimation de pose, codage vidéo à faible latence) peuvent être exécutées sur le Jetson. Le cloud peut être ajouté pour les calculs plus lourds si nécessaire. Aucun serveur GPU n'est requis.
• Inspection simple des quadrupèdes. Un robot de type Spot ou Go2 effectuant une patrouille fixe, équipé d'un système de détection de pointe et d'une caméra thermique, n'a pas besoin d'un module VLM 72B. Le Jetson embarqué assure cette fonction. Les données sont envoyées au cloud pour analyse après la patrouille, et non pendant.
• Démonstrations et projets pilotes ponctuels. Il vous faut un système opérationnel pour un salon professionnel, une présentation client ou une validation de concept de trois semaines. Le cloud vous permet d'atteindre cet objectif en un après-midi. Investir dans une infrastructure sur site est inadapté à une charge de travail qui sera supprimée dans un mois.
• Utilisation à des fins récréatives et éducatives. Un laboratoire universitaire doté d'un seul processeur G1 EDU, d'un budget limité et privilégiant l'entraînement par renforcement plutôt que l'inférence. Un Jetson et une station de travail 4090 suffisent pour mener des recherches pertinentes. L'offre complète K-AI 8× est disproportionnée.
• Charges de travail purement linguistiques. Un robot qui parle mais ne voit pas — un assistant vocal sur pattes. Une API LLM dans le cloud convient parfaitement. La latence est limitée à la conversation, et non à une boucle fermée.

Principe : si votre robot n’utilise pas un véritable VLM dans la boucle de perception fermée, vous n’avez pas besoin de la couche périphérique dédiée. Dans le cas contraire, elle est nécessaire.

Lorsque la solution sur site justifie l'argumentation

Le niveau de bordure dédié devient la solution idéale lorsqu'au moins une des conditions suivantes est vraie, et idéalement deux ou plus :

1. Un véritable VLM fonctionne en boucle fermée. Pas « pour des questions occasionnelles » — in La boucle perception-action s'exécute toutes les 100 à 500 ms. C'est la raison structurelle de l'existence des infrastructures sur site.
2. Charge soutenue. Huit heures par jour, cinq jours par semaine, indéfiniment. Les dépenses d'investissement s'amortissent. Le coût par appel du cloud s'accumule indéfiniment.
3. Les données ne peuvent pas quitter le bâtiment. RGPD, HIPAA, ITAR, concurrence ou simple paranoïa : les données restent sur le réseau local. Non négociable.
4. Plusieurs robots. Deux unités ou plus partagent une mémoire de scène ou coordonnent des tâches. L'amortissement du serveur partagé est calculé par robot, et le budget de latence entre robots est réduit à néant.
5. La personnalisation est importante. VLM optimisés, versions de modèles figées, têtes propriétaires sur architectures ouvertes, quantifications de niche. La liberté est le produit.
6. La vitesse d'itération est importante. L'équipe publie des mises à jour de politique chaque semaine, voire plus fréquemment. La simulation et l'entraînement sur le même matériel que l'inférence permettent de réduire le délai de plusieurs jours à quelques heures.

Si vous cochez trois de ces cases ou plus, la question n'est plus posée. if sur place mais quelle tailleUne configuration K-AI 96 à quatre GPU (RTX 4090 ou 5090) suffit pour un robot effectuant des tâches complexes. Une configuration K-AI 256 à huit GPU (5090 ou Pro 6000 Blackwell) est idéale pour une petite flotte, les plus grands VLM ou tout déploiement nécessitant un entraînement en plus de l'inférence.

---

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. Vos commentaires et corrections sont les bienvenus à l'adresse info@kentino.com.