Au-delà d'une carte : comment les modèles géants tournent sur des centaines de GPU

Les plus grands modèles d'IA actuels portent plus de mille milliards de paramètres, et il faut près de 2 téraoctets de mémoire pour loger leurs poids. Or le plus gros GPU du marché offre environ 288 Go : même la carte la plus ambitieuse ne joue pas dans la même cour que ces géants. Alors comment les robots conversationnels utilisés chaque jour par des millions de personnes servent-ils ces modèles sans interruption ? La réponse est d'une simplicité désarmante : il n'existe pas un méga-ordinateur unique qui les héberge. Ils tournent sur un système coordonné de dizaines, parfois de centaines de GPU. Sur la chaîne IBM Technology, Grace Ableidinger décortique comment une charge d'inférence LLM reste en vie à cette échelle, étape par étape.

Servir un modèle en production, c'est résoudre trois contraintes à la fois. D'abord, l'empreinte mémoire du modèle : chaque poids doit être logé en mémoire avant que le travail commence. Ensuite, la mémoire de travail appelée cache KV : pendant que le modèle rédige sa réponse, il y garde le contexte de la conversation, et cette zone grandit à chaque jeton produit. Enfin, le débit de requêtes : quand des centaines, voire des milliers de personnes sollicitent le modèle en même temps, chaque demande fait la queue sur la carte et l'attente de chacun s'allonge. Le cache KV est le plus sournois des trois, car il ne reste jamais en place : il enfle tant que la génération continue. Selon les travaux Dynamo de Nvidia, ce contexte qui gonfle peut quitter la mémoire GPU vers des paliers moins chers comme la mémoire CPU et les disques rapides ; des validations menées avec Vast et WEKA ont mesuré 35 Go/s vers un seul H100 et 270 Go/s sur huit cartes.

Absorber le trafic : le parallélisme de données

Quand le modèle et son cache tiennent sur une carte mais que le nombre d'utilisateurs devient ingérable, la solution la plus simple consiste à copier le modèle entier sur plusieurs cartes. Avec le parallélisme de données , chaque carte garde une réplique identique et les requêtes sont aiguillées selon la charge du moment — voire selon la carte qui détient déjà le contexte utile dans son cache. Aucune coordination entre répliques : il suffit de faire entrer chaque demande par la bonne porte. D'après le billet d'inférence distribuée de l'équipe vLLM, daté du 17 février 2025, la quantification sur peu de bits ne suffit plus au-delà de quelques centaines de milliards de paramètres ; c'est pourquoi le moteur propose le parallélisme de tenseurs dans la carte et le parallélisme de pipeline entre les cartes. Le trafic se règle donc par le nombre de copies, et la place par les techniques de découpe.

La copie ne suffit plus pour les modèles vraiment immenses, car le modèle lui-même ne tient pas sur une carte. Un modèle, c'est une suite de couches de transformeurs qui portent la connaissance, et l'inférence consiste à y faire passer l'entrée l'une après l'autre. Le parallélisme de pipeline découpe le modèle en groupes de couches : les premières sur la première carte, les suivantes sur la seconde. Avec une seule requête, la plupart des cartes attendent leur tour les bras croisés ; les demandes défilent donc en continu, comme sur une chaîne de montage, pour garder chaque poste occupé. Les notes d'ingénierie de Baseten chiffrent un milliard de paramètres à environ un gigaoctet en précision FP8 ; DeepSeek-V3.1, avec ses 671 milliards de paramètres, provoque une erreur de mémoire sur un seul B200, et même 720 Go sur quatre B200 couvrent les poids sans laisser de place au cache KV — qui capte le plus souvent 80 % ou plus de l'espace restant après les poids. Conclusion : le trafic réel à cette taille veut un nœud complet de huit cartes.

Deux façons de découper : pipeline et tenseurs

Au lieu de trancher le modèle à la verticale, on peut le trancher à l'horizontale. Le parallélisme de tenseurs divise le calcul à l'intérieur de chaque couche plutôt que les couches elles-mêmes : chaque carte prend une tranche de la même couche, effectue sa part de mathématiques, puis les cartes fusionnent leurs résultats partiels. Cette fusion est une opération collective, une barrière bloquante à chaque couche : les cartes doivent bavarder sans relâche au milieu du calcul. Ce bavardage dense n'avance qu'avec une liaison haut débit et à faible latence à l'intérieur d'un même serveur ; sur un réseau lent, la discussion devient le goulot au lieu d'être l'optimisation. Le guide DigitalOcean rappelle qu'un modèle dense de 70 milliards de paramètres en BF16 réclame quelque 140 Go pour ses seuls poids ; un modèle à l'aise avec 4K de contexte peut refuser de tenir à 64K ou 128K sous un vrai trafic de production. Le message est clair : la vitesse de la route entre les cartes compte autant que la technique de découpe.

Il existe aussi la famille qui travaille comme une communauté de spécialistes : le mélange d'experts. Au lieu d'activer un seul bloc de poids pour chaque entrée, ces modèles abritent de petits sous-réseaux experts de différents aspects de la génération — l'un porté sur les exemples de code, l'autre sur la ponctuation, un troisième sur les chiffres. Le parallélisme d'experts répartit ces experts sur les cartes, si bien qu'aucune carte ne détient le modèle entier. À chaque couche, un routeur envoie chaque jeton vers la poignée d'experts choisie ; les modèles actuels en retiennent environ 8 sur 256, puis les sorties sont recombinées. Le calcul par jeton chute fortement, payé d'un trafic intense de routage entre cartes. Comme le souligne le manuel de Modular, chaque réplique de données peut elle-même combiner tenseurs ou pipeline en interne, et le routeur trace une frontière de panne en écartant les répliques qui ratent leurs contrôles de santé.

Un parc par métier : pré-remplissage et décodage

Les deux phases de l'inférence LLM fatiguent le matériel de manières opposées. Pendant le pré-remplissage , le modèle lit et assimile l'entrée, enchaîne des calculs parallèles denses sur des poids figés à la vitesse du calcul, et bâtit au passage le cache KV. Pendant le décodage , la réponse naît jeton par jeton, en extrayant à chaque pas tout le cache grandi de la mémoire, à la vitesse de la bande passante. Parquées ensemble, les deux phases se gênent : l'appétit mémoire du décodage rétrécit le territoire du pré-remplissage. La sortie consiste à installer chaque phase sur son propre parc de GPU, réglé pour son goulot — à condition que le cache voyage entre les parcs à la vitesse de la lumière. Le TCP ordinaire sur Ethernet standard ne suit pas ; il faut un réseau dédié, à faible latence, compatible RDMA. Le récit SageMaker HyperPod d'Amazon relie les parcs séparés par EFA et RDMA, règle indépendamment le délai du premier jeton et la latence entre jetons, et empêche les longues entrées de bloquer la génération en cours. Le guide de Ray ajoute que la même séparation met chaque phase à l'échelle sur des nœuds hétérogènes moins chers, avec les passerelles NIXL et LMCache de vLLM pour le transport.

Les déploiements réels empilent ces techniques : tenseurs dans le serveur, pipeline entre serveurs, données entre répliques, experts pour les mélanges, et parcs séparés par phase. Cet empilement porte le nom de parallélisme multidimensionnel. Au sommet trône une couche d'orchestration qui dirige chaque requête vers le bon parc de GPU, équilibre la charge et absorbe les cartes en panne sans perdre de demandes. Comme le résume la présentatrice, la règle est simple : trafic qui déborde, on ajoute des copies ; modèle qui ne tient pas, on découpe couche par couche ou tranche par tranche ; mémoire qui enfle de deux travaux mêlés, on donne à chacun son parc. L'inférence distribuée n'est pas l'entêtement à tasser des modèles géants dans une machine — c'est la discipline de couper le travail en bons morceaux et de faire tourner chacun sur le bon matériel.