La course à la formation de modèles de langage de plus en plus grands rencontre un problème moins visible que la taille des paramètres ou la qualité des données : la logistique du matériel informatique. En pratique, déployer une infrastructure de machine learning à grande échelle ne consiste plus seulement à “acheter plus de GPU”, mais aussi à les obtenir, à les intégrer et à faire en sorte qu’ils travaillent ensemble sans transformer le système en un casse-tête de compatibilités.

C’est là qu’intervient HetCCL, une nouvelle bibliothèque de communication collective présentée par une équipe de chercheurs affiliée à l’Université nationale de Séoul et à Samsung Research. Sa proposition cible un goulet d’étranglement précis : la difficulté d’utiliser efficacement et en toute transparence des grappes hétérogènes avec des GPUs de différents fabricants pour entraîner des modèles de langage et d’autres charges massives d’apprentissage profond.

Le vrai problème : la communication, pas le calcul

Dans l’entraînement distribué, une grande partie du temps n’est pas consacrée au “calcul”, mais à la synchronisation. Des opérations telles que all-reduce, all-gather ou reduce-scatter sont essentielles pour combiner les gradients et maintenir la cohérence entre les nœuds. Dans des environnements homogènes, l’écosystème dispose déjà d’outils très optimisés : NVIDIA promeut NCCL comme norme de facto pour ses GPU, tandis qu’AMD propose RCCL dans son écosystème ROCm.

Le choc survient lorsque le cluster devient hétérogène. À mesure que les organisations combinent différentes générations, modèles et fournisseurs pour augmenter leur capacité, la couche de communication devient un obstacle : les backends sont optimisés pour “leur” matériel, et l’interopérabilité entre fournisseurs n’est pas toujours résolue de manière claire dans de nombreux flux de travail habituels. Le résultat, connu des équipes d’infrastructure, est une augmentation des coûts, une sous-utilisation des ressources et, dans le pire des cas, l’abandon partiel du parc installé faute de compatibilité avec le même processus d’entraînement.

Ce que propose HetCCL

HetCCL se présente comme une bibliothèque de communication collective conçue pour fonctionner entre GPU NVIDIA et AMD dans un même cluster, exploitant RDMA pour des transferts directs et rapides, sans nécessiter de modifications des pilotes. Plutôt que de “réinventer” toute la communication, cette approche intègre et tire parti des bibliothèques optimisées existantes (NCCL et RCCL) via des mécanismes de coordination d’opérations collectives dans un environnement hétérogène.

L’objectif pratique est ambitieux mais précis : que les charges distribuées (par exemple avec PyTorch) puissent utiliser des GPU de différents fournisseurs sans avoir à réécrire le code d’entraînement ni à repenser entièrement la pile de communication. En somme, transformer l’hétérogénéité d’un parc matériel en une caractéristique d’achat et de capacité — pas en un casse-tête d’ingénierie sans fin.

RDMA comme raccourci : contourner le CPU (quand c’est pertinent)

La clé technique réside dans RDMA (Remote Direct Memory Access), une famille de technologies permettant d’accéder à la mémoire distante avec de faibles latences et une intervention limitée du système d’exploitation. Dans le contexte GPU, cela devient particulièrement précieux : une NIC (carte réseau) compatible RDMA peut interagir directement avec la mémoire GPU, évitant les copies intermédiaires inutiles et réduisant la charge sur le CPU.

Selon les auteurs, HetCCL établit une communication directe point à point exploitant RDMA et des mécanismes d’enregistrement de mémoire qui permettent au réseau de “voir” des régions de mémoire GPU via des API spécifiques (CUDA/HIP) et la pile réseau RDMA habituelle (comme IB Verbs). Concrètement, cela s’adapte aux réseaux dominants en IA à grande échelle : InfiniBand et aussi RoCE (RDMA sur Ethernet convergé) dans certains déploiements.

Performance : s’approcher des solutions “natives” sans en payer le prix de l’enfermement

Lors de leurs évaluations, l’équipe indique que HetCCL atteint des performances comparables à NCCL et RCCL dans des environnements homogènes, tout en assurant une scalabilité dans des scénarios hétérogènes. Concrètement, ils rapportent une efficacité élevée par rapport à une exécution de référence, proche de 90% en moyenne, avec des pics allant jusqu’à 97% dans certains cas. De plus, le passage de 8 à 16 GPU montre une croissance quasi linéaire dans leurs tests.

Une autre préoccupation classique concernant ces intégrations concerne la “qualité” : le changement de couche de communication dégrade-t-il l’entraînement ? Selon leur étude, les différences numériques observées dans la perte finale restent faibles (erreurs relatives inférieures à 7 × 10⁻³), un détail important pour les applications où la stabilité de la convergence est critique.

Pourquoi cela concerne les sysadmins et les équipes plateforme

Pour un public en charge de l’administration système et du développement, HetCCL présente des avantages professionnels :

• Moins de dépendance à un seul fournisseur : si la communication n’est plus un frein, la stratégie d’achat peut privilégier la disponibilité, le coût total et les délais.
• Réutilisation de l’inventaire : les GPUs “différents” cessent d’être du hardware de second choix et peuvent cohabiter dans un même cluster avec un objectif commun.
• Une scalabilité plus réaliste : en pratique, les clusters se développent par vagues ou budgets, pas toujours avec des composants parfaitement homogènes.
• Optimisation du déploiement : si le code n’exige pas de modification, la barrière à l’adoption baisse, notamment dans les organisations disposant de pipelines automatisés.

Il faut cependant souligner l’envers de la médaille : ces solutions dépendent fortement de l’infrastructure RDMA (réseau, NICs, compatibilités, configuration) et exigent un suivi rigoureux en matière d’isolation et d’observabilité. En environnement d’IA, le réseau n’est pas un simple accessoire, mais une partie intégrante du moteur. Toute couche de communication doit donc être monitorée, testée dans des conditions contrôlées, avec des attentes réalistes.

Le contexte : la “hétérogénéité” n’est plus une exception

La course à des modèles plus grands, avec des budgets qui stagnent ou croissent lentement, pousse à adopter des infrastructures hybrides par pragmatisme. HetCCL s’inscrit dans cette tendance : considérer que la heterogénéité sera la norme plutôt qu’une exception, et que le logiciel — et pas seulement le hardware — déterminera la capacité réelle d’un centre de données à exploiter ses ressources.

Si cette approche se généralise au-delà du cercle académique, elle pourrait ouvrir la voie à des entreprises moyennes et des laboratoires pour réduire les frictions dans la constitution de clusters performants, sans tomber dans un verrouillage total de certaines plateformes. Et surtout, elle pourrait faire évoluer la conversation dans beaucoup d’organisations : “Nous avons des GPUs, mais nous ne pouvons pas les utiliser ensemble”.

Questions fréquentes

Qu’est-ce qu’une bibliothèque de communication collective (CCL) et pourquoi est-ce si crucial pour l’entraînement de grands modèles de langage ?
Une CCL accélère des opérations comme all-reduce ou all-gather, indispensables pour synchroniser gradients et paramètres entre GPU. Si cette communication est lente ou inefficace, le cluster “paie” le temps de la synchronisation, ce qui augmente le coût par itération.

Peut-on entraîner un LLM avec des GPU AMD et NVIDIA dans un même cluster sans modifier le code PyTorch ?
HetCCL vise précisément à permettre cela, en proposant une couche de communication capable d’opérer sur des environnements hétérogènes sans toucher au code d’entraînement. Son efficacité dépend toutefois de l’intégration dans le stack et de la compatibilité RDMA disponible.

Quels sont les prérequis en termes de réseau pour que RDMA fasse la différence dans l’IA ?
Une infrastructure basée sur RDMA (InfiniBand ou RoCE), avec des NIC compatibles et une configuration correcte pour minimiser pertes, latence et goulots d’étranglement. Dans l’IA, le réseau et ses réglages (tuning et observabilité) sont aussi critiques que le choix des GPU.

Quels bénéfices offrent la communication directe en mémoire GPU (type GPUDirect RDMA) dans des déploiements distribués ?
Elle réduit les copies intermédiaires et l’intervention du CPU, abaissant la latence et libérant des ressources système. Ceci peut améliorer le rendement global du cluster et faciliter la scalabilité à grand nombre de nœuds.

source : quantum zeitgeist et HetCCL : Accelerating LLM Training with Heterogeneous GPUs