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 la logique de décision qui sous-tend cette répartition : quand un seul boîtier à 8 GPU est la solution adéquate, quand il ne l’est pas, et comment déterminer de quel côté de la ligne se situe votre charge de travail. Des articles complémentaires traitent des aspects techniques (K02 ou autre K03 inférence, K07 limites PCIe, K06 gestion des défaillances) ; c'est à l'acheteur de décider.

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 fonctionnement : allouer 60 à 70 % de la VRAM, laissant 30 à 40 % pour le reste. Avec cette contrainte, 405 octets à FP8 fonctionnent correctement. pas S'adapte parfaitement à 8× Pro 6000 pour l'inférence à n'importe quel niveau de concurrence utile — il s'adapte aux poids, pas à 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înement d'un modèle 70B+ à partir de zéro. Huit GPU ne suffisent pas en termes de temps de calcul. Un pré-entraînement de 70 milliards de données avec les budgets de jetons publiés (1.5 à 15 T) nécessite des centaines de mois-GPU sur du matériel de classe H100, et davantage sur des GPU grand public PCIe. Ce travail requiert entre 32 et 128 GPU, voire plus, ainsi qu'une architecture SXM. Kentino ne propose pas ce niveau de service.

Réglage fin complet du rang 70B+. Il ne s'agit pas de LoRA : un réglage fin complet est nécessaire, avec les états de l'optimiseur, les gradients et les activations résidents. Un réglage fin complet de 70 milliards de données (poids FP16 + Adam FP32 + gradient + activation) représente 1.2 à 1.5 To d'état, dépassant la capacité d'un nœud de 8 GPU, même avec FSDP. Cela justifie un cluster IB de 2 à 4 nœuds.

Hébergement de plus de 405 milliards de bits avec une latence de production. La configuration avec 8 processeurs Pro 6000 (8 GPU) permet de gérer les poids de manière optimale, mais 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=4 × PP=2 ou TP=4 × PP=4 constituent le minimum réaliste pour Llama 3.1 405B avec un débit QPS correct. K03 déballe ceci.

Production multi-locataires avec un agrégé de >100 000 requêtes par seconde. Un nœud à 8 GPU gère un débit agrégé de 500 à 2 000 requêtes par seconde à 70 milliards de FP8. Au-delà de quelques dizaines de milliers de requêtes par seconde, plusieurs réplicas sont nécessaires, et au-delà encore, un véritable cluster avec routeur et routage prenant en compte le cache de préfixes s'impose. La solution optimale consiste généralement en plusieurs réplicas DP, plutôt qu'en un seul cluster TP gigantesque.

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 :

La contrainte principale : NVLink n'est pas présent sur ces cartes. Les cartes graphiques RTX 5090, RTX Pro 6000 Blackwell, L40 et L4 sont connectées via PCIe. Les modules SXM NVLink (H100 SXM, B200 SXM, GB200) nécessitent des cartes mères HGX que nous ne fabriquons pas. K07 couvre les frais; N03 Couvre les cas où NVLink est important.

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 fréquence inférieurs à la microseconde. Entre nœuds, on obtient environ 25 Go/s sur une liaison Internet de 200 Gbit/s (IB) : une pénalité de 2x sur IB, de 4 à 5x sur 100 Gbit/s et de 15x sur 25 Gbit/s. Pour les groupes de transfert de données (TP) qui activent chaque couche de transformateur, cela représente un coût important. K07 possède le tableau de chronométrage de réduction totale.

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 à retenir. 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 ordinateur. — chaque interface inter-nœuds est plus lente que le PCIe interne de votre boîtier. Deuxièmement, Le parallélisme de données s'adapte beaucoup mieux que le parallélisme de tenseurs sur l'ensemble du réseau. Si votre véritable question est « puis-je traiter plus de requêtes » plutôt que « puis-je exécuter un modèle plus gros plus rapidement », les réplicas DP fonctionnent, et ils fonctionnent sur une connexion 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.

---

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.