Architecture mono-nœud multi-GPU vs architecture multi-nœuds : quand faut-il passer à l’échelle ?

L'erreur la plus coûteuse lors de l'achat d'un GPU est de répartir le budget entre deux nœuds alors qu'un seul nœud plus puissant aurait suffi. La deuxième erreur la plus coûteuse est de se contenter d'un seul nœud alors que la charge de travail exige réellement une architecture réseau performante, puis de passer six mois à faire comme si le système suivait.

Cet article expose les éléments de décision justifiant ce choix : quand une configuration à 8 GPU est la solution adéquate, quand elle ne l’est pas, et comment déterminer de quel côté se situe votre charge de travail. D’autres articles abordent les aspects techniques ( entraînement K02 , inférence K03 , limites PCIe K07 , gestion des pannes K06 ) ; celui-ci laisse le choix à l’acheteur.

Le plafond de 8 GPU, par modèle

La première question est de savoir si le modèle tient dans une seule gravure. Avec 8 RTX Pro 6000 Blackwell (96 Go chacune), on obtient 768 Go de VRAM utilisable ; avec 8 RTX 5090 (32 Go chacune), on obtient 256 Go. Aucune de ces configurations n'est négligeable selon les standards de 2026, mais aucune ne peut tout contenir.

Le point critique se situe à la limite 405 octets / 671 octets. En dessous, un seul système Pro 6000 à 8 GPU suffit. Au-delà, soit vous devez quantifier de manière agressive (poids INT4 — convenable pour l'inférence, catastrophique pour l'entraînement), soit vous franchissez la limite d'un nœud.

« Compatible » ne signifie pas « fonctionne correctement ». Un modèle occupant 95 % de la VRAM sans marge pour le cache KV, le cache de préfixes, les graphes CUDA ou la mémoire d'activation interrompra les requêtes en cas de charge réelle. La règle de base : allouer les ressources à 60-70 % de la VRAM, laissant 30-40 % pour le reste. Avec cette contrainte, 405 octets en FP8 ne tiennent pas confortablement sur 8 processeurs Pro 6000 pour l'inférence à un niveau de concurrence utile ; l'allocation est optimale pour les ressources, mais pas pour la charge de travail.

Quand il ne faut PAS passer à l'échelle supérieure

Cas où le choix d'un nœud unique est sans ambiguïté correct :

• Inférence pour tout modèle approprié. Si le modèle plus KV atteint la concurrence cible, le protocole TP multi-nœuds sur Ethernet ou IB est systématiquement plus lent que le protocole mono-nœud. Le PCIe Gen5 intégré offre environ 50 Go/s entre les GPU sur le même commutateur ; l'IB à 200 Gbit/s entre les nœuds offre environ 25 Go/s. Une charge de travail qui peine sur PCIe est extrêmement lente sur IB.
• Service de production mono-locataire. Un seul modèle, un seul client, une concurrence modérée. Un Pro 6000 à 8 GPU gère sans problème 70 octets avec 32 à 64 requêtes simultanées. Un second serveur ne sert qu'en tant que serveur de secours ou pour doubler le débit du DP ; il ne s'agit pas d'une véritable montée en charge.
• Laboratoires de recherche utilisant les modèles 7B–72B. La plupart des travaux de recherche et d'application prévus en 2026 se concentrent ici : Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma et la queue de réglage fin de 70B. Aucun de ces projets ne nécessite plus d'un nœud.
• Réglage fin LoRA / QLoRA. L'intérêt de PEFT réside dans le fait qu'il ne nécessite pas de ressources d'entraînement complètes pour le modèle. 70 octets de données LoRa tiennent sur 4 à 8 GPU dans un seul nœud ; 405 octets de données QLoRA tiennent sur 8 GPU Pro 6000.
• Inférence par lots et charges de travail hors ligne. Si le SLA stipule « traiter ce corpus d'ici vendredi », le traitement par lots en mode débit sur un seul serveur à 8 GPU suffit. Le recours à plusieurs nœuds n'est utile que si le traitement ne peut être terminé à temps, généralement parce que le modèle est trop volumineux, et non parce qu'un nœud est trop lent.

Environ 80 % des clients de Kentino devraient acheter un nœud plus gros au lieu de deux plus petits, et la plupart des 20 % restants souhaitent en réalité des répliques DP derrière un équilibreur de charge, et non un cluster.

Quand vous DEVEZ passer à l'échelle supérieure

Les cas où un seul nœud ne suffit réellement pas sont plus rares qu'on ne le pense.

Entraîner un modèle de plus de 70 milliards d'éléments à partir de zéro nécessite huit GPU, soit un temps de calcul insuffisant. Un pré-entraînement de 70 milliards d'éléments avec les budgets de jetons publiés (1.5 à 15 T) prend des centaines de mois-GPU sur du matériel de classe H100, et encore plus sur des GPU grand public PCIe. Cette tâche requiert entre 32 et 128 GPU, voire plus, ainsi qu'une architecture SXM. Kentino ne fournit pas cette infrastructure.

Optimisation complète de rang supérieur à 70 milliards d'itérations. Il ne s'agit pas d'une optimisation LoRA, mais d'une optimisation complète avec états, gradients et activations résidents. Une optimisation complète de 70 milliards d'itérations (poids FP16 + Adam FP32 + gradient + activation) représente 1.2 à 1.5 To d'état, dépassant la capacité d'un nœud 8 GPU, même avec FSDP. Cela justifie un cluster IB de 2 à 4 nœuds.

L'hébergement de plus de 405 octets avec une latence de production permet de gérer efficacement les poids sur 8 serveurs Pro 6000 (INT4). Cependant, le cache KV et le service simultané avec une latence acceptable nécessitent deux nœuds, voire plus. Deux serveurs Pro 6000 à 8 GPU en configuration TP=8 × PP=2 ou TP=4 × PP=4 constituent le minimum réaliste pour Llama 3.1 avec un débit QPS correct et un débit de 405 octets. K03 détaille ce point.

Production mutualisée avec un débit agrégé supérieur à 100 000 requêtes par seconde (QPS). Un nœud à 8 GPU gère un débit agrégé de 500 à 2 000 tok/s à 70 milliards de FP8. Au-delà de quelques dizaines de milliers de QPS, plusieurs réplicas sont nécessaires, puis un véritable cluster avec routeur et routage prenant en compte le cache de préfixes. La solution optimale consiste généralement en plusieurs réplicas DP, plutôt qu'en un seul cluster TP géant.

En dehors de ces quatre cas, l'argument perd rapidement de son utilité. La plupart du temps, les demandes de « multi-nœuds » se transforment en « je veux plus de débit » — une question de réplication, et non d'infrastructure réseau.

Le point idéal à nœud unique

La géométrie d'une architecture mono-nœud robuste, sur le matériel que Kentino livre réellement :

Contrainte principale : NVLink n’est pas disponible sur ces cartes. Les RTX 5090, RTX Pro 6000 Blackwell, L40 et L4 sont connectées en PCIe. Les modules SXM compatibles NVLink (H100 SXM, B200 SXM, GB200) nécessitent des cartes mères HGX que nous ne fabriquons pas. La solution K07 couvre le coût ; la solution N03 couvre les cas où NVLink est nécessaire.

L'interface PCIe est idéale pour les travaux axés sur l'inférence et la plupart des entraînements, à l'exception des modèles de pointe. Le traitement par lots en mode débit permet d'amortir le coût de la réduction globale pour l'inférence. Pour l'ajustement fin de modèles de taille fixe, le surcoût en temps réel par rapport à SXM est de 1.2 à 1.4 fois, ce qui est généralement acceptable. Pour l'entraînement parallèle de tenseurs de plus de 70 milliards d'éléments à partir de zéro, ce surcoût est de 2 à 3 fois, et la conclusion est sans appel : « Achetez SXM ou n'effectuez pas ce travail sur du matériel Kentino. »

Le fossé entre nœud unique et nœuds multiples

Ce qui distingue les systèmes multi-nœuds, c'est le fossé d'interconnexion entre les nœuds internes et externes, en termes de bande passante et de latence.

Au sein d'un même boîtier, deux GPU communiquent à environ 50 Go/s avec des sauts de temps inférieurs à la microseconde. Entre nœuds, on obtient environ 25 Go/s sur une liaison Internet de 200 Gbit/s (IB) — soit une pénalité de 2x sur IB, de 4 à 5x sur 100 Gbit/s et de 15x sur 25 Gbit/s. Pour les opérations collectives de transformation qui activent chaque couche de transformateur, cela a un impact considérable. K07 dispose de la table de timings optimisée.

La latence amplifie ce phénomène : le délai entre les nœuds est de 5 à 15 microsecondes sur un RoCE optimisé, contre quelques nanosecondes à l’intérieur d’une box. Pour l’entraînement et le préremplissage, cet écart est négligeable ; pour l’inférence interactive à faible latence avec un TP serré, il ne l’est pas.

C’est là le problème : ajouter un boîtier supplémentaire n’est pas une décision à prendre à la légère. Ce qui fonctionne à peine sur PCIe au sein d’un nœud ne fonctionnera pas sur Ethernet ou IB entre les nœuds.

Mathématiques à forte échelle : leurs limites

Loi d'Amdahl : l'accélération est limitée par la fraction séquentielle de la charge de travail, et pour l'entraînement distribué, cette fraction correspond à la surcharge de communication. Pour une étape d'entraînement de classe 70B sur du matériel PCIe de classe Kentino, l'efficacité de mise à l'échelle (débit par GPU par rapport à la performance de base sur un seul GPU) se présente comme suit pour les versions que nous avons déployées :

Deux points importants. Premièrement, répartir une tâche nécessitant 8 GPU sur deux nœuds de 4 GPU est moins performant que de l'exécuter sur un seul serveur : chaque interconnexion est plus lente que l'interface PCIe interne du serveur existant. Deuxièmement, le parallélisme de données s'adapte bien mieux que le parallélisme de tenseurs sur une infrastructure. Si votre véritable question est « puis-je traiter plus de requêtes » plutôt que « puis-je exécuter un modèle plus volumineux plus rapidement », les réplicas DP sont une solution efficace, et ils fonctionnent même avec une connectivité 100 GbE standard.

Si l'efficacité prévue chute sous les 60 %, la charge de travail est inadaptée à une architecture multi-nœuds sur une infrastructure standard. Il est nécessaire de repenser l'architecture (TP intégré à un nœud, PP ou DP répartis), d'acquérir un nœud unique plus puissant ou d'opter pour du matériel de type SXM. La solution par la force brute est inefficace.

Le piège des laboratoires de recherche et la taxe opérationnelle

Un schéma récurrent qu'il convient de souligner : un laboratoire, prévoyant l'avenir, commande deux nœuds à 4 GPU au lieu d'un seul à 8 GPU. Résultat : un entraînement moins performant (0.65 fois le taux de vrais positifs inter-nœuds contre 0.73 fois le taux de vrais positifs intra-nœud), une inférence moins efficace pour tout modèle tenant sur un seul serveur, une charge opérationnelle doublée (deux BMC, deux configurations de carte réseau, deux états de broches de pilotes, deux domaines de défaillance), et un coût des composants sensiblement identique après la mise à niveau avec la deuxième carte réseau, la deuxième alimentation et le commutateur. Mieux vaut opter pour un seul nœud à 8 GPU dès le départ.

Le multi-nœuds, lorsqu'il constitue la solution adéquate, n'est pas gratuit. La taxe supplémentaire :

• Stockage partagé — le NVMe local ne suffit plus. NFS, BeeGFS ou Lustre, plus un VLAN de stockage (K04).
• points de contrôle asynchrones fragmentés — Les écritures synchrones non partitionnées sur NFS bloquent le cluster. PyTorch DCP ou NeMo est requis.
• Réglage NIC et NCCL — Contrôle de flux RoCE, PFC, ECN, trames jumbo, choix du transport NCCL, fichiers de topologie, algorithmes en anneau ou en arbre. Tout sera mal configuré par défaut.
• Le Monitoring — DCGM par nœud, fédération Prometheus, tampons de trace NCCL.
• Gestion des échecs — Déconnexions de nœuds, réinitialisations de cartes réseau, instabilités des ports de commutation. K06 couvre les modes ; les taux de défaillance multi-nœuds sont environ N fois supérieurs à ceux d'un seul nœud, la récupération est plus complexe.

En termes de temps d'ingénierie, le coût d'un cluster multi-nœuds est multiplié par 4 à 5 par nœud supplémentaire. Prévoyez-le, sinon vous risquez de voir le cluster fonctionner à mi-capacité théorique pendant ses six premiers mois.

Le flux de décision concret

Suivez ces étapes dans l'ordre. Le premier « oui » met fin à la conversation.

1. Le modèle tient-il dans 8 × 96 Go à FP8 avec une marge de 30 à 40 % de VRAM pour KV ? Si oui, un nœud, c'est terminé.
2. Est-ce que ça rentre en INT4 avec la même hauteur sous plafond ? Si oui, et que vous effectuez une inférence (et non un entraînement), un nœud au niveau INT4 est la solution. Les poids INT4 ne sont pas adaptés au chemin de gradient de l'entraînement ; poursuivez.
3. La charge de travail est-elle limitée par le débit plutôt que par la taille du modèle ? Si oui, la solution consiste à utiliser des répliques de données parallèles de configurations à un seul nœud, et non un cluster. Deux machines derrière un équilibreur de charge suffisent, sans infrastructure réseau.
4. La charge de travail correspond-elle à l'entraînement parallèle tensoriel d'un modèle qui ne tient pas sur un seul nœud ? Multi-nœuds avec InfiniBand. Optimisation de l'efficacité du passage à l'échelle du projet grâce à K07Tableau de . En dessous de 60 %, repenser l'architecture (TP à l'intérieur, PP à l'extérieur) ou réduire le nombre de nœuds et accepter un temps d'exécution plus long.
5. La charge de travail consiste-t-elle à pré-entraîner un modèle de plus de 70 milliards d'éléments à partir de zéro ? Cas particulier. Architecture multi-nœuds avec NDR IB ou SXM. Kentino peut gérer la partie IB, mais la plupart des clients qui posent la question n'ont pas besoin de s'en charger eux-mêmes.

Les étapes un et deux représentent l'essentiel du marché. L'étape trois indique une bonne croissance : il s'agit alors de répliques, et non d'un regroupement. Les étapes quatre et cinq sont réelles, mais rares.

Avis honnête

L'architecture multi-nœuds est à la pointe du progrès : plus de 70 milliards de requêtes d'entraînement à partir de zéro, plus de 405 milliards d'inférences avec une latence de production, des infrastructures hyperscale gérant plus de 100 000 requêtes par seconde, ou encore des recherches exigeant un débit journalier qu'un seul serveur ne peut atteindre. Ce sont des charges de travail réelles. Elles ne représentent pas la majorité des infrastructures actuellement développées.

Pour tout le reste, un nœud 8 GPU bien configuré est la solution. Il exécute sans problème toutes les charges de travail d'inférence open-weight de 2026 Go pouvant tenir dans 768 Go en FP8/INT4, LoRa et QLoRa jusqu'à 405 octets, et effectue des réglages fins complets pour les calculs de classe 13 octets. Il peut également être étendu à deux ou trois réplicas DP pour augmenter le débit sans nécessiter d'infrastructure de cluster. De plus, son utilisation est considérablement plus simple.

Le déroulement de nos échanges avec la plupart des clients est le suivant : description de la charge de travail, calcul de l’adéquation aux besoins, estimation de l’efficacité de la mise à l’échelle. Si la configuration envisagée est un cluster, nous créons un cluster. Si elle ne nécessite qu’un seul nœud, nous créons un seul nœud. Si elle nécessite deux réplicas derrière un routeur, nous mettons en place cette configuration. Nous ne vous proposons pas la configuration la plus imposante que vous puissiez tolérer, mais celle qui fonctionnera réellement.

---

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. Commentaires et corrections bienvenus à info@kentino.com.