Pourquoi les robots ont besoin d'un calcul edge dédié

Un humanoïde qui marche est un problème résolu. Un humanoïde qui comprend ce qu'il regarde, planifie une tâche en plusieurs étapes et se souvient de ce qui s'est passé cinq minutes plus tôt, non. La puissance de calcul qui comble cet écart ne tient pas sur le robot, et le cloud n'est pas le bon endroit où la placer. Cet article expose l'argumentaire technique : pourquoi, en 2026, un serveur d'inférence dédié sur site est la réponse de pointe pour tout déploiement robotique assez sérieux pour accomplir un travail utile.

I01 explique comment le robot et le serveur sont reliés. Cet article explique pourquoi vous achèteriez ce serveur. Si vous vous demandez encore si le sur site a du sens, commencez par celui-ci.

Le budget de latence décisionnelle

Chaque action d'un robot relève de l'un des quatre paliers de latence. Chaque palier dispose d'un budget imposé par la physique de la tâche : le dépasser casse le comportement d'une manière précise et reconnaissable.

Ces valeurs n'ont rien d'arbitraire : elles découlent de la bande passante de la boucle fermée dans laquelle elles s'inscrivent.

Le contrôle réactif tourne entre 500 Hz et 1 kHz au niveau articulaire parce que 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 hérite de la cadence des caméras (30–60 FPS = 16–33 ms par image) et de l'échelle de temps du contact physique (un doigt qui appuie sur un objet referme un événement de contact en 20–40 ms). La planification délibérative est bornée par les attentes humaines en conversation (une seconde paraît réactive, deux paraissent lentes) et par la latence du modèle d'un VLM utile. Le raisonnement stratégique est le seul palier à disposer d'une vraie marge, ce qui explique que tout le monde veuille y pousser la planification — et se fasse rattraper quand son VLM ne suit pas.

Ce n'est pas un avis de Kentino. Ce budget à quatre paliers est le découpage qu'intègre toute pile de contrôle robotique crédible — ROS 2, Isaac, Drake, OCS2. Ce qui change, c'est le matériel que vous placez derrière chaque palier.

Ce que le calcul embarqué peut et ne peut pas faire

Un humanoïde de 2026 embarque, au sommet de la fiche technique, un NVIDIA Jetson AGX Orin : 64 GB de mémoire unifiée, jusqu'à 275 TOPS INT8 en mode sparse (138 en dense), une enveloppe configurable de 15–60 W. C'est réellement impressionnant pour un module embarqué. C'est aussi très loin de ce que réclame un robot moderne piloté par VLM.

Faites le calcul pour les trois classes de modèles que vous voudriez réellement faire tourner sur un humanoïde :

L'Orin AGX 64 GB hébergera un VLM de classe 32B en INT4 si vous acceptez une inférence lente, aucun batching réel et aucune charge de travail concurrente. Il n'hébergera pas les VLM de classe 70B qui sont de pointe pour la compréhension de scène en 2026 — Qwen2.5-VL 72B, les variantes Cosmos les plus grosses, les modèles propriétaires dont les éditeurs ne publient pas les poids. Les poids cumulés, le cache KV d'un long contexte visuel et la moindre place pour un second modèle n'y tiennent pas.

Un second chiffre passe souvent à la trappe : la consommation. Les 275 TOPS de l'Orin supposent le mode MAX_N (60 W). On parle d'une plateforme sur batterie qui brûle 60 W de calcul en plus de 200–800 W d'actionneurs. Un MAX_N soutenu divise par deux l'autonomie du robot. En pratique, l'Orin passe l'essentiel de son temps en mode 30 W, ce qui ampute les TOPS de moitié environ et fait basculer une inférence déjà limite en territoire « inutilisable ».

Traduction : le Jetson embarqué est dimensionné pour les paliers réactif et réflexe. Il n'est pas dimensionné pour héberger un VLM. Quiconque vous affirme que son humanoïde « fait tourner Qwen2.5-VL en embarqué » fait tourner soit le modèle 3B ou 7B en s'en contentant, soit le gros modèle à 0.5 FPS en appelant cela une démo. Les deux sont valables pour des cas d'usage précis. Aucun des deux n'est de la perception robotique polyvalente.

Pourquoi le cloud est la mauvaise réponse en robotique en boucle fermée

L'inférence dans le cloud est peu coûteuse, passe à l'échelle sans effort et ne demande aucun capex. Pour un robot, elle pose quatre problèmes, grosso modo par ordre de gravité.

1. Plancher de latence WAN. Un appel cloud bien réglé à l'intérieur de l'UE atteint 15–40 ms d'aller-retour sur le WAN lui-même, plus 5–15 ms de surcoût TLS / HTTP / répartiteur de charge, plus le temps d'inférence du modèle, plus le trajet retour. Le transatlantique ajoute 80–120 ms d'aller-retour par-dessus. Pour une requête de perception réflexe — « y a-t-il un obstacle devant moi ? » — ajouter 30–50 ms avant même que le modèle ne démarre fait sauter le budget. Pour une planification délibérative à 200–500 ms, vous pourriez le tolérer, mais chaque paquet perdu, chaque retransmission, chaque bascule d'antenne vous propulse au palier supérieur.

2. Gigue. Le RTT WAN n'est pas une constante : c'est une distribution. Médiane 25 ms, P99 250 ms, P99.9 plusieurs secondes. Un robot qui agit dans le monde réel ne peut pas accepter une pause de plusieurs secondes parce qu'une route BGP a battu. En LAN sur site, le P99.9 est de 1–2 ms.

3. Coût en charge soutenue. Une seule inférence d'un VLM 70B ne coûte presque rien au fournisseur cloud — il la facture quelques centimes. Un robot qui « perçoit en permanence » émet un appel VLM toutes les 100–500 ms tant qu'il est actif. Cela représente 7,000–36,000 appels par heure et par robot. Une flotte de trois robots tournant huit heures par jour, dans la fourchette haute, c'est 850,000 appels. À seulement $0.005 l'appel sur un endpoint 72B hébergé, cela fait $4,250 par jour, soit $125k par mois. Un serveur sur site à 8× GPU est amorti en moins de trois mois à ce niveau de charge.

4. Souveraineté des données. Le robot voit un atelier de production, une chambre de patient, un laboratoire de recherche, un entrepôt dont l'agencement est confidentiel, un terrain d'entraînement militaire. Cette vidéo est protégée ou encadrée par le RGPD, HIPAA, ITAR, ou simplement sensible sur le plan concurrentiel. L'envoyer vers un cloud tiers — même signataire d'un DPA — est soit interdit, soit une charge de conformité loin d'être anodine. L'inférence sur site fait disparaître la question de la souveraineté : les octets ne quittent jamais le bâtiment.

Il existe un cinquième problème, plus diffus : l'enfermement propriétaire. Les API cloud servent les modèles que le fournisseur veut bien servir, avec les quantifications et les fenêtres de contexte qu'il a choisies. Vous ne pouvez pas faire tourner un VLM fine-tuné sur l'endpoint d'OpenAI. Vous ne pouvez pas figer un commit précis d'un modèle à poids ouverts. Vous ne pouvez pas mélanger dans un même pipeline des modèles de fournisseurs concurrents. Pour du prototypage, ces contraintes passent. Pour un déploiement robotique de production qui doit rester prévisible pendant des années, non.

Le dossier du serveur edge dédié

Un serveur d'inférence dédié sur site se trouve sur le LAN, à un ou deux sauts du robot. Pour la gamme Kentino Kentino AI, il s'agit d'un serveur rack 4U, hôte EPYC ou Xeon, 4× ou 8× GPU, sur un commutateur 10 GbE. Les chiffres qu'il apporte :

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

Un Kentino AI 256 Turin Dual représentatif, avec 8× RTX 5090, offre 256 GB de VRAM cumulée et 1.0–1.5 kW de consommation GPU en charge. De quoi héberger simultanément :

• Qwen2.5-VL 72B en INT4 (~45–50 GB de poids + 10–20 GB de KV par paire de GPU, en parallélisme tensoriel sur 4 GPU)
• Qwen2.5 32B texte seul (planification, dialogue) sur 2 GPU
• Un petit VLA (OpenVLA 7B ou Cosmos-Reason 7B) sur 1 GPU pour l'intention de mouvement
• Une mémoire de scène / base RAG (pgvector ou ChromaDB) sur le CPU hôte
• De la capacité de fine-tuning de politique en ligne sur le GPU restant lorsque le robot est à la station

Le TTFT du VLM Qwen2.5-VL 72B sur ce matériel se situe entre 200 et 400 ms sur une requête isolée, et monte à 1–4 secondes sous forte charge concurrente. Le streaming de jetons tourne à 25–50 tok/s. Cela suffit à placer un VLM 72B dans le palier de planification délibérative (100 ms – 1 s) pour un robot seul, et dans le palier de raisonnement stratégique (1 s – multi-s) pour une petite flotte. Aucun des deux paliers ne pose problème ; les paliers réactif et réflexe restent embarqués, là où ils doivent être.

Écart de capacité : ce que seul le palier edge dédié permet

Le serveur sur site, ce n'est pas simplement « le même robot, mais plus rapide ». Il rend possible une classe de charges de travail que les deux autres paliers ne peuvent structurellement pas héberger. La liste honnête :

1. Retour de compréhension de scène en temps réel. Un VLM 72B qui regarde la caméra du robot toutes les 200–500 ms et renvoie une description structurée de la scène que le planificateur consomme. Le cloud ne peut pas le faire à l'échelle, à cause de la gigue WAN et du coût. L'embarqué ne le peut pas, parce que le modèle n'y tient pas. Le sur site boucle en 250–500 ms au total.

2. Fusion VLM multi-caméras. Un humanoïde dispose de 3–5 caméras (tête, deux poignets, deux sur le corps / le torse). Faire tourner un VLM sur toutes en même temps — ancrage spatial, gestion des occlusions, coordination œil-main — multiplie par 5 la charge d'inférence. Le cloud limite le débit ou facture au flux. L'embarqué encaisse un seul flux, à petite échelle. Le sur site regroupe les cinq en lot sur le même endpoint VLM.

3. Planification de tâches à long horizon avec mémoire de scène persistante. « Hier, j'ai laissé la clé sur la deuxième étagère. Retrouvez-la. » Cela suppose qu'un VLM, un LLM et une base vectorielle tournent ensemble avec un état persistant d'une session du robot à l'autre. Cet état doit résider quelque part de stable, d'interrogeable et de rapide. C'est une base de données sur le serveur, pas une fenêtre de contexte cloud recréée à chaque appel, ni 4 GB de RAM sur le Jetson.

4. Fine-tuning de politique en ligne. Le robot collecte des démonstrations de tâches dans la journée. La nuit, pendant qu'il est à la station, vous lancez des fine-tunings LoRA sur les données du jour à partir d'un VLA de base, vous poussez l'adaptateur mis à jour, et le robot est meilleur le lendemain. L'empreinte mémoire est 2× à 5× celle de l'inférence. Le cloud facture séparément l'entraînement et le stockage. Le sur site absorbe tout cela dans la même machine.

5. Coordination de flotte multi-robots. Deux ou trois robots qui partagent une mémoire de scène, se coordonnent sur des tâches et surveillent mutuellement leur état. La couche de coordination inter-robots réclame une latence inférieure à 10 ms entre robots. Le sur site, avec un serveur partagé sur le LAN, l'offre. Le cloud non : chaque mise à jour part vers une région, revient, puis atteint le robot suivant.

6. Itération sim-to-real. Isaac Sim tournant sur les mêmes GPU que l'inférence, générant des données d'entraînement synthétiques et validant les mises à jour de politique avant qu'elles n'atteignent le robot réel. Dans le cloud, c'est une demi-journée par itération (rien que pour déplacer les données) ; sur site, une boucle de 30 minutes.

Rien de tout cela ne relève de la science-fiction. Ce sont des charges de travail que les intégrateurs robotiques font tourner aujourd'hui, en 2026. Aucune ne fonctionne proprement sur l'un des deux autres paliers.

Pourquoi c'est la réponse de pointe en 2026

L'état de l'art de la perception robotique en 2026, c'est le VLM dans la boucle. Le modèle regarde le monde, raisonne dessus en langage, émet des plans structurés, et la politique les exécute. C'était une idée de recherche en 2023, une démo produit en 2024 ; c'est un schéma de production en 2025–2026.

La tendance qui impose le palier sur site est simple : les VLM qui fonctionnent grossissent, ils ne rétrécissent pas. Qwen2.5-VL 7B est bon. Qwen2.5-VL 72B est nettement meilleur. Les modèles propriétaires que les laboratoires de pointe ne publient pas sont encore plus gros. La voie du « petit VLM qui tourne sur l'appareil » existe et continuera d'exister, mais elle accuse 12–18 mois de retard sur la frontière, et un écart de capacité bien réel. Si vous voulez le comportement de la frontière, vous hébergez le modèle de la frontière. Et ce modèle ne tient pas sur un Jetson.

En théorie, le cloud pourrait suivre. En pratique, non, pour les quatre raisons ci-dessus (latence, gigue, coût, souveraineté), et parce que les laboratoires de pointe réservent leurs plus gros modèles à des niveaux de partenariat auxquels une start-up en robotique n'a pas accès. Les VLM de classe 70B à poids ouverts, eux, existent, peuvent être hébergés et tournent bien sur des serveurs 8 GPU standard. C'est cette conjonction — des modèles de classe frontière à poids ouverts et du matériel multi-GPU standard — qui fait du sur site la bonne réponse aujourd'hui, alors qu'elle ne l'était pas en 2023.

Là encore, ce n'est pas un avis de Kentino. Le palier d'inférence sur site est ce autour de quoi la pile Isaac de NVIDIA est bâtie, ce pour quoi les grandes plateformes robotiques publient des architectures de référence, et ce que provisionne chaque intégrateur sérieux avec qui nous avons échangé ces six derniers mois. Le marché a rattrapé le matériel, qui a rattrapé les modèles : 2026 est l'année où tout s'est aligné.

Quand la voie du sur site est la mauvaise réponse

Pour rester honnête : le palier edge dédié est surdimensionné dans plusieurs cas bien réels.

• Robots téléopérés. L'opérateur est le planificateur. Le robot est une marionnette au bout d'un lien de commande. Aucun VLM dans la boucle ; le peu d'inférence nécessaire (estimation de pose, encodage vidéo à faible latence) tient sur le Jetson. Ajoutez du cloud pour les gros traitements si besoin. Aucun serveur GPU requis.
• Quadrupèdes d'inspection simples. Un robot de classe Spot ou Go2 qui parcourt une ronde fixe avec de la détection de niveau YOLO et une caméra thermique n'a pas besoin d'un VLM 72B. Le Jetson embarqué fait l'affaire. Les données partent vers le cloud pour analyse après la ronde, pas pendant.
• Démos et pilotes ponctuels. Il vous faut un système opérationnel pour un salon, une présentation client, une preuve de concept de trois semaines. Le cloud vous y amène en une après-midi. Le capex d'une installation sur site n'a aucun sens pour une charge de travail démontée dans un mois.
• Usage loisir et enseignement. Un laboratoire universitaire avec un seul G1 EDU, un budget contraint et la priorité donnée à l'entraînement RL plutôt qu'à l'inférence. Le Jetson et une simple station de travail 4090 suffisent à mener des travaux de recherche utiles. La gamme Kentino AI 8× complète correspond à une facture d'une tout autre nature.
• Charges de travail purement langagières. Un robot qui parle mais ne voit pas — un assistant vocal sur pattes. Une API LLM dans le cloud convient très bien. Le budget de latence est conversationnel, pas en boucle fermée.

La règle : si votre robot ne fait pas tourner un vrai VLM dans la boucle de perception fermée, vous n'avez pas besoin du palier edge dédié. S'il le fait, vous en avez besoin.

Quand la voie du sur site s'impose

Le palier edge dédié devient la bonne réponse dès qu'au moins l'un des points suivants est vrai — idéalement deux ou plus :

1. Un vrai VLM est dans la boucle fermée. Pas « pour des questions occasionnelles » — dans la boucle perception-action, exécuté toutes les 100–500 ms. C'est la raison d'être structurelle du sur site.
2. Charge soutenue. Huit heures par jour, cinq jours par semaine, indéfiniment. Le capex s'amortit. Le coût cloud à l'appel, lui, s'accumule sans fin.
3. Les données ne peuvent pas quitter le bâtiment. RGPD, HIPAA, ITAR, concurrence, ou simple paranoïa. Les octets restent sur le LAN. Non négociable.
4. Plusieurs robots. Deux unités ou plus partageant une mémoire de scène ou coordonnant leurs tâches. L'amortissement du serveur partagé se répartit par robot, et le budget de latence inter-robots s'effondre.
5. La personnalisation compte. VLM fine-tunés, versions de modèles figées, têtes propriétaires sur des dorsales ouvertes, quantifications de niche. La liberté, c'est le produit.
6. La vitesse d'itération compte. L'équipe livre des mises à jour de politique chaque semaine, voire plus vite. Simulation et entraînement sur le même matériel que l'inférence font passer la boucle de plusieurs jours à quelques heures.

Si vous cochez trois cases ou plus, la question n'est plus si le sur site, mais quelle taille. Le palier Kentino AI 96 à quatre GPU (RTX 4090 ou 5090) suffit pour un robot qui fait un vrai travail. Le Kentino AI 256 à huit GPU (5090 ou Pro 6000 Blackwell) est le bon format pour une petite flotte, pour les plus gros VLM, ou pour tout déploiement qui ajoute de l'entraînement à l'inférence.

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.