Mono-nœud multi-GPU ou multi-nœud : quand passer à l'échelle

L'erreur la plus coûteuse au moment de l'achat consiste à répartir un budget GPU sur deux nœuds alors qu'un seul nœud plus puissant aurait suffi. La deuxième plus coûteuse consiste à rester sur un seul nœud alors que la charge de travail réclame vraiment un réseau d'interconnexion, puis à passer six mois à faire comme si la machine suivait le rythme.

Cet article expose la logique de décision derrière ce choix : quand une seule machine à 8 GPU est la bonne réponse, quand elle ne l'est pas, et comment savoir de quel côté de la ligne se situe votre charge de travail. Les articles associés traitent des aspects techniques (K02 entraînement, K03 inférence, K07 limites PCIe, K06 gestion des pannes) ; celui-ci porte sur la décision d'achat.

Le plafond des 8 GPU, modèle par modèle

La première question est de savoir si le modèle tient dans un seul nœud. Avec 8× RTX Pro 6000 Blackwell (96 GB chacune), vous disposez de 768 GB de VRAM utilisable ; avec 8× RTX 5090 (32 GB chacune), de 256 GB. Aucune de ces valeurs n'est modeste au regard des standards de 2026, aucune ne suffit à tout contenir.

La rupture se situe à la ligne 405B / 671B. En dessous, une seule machine à 8 GPU Pro 6000 suffit. À ce niveau et au-delà, soit vous quantifiez agressivement (poids INT4 — très bien pour l'inférence, désastreux pour l'entraînement), soit vous franchissez la frontière du nœud.

« Tenir » n'est pas la même chose que « bien tourner ». Un modèle qui occupe 95 % de la VRAM sans marge pour le cache KV, le cache de préfixes, les graphes CUDA ou la mémoire d'activation préemptera des requêtes sous toute charge réelle. La règle pratique : les poids à 60–70 % de la VRAM, 30–40 % laissés au reste. Avec cette contrainte, un 405B en FP8 ne tient pas confortablement sur 8× Pro 6000 pour de l'inférence à une concurrence utile : la place est là pour les poids, pas pour la charge de travail.

Quand il ne faut PAS passer à plusieurs nœuds

Les cas où rester sur un nœud unique est sans ambiguïté le bon choix :

• Inférence de tout modèle qui tient. Si le modèle plus le cache KV tiennent à la concurrence visée, le parallélisme tensoriel multi-nœuds sur Ethernet ou IB est strictement plus lent qu'un nœud unique. Le PCIe Gen5 interne offre ~50 GB/s entre GPU sur le même switch ; l'IB 200 Gbps entre nœuds offre ~25 GB/s. Une charge qui peine sur PCIe se traîne sur IB.
• Mise en production mono-locataire. Un modèle, un client, une concurrence modérée. Une machine à 8 GPU Pro 6000 absorbe sans peine un 70B avec 32 à 64 requêtes simultanées. Une deuxième machine ne sert que de secours à chaud ou à doubler le débit en parallélisme de données — ni l'un ni l'autre n'est un passage à l'échelle au sens fortement couplé.
• Laboratoires de recherche exploitant des modèles de 7B à 72B. L'essentiel des travaux académiques et appliqués de 2026 se situe ici — Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma, la longue traîne des réglages fins de 70B. Aucun n'exige plus d'un nœud.
• Réglage fin LoRA / QLoRA. Tout l'intérêt du PEFT est de se passer des ressources d'un entraînement complet. Un LoRA 70B tient sur 4 à 8 GPU dans un seul nœud ; un QLoRA 405B tient sur 8× Pro 6000.
• Inférence par lots et charges hors ligne. Si l'engagement de service se résume à « traiter ce corpus d'ici vendredi », le traitement par lots en mode débit sur une machine à 8 GPU y suffit. Le multi-nœuds n'aide que si vous ne pouvez pas terminer à temps — généralement parce que le modèle est trop gros, pas parce qu'un nœud est trop lent.

Environ 80 % des clients de Kentino devraient acheter un nœud plus puissant plutôt que deux plus modestes, et la majeure partie des 20 % restants cherche en réalité des répliques en parallélisme de données derrière un répartiteur de charge, pas un cluster.

Quand il FAUT passer à plusieurs nœuds

Les cas où un seul nœud ne suffit vraiment pas sont plus rares qu'on ne l'imagine.

Entraîner un modèle de 70B ou plus à partir de zéro. Huit GPU ne donnent pas assez de temps machine. Un pré-entraînement de 70B aux budgets de tokens publiés (1.5 à 15 T) demande des centaines de mois-GPU sur du matériel de classe H100, davantage sur des GPU grand public en PCIe. Ce travail réclame de 32 à plus de 128 GPU et un réseau SXM. Kentino ne construit pas ce niveau de machines.

Réglage fin complet d'un modèle de 70B ou plus. Pas du LoRA : un réglage fin complet, avec états de l'optimiseur, gradients et activations résidents. Un réglage fin complet de 70B (poids FP16 + Adam FP32 + gradients + activations) représente 1.2 à 1.5 TB d'état, au-delà d'un nœud à 8 GPU même avec FSDP. Cela justifie un cluster IB de 2 à 4 nœuds.

Héberger un 405B ou plus à une latence de production. Les poids tiennent en INT4 sur 8× Pro 6000, mais le cache KV ajouté au service simultané à une latence exploitable impose deux nœuds ou plus. Deux machines à 8 GPU Pro 6000 en TP=8 × PP=2 ou TP=4 × PP=4 constituent le minimum réaliste pour Llama 3.1 405B à un nombre de requêtes par seconde correct. K03 détaille ce point.

Production multi-locataires à >100k requêtes par seconde cumulées. Un nœud à 8 GPU délivre 500 à 2,000 tok/s cumulés sur un 70B en FP8. Au-delà de quelques dizaines de milliers de requêtes par seconde, il vous faut plusieurs répliques ; au-delà encore, un véritable cluster avec routeur et routage tenant compte du cache de préfixes. La bonne réponse est généralement de multiplier les répliques en parallélisme de données, pas de bâtir un gigantesque cluster en parallélisme tensoriel.

En dehors de ces quatre cas, l'argument s'effondre vite. La plupart des « il me faut du multi-nœuds » se révèlent être des « je veux plus de débit » — une question de répliques, pas d'interconnexion.

Le point d'équilibre du nœud unique

La configuration type d'un nœud unique performant, avec du matériel que Kentino livre réellement :

La contrainte décisive : ces cartes n'ont pas de NVLink. Les RTX 5090, RTX Pro 6000 Blackwell, L40 et L4 passent par le PCIe. Les modules SXM à fabric NVLink (H100 SXM, B200 SXM, GB200) exigent des cartes de base HGX que nous ne construisons pas. K07 en chiffre le coût ; N03 explique quand le NVLink compte vraiment.

La voie PCIe convient aux travaux orientés inférence et à la plupart des entraînements en deçà de la frontière technologique. Le traitement par lots en mode débit amortit le coût des opérations all-reduce en inférence. Pour le réglage fin de modèles de taille fixe, la pénalité en temps réel face au SXM est de 1.2 à 1.4× — généralement acceptable. Pour un entraînement en parallélisme tensoriel d'un 70B ou plus à partir de zéro, la pénalité monte à 2–3× et la réponse devient : « achetez du SXM, ou ne faites pas ce travail sur du matériel Kentino ».

La rupture entre nœud unique et multi-nœuds

Ce qui fait du multi-nœuds une tout autre catégorie de système, c'est la rupture d'interconnexion entre l'intra-nœud et l'inter-nœud, en bande passante comme en latence.

Dans une même machine, deux GPU dialoguent à ~50 GB/s avec des sauts inférieurs à la microseconde. D'un nœud à l'autre, vous obtenez ~25 GB/s sur de l'IB 200 Gbps — une pénalité de 2× sur IB, de 4–5× sur 100 GbE, de 15× sur 25 GbE. Pour des collectives en parallélisme tensoriel déclenchées à chaque couche du transformeur, le coup est rude. K07 donne le tableau des temps d'all-reduce.

La latence amplifie le phénomène : 5 à 15 microsecondes entre nœuds sur du RoCE optimisé, contre quelques nanosecondes à l'intérieur d'une machine. Pour l'entraînement et le préremplissage, l'écart s'efface ; pour de l'inférence interactive à faible latence avec un parallélisme tensoriel serré, non.

C'est à cause de cette rupture que « il suffit d'ajouter une machine » n'est pas une décision continue. Tout ce qui survit à peine sur le PCIe d'un seul nœud ne survivra pas sur de l'Ethernet ou de l'IB entre nœuds.

Le calcul du passage à l'échelle : là où il s'effondre

La loi d'Amdahl : l'accélération est bornée par la fraction séquentielle de la charge de travail, et pour l'entraînement distribué cette fraction, c'est le coût des communications. Pour une étape d'entraînement de classe 70B sur du matériel PCIe de classe Kentino, l'efficacité du passage à l'échelle (débit par GPU face à la référence mono-GPU) se présente ainsi sur les configurations que nous avons livrées :

Deux enseignements. Premièrement, découper une tâche de 8 GPU sur deux nœuds de 4 GPU est pire que de la faire tourner dans une seule machine — toute interconnexion entre nœuds est plus lente que le PCIe de la machine que vous aviez déjà. Deuxièmement, le parallélisme de données passe bien mieux à l'échelle que le parallélisme tensoriel à travers une interconnexion. Si votre vraie question est « puis-je servir davantage de requêtes » plutôt que « puis-je faire tourner un modèle plus gros plus vite », les répliques en parallélisme de données fonctionnent, et elles fonctionnent sur du 100 GbE standard.

Si l'efficacité projetée tombe sous 60 %, la charge de travail n'a pas la bonne forme pour du multi-nœuds sur interconnexion standard. Revoyez l'architecture (TP à l'intérieur d'un nœud, PP ou DP entre les nœuds), achetez un nœud unique plus puissant, ou passez à du matériel de classe SXM. La force brute ne fonctionne pas.

Le piège du laboratoire de recherche et la taxe opérationnelle

Un schéma assez fréquent pour mériter d'être signalé : un laboratoire anticipe « l'avenir » et commande deux nœuds de 4 GPU au lieu d'un nœud de 8. Ce qu'il obtient en réalité, c'est un entraînement moins bon (0.65× en TP entre nœuds contre 0.73× en interne), une inférence moins bonne pour tout modèle qui tenait dans une seule machine, une charge d'exploitation doublée (deux BMC, deux réglages de cartes réseau, deux versions de pilotes à figer, deux domaines de panne) et un coût en matériel à peu près identique une fois ajoutés la deuxième carte réseau, la deuxième alimentation et le switch plus capable. Commencez par acheter un seul nœud à 8 GPU.

Le multi-nœuds, quand il est la bonne réponse, 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 reprise fragmentés et asynchrones — des écritures synchrones non fragmentées vers NFS bloquent le cluster. PyTorch DCP ou NeMo devient obligatoire, pas optionnel.
• Réglage des cartes réseau et de NCCL — contrôle de flux RoCE, PFC, ECN, trames jumbo, choix du transport NCCL, fichiers de topologie, algorithmes en anneau ou en arbre. Chaque réglage sera mauvais par défaut.
• Supervision — DCGM sur chaque nœud, fédération Prometheus, tampons de trace NCCL.
• Gestion des pannes — nœuds qui décrochent, cartes réseau qui se réinitialisent, ports de switch instables. K06 décrit les modes de défaillance ; les taux de panne en multi-nœuds valent à peu près N fois ceux d'un nœud unique, et la reprise est plus laborieuse.

En temps d'ingénierie, le multi-nœuds coûte 4 à 5× par nœud ajouté. Prévoyez-le, ou acceptez que le cluster passe ses six premiers mois à la moitié de sa capacité théorique.

L'arbre de décision concret

Déroulez-le dans l'ordre. Le premier « oui » clôt la discussion.

1. Le modèle tient-il sur 8× 96 GB en FP8 avec 30–40 % de VRAM de marge pour le cache KV ? Si oui : un nœud, affaire classée.
2. Tient-il en INT4 avec la même marge ? Si oui et que vous faites de l'inférence (pas de l'entraînement), un nœud en INT4 est la réponse. Les poids INT4 ne conviennent pas au calcul des gradients d'un entraînement — passez à la suite.
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 réponse consiste à répliquer des configurations à un nœud en parallélisme de données, pas à monter un cluster. Deux machines derrière un répartiteur de charge, sans interconnexion dédiée.
4. S'agit-il d'un entraînement en parallélisme tensoriel d'un modèle qui ne tient pas dans un seul nœud ? Multi-nœuds avec InfiniBand. Projetez l'efficacité du passage à l'échelle à l'aide du tableau de K07. En dessous de 60 %, revoyez l'architecture (TP à l'intérieur, PP entre les nœuds) ou réduisez le nombre de nœuds en acceptant un temps de calcul plus long.
5. S'agit-il de pré-entraîner un modèle de 70B ou plus à partir de zéro ? Cas de la frontière technologique. Multi-nœuds avec IB NDR ou SXM. Kentino peut réaliser la partie IB, mais la plupart des clients qui posent la question n'ont en réalité pas besoin de mener ce travail eux-mêmes.

Les étapes une et deux représentent l'essentiel du marché. L'étape trois signifie que vous grandissez bien — la réponse tient aux répliques, pas à un cluster. Les étapes quatre et cinq existent, mais restent rares.

Notre avis sans détour

Le multi-nœuds s'impose à la frontière technologique — entraînement d'un 70B ou plus à partir de zéro, inférence d'un 405B ou plus à latence de production, service à très grande échelle au-delà de 100k requêtes par seconde, ou recherche dépendant d'un débit quotidien qu'une seule machine ne peut fournir. Ce sont de vraies charges de travail. Elles ne représentent pas l'essentiel de ce qui se construit.

Pour tout le reste, un nœud à 8 GPU bien dimensionné est la réponse. Il exécute toute charge d'inférence à poids ouverts de 2026 tenant dans 768 GB en FP8/INT4, les LoRA et QLoRA jusqu'à 405B, les réglages fins complets de classe 13B sans broncher, et monte à deux ou trois répliques en parallélisme de données pour le débit, sans aucune interconnexion de cluster. Et il est bien plus simple à exploiter.

Voici comment se déroule l'échange avec la plupart de nos clients : décrire la charge de travail, faire le calcul de capacité, projeter l'efficacité du passage à l'échelle. Si la projection dit cluster, nous construisons un cluster. Si elle dit un nœud, nous construisons un nœud. Si elle dit deux répliques derrière un routeur, nous construisons cela. Nous ne vendons pas la plus grosse configuration que vous êtes prêt à supporter — nous vendons celle qui fonctionnera vraiment.

---

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 à l'adresse info@kentino.com.