Imaginons que vous vouliez déployer un modèle Llama-2-70B. Vous avez quatre GPU de 24 Go, mais le modèle, une fois chargé, demande bien plus de VRAM que ce que propose une seule carte. C'est là que la magie opère : vous ne pouvez pas simplement "ajouter" des cartes, vous devez découper le cerveau du modèle pour qu'il tienne sur plusieurs processeurs simultanément. Le tensor parallelism est la réponse technique à ce casse-tête mémoire.
Le problème concret est simple : la mémoire d'un seul GPU est souvent trop petite pour les modèles dépassant 20 milliards de paramètres. Si vous tentez de forcer le chargement, vous obtenez l'erreur classique "Out of Memory" (OOM). Le parallélisme de tenseurs permet de répartir les couches du réseau de neurones horizontalement. Contrairement à d'autres méthodes, on ne divise pas le modèle par blocs de couches, mais on divise chaque opération mathématique elle-même entre les GPU.
| Attribut | Valeur / Détail |
|---|---|
| Concept central | Découpage horizontal des matrices de poids |
| Cible principale | Modèles > 20B paramètres (ex: Llama, OPT) |
| Matériel recommandé | Interconnexions haute vitesse (NVLink) |
| Gain de performance | Jusqu'à 3.2x de speedup (pour TP=4 sur modèles 13B) |
| Frameworks leaders | vLLM, TensorRT-LLM, TGI |
Comment ça marche techniquement ?
Pour comprendre le fonctionnement, il faut regarder comment un LLM traite l'information. Tout repose sur des multiplications de matrices. Le Tensor Parallelism est une technique de parallélisme de modèle qui partitionne les couches d'un réseau de neurones en divisant les tenseurs selon la dimension des caractéristiques.
En pratique, on utilise deux types de découpages :
- Le parallélisme de colonne : On divise la matrice de poids verticalement. Chaque GPU reçoit la même entrée, mais traite une partie différente des colonnes. C'est typiquement utilisé pour les couches de projection (q_proj, k_proj, v_proj) dans le mécanisme d'attention.
- Le parallélisme de ligne : Ici, on divise la matrice horizontalement. Les entrées sont elles-mêmes splittées entre les GPU, et on additionne les résultats partiels à la fin. C'est la méthode privilégiée pour les couches de sortie (out_proj).
Prenons l'exemple du modèle OPT-175B. Avec 96 têtes d'attention et 8 GPU, le système n'envoie pas les 96 têtes sur chaque carte. Il en assigne simplement 12 par GPU. Cela réduit drastiquement l'empreinte mémoire par unité tout en maintenant la cohérence du calcul.
Le duel : Tensor Parallelism vs Pipeline vs Data Parallelism
On confond souvent ces termes, mais ils répondent à des besoins différents. Le Data Parallelism consiste à copier tout le modèle sur chaque GPU et à envoyer des données différentes à chaque copie. C'est génial pour augmenter la taille des lots (batch size), mais ça ne règle pas le problème si le modèle est trop gros pour un seul GPU.
Le Pipeline Parallelism, lui, coupe le modèle verticalement. Le GPU 1 traite les couches 1 à 10, le GPU 2 traite les couches 11 à 20, et ainsi de suite. Le problème ? On se retrouve avec des "bulles de pipeline" : pendant que le GPU 2 travaille, le GPU 1 attend souvent la prochaine requête, ce qui peut faire chuter l'utilisation des ressources de 30 à 60 %.
Le tensor parallelism élimine ces bulles car tous les GPU travaillent sur la même couche en même temps. C'est donc la solution reine pour réduire la latence. Cependant, cela demande énormément de communication entre les cartes. Si vos GPU communiquent via un bus PCIe 4.0 lent, vous allez perdre tout le bénéfice du calcul parallèle à cause du temps d'attente réseau.
L'importance critique de l'infrastructure matérielle
Vous ne pouvez pas faire du tensor parallelism efficace avec n'importe quel matériel. Le goulot d'étranglement, c'est la synchronisation. À chaque étape du calcul, les GPU doivent s'échanger des données via des opérations comme l'"all-reduce".
C'est là qu'intervient le NVLink, une interconnexion propriétaire de NVIDIA. Avec une bande passante bidirectionnelle de 600 Go/s, NVLink réduit l'overhead de communication de 35 % par rapport au PCIe 4.0. Pour vous donner une idée, utiliser du réseau standard pour synchroniser des tenseurs sur plusieurs nœuds peut ajouter plusieurs millisecondes de latence par point de synchronisation, ce qui rend l'opération presque inutile pour des applications en temps réel.
D'ailleurs, la plupart des experts s'accordent pour dire que le tensor parallelism est idéal pour un seul nœud (un serveur avec 8 GPU), mais devient très coûteux dès qu'on essaie de passer sur plusieurs serveurs. Pour le multi-nœud, on bascule généralement sur un mélange hybride avec le parallélisme de pipeline.
Mise en œuvre avec les frameworks modernes
Heureusement, vous n'avez pas à réécrire les multiplications de matrices à la main. Des outils comme vLLM ou Text Generation Inference (TGI) de Hugging Face automatisent tout cela.
Pour lancer un modèle avec vLLM, il suffit souvent de spécifier le paramètre --tensor-parallel-size. Si vous avez 4 GPU, vous réglez ce chiffre sur 4. Le framework s'occupe alors de :
- Découper les poids du modèle selon la configuration choisie.
- Distribuer les fragments de matrices sur les VRAM respectives.
- Gérer les communications NCCL (NVIDIA Collective Communications Library) pour synchroniser les résultats.
Une astuce de pro : utilisez la précision FP16 ou BF16. En réduisant la précision des nombres, vous divisez par deux le volume de données à transférer entre les GPU, ce qui booste la vitesse globale et libère encore plus de mémoire.
Pièges courants et limites à connaître
Tout n'est pas rose. Le principal problème reste le "scaling sublinéaire". Si vous passez de 1 à 2 GPU, vous gagnez beaucoup. Mais passer de 4 à 8 GPU ne vous donnera pas forcément un gain de vitesse proportionnel. Pourquoi ? Parce que plus vous avez de GPU, plus le volume de messages de synchronisation augmente. Dans certains cas, la communication consomme 15 à 25 % du temps total d'inférence.
On observe aussi des erreurs de "timeout" fréquentes lors de l'utilisation de configurations TP (Tensor Parallel) supérieures à 4 sur du matériel non optimisé. Cela arrive quand un GPU met trop de temps à répondre et que le système croit que le processus a planté. La solution consiste souvent à ajuster les délais de l'écosystème NCCL ou à optimiser la topologie de placement des processus.
Enfin, pour les modèles de type Mixture-of-Experts (MoE), le tensor parallelism pur peut être inefficace. On lui préfère alors l'"expert parallelism", où chaque GPU héberge l'intégralité de certains experts, réduisant ainsi les échanges de données de 40 à 60 %.
Le tensor parallelism est-il utile pour les petits modèles ?
Pas vraiment. Pour des modèles de moins de 10 ou 20 milliards de paramètres, le coût de la communication entre GPU risque d'annuler le gain de vitesse. C'est surtout indispensable quand le modèle ne tient physiquement pas sur une seule carte.
Quelle est la différence majeure avec le pipeline parallelism ?
Le tensor parallelism divise l'opération mathématique (horizontale), tandis que le pipeline parallelism divise les couches du modèle (verticale). Le tensor parallelism est beaucoup plus rapide pour la latence mais demande un matériel plus performant (NVLink).
Peut-on utiliser le tensor parallelism sur des GPU grand public ?
Oui, c'est possible (par exemple avec 4x RTX 3090/4090), mais sans NVLink, les performances seront bridées par le bus PCIe. Vous pourrez faire tourner le modèle, mais la vitesse de génération des tokens sera moindre.
Qu'est-ce que l'opération all-reduce ?
C'est une opération de communication collective où chaque GPU partage ses résultats partiels avec les autres, et tout le monde finit avec la somme totale synchronisée. C'est l'étape la plus gourmande en ressources du tensor parallelism.
Quels frameworks recommandez-vous pour débuter ?
vLLM est actuellement le plus accessible pour la recherche et les startups grâce à sa gestion simplifiée du parallélisme. Pour un environnement entreprise avec des besoins de latence ultra-faibles, TensorRT-LLM de NVIDIA est la référence.
Prochaines étapes et dépannage
Si vous commencez tout juste, ne cherchez pas à optimiser le code source. Commencez par configurer vLLM avec un tensor-parallel-size égal au nombre de vos GPU. Si vous constatez des lenteurs anormales, vérifiez d'abord vos pilotes NVIDIA et assurez-vous que NCCL utilise bien le chemin le plus rapide (NVLink plutôt que PCIe).
Pour ceux qui visent une échelle massive (plusieurs serveurs), la prochaine étape est l'étude du parallélisme 3D, qui combine tensor, pipeline et data parallelism. C'est la méthode utilisée par DeepSpeed pour entraîner et déployer les modèles les plus colossaux du marché.
