Topologie de réseau pour un laboratoire de calcul en robotique et IA

Un laboratoire de robotique n'est ni un bureau, ni un centre de données, ni un laboratoire domestique. C'est un petit réseau, mais particulièrement exigeant : une poignée d'appareils aux profils de trafic très différents, tous connectés au même câble. Un humanoïde diffuse un flux vidéo stéréo vers un serveur d'inférence. Un poste de développement récupère un point de contrôle de modèle de 70 Go. Un quadrupède cherche sa station d'accueil. Un port IPMI transmet discrètement la vitesse d'un ventilateur.

Une topologie mal configurée engendre des symptômes désagréables et indirects : un robot saccade lorsqu'un collègue transfère une image Docker ; la latence du serveur d'inférence double lorsqu'un utilisateur se connecte au Wi-Fi ; la synchronisation des gradients avec votre système de réglage fin subit mystérieusement des pics de 200 ms pendant le coup de feu du déjeuner. Une topologie correcte garantit la transparence du réseau, ce qui est l'objectif principal.

Cet article décrit la configuration idéale de ce réseau en 2026. Public cible : intégrateurs et concepteurs de laboratoires qui mettent en place un « laboratoire intégré » – un à quatre robots, un ou deux serveurs d’inférence K-AI, quelques stations de travail de développement, ainsi que les éléments de stockage et de gestion nécessaires à leur interconnexion. Il ne s’agit pas d’une architecture de référence pour hyperscaler, ni d’une configuration à petit budget pour un laboratoire personnel. Il s’agit d’une solution intermédiaire.

La cible du « laboratoire en boîte »

Le déploiement de référence pour cet article :

• 1 à 4 robots — humanoïdes, quadrupèdes ou un mélange des deux. Wi-Fi 6E principal, connexion filaire optionnelle pendant le développement.
• 1 à 2 serveurs d'inférence K-AI — 4× ou 8× GPU (5090 / RTX Pro 6000 Blackwell), exécutant vLLM / SGLang pour les VLM et les LLM.
• 1 à 2 boîtiers de stockage / NAS — ensembles de données, points de contrôle, journaux de capteurs enregistrés. Généralement, un système de fichiers ZFS avec cache NVMe.
• 2 à 6 postes de travail de développement — ingénieurs utilisant ROS 2, Isaac Sim, ajustements d'entraînement, copie de données.
• Plan de gestion — IPMI/BMC sur chaque serveur, commutateur, point d'accès, hôte DNS/DHCP local.

Au total : 15 à 40 périphériques réseau actifs. Un seul commutateur pourrait assurer l’alimentation électrique. La présence de deux commutateurs dans le schéma ci-dessous n’est pas liée à la capacité, mais à la gestion des pannes, au budget PoE et à la volonté de séparer le trafic des robots et celui des GPU sur des câbles physiques distincts afin d’éviter toute coupure d’alimentation.

Topologie physique

Deux commutateurs physiques, un pare-feu, un ou deux points d'accès. Les serveurs K-AI sont connectés au cœur du réseau à 25 GbE ; le commutateur d'accès agrège les postes de travail et les points d'accès ; les robots se connectent via un SSID dédié de 6 GHz.

Deux commutateurs physiques, un pare-feu et un ou deux points d'accès. Les serveurs K-AI et le boîtier de stockage sont connectés au commutateur central à 25 GbE. Le commutateur d'accès prend en charge les périphériques câblés, mais plus lents (postes de travail, points d'accès, IPMI, caméras), et établit des liaisons montantes avec le commutateur central à 10 GbE. Les robots se connectent via Wi-Fi 6E sur un SSID dédié.

Pourquoi 25 GbE entre le cœur de réseau et K-AI ? Parce que la carte réseau ConnectX-6 Lx double port SFP28 est la carte fiable la moins chère en 2026 (700 à 900 € en magasin, parfois moins d’occasion) et que 25 GbE suffisent largement pour l’inférence sur un serveur unique. Un modèle de 70 milliards de dollars du quatrième trimestre, diffusant des jetons à quatre robots simultanément, consomme plusieurs dizaines de Mbit/s. Le brassage des points de contrôle d’un modèle est l’opération qui consomme le plus de bande passante, et 25 GbE permettent de dépasser 100 Go en environ 35 secondes. Les clients effectuant un entraînement multi-nœuds ont besoin de 100 GbE, ce qui est pris en charge par… N01 et N08 — mais il s'agit d'un réseau différent de celui dont il est question dans cet article.

dimensionnement des niveaux de vitesse

Deux choses à retenir :

• Vous n'avez pas besoin de 100 GbE dans un laboratoire à serveur unique. On le choisit souvent car sa fiche technique est impressionnante. Le débit réseau réel et soutenu du serveur K-AI correspond au nombre de jetons émis (Mbit/s) auquel s'ajoutent quelques Gbit/s lors des transferts ponctuels de points de contrôle. Dans un laboratoire dédié à l'inférence, le réseau filaire n'est jamais un facteur limitant.
• Le Wi-Fi est toujours le moyen de connexion le plus lent. Tenez-en compte dans votre planification. Une bonne connexion 6 GHz à un client Wi-Fi 6E offre un débit réel de 1.2 à 1.8 Gbit/s à 10 m en visibilité directe, avec une latence de 3 à 8 ms et une gigue de ±2 ms dans des conditions optimales. Les flux de capteurs de robots (une ou deux caméras RGB-D à 1080p30 chacune) nécessitent un débit soutenu d'environ 150 à 300 Mbit/s ; vous disposez d'une marge confortable, jusqu'à ce qu'un autre utilisateur se connecte au SSID.

Segmentation VLAN

Ce réseau comporte six VLAN non pas par souci d'hygiène informatique, mais pour éviter qu'un dysfonctionnement d'un appareil ne perturbe le fonctionnement des autres.

La faille qui piège les gens : Les robots et K-AI se trouvent sur des VLAN différents même s'ils communiquent constamment entre eux. Le routage inter-VLAN est du ressort du pare-feu/routeur, qui contrôle les communications entre les appareils. Si des robots et l'IA de type K partageaient un VLAN, un robot compromis (et les humanoïdes grand public présentent une surface d'attaque) aurait un accès direct de couche 2 au serveur GPU. C'est absolument inacceptable pour tout déploiement sérieux.

L'autre scission qui mérite d'être défendue : Le plan de gestion constitue son propre VLAN, point final. Les interfaces IPMI/BMC sont livrées avec des failles de sécurité propriétaires depuis vingt ans, et il faut s'attendre à ce que cela reste toujours le cas. Elles disposent de leur propre sous-réseau, de leurs propres règles d'accès, et seul un ordinateur portable d'administrateur sur le VLAN de gestion peut y accéder.

Règles de pare-feu

Interdiction par défaut entre les VLAN. Exceptions :

Deux règles subjectives qu'il convient de signaler :

• Les robots n'ont pas accès à Internet. Les gens s'y opposent car cela interrompt le flux de télémétrie/mise à jour du micrologiciel du fabricant. C'est une bonne chose. Autorisez le serveur de mise à jour du fabricant pendant une fenêtre de maintenance, puis fermez-le. Par défaut, le robot ne peut pas se connecter à son serveur.
• La sortie K-AI WAN est à la demande. Lors du téléchargement d'un modèle ou de l'extraction d'un conteneur, ouvrez le port 443. Sinon, gardez-le fermé. Le serveur d'inférence n'a pas vocation à naviguer sur le Web, et vous ne souhaitez pas qu'un développeur curieux y accède. curl Le script étant le chemin utilisé par un ver pour exfiltrer vos données.

Configuration Wi-Fi

L'erreur la plus fréquente lors de la configuration d'un réseau Wi-Fi pour un laboratoire de robotique est de connecter les robots au même réseau que le bureau. Ce réseau est alors partagé par des téléphones, des ordinateurs portables, des imprimantes, un réfrigérateur connecté et trois personnes en visioconférence. La latence est alors catastrophique et le comportement réactif des robots s'en trouve fortement perturbé.

La bonne réponse :

• Un SSID par VLAN. « lab-robots » sur le VLAN 10, « lab-dev » sur le VLAN 30, « lab-guest » sur le VLAN 99. Le VLAN de gestion n'a aucune présence sans fil.
• Le SSID dédié à la robotique est exclusivement en 6 GHz. Pas de bande 2.4 GHz, ni de repli sur la bande 5 GHz. En effet, les anciens appareils ne pourront pas se connecter ; c’est le but recherché. La bande 6 GHz sera nettement moins encombrée, car le nombre d’appareils anciens qui l’utilisent sera quasiment nul en 2026.
• Largeur de canal 80 MHz, et non 160. La fréquence de 160 MHz semble plus avantageuse sur le papier, mais deux points d'accès 160 MHz dans un même bâtiment s'interfèrent mutuellement. La fréquence de 80 MHz à 6 GHz offre quatre à six canaux dédiés et une latence prévisible.
• Un AP par ~60–80 m² de zone de travail du robot, en ligne de mire si possible. Si le laboratoire est entouré de murs, ajoutez un point d'accès. L'itinérance fonctionne correctement sur le Wi-Fi 6E avec les normes 802.11r/k/v activées, mais un robot en pleine tâche n'apprécie pas une interruption de connexion.
• Désactiver l'équité du temps d'antenne pour le SSID du robot. La configuration par défaut privilégie les clients plus lents ; vous souhaitez que le robot, qui est le seul utilisateur de ce SSID, bénéficie de chaque créneau de temps d'antenne.

Pour le matériel de 2026 : les modèles UniFi U6 Enterprise (Wi-Fi 6E, environ 450 €) ou les plus récents U7 Pro/E7 (Wi-Fi 7, respectivement à partir de 189 € et 499 €) constituent les options les plus économiques. Les gammes Aruba 650 et Cisco Meraki MR représentent les alternatives professionnelles, deux à trois fois plus chères ; leur interface de gestion est plus conviviale et leurs radios offrent de meilleures performances en cas de forte densité de clients, deux caractéristiques superflues pour un déploiement dans un seul laboratoire avec deux robots.

Synchronisation horaire — PTP et NTP

Un décalage d'horloge entre le robot et le serveur perturbe la fusion des capteurs de manière subtile et gênante. Un décalage de 20 ms provoque l'apparition d'objets fantômes dans le système de traitement de la profondeur stéréo. Un décalage de 100 ms induit le planificateur de manipulation en erreur, faisant croire au préhenseur qu'il se trouve à un endroit où il ne se trouve pas.

Deux niveaux de solution :

• NTP au chronyd Par rapport à un serveur local de niveau 1 (un Raspberry Pi avec une carte GPS, environ 80 € tout compris, ou le pare-feu faisant office de serveur de niveau 2). Atteint une précision d'environ 1 ms sur un réseau local câblé et d'environ 5 à 20 ms en Wi-Fi. Suffisant pour la plupart des applications robotiques.
• PTP (IEEE 1588v2) Avec horodatage matériel sur les commutateurs compatibles. Les séries MikroTik CRS3xx/CRS5xx prennent en charge l'horloge de frontière PTP avec une synchronisation à la nanoseconde ; Aruba CX 6300 et Cisco Catalyst la gèrent également. La synchronisation atteint la sous-microseconde sur les liaisons filaires et la sous-milliseconde en Wi-Fi.

Pour 1 à 2 robots, NTP convient parfaitement. Lancer chronyd Sur chaque nœud, configurez-le pour qu'il pointe vers le maître local, surveillez le décalage et déclenchez une alarme en cas de dérive supérieure à 5 ms. Pour quatre robots ou plus, ou pour tout déploiement effectuant une fusion multisensorielle entre machines, utilisez PTP côté réseau câblé et NTP comme solution de repli. Dans tous les cas, surveiller la dériveLe nombre de laboratoires qui « ont une synchronisation horaire » parce qu'ils ont exécuté apt install ntp Il y a deux ans, c'était énorme.

DNS, DHCP et IPAM

Un résolveur local sur le plan de gestion, point final. Pi-hole ou Unbound sur une petite machine virtuelle font l'affaire. Voici pourquoi :

1. Les robots et les serveurs d'inférence doivent résoudre vllm.lab.local, nas.lab.local, etc. sans aller-retour au WAN.
2. Vous souhaitez un seul endroit pour ajouter une entrée d'hôte lorsque vous créez un nouveau point de terminaison K-AI.
3. Pi-hole vous offre un blocage gratuit des publicités et des données de télémétrie pour l'ensemble du réseau, empêchant ainsi les communications indésirables des fabricants de transiter par vos câbles.

DHCP par VLAN, configuré sur le pare-feu/routeur (UDM Pro Max, OPNsense, pfSense le font tous de manière compétente). Des réservations pour tout ce qui compte — robots, serveurs, points d'accès, IPMI, commutateurs, NAS. Les pools dynamiques sont réservés aux visiteurs et aux postes de travail temporaires. Un robot qui reçoit une adresse IP différente à chaque redémarrage risque de voir ses fichiers de lancement ROS 2 dysfonctionner systématiquement.

Le Monitoring

Un laboratoire sans surveillance est un laboratoire où les problèmes sont diagnostiqués par leurs conséquences. Exécutez la pile standard sur le plan de gestion :

• Prométhée commutateur de récupération SNMPv3, compteurs NIC (node_exporter), métriques GPU (dcgm_exporter), et les métriques du serveur d'inférence (vLLM expose Prometheus nativement).
• Grafana Tableaux de bord : utilisation par port, débit par VLAN, température et utilisation du GPU, dérive PTP/NTP, disponibilité de la connectivité du robot.
• Alertes qui se déclenchent réellement : compteur de pause PFC > 0 sur n’importe quel port (cela signifie que quelqu’un congestionne le RDMA, ce qui ne devrait pas se produire sur ce réseau, mais vérifiez quand même), température du GPU > 80 °C, dérive temporelle > 5 ms, anomalie du nombre de clients AP.

SNMPv3, pas v2c. Le laboratoire est suffisamment petit pour que la configuration minimale prenne quinze minutes et que la sécurité minimale soit bien réelle.

Nomenclature du béton — 1 serveur, 2 robots, 4 postes de travail

Liste de courses fonctionnelle et à prix réaliste pour le déploiement de référence, mi-2026, hors TVA :

À titre de comparaison : le serveur K-AI à 8 GPU coûte à lui seul entre 40 000 et 70 000 €, et les deux humanoïdes entre 30 000 et 80 000 € chacun. Le réseau représente 5 à 10 % du budget total et constitue le poste de dépense le plus susceptible de faire la différence entre un laboratoire fonctionnel et un laboratoire non fonctionnel.

Si le budget est limité, voici quelques coupes raisonnables : remplacer le commutateur principal par un MikroTik CRS504-4XQ-IN (4 × QSFP28, ports de dérivation vers 16 × 25 GbE, environ 700 €) et accepter un nombre de ports réduit ; utiliser un seul point d’accès si la zone de travail est inférieure à 60 m² ; se passer de la source NTP GPS et utiliser Chrony sur le WAN.

Erreurs courantes

Par ordre approximatif de fréquence de chaque morsure :

• Mélanger le trafic robotique avec le Wi-Fi général des bureaux. Les variations de latence nuisent à la réactivité. La première solution proposée à chaque appel du type « mon robot dysfonctionne » est de lui attribuer son propre SSID sur la bande 6 GHz.
• Tampons sous-dimensionnés sur des commutateurs bon marché. Un commutateur 10G à 8 ports à 200 € gère correctement deux appareils, mais sature lorsque quatre nœuds utilisent la même liaison montante. Le trafic IA est irrégulier ; les mémoires tampons du commutateur absorbent ces pics. Le commutateur à mémoire tampon profonde le plus abordable et performant présenté dans cet article est l'Aruba CX 6300 (8/16/32 Mo de mémoire tampon partagée) ; le MikroTik CRS5xx offre une mémoire tampon plus faible, mais suffisante pour un laboratoire mono-serveur.
• Pas de maître PTP, pas d'audit NTP. La synchronisation horaire fonctionne jusqu'à un certain point, et la fusion des capteurs échoue silencieusement entre-temps. Surveillez le décalage et l'alarme.
• Budget PoE mal calculé. Un switch est annoncé comme compatible « PoE++ », mais vous découvrez que sa puissance totale est de 200 W, dont la moitié est consommée par des caméras dont personne ne vous a parlé, et par le point d'accès qui subit des baisses de tension au démarrage. Additionnez les puissances consommées et prévoyez une marge de 30 %.
• Le robot est autorisé à téléphoner à la maison. Mise à jour du firmware du fabricant un mardi matin, téléchargeant un nouveau modèle qui modifie la latence d'inférence embarquée, ce qui perturbe la synchronisation de la pince. À chaque fois. Pare-feu WAN pour la sortie du robot ; contrôle manuel des mises à jour.
• Aucune surveillance jusqu'à ce qu'un problème survienne. Le laboratoire fonctionne parfaitement pendant six mois. Puis, le point d'accès commence à déconnecter les clients deux fois par jour, et personne ne s'en aperçoit pendant une semaine, faute de tableaux de bord. Quand quelqu'un finit par se pencher sur le problème, quatre autres éléments ont changé et personne ne sait ce qui a dysfonctionné en premier.

Avis honnête

La plupart des laboratoires de robotique surdimensionnent leur réseau et sous-dimensionnent les composants essentiels. On conçoit des réseaux dorsaux 100 GbE pour des laboratoires d'inférence à serveur unique, puis on connecte le robot au Wi-Fi du bureau. On achète un Cisco Catalyst 9300X avec des tampons importants, puis on utilise une couche 2 plate sans segmentation VLAN.

La conception 80/20 pour un laboratoire à serveur unique et 1 à 4 robots en 2026 est petite et peu attrayante :

• 25 GbE entre le commutateur central et le serveur K-AI. Une carte réseau, un convertisseur numérique-analogique, et c'est tout.
• 10 GbE entre le cœur et l'accès. Deux convertisseurs N/A.
• Un commutateur central, un commutateur d'accès, un pare-feu, un ou deux points d'accès.
• Six VLAN, pare-feu avec blocage par défaut, SSID distincts par rôle.
• NTP provenant d'une source locale, surveillé.
• Prometheus + Grafana sur une petite machine virtuelle.

Dépenses totales pour le réseau : moins de 7 000 €. Délai total de mise en service : environ une semaine si le câblage est prêt. Cette infrastructure comprend un véritable laboratoire de production ; l’étape suivante — un réseau dorsal 100 GbE, des commutateurs Clos routés et des commutateurs IA à mémoire tampon profonde — est destinée à la formation multi-serveurs, domaine de prédilection de… N04, N08 et K02.

---

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.