Configuration de référence : Un laboratoire de robotique et d’IA dans un seul rack

Les articles précédents décrivaient l'architecture, la pile logicielle, la consommation énergétique et la conception du réseau. Celui-ci détaille le prix et la liste des composants, basés sur du matériel réel commercialisé et testé par Kentino, et non sur une nomenclature théorique issue d'un document marketing.

Le déploiement cible est un laboratoire de recherche ou d'intégration exploitant un à quatre robots, avec une infrastructure d'inférence sur site et une piste d'entraînement. Il s'agit d'une infrastructure de taille moyenne : ni un système amateur peinant à gérer 7 milliards de dollars, ni un cluster hyperscale nécessitant une équipe dédiée. C'est un environnement de travail performant qu'une équipe de deux à six personnes peut mettre en place, exploiter et faire évoluer sans personnel DevOps dédié.

L'article aborde deux niveaux d'une même architecture. Le modèle à 4 GPU niveau de développement C'est le point de départ de la plupart des laboratoires. Le système à 8 GPU niveau de production C’est là qu’ils se retrouvent après la première véritable charge de travail. Les choix matériels diffèrent ; l’architecture, elle, est identique.

Ce que montrent les données de la flotte

Kentino a déployé une flotte de nœuds de calcul à quatre GPU, configurés de manière uniforme. Chaque unité possède les mêmes spécifications : processeur AMD EPYC 7542 (32 cœurs / 64 threads, fréquence boost de 2.9 GHz), 512 Go de mémoire DDR4 ECC LRDIMM à 2 4 MT/s répartis sur huit barrettes, quatre GPU RTX 4090 (24 Go de VRAM chacune, soit 96 Go au total), un disque NVMe de 2 To dédié aux tâches et un SSD SATA de 512 Go pour le système d’exploitation. La carte mère est une ASRockRack ROMED8-2666T/BCM. Le système d’exploitation utilisé est Ubuntu 24.04 LTS, avec un noyau 6.8.0-generic, un pilote NVIDIA 590.48.01 et CUDA 13.1/13.2.

Les dix nœuds affichent des résultats de référence identiques. Ce n'est pas un hasard : c'est le principe même d'une configuration de référence. Lorsque chaque unité utilise la même configuration, le résultat du test est une spécification, et non le fruit du hasard.

Calcul GPU

Matmul FP16 Tensor-Core sur les quatre cartes (charge de travail 8192 × 8192) :

Le GPU 1 affiche des performances inférieures d'environ 6 % à celles des GPU 0, 2 et 3, ce qui correspond à l'écart habituel lié à la qualité des puces pour les cartes graphiques grand public. Les quatre cartes ont passé avec succès le test de vieillissement accéléré du GPU (60 secondes) et le test combiné GPU+CPU sans aucune erreur de calcul. La marge de température est confortable : le seuil de limitation thermique pour la RTX 4090 est de 83 °C, et la carte la plus chaude du test a atteint un pic de 73 °C sous charge simultanée GPU et CPU. Aucun bridage thermique n'a été observé sur aucun des nœuds de gravure.

Note pratique concernant les limites de puissance : les cartes de la flotte sont livrées avec des limites légèrement différentes (450 W, 480 W ou 500 W selon l’emplacement). Pour une utilisation intensive en production, normaliser les quatre cartes à 450 W permet de lisser la consommation totale et de réduire le déséquilibre de l’alimentation. La perte de TFLOPS à 450 W par rapport à 500 W est inférieure à 2 %, ce qui ne justifie pas la charge asymétrique sur le réseau électrique.

Inférence vLLM — Lama 3.3 70B AWQ

Testé avec vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

Une mise en garde importante : le référentiel utilisé awq noyau de quantification, non awq_marlinL’ awq_marlin Le chemin d'accès sur Ada Lovelace (RTX 4090) est 2 à 3 fois plus rapide pour la latence d'une requête unique. Les déploiements en production devraient utiliser awq_marlin ou le chemin FP8 sous vLLM 0.20+, qui réduit encore davantage l'écart. awq_marlinLe nombre de requêtes uniques mentionné ci-dessus passe d'environ 8 tok/s à environ 16-20 tok/s sur ces cartes, ce qui correspond davantage à l'expérience utilisateur réelle. Le gain en débit par lots global est proportionnellement plus faible car, en cas de forte concurrence, le goulot d'étranglement se situe au niveau de la bande passante mémoire plutôt que de la puissance de calcul.

Ces chiffres concernent Llama 3.3 70B à INT4 (AWQ). Un modèle 7B ou 8B à Q4 s'exécute 4 à 6 fois plus rapidement par jeton sur le même matériel ; un modèle 13B s'exécute environ 2.5 fois plus rapidement. La valeur de 70B représente la contrainte de dimensionnement pertinente pour VLM et les grands modèles de planification dans un contexte robotique.

llama.cpp — mono-utilisateur, sans concurrence

Testé avec llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, sur les quatre GPU :

llama.cpp se charge plus rapidement (10.8 s contre 95 s pour vLLM) et offre une vitesse de décodage mono-utilisateur supérieure sur ces cartes, car il n'est pas soumis à la surcharge du planificateur de traitement par lots continu. En contrepartie, il n'y a aucune concurrence : un seul utilisateur à la fois. En résumé : sur un nœud à 4 GPU, llama.cpp offre au développeur un modèle 70 octets réactif pour une utilisation interactive ; vLLM est le choix optimal dès lors qu'il y a plus d'un client.

Voir I02 pour la matrice de décision complète de la pile de service. En bref : commencez par vLLM dans Docker, utilisez awq_marlin quantification, et passage à llama.cpp uniquement pour les postes de développement mono-utilisateur ou les déploiements Jetson.

Bande passante de la mémoire GPU

La bande passante entre les périphériques (sur carte) est constante entre 920.2 et 920.6 Go/s sur les quatre cartes, avec une variation inférieure à 0.04 %, confirmant que la GDDR6X n'est pas en cause. La bande passante PCIe hôte → périphérique atteint 26.2 à 26.3 Go/s, confirmant que la négociation Gen4 x16 est pleinement effective en charge (l'état de la liaison au repos affiche Gen1 en raison de l'économie d'énergie ASPM ; il s'agit d'un comportement normal et non d'un défaut). Les transferts de GPU à GPU via PCIe (sans NVLink) mesurent entre 19 et 22 Go/s, ce qui correspond à la limite attendue pour les transferts pair à pair sur un complexe racine PCIe partagé sans NVLink (voir [référence manquante]). N03 pour le contexte).

Stockage NVMe

La bande passante séquentielle est proche de la limite Gen4 x4. Les IOPS aléatoires à une profondeur de file d'attente de 32 atteignent une bonne saturation : 568 000 IOPS en lecture dépassent largement les besoins liés au chargement des poids LLM ou aux accès aux données à l'échelle d'un nœud unique. Le chargement du modèle du NVMe vers la VRAM prend entre 10 et 30 secondes selon sa taille ; ce disque n'est donc pas le facteur limitant.

La configuration de référence

Nomenclature des composants (BOM) — Niveau de développement à 4 GPU

Le niveau de développement est le point de départ idéal pour un laboratoire utilisant un ou deux robots, un ou deux modèles actifs et effectuant occasionnellement des réglages LoRA.

Niveau de développement : nœud de calcul 4 GPU + commutateur ToR géré + point d'accès 6 GHz + onduleur en ligne 5 kVA.

Nomenclature — Niveau de production 8 GPU

Le niveau de production double le nombre de GPU. L'architecture reste la même ; le processeur, la RAM et le châssis sont dimensionnés en conséquence pour prendre en charge huit emplacements PCIe à pleine bande passante. Une plateforme AMD EPYC Genoa ou Turin fournit le nombre de lignes PCIe nécessaires pour huit emplacements x16 sans compromis sur la bifurcation (voir W02).

Remarque : la carte réseau 25 GbE supplémentaire est uniquement compatible avec les châssis à 8 GPU. Le châssis à 4 GPU ne dispose pas de l’espace nécessaire pour une carte réseau supplémentaire ; les ports 10 GbE intégrés du ROMED8-2T/BCM constituent la limite pratique pour les configurations à 4 GPU (voir N01 et les règles de la page produit).

Stockage au-delà du nœud de calcul

Pour l'environnement de développement, un NAS à 4 baies avec 4 disques durs de 16 To offre 48 To utilisables en RAID 5, soit suffisamment de données pour une année de production dans un laboratoire à 2 robots. Connectez-le en 10 GbE au commutateur ToR ; ne le placez pas sur la même interface que le trafic des robots.

Alimentation et refroidissement du rack

Dès I04:

Les données des tests de charge confirment que le nœud à 4 GPU consomme environ 1 914 W à pleine charge GPU, les quatre cartes atteignant leurs limites de puissance. En ajoutant la consommation du CPU (environ 120 W en continu), du NVMe et des ventilateurs, la consommation du nœud atteint environ 2.1 à 2.2 kW en continu.

Installation électrique pour l'environnement de développement : une alimentation triphasée de 400 V et 16 A est le minimum requis ; une alimentation triphasée de 32 A permet une marge d'évolution. Câbles d'alimentation sur deux phases distinctes. Voir I04 et P02 Pour le câblage, pour le niveau de production (rack complet de 10 kW), il vous faut une alimentation triphasée de 400 V 32 A avec une capacité de refroidissement d'au moins 15 kW.

Dimensionnement de l'onduleur : dimensionnement pour le serveur uniquement, pas pour les robots. Pour l'environnement de développement, un onduleur en ligne à double conversion de 5 kVA est le minimum raisonnable. Pour l'environnement de production, 10 kVA. Spécifiez toujours un onduleur en ligne à double conversion. Voir P05.

Pile logicielle sur matériel nu

Pile logicielle : Ubuntu épinglé + pilote NVIDIA → boîte à outils de conteneur → vLLM + llama.cpp + nginx + surveillance.

L'affectation des conducteurs est non négociable. La flotte utilise le conducteur 590.48.01 ; apt-mark hold nvidia-driver-590 C'est la première chose à faire après l'installation d'un système d'exploitation nu. Une installation sans surveillance apt-get upgrade L'installation d'un pilote plus récent a provoqué des erreurs de production exactement autant de fois que prévu. Voir L01 pour la procédure complète.

La surveillance est indispensable. Les données du parc de machines montrent que le GPU 3 d'un nœud a présenté des erreurs PCIe AER corrigibles (RxErr + BadTLP) lors des tests de performance — corrigées automatiquement par le matériel, mais visibles dans les compteurs DCGM. Sans surveillance, cela se manifeste par des « erreurs d'inférence étranges et ponctuelles » plusieurs semaines plus tard. Configurez DCGM et paramétrez une alerte en cas de dépassement d'un taux d'erreurs ECC corrigibles de base. Voir L05 pour la pile Prometheus + Grafana.

Variations de taille

Le niveau de développement à 4 GPU — ce qu’il peut réellement exécuter

96 Go de VRAM au total (4 × 24 Go) avec TP=4 :

La VLM 72 octets ne tient pas confortablement sur 4 × 24 Go à INT4 : le calcul est presque bon, mais les fenêtres contextuelles au-delà de 4K la dépassent. Utilisez la variante VLM 32 octets, ou passez à une configuration 8 GPU ou à un nœud Blackwell 4 × RTX Pro 6000 (96 Go de VRAM chacune) pour la classe 72 octets. Voir W07 pour la discussion sur la VRAM par rapport au niveau du modèle.

La couche de développement gère : un modèle d’inférence de 70 milliards de caractères desservant 1 à 3 robots clients simultanés, un VLM (classe de 32 milliards de caractères) pour les requêtes visuelles et des ajustements ponctuels LoRa sur un modèle de base plus petit. Cela couvre 80 % des cas d’utilisation des laboratoires de robotique en 2026.

Le niveau de production à 8 GPU — la marge de manœuvre supplémentaire

192 Go de VRAM totale (8 × 24 Go) :

L'architecture à 8 GPU permet également le traitement simultané de plusieurs modèles : un LLM de 70 octets sur 4 GPU et un VLM de 32 octets sur les 4 autres, gérant simultanément une flotte de robots hétérogène aux exigences de modèles différentes, à partir d'un seul système. Avec une architecture à 4 GPU, cela nécessite une étape de changement de modèle, entraînant une interruption de service de 30 à 120 secondes par changement.

Remarque concernant TP=8 pour un processeur 70B : TP=8 sur PCIe peer-to-peer (sans NVLink) est moins performant que TP=4 × PP=2 pour une concurrence supérieure à 8, car le coût de communication pour la réduction globale augmente avec le degré de parallélisme des tenseurs. Les données de référence montrent une bande passante PCIe GPU-à-GPU de 19 à 22 Go/s, suffisante pour TP=4, mais la réduction globale avec TP=8 et des tailles de lots élevées sature ces liaisons. La configuration recommandée pour un processeur 70B sur 8 × 4090 est TP=4 × PP=2, comme indiqué dans… I02.

Agencement des racks

Le nœud de calcul est toujours placé sous le commutateur et l'onduleur ; le flux d'air d'avant en arrière exige que l'air froid entre par l'avant de la baie (allée froide ou alimentation électrique de la salle), traverse le serveur et sorte dans l'allée chaude à l'arrière. Voir W05 et I04 pour la discipline du flux d'air.

Le serveur de rebond est une machine 1U ou compacte dotée d'un port DisplayPort, utilisée pour la mise en service initiale, l'installation des pilotes et la maintenance lorsque le serveur principal est inaccessible sur le réseau. Il ne nécessite pas de carte graphique. Une station de travail d'occasion ou une machine 1U compacte avec 16 Go de RAM et un SSD Gen3 convient parfaitement.

Ce que cette configuration n'est pas

Il ne s'agit pas d'un serveur GPU de bureau dans un boîtier rack. La configuration tour ouverte (cartes graphiques montées sur une carte riser, sans boîtier, ventilateurs orientés vers le plafond) ne correspond pas à ce qui est décrit ici. Les configurations de bureau conviennent au développement ; elles ne sont pas conçues pour un fonctionnement continu 24 h/24 et 7 j/7 et n’offrent pas le flux d’air dirigé de l’avant vers l’arrière nécessaire au maintien d’une température de fonctionnement stable des cartes graphiques pendant plusieurs semaines.

Il ne s'agit pas d'un cluster NVLink. La RTX 4090 (grand public/stations de travail) ne prend pas en charge NVLink. Les transferts GPU-à-GPU s'effectuent via PCIe à 19-22 Go/s, et non à 900 Go/s. Ceci est suffisant pour l'inférence TP=4, mais constitue une véritable limitation pour l'entraînement TP=8. Si votre charge de travail consiste en un entraînement distribué intensif sur un modèle de plus de 70 milliards de données, la RTX Pro 6000 Blackwell (compatible NVLink dans sa version multi-GPU) ou une plateforme avec NVSwitch change la donne, mais aussi le prix. Voir N03.

Alimentations non redondantes. La configuration à double alimentation répartit l'alimentation : l'alimentation A alimente les GPU 0 et 1 (ainsi que la carte mère), l'alimentation B alimente les GPU 2 et 3. Si l'alimentation A tombe en panne, deux GPU et la carte mère sont hors service. Aucun système de basculement automatique n'est installé. Il s'agit d'une véritable alimentation à double alimentation : elle équilibre la charge sur les rails et réduit le risque de panne unique par rapport à une seule alimentation de grande capacité, mais elle n'offre pas une redondance N+1. Voir W04.

Pas une solution cloud pour tout. Si la charge de travail principale de votre laboratoire consiste en un seul appel de modèle dix fois par jour, le calcul du coût total de possession (TCO) ne justifie pas une infrastructure sur site. Cette architecture est rentable par rapport aux dépenses liées aux API cloud lorsque vous effectuez des inférences continues pour plusieurs clients, des réglages fins réguliers ou lorsque vous êtes soumis à des contraintes de résidence des données. Voir T02 pour les calculs mathématiques détaillés.

Pourquoi ces choix précis ?

AMD EPYC 7542 comme processeur hôte. Un processeur EPYC à 32 cœurs offre à lui seul 128 lignes PCIe 4.0, suffisantes pour 4 GPU en x16 sans bifurcation, ainsi qu'une carte réseau, du stockage et un commutateur PCIe pour l'extension. L'EPYC est la plateforme standard pour les serveurs d'IA multi-GPU de cette envergure, et ce pour une bonne raison : à nombre de cœurs égal, les processeurs Intel Xeon offrent moins de lignes PCIe, ce qui impose des compromis en matière de bifurcation pour les configurations à plus de 4 GPU. Voir W02 pour le calcul du nombre de voies.

512 Go de mémoire vive système. La flotte est livrée avec 512 Go (8 × 64 Go), dépassant ainsi les 256 Go spécifiés. Ce surcroît de mémoire est intentionnel : le chargement de modèles volumineux au démarrage du conteneur, le préchargement des données d’entraînement et le cache de pages du système d’exploitation consomment de la RAM que la VRAM ne peut pas utiliser. Pour vLLM avec espace d’échange du cache KV activé, la RAM système est directement utilisable comme mémoire de débordement ; un espace d’échange de 4 Go par GPU nécessite 16 Go de RAM système disponible. Les 512 Go offrent cette marge, avec de l’espace supplémentaire pour Isaac Sim, qui peut stocker de 10 à 30 Go d’état de simulation en RAM système pendant l’entraînement des politiques.

Disque de travail NVMe de 2 To. Le test de performance affiche une vitesse de lecture séquentielle de 4 589 Mo/s, suffisante pour charger un modèle FP8 de 70 octets (environ 75 Go) en moins de 20 secondes. Pour un laboratoire qui change fréquemment de modèles (flux de travail de développement, tests A/B), le temps de chargement est crucial. Un SSD SATA plus lent double, voire triple, ce temps à chaque changement.

Flux d'air du rack d'avant en arrière. L'erreur la plus fréquente lors des premiers montages : l'orientation du poste de calcul (entrée d'air latérale, extraction d'air par le haut ou par l'arrière) ne fonctionne pas dans une baie fermée. Le nœud de calcul doit utiliser un flux d'air dirigé correspondant à la convention allée froide/allée chaude de la baie. Voir I01 et W05.

Un avis honnête sur le matériel de 2026

Il s'agit d'une configuration de référence pour mai 2026. La RTX 4090 n'est pas la plus récente option de GPU Kentino : les RTX 5090 (32 Go de VRAM, architecture Blackwell, sm_120) et RTX Pro 6000 Blackwell (96 Go de VRAM) sont disponibles et modifient considérablement le calcul de la VRAM par carte. Un nœud à 4 GPU avec RTX Pro 6000 Blackwell offre 384 Go de VRAM, ce qui est suffisant pour faire tourner confortablement Qwen 2.5 VL 72B en FP8 sur quatre cartes, moyennant un coût par carte proportionnellement plus élevé.

Ce qui reste inchangé d'une génération à l'autre : l'architecture. Serveur AMD EPYC, multi-GPU PCIe, châssis à double alimentation, Ubuntu 24.04, vLLM dans Docker, exportateur Prometheus + DCGM. Cette architecture est restée la même pendant deux générations de GPU et le restera pour la prochaine. Les composants sont moins chers et plus performants ; l'architecture, elle, demeure.

---

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.