Pourquoi doubler le nombre de GPU ne divise pas toujours le temps de calcul

Ajouter des GPU augmente les ressources disponibles, mais le programme doit parvenir à les utiliser ensemble. Certaines opérations restent séquentielles, des données doivent circuler et les unités peuvent attendre leurs partenaires. La vitesse d’un calcul distribué dépend donc du découpage du travail et de l’interconnexion, pas seulement du nombre de puces.

Cette distinction aide à lire une annonce de puissance de calcul ou à préparer un essai sur une infrastructure partagée. Il faut d’abord préciser l’objectif : résoudre le même problème plus vite, traiter davantage de problèmes indépendants ou rendre possible un modèle qui ne tient pas sur une seule unité.

Trois objectifs qui produisent trois comparaisons différentes

Si l’on conserve exactement le même travail et augmente les ressources, on teste sa capacité à accélérer. Si l’on augmente le travail en même temps, on teste la capacité à absorber une charge plus grande. Une infrastructure peut réussir le second objectif sans diviser par deux la durée du premier.

Le cours de Cornell sur la loi d’Amdahl expose cette distinction entre problème de taille fixe et problème agrandi. La part qui ne peut pas être parallélisée limite l’accélération du travail fixe. Il s’agit d’un modèle théorique simplifié, pas d’un résultat mesuré sur un serveur IA.

Un troisième cas concerne la capacité : plusieurs GPU peuvent permettre de répartir un modèle trop volumineux pour un seul. Dans cette situation, demander uniquement « combien de fois plus rapide ? » peut manquer le premier bénéfice recherché. Il faut aussi comparer la solution à une autre façon réaliste d’exécuter le même travail.

Les communications font partie du calcul

La bibliothèque NCCL de NVIDIA fournit des opérations de communication entre GPU, dans une machine ou entre plusieurs machines. Parmi elles, AllReduce combine des résultats et les redistribue aux participants ; d’autres opérations rassemblent ou diffusent des données. NCCL tient compte de la topologie et prend en charge différentes interconnexions, notamment PCIe, NVLink et des réseaux entre machines.

Cette documentation établit le rôle des communications dans cet environnement. Elle ne permet pas de conclure qu’un lien portant un nom donné garantit une performance particulière. Le chemin effectivement emprunté, les autres transferts et le logiciel restent déterminants.

Pour visualiser la différence, imaginons deux façons d’organiser un travail. Dans la première, chaque GPU traite une image indépendante et rend son résultat. Dans la seconde, plusieurs GPU doivent régulièrement échanger des résultats intermédiaires pour poursuivre une même tâche. Le second scénario impose davantage de coordination. Le volume et la fréquence précis dépendent du programme.

Une borne simple avant les détails du réseau

Voici un exemple fictif. Un travail dure 100 secondes sur une ressource. On suppose que 80 secondes peuvent être parfaitement réparties, tandis que 20 secondes restent séquentielles. On ignore volontairement toutes les communications pour calculer une limite idéale.

Ressources identiques	Durée idéale fictive	Accélération par rapport à 100 s
1	100 s	1 fois
2	60 s	1,67 fois environ
4	40 s	2,5 fois
8	30 s	3,33 fois environ

La formule est : 20 + 80 ÷ nombre de ressources. Même avec une quantité immense de ressources, les 20 secondes séquentielles subsistent dans ce modèle. Ajouter des communications ne peut pas être ignoré dans une mesure réelle, mais il ne faut pas simplement les additionner si elles se recouvrent avec le calcul : une chronologie d’exécution est nécessaire.

L’exemple sert à distinguer borne et mesure. Il ne donne ni l’efficacité d’un réseau réel, ni la fraction parallélisable d’un modèle existant. Ces paramètres doivent être observés sur la charge étudiée.

Bande passante et latence ne sont pas interchangeables

La bande passante décrit un volume transférable par unité de temps ; la latence concerne le délai d’un échange. Un programme qui effectue beaucoup de petits échanges dépendants ne rencontre pas le même problème qu’un programme qui déplace de gros blocs. Réduire le nombre d’échanges peut parfois compter autant qu’augmenter le débit maximal d’un lien.

Il faut également regarder la topologie, autrement dit la façon dont les composants sont reliés. Deux GPU installés dans un même ensemble ne disposent pas nécessairement d’un chemin identique vers tous leurs voisins. La documentation NCCL précise son adaptation à cette organisation ; c’est une raison de mesurer le groupe réellement alloué plutôt qu’une machine ressemblante sur le papier.

Le guide sur la mémoire des puces IA décrit les transferts à l’intérieur de la chaîne de calcul. Ici, on ajoute une frontière : des résultats doivent aussi franchir des liens entre unités ou entre machines.

Ce qu’une courbe de montée en charge doit conserver

Pour comparer un, deux puis quatre GPU, documenter le travail exact, le matériel, le moteur logiciel, la précision numérique et les réglages. Si la taille de lot change, l’afficher. Si une expérience d’entraînement vise un niveau de qualité, vérifier ce niveau plutôt que comparer seulement le temps d’une itération.

Deux mesures répondent à des questions différentes : le temps écoulé et le temps de ressource consommé. Dans un exemple fictif, un travail de 60 secondes sur deux GPU représente 120 GPU-secondes, contre 100 GPU-secondes pour 100 secondes sur un seul. Le délai a baissé, mais la quantité de ressource réservée a augmenté. Cette unité ne mesure pas l’énergie : il faudrait pour cela relever la puissance dans le temps.

Pour une décision, ajouter le coût selon le contrat réel et la disponibilité des ressources. Un délai de réservation ou d’attente peut compter davantage que quelques secondes gagnées pendant l’exécution. Séparer ces étapes permet de localiser ce qui ralentit effectivement le projet.

Avant d’acheter davantage, localiser l’attente

Le protocole proposé par Pnebbula consiste à relever une chronologie distinguant préparation, calcul, communication et synchronisation. Vérifier si une unité attend des données, si toutes attendent la plus lente ou si la charge est mal répartie. Un taux d’utilisation isolé ne suffit pas à expliquer la cause.

Tester ensuite une modification à la fois : taille de lot, répartition, organisation des données ou nombre de ressources. Conserver un résultat de référence et la qualité obtenue. Si le programme est surtout limité par une étape séquentielle, acheter davantage de GPU sans modifier cette étape peut laisser le délai presque inchangé.

Les AI Factories européennes donnent un contexte aux moyens de calcul partagés. L’accès à une grande capacité reste distinct de la preuve que votre application l’exploite efficacement. La preuve utile est une mesure reproductible, avec le même objectif et un périmètre explicite.

Sources et portée

Consultées le 22 octobre 2026 : Cornell Center for Advanced Computing, Amdahl’s Law ; NVIDIA, Overview of NCCL. Les calculs de durée et de GPU-secondes sont fictifs. Aucun résultat de centre de calcul ni coût commercial n’est attribué à ces exemples.