Le parallélisme tensoriel expliqué : comment fonctionne l'inférence LLM multi-GPU

Le parallélisme tensoriel permet à plusieurs GPU de travailler ensemble sur une seule copie d'un modèle en divisant les tenseurs à l'intérieur de ses couches entre ces GPU.

Si un modèle nécessite 70 Go de poids et que chaque GPU dispose de 32 Go de VRAM, le parallélisme tensoriel peut répartir ces poids sur plusieurs cartes plutôt que de nécessiter un seul GPU assez grand pour contenir l'intégralité du modèle.

Mais deux GPU de 32 Go ne deviennent pas un seul GPU de 64 Go.

Chaque GPU conserve sa propre mémoire. Le framework d'inférence décide quelle partie du modèle chaque GPU stocke, envoie l'entrée pertinente à travers ces fragments et coordonne les résultats partiels à mesure que le modèle progresse de couche en couche.

Cette communication est le coût du parallélisme tensoriel.

Les recommandations actuelles de vLLM décrivent le parallélisme tensoriel comme la stratégie la plus courante pour l'inférence de grands modèles au sein d'un nœud unique. Il est recommandé d'utiliser le TP lorsqu'un modèle est trop volumineux pour un seul GPU ou lorsque la distribution des poids laisse davantage de mémoire par GPU disponible pour le cache KV et un débit de service plus élevé.

La question pratique n'est donc pas :

Combien de GPU puis-je ajouter ?

Elle est :

Quelle est la configuration de parallélisme tensoriel minimale qui permet d'accueillir le modèle, de laisser suffisamment de mémoire pour la charge de travail et de communiquer efficacement ?

Qu'est-ce que le parallélisme tensoriel ?

Une couche de réseau neuronal contient de grandes matrices.

Une opération linéaire simplifiée ressemble à :

Y = XW

où :

• X est l'entrée
• W est la matrice de poids de la couche
• Y est le résultat

Si W est trop grande, le parallélisme de tenseurs permet de la répartir sur plusieurs GPU.

Conceptuellement :

              Matrice de poids W
       ┌────────────┬────────────┐
       │            │            │
       │   GPU 0    │   GPU 1    │
       │ fragment W0│ fragment W1│
       │            │            │
       └────────────┴────────────┘
             ↑             ↑
             └──── entrée ─┘

Les deux GPU travaillent simultanément sur la même couche du modèle.

Chacun calcule une partie du résultat.

Ces résultats partiels doivent ensuite être combinés ou redistribués pour que l'opération suivante puisse se poursuivre.

C'est différent de l'assignation :

couches 1–40 → GPU 0
couches 41–80 → GPU 1

ce qui se rapproche davantage du parallélisme de pipeline.

Le parallélisme tensoriel répartit le travail au sein des couches.

Le parallélisme de pipeline répartit le travail entre des groupes de couches.

vLLM décrit la même distinction : le TP fragmente les paramètres du modèle à l'intérieur de chaque couche, tandis que le parallélisme de pipeline place différentes couches sur différents GPU et les traite en séquence.

Le parallélisme tensoriel ne mutualise pas la mémoire GPU

C'est l'idée reçue la plus importante à dissiper.

Supposons que vous ayez :

2 × RTX 5090

Chaque GPU dispose de :

32 Go de VRAM

Le système dispose de :

64 Go de VRAM totale

mais il n'existe aucun espace d'adressage physique unique de :

64 Go de VRAM

que chaque opération CUDA puisse utiliser sans coordination.

Au lieu de cela, le framework peut placer environ la moitié d'une matrice de poids fragmentée sur le GPU 0 et l'autre moitié sur le GPU 1.

Chaque périphérique travaille avec sa propre mémoire.

Le logiciel rend le modèle distribué.

Il ne transforme pas le matériel en un seul GPU plus puissant.

Cette distinction est importante car toute opération nécessitant des informations provenant d'un autre fragment implique désormais une communication.

Pourquoi utiliser le parallélisme tensoriel ?

La première raison est simple :

le modèle ne tient pas sur un seul GPU.

Imaginez un modèle de langage dense de 70 milliards de paramètres.

Très approximativement :

BF16 :
70B × 2 octets
≈ 140 Go

FP8 :
70B × 1 octet
≈ 70 Go

4 bits :
70B × 0,5 octet
≈ 35 Go

Il s'agit d'estimations basées uniquement sur les poids.

Une seule RTX 5090 dispose de 32 Go de VRAM ; par conséquent, même le calcul théorique des poids en 4 bits dépasse la capacité d'une seule carte, sans compter la surcharge à l'exécution et le cache KV. Les instances RTX 5090 actuelles de Hivenet offrent 32 Go de GDDR7 par GPU et permettent de passer d'un à huit GPU au sein d'une même instance.

C'est la limite que nous avons explorée dans notre guide des besoins GPU pour Llama 3.3 70B.

Le parallélisme tensoriel est une solution pour y parvenir.

Un exemple simple avec un modèle 70B

Prenons un modèle 70B BF16 hypothétique avec environ :

140 Go

de poids bruts.

Si ces poids pouvaient être répartis de manière parfaitement égale, la part théorique par poids serait de :

‍

‍

Cela ne signifie pas qu'une configuration à quatre GPU de 32 Go peut automatiquement faire fonctionner un modèle BF16 de 140 Go.

Avec un TP=4, la répartition théorique brute des poids est déjà d'environ 35 Go par GPU, ce qui dépasse les 32 Go de chaque RTX 5090.

Avec un TP=8, la simple division des poids laisse beaucoup plus de marge :

~17,5 Go par GPU

pour les poids fragmentés, avant les autres allocations.

C'est pourquoi notre guide Llama utilise huit RTX 5090 comme classe de planification BF16 raisonnable, plutôt que d'additionner les tailles des poids en supposant que la VRAM totale résout le problème.

La mémoire réelle d'un modèle n'est pas divisée parfaitement

Ce tableau simple aide à se faire une idée.

Le déploiement réel est plus complexe.

Chaque allocation n'est pas nécessairement fragmentée selon exactement le même facteur.

Selon le modèle et l'environnement d'exécution, la mémoire GPU peut également contenir :

• des embeddings
• des paramètres de normalisation
• des têtes de sortie
• des tampons temporaires
• des graphes CUDA
• un espace de travail pour l'attention
• un cache KV
• composants multimodaux
• métadonnées de quantification
• allocations à l'exécution

Ainsi :

taille du modèle ÷ nombre de GPU

est une estimation de bas niveau utile pour la partie fragmentée du modèle.

Ce n'est pas une prévision complète de la VRAM.

Le seul test final fiable consiste à charger le point de contrôle réel avec la pile de service réelle et à mesurer la charge de travail.

Le parallélisme tensoriel peut aider même lorsque le modèle tient déjà

La taille du modèle n'est pas la seule raison de fragmenter.

vLLM recommande également le parallélisme tensoriel lorsque la réduction de l'empreinte des poids par GPU offre au serveur plus de mémoire pour le cache KV, ce qui peut augmenter la capacité de service.

Supposons qu'un modèle tienne sur un GPU mais laisse :

4 Go

pour le cache et l'état d'exécution.

Un déploiement en parallélisme tensoriel bidirectionnel peut réduire suffisamment la mémoire modèle consommée sur chaque carte pour laisser beaucoup plus d'espace de cache par GPU.

Cet espace supplémentaire peut prendre en charge :

• des contextes actifs plus longs
• davantage de requêtes simultanées
• lots plus importants

La pertinence d'ajouter un GPU supplémentaire dépend de la capacité de service que cette mémoire permet d'obtenir.

Notre guide sur le cache KV explique pourquoi le contexte actif peut consommer plusieurs gigaoctets de VRAM, même une fois les poids du modèle chargés.

Comment le cache KV interagit avec le parallélisme tensoriel

Dans une implémentation classique de l'attention avec parallélisme tensoriel, les têtes d'attention ou les têtes KV peuvent également être réparties entre les rangs du parallélisme tensoriel.

Cela signifie que chaque GPU n'a peut-être besoin que du cache associé à l'état d'attention assigné à sa partition.

La documentation actuelle de vLLM décrit explicitement le partitionnement du cache KV par parallélisme tensoriel le long de la dimension des têtes comme un moyen d'augmenter la capacité du cache lorsqu'un seul GPU ne peut pas gérer suffisamment de requêtes actives.

C'est une autre raison pour laquelle la question pertinente n'est pas simplement :

De quelle quantité totale de VRAM est-ce que je dispose ?

L'architecture du modèle et l'implémentation du parallélisme déterminent quelles parties de l'état d'inférence sont réellement distribuées.

Que signifie tensor_parallel_size dans vLLM ?

Dans vLLM, le parallélisme tensoriel se configure via :

tensor_parallel_size

ou son équivalent en ligne de commande :

--tensor-parallel-size

Pour quatre GPU :

vllm serve <model> \
 --tensor-parallel-size 4

vLLM répartit ensuite chaque réplique de modèle supportant le parallélisme tensoriel sur quatre GPU. Sa documentation actuelle sur le déploiement utilise exactement ce modèle pour l'inférence multi-GPU.

En Python :

from vllm import LLM

llm = LLM(
   model="<model>",
   tensor_parallel_size=4,
)

Pour un modèle réel, veuillez suivre les instructions de déploiement associées au point de contrôle (checkpoint) plutôt que de considérer ces trois lignes comme une configuration de production complète.

L'objectif ici est d'illustrer ce que TP = 4 signifie.

Une réplique de modèle est répartie sur quatre GPU.

Que se passe-t-il lors d'une couche à parallélisme tensoriel ?

Les implémentations de transformeurs utilisent couramment des combinaisons de parallélisme par colonnes et de parallélisme par lignes couches linéaires.

Imaginez une grande matrice divisée verticalement :

W = [ W0 | W1 | W2 | W3 ]

Chaque GPU reçoit l'entrée et calcule :

GPU 0 → XW0
GPU 1 → XW1
GPU 2 → XW2
GPU 3 → XW3

Ces segments représentent différentes parties de la sortie de la couche.

Une autre opération peut diviser une matrice dans la direction complémentaire et nécessiter, à terme, que les résultats partiels de tous les GPU soient réduits ou rassemblés.

Le schéma de communication exact varie selon la couche et le framework.

L'essentiel est que le parallélisme de tenseurs crée régulièrement des points où les GPU doivent échanger des données.

Le modèle est distribué lors de la passe avant.

C'est pourquoi la performance de la communication entre GPU est si cruciale.

Qu'est-ce que NCCL ?

NCCL est la bibliothèque de communications collectives de NVIDIA.

Elle implémente les opérations de communication entre GPU utilisées par les charges de travail distribuées.

Une opération importante est AllReduce.

NVIDIA définit AllReduce comme une opération consistant à prendre des données fournies par plusieurs rangs, à appliquer une réduction telle qu'une somme, et à rendre le résultat combiné disponible pour chaque rang participant.

Conceptuellement :

GPU 0 ─┐
GPU 1 ─┼── combiner ──→ résultat sur GPU 0
GPU 2 ─┼──────────────→ résultat sur GPU 1
GPU 3 ─┘──────────────→ résultat sur GPU 2
                      → résultat sur GPU 3

Les autres opérations collectives incluent :

• AllGather
• ReduceScatter
• Broadcast
• AllToAll

Différentes implémentations du parallélisme utilisent différentes combinaisons de ces opérations.

Pour l'inférence en parallélisme tensoriel, le principe utile est simple :

Les GPU doivent échanger des tenseurs intermédiaires assez rapidement pour que la communication n'annule pas le bénéfice du fractionnement du calcul.

Pourquoi la communication entre GPU fait partie de la performance d'inférence

Un modèle sur un seul GPU effectue toutes ses opérations pertinentes localement.

Un modèle en parallélisme tensoriel peut effectuer :

calcul
↓
communiquer
↓
calculer
↓
communiquer
↓
calculer

à travers de nombreuses couches de modèle.

L'ajout de GPU réduit la quantité de calcul et l'état du modèle assignés à chaque GPU.

Cela introduit également de la synchronisation et de la communication.

Cela crée un compromis.

Si chaque GPU économise beaucoup de calcul alors que le chemin de communication est rapide, le parallélisme tensoriel peut très bien fonctionner.

Si le fragment de modèle devient petit alors que la communication reste coûteuse, l'ajout d'un GPU supplémentaire peut apporter beaucoup moins d'avantages.

Voici pourquoi :

2 GPU

ne signifie pas :

2× la performance d'inférence

et :

8 GPU

ne signifie en aucun cas :

8× plus de performance

pour une seule requête.

La communication multi-GPU est un aspect que Hivenet est réellement en mesure de quantifier

C'est là que nous disposons de preuves plus concrètes qu'une simple explication générique sur le parallélisme tensoriel.

Compute with Hivenet a testé NCCL AllReduce sur un hôte unique équipé de huit GPU RTX 5090.

La bande passante bus AllReduce mesurée pour une taille de message de 1 Go était de :

‍

‍

L'écart de 0,5 % se situant dans la variance habituelle entre deux exécutions, nous ne l'interprétons pas comme une supériorité de la machine virtuelle. Le résultat probant est que, pour ce benchmark de communication sur l'hôte à 8 GPU testé, la machine virtuelle a égalé les performances du bare-metal. Ce résultat a été confirmé par des milliers d'exécutions de tests répétées.

Vous pouvez consulter la méthodologie complète dans notre benchmark comparatif GPU VM vs bare-metal.

Ce test ne prouve pas que tous les modèles à parallélisme tensoriel égaleront la latence de bout en bout du bare-metal.

Il mesure le canal de communication sur lequel reposent des charges de travail telles que l'inférence à parallélisme tensoriel.

La distinction est importante.

Ce que le benchmark NCCL prouve et ne prouve pas

Le benchmark indique que la machine virtuelle Hivenet testée n'a pas entraîné de perte de bande passante AllReduce mesurable par rapport à une référence bare-metal sur un hôte équipé de 8 × RTX 5090.

Il ne prouve pas que :

• chaque modèle évolue correctement sur huit GPU
• chaque degré de parallélisme tensoriel est efficace
• chaque taille de message se comporte de manière identique
• le stockage ou le processeur ne deviennent jamais un goulot d'étranglement
• la communication multi-nœuds est aussi performante que la communication sur un seul hôte
• huit GPU sont plus efficaces que quatre pour votre charge de travail

Le test de Hivenet limite délibérément ses conclusions au modèle de communication réellement mesuré.

C'est également ainsi que vous devriez évaluer le parallélisme tensoriel.

Évaluez l'application.

Pourquoi doubler le nombre de GPU ne double que rarement la vitesse

Imaginez qu'un GPU prenne :

100 unités de temps

pour effectuer une charge de travail.

Si deux GPU se partagent parfaitement le calcul, le temps de traitement pourrait tomber vers :

50 unités

Mais ajoutez maintenant :

communication
synchronisation
surcharge de lancement du noyau
opérations sur matrices plus petites moins efficaces

Le résultat réel devient peut-être :

65 unités

Vous avez tout de même gagné en performance.

Vous n'avez pas doublé vos performances.

À mesure que le degré de parallélisme tensoriel (TP) augmente, la charge de travail par GPU diminue tandis que le besoin de coordination persiste.

À terme, l'ajout d'un GPU supplémentaire peut coûter plus cher qu'il ne rapporte.

Le point de bascule dépend du modèle, de la taille des lots, de la longueur de séquence, de la précision, des noyaux et de la topologie matérielle.

La latence et le débit peuvent diverger

Supposons que le passage de TP=2 à TP=4 permette de terminer une requête plus rapidement.

Cela semble être une victoire évidente.

Mais vous utilisez désormais quatre GPU pour cette requête au lieu de deux.

Si le serveur à quatre GPU n'offre qu'une amélioration modeste de la latence, le débit par GPU peut être moins bon.

Ces éléments répondent à des questions différentes :

Latence
Combien de temps une requête attend-elle ?

Débit total
Quelle quantité de travail le serveur effectue-t-il ?

Débit par GPU
Quelle est l'efficacité de l'utilisation du matériel pour lequel vous payez ?

Une configuration de service peut améliorer le premier point tout en dégradant le troisième.

Choisissez la métrique adaptée à votre produit.

Parallélisme tensoriel versus parallélisme de pipeline

Il est utile de clarifier cette distinction :

‍

‍

Avec le parallélisme tensoriel :

Couche 1 → GPU 0 + GPU 1 + GPU 2 + GPU 3
Couche 2 → GPU 0 + GPU 1 + GPU 2 + GPU 3
Couche 3 → GPU 0 + GPU 1 + GPU 2 + GPU 3

Avec le parallélisme de pipeline :

GPU 0 → couches 1–20
GPU 1 → couches 21–40
GPU 2 → couches 41–60
GPU 3 → couches 61–80

Les recommandations actuelles de vLLM préconisent le parallélisme de pipeline lorsque le parallélisme tensoriel a déjà été utilisé efficacement mais que le modèle nécessite une distribution supplémentaire, ou lorsque la répartition par couches est mieux adaptée à l'architecture. Il est également noté que le PP peut être préférable si le modèle ne peut pas être divisé équitablement selon la configuration TP disponible ou si l'interconnexion entre les GPU rend la communication TP coûteuse.

Ils peuvent également être combinés.

Le parallélisme tensoriel et le parallélisme de pipeline peuvent fonctionner ensemble

Supposons que vous disposiez de huit GPU.

Vous pourriez configurer :

taille du parallélisme tensoriel = 4
taille du parallélisme de pipeline = 2

ce qui donne :

4 × 2 = 8 GPU

Conceptuellement :

Étape de pipeline 1
GPU 0 + GPU 1 + GPU 2 + GPU 3
       ↓
Étape de pipeline 2
GPU 4 + GPU 5 + GPU 6 + GPU 7

Au sein de chaque étape, quatre GPU utilisent le parallélisme tensoriel.

Entre les étapes, le modèle est divisé par couches.

vLLM prend en charge cette configuration combinée pour les modèles nécessitant des déploiements distribués plus importants.

La combinaison optimale dépend du matériel et du modèle.

Il n'est pas nécessaire d'utiliser toutes les techniques de parallélisation simplement parce que le framework les prend en charge.

Parallélisme de tenseur versus parallélisme de données

Le parallélisme de données répond à un problème différent.

Parallélisme de tenseur :

un seul modèle
réparti sur plusieurs GPU

Parallélisme de données :

réplique complète du modèle
sur plusieurs groupes de GPU

Chaque réplique de parallélisme de données peut traiter des requêtes différentes.

vLLM recommande actuellement le parallélisme de données lorsque le modèle complet tient déjà dans chaque réplique et que l'objectif principal est d'augmenter le débit de service plutôt que de permettre au modèle de tenir en mémoire.

Par exemple, si un modèle tient sur un seul GPU et que vous en avez quatre :

DP = 4

GPU 0 → modèle complet → ensemble de requêtes A
GPU 1 → modèle complet → ensemble de requêtes B
GPU 2 → modèle complet → ensemble de requêtes C
GPU 3 → modèle complet → ensemble de requêtes D

Cela peut être beaucoup plus efficace qu'un TP=4 si le modèle n'a pas besoin d'être fragmenté.

Pourquoi faire coordonner quatre GPU sur chaque requête si chacun peut servir le modèle indépendamment ?

La meilleure configuration peut consister à combiner le TP et le parallélisme de données

Imaginez un modèle 70B qui nécessite deux GPU après quantification.

Avec huit GPU, vous pourriez créer :

4 répliques
×
parallélisme tensoriel de degré 2

Chaque réplique du modèle s'étend sur deux GPU.

Quatre répliques traitent des lots de requêtes indépendants.

Conceptuellement :

Réplique A → GPU 0 + 1
Réplique B → GPU 2 + 3
Réplique C → GPU 4 + 5
Réplique D → GPU 6 + 7

Cela peut être plus utile pour une API à haut débit qu'une seule :

TP = 8

réplique où les huit GPU collaborent sur chaque requête.

vLLM permet de combiner le TP et le parallélisme de données de cette manière.

Encore une fois, effectuez des tests de performance.

Qu'en est-il des modèles Mixture-of-Experts ?

Les modèles MoE offrent une autre option de parallélisme.

Au lieu de diviser chaque expert sur chaque GPU, parallélisme d'experts permet de placer différents experts sur différents appareils.

vLLM prend actuellement en charge une stratégie dédiée au parallélisme d'experts pour les modèles MoE, distincte du parallélisme tensoriel classique.

Cela est particulièrement pertinent pour les modèles de type DeepSeek, où seuls certains experts sont actifs pour chaque jeton.

Nous aborderons les implications matérielles séparément dans notre futur guide sur la mémoire GPU pour les modèles Mixture of Experts.

Le parallélisme tensoriel reste important dans les déploiements MoE.

Il cesse simplement d'être la seule méthode efficace pour diviser le modèle.

Faut-il privilégier la quantification ou le parallélisme tensoriel ?

C'est l'une des décisions d'infrastructure les plus cruciales pour l'ensemble du cluster.

Imaginons qu'un modèle en BF16 nécessite deux GPU, alors qu'un point de contrôle NVFP4 optimisé tient sur un seul.

Deux options s'offrent à vous :

Option A

précision supérieure
+
parallélisme tensoriel
+
plus de GPU

Option B

précision inférieure
+
un seul GPU
+
aucune communication par parallélisme tensoriel

Aucune des deux options n'est systématiquement meilleure.

Notre guide NVFP4 explique les changements induits par le processus de quantification.

Le parallélisme tensoriel préserve une meilleure précision, mais augmente les besoins en matériel, en communication, en synchronisation et en coûts.

Quand la quantification est probablement la meilleure première étape

Je testerais la quantification en priorité si :

• un point de contrôle quantifié validé existe
• il réussit vos tests de qualité
• il réduit suffisamment le modèle pour tenir confortablement sur un seul GPU
• vous n'avez pas besoin d'une capacité de cache KV énorme
• la latence sur un seul GPU et la simplicité opérationnelle sont prioritaires
• le coût est un facteur déterminant

Passer de deux GPU à un seul élimine toute la complexité liée au calcul distribué.

Cela peut représenter un avantage considérable.

Si le modèle quantifié se comporte de manière suffisamment identique pour votre charge de travail, ajouter un second GPU uniquement pour préserver une précision inutilisée n'est peut-être pas un bon compromis.

Quand le parallélisme de tenseurs est le meilleur choix

Je privilégierais le TP lorsque :

• une précision supérieure améliore concrètement la tâche
• aucun point de contrôle quantifié satisfaisant n'existe
• le modèle ne tient toujours pas en mémoire après une quantification acceptable
• vous avez besoin d'une plus grande capacité de KV-cache
• vous avez besoin d'une latence par requête plus faible et que les tests montrent que le TP aide
• la charge de travail de service justifie l'ajout de GPU supplémentaires
• le chemin de communication est suffisamment performant

Il existe également une troisième option :

quantification
+
parallélisme de tenseurs

Un modèle 70B quantifié peut techniquement tenir sur deux GPU, mais fonctionner mieux sur quatre, car les cartes supplémentaires offrent plus de marge pour le cache et la concurrence.

Ces techniques sont complémentaires.

La taille de TP minimale fonctionnelle est un bon point de départ

Je ne commencerais pas un déploiement en me demandant :

Comment utiliser les huit GPU ?

Commencez par :

Quel est le degré de TP minimal répondant à la charge de travail ?

Si :

TP = 2

convient au modèle et fournit suffisamment de cache, testez-le.

Comparez ensuite avec :

TP = 4

en utilisant exactement le même modèle et la même charge de travail.

Si quatre GPU améliorent significativement la métrique qui vous intéresse, conservez-les.

S'ils n'apportent qu'un gain mineur pour deux fois plus de matériel, un TP=2 peut constituer un meilleur déploiement.

Les GPU inutilisés peuvent prendre en charge une autre réplique.

Que faut-il évaluer ?

Pour l'inférence, suivez au minimum :

Temps jusqu'au premier jeton (TTFT)
Combien de temps avant que la génération ne commence ?

Latence inter-jetons
À quelle vitesse les jetons suivants arrivent-ils ?

Débit de sortie
Combien de jetons par seconde sont produits ?

Débit total des requêtes
Combien de requêtes le service peut-il supporter ?

Concurrence
Comment la performance évolue-t-elle lorsque plusieurs utilisateurs sont actifs ?

VRAM par GPU
Le parallélisme tensoriel (TP) a-t-il créé la marge de cache attendue ?

Utilisation du GPU
Les GPU effectuent-ils des calculs utiles ou sont-ils en attente ?

Temps de communication
Quelle part de la requête est consacrée à la coordination des GPU ?

Ces métriques vous indiquent si l'ajout d'un GPU résout réellement un problème.

Comment tester la communication séparément

Le nccl-tests package inclut des benchmarks tels que :

all_reduce_perf

qui isolent la communication collective au lieu de mesurer l'intégralité du LLM.

C'est le benchmark qu'Hivenet a utilisé pour son test comparatif entre machine virtuelle et serveur dédié.

Un benchmark de communication est utile car il permet de distinguer :

un problème de communication GPU

de :

un problème de modèle ou de moteur d'inférence

Si les performances de NCCL sont bonnes mais que le modèle passe mal à l'échelle de TP=4 à TP=8, le goulot d'étranglement se situe peut-être au niveau de la charge de travail plutôt que dans le chemin de communication de base des GPU.

Vérifiez la topologie des GPU

Le chemin physique entre les GPU a son importance.

Sur une machine Linux multi-GPU, NVIDIA fournit :

nvidia-smi topo -m

pour inspecter la topologie exposée par le système.

Le principe général est important, même si vous ne lisez jamais manuellement un tableau de topologie PCIe :

le fait que deux GPU se trouvent dans la même machine ne garantit pas que chaque paire communique via un chemin d'efficacité équivalente.

Les sockets CPU, les complexes racines PCIe, les commutateurs et les interconnexions d'accélérateurs peuvent affecter la communication.

Le benchmark multi-GPU de Hivenet a explicitement testé si la machine virtuelle exposait suffisamment bien la topologie sous-jacente de l'hôte pour que NCCL fonctionne comme prévu ; c'est pourquoi ce résultat est plus utile qu'un benchmark de calcul sur un seul GPU pour cette question précise.

Le parallélisme tensoriel sur un seul nœud est le cas le plus simple

Lorsque tous les GPU en parallélisme tensoriel se trouvent dans un seul serveur, la communication reste interne à cette machine.

Dès que le parallélisme tensoriel dépasse les limites d'une machine, le réseau devient partie intégrante de chaque opération distribuée.

Le guide sur le parallélisme de vLLM avertit qu'un parallélisme tensoriel multi-nœud efficace nécessite une communication inter-nœuds rapide et recommande pour cette raison un réseau à haut débit.

C'est pourquoi une conception courante consiste à utiliser :

le parallélisme tensoriel
au sein d'un nœud

+

le parallélisme de pipeline ou de données
entre les nœuds

plutôt que de supposer qu'un seul groupe TP massif doit couvrir l'ensemble du cluster.

Pour les déploiements Hivenet dans ce cluster de contenu, nous nous concentrons principalement sur l'inférence multi-GPU sur un seul hôte.

C'est également la portée de nos mesures NCCL publiées.

Quel est le coût du parallélisme tensoriel sur les RTX 5090 ?

Hivenet propose actuellement la puissance de calcul des RTX 5090 à partir de 0,75 € par heure et par GPU, avec une facturation à la seconde.

À ce tarif, le calcul simple du temps GPU est le suivant :

Ces chiffres ne vous indiquent pas le coût par requête.

‍

‍

Si un TP=4 permet d'effectuer deux fois plus de travail utile qu'un TP=2 mais coûte deux fois plus cher, l'équilibre économique reste globalement neutre.

Si un TP=4 améliore la latence de 15 % tout en doublant la facture GPU, le matériel supplémentaire représente un coût élevé pour un gain de latence.

Mesurez :

coût total des GPU
÷
travail utile accompli

plutôt que de choisir uniquement en fonction du prix horaire.

Une VRAM globale plus importante peut s'avérer utile, même lorsque la mise à l'échelle est médiocre

Supposons que TP=4 n'offre pas un nombre de jetons par seconde nettement supérieur à TP=2.

Il peut tout de même s'agir de la configuration idéale si elle vous permet de prendre en charge :

• une fenêtre de contexte plus longue
• davantage de séquences simultanées
• le format FP8 au lieu du FP4
• un modèle plus volumineux
• moins d'erreurs de type OOM

La performance ne se résume pas à la vitesse de décodage.

La capacité peut être la raison pour laquelle vous avez ajouté des GPU.

Identifiez clairement le problème que les cartes supplémentaires permettent de résoudre.

Erreurs courantes liées au parallélisme de tenseurs

« Deux GPU de 32 Go équivalent à un GPU de 64 Go »

Ils vous offrent 64 Go de VRAM globale.

Le framework doit toujours fragmenter le modèle et coordonner les opérations entre deux périphériques distincts.

« TP=4 devrait être quatre fois plus rapide »

Le calcul est divisé, mais la communication et la synchronisation s'ajoutent.

La mise à l'échelle dépend de la charge de travail.

« Utiliser tous les GPU disponibles »

La taille de TP économiquement pertinente peut être inférieure au nombre de GPU dont vous disposez.

Les GPU restants peuvent parfois devenir des répliques supplémentaires du modèle.

« Le modèle tient en mémoire, donc le TP est inutile »

Vous pouvez toujours utiliser le TP pour créer plus d'espace de cache KV ou pour répondre aux exigences de latence.

« Le modèle ne tient pas en mémoire, donc le TP est la seule solution »

La quantification, un GPU avec plus de mémoire, le parallélisme de pipeline ou un autre modèle pourraient être de meilleures options.

« La VRAM totale suffit à dimensionner le déploiement »

Le partitionnement du modèle, les allocations non partitionnées, la mémoire d'exécution et le cache KV sont tous des facteurs importants.

Un arbre de décision pratique

Si le modèle tient confortablement sur un seul GPU:

Commencez avec TP = 1

Testez d'abord cette configuration.

Si le modèle tient tout juste mais laisse trop peu d'espace pour le cache KV:

comparez la quantification
et
TP = 2

Si le modèle ne tient pas sur un seul GPU:

testez la plus petite taille de TP
pouvant contenir le point de contrôle réel
avec une marge mémoire utile

Si le passage à l'échelle du TP devient inefficace :

testez le parallélisme de pipeline
ou une autre combinaison TP/PP

Si vous avez besoin de plus de débit, plutôt que d'une réplique de modèle plus grande :

ajoutez des répliques en parallélisme de données
au lieu d'augmenter indéfiniment le TP

Si le modèle est un MoE :

évaluez également le parallélisme d'experts

C'est un cadre plus utile que « grand modèle = plus de GPU ».

Le parallélisme tensoriel est avant tout une décision de placement de modèle

Le terme ressemble à une optimisation de performance.

Souvent, sa première fonction est plus simple :

rendre le modèle possible.

Un modèle de 140 Go ne peut pas tenir sur un GPU de 32 Go.

Le répartir sur un nombre suffisant de GPU permet d'obtenir une configuration mémoire viable.

Une fois le modèle chargé, vous pouvez commencer à optimiser :

• précision
• degré de parallélisme tensoriel
• cache
• traitement par lots
• latence
• débit
• nombre de répliques

Cet ordre a son importance.

Un système ne peut pas optimiser une configuration d'inférence qui ne peut pas être chargée.

Et c'est, en second lieu, un problème de communication.

Dès que vous divisez le modèle, chaque GPU cesse d'être indépendant.

Ils deviennent les participants d'un calcul distribué unique.

Cela signifie que les performances dépendent désormais de :

la puissance de calcul du GPU
+
la mémoire du GPU
+
Communication entre GPU
+
synchronisation
+
implémentation du moteur de service

C'est pourquoi l'inférence multi-GPU relève de l'ingénierie système plutôt que de l'arithmétique GPU.

Ajouter de la VRAM est facile.

L'utiliser efficacement sur plusieurs appareils est le véritable défi.

FAQ sur le parallélisme tensoriel

Qu'est-ce que le parallélisme tensoriel ?

Le parallélisme tensoriel divise les tenseurs et les opérations de modèle au sein des couches individuelles d'un réseau de neurones entre plusieurs GPU. Chaque GPU calcule une partie de la couche et communique avec les autres pour produire le résultat complet. vLLM le décrit comme une stratégie courante pour l'inférence de grands modèles au sein d'un même nœud.

Pourquoi utiliser le parallélisme tensoriel pour les LLM ?

Il permet aux modèles trop volumineux pour un seul GPU de s'exécuter sur plusieurs GPU. Il peut également réduire la pression sur la mémoire VRAM par GPU, laissant plus de VRAM disponible pour le cache KV et la concurrence de service.

Le parallélisme tensoriel combine-t-il la VRAM des GPU ?

Il permet à un modèle d'utiliser la mémoire agrégée de plusieurs GPU grâce au partitionnement (sharding), mais il ne transforme pas ces GPU en un seul périphérique à mémoire partagée physique. Le framework de service doit distribuer explicitement le modèle et coordonner le calcul.

Que signifie la taille du parallélisme tensoriel ?

La taille du parallélisme tensoriel correspond au nombre de GPU participant à une réplique de modèle en parallélisme tensoriel. --tensor-parallel-size 4 indique à vLLM de distribuer le modèle pris en charge sur quatre GPU.

Comment activer le parallélisme tensoriel dans vLLM ?

Pour quatre GPU :

vllm serve <model> \
 --tensor-parallel-size 4

vLLM expose également tensor_parallel_size via sa classe Python LLM .

Quelle est la différence entre le parallélisme de tenseurs et le parallélisme de pipeline ?

Le parallélisme de tenseurs répartit les opérations au sein des couches du modèle entre plusieurs GPU. Le parallélisme de pipeline place différents groupes de couches sur des GPU distincts et transmet les activations entre ces étapes.

Quelle est la différence entre le parallélisme de tenseurs et le parallélisme de données ?

Le parallélisme de tenseurs divise une réplique de modèle sur plusieurs GPU. Le parallélisme de données conserve des répliques complètes et distinctes du modèle et envoie différents lots de requêtes à chaque réplique.

Le parallélisme de tenseurs et le parallélisme de pipeline peuvent-ils être combinés ?

Oui. vLLM prend en charge les configurations utilisant les deux. Par exemple, TP=4 et PP=2 utilisent huit GPU au total.

Le parallélisme de tenseurs et le parallélisme de données peuvent-ils être combinés ?

Oui. Un modèle nécessitant deux GPU par réplique peut utiliser TP=2, puis exécuter plusieurs répliques en parallèle sur un pool de GPU plus large. vLLM prend en charge les configurations combinant TP et DP.

Le parallélisme de tenseurs accélère-t-il l'inférence ?

Il peut réduire le temps de calcul et la latence par requête, mais la mise à l'échelle n'est pas linéaire car les GPU doivent échanger et synchroniser des résultats intermédiaires. Le gain réel dépend de l'architecture du modèle, de la charge de travail, du degré de TP et des performances de communication.

Pourquoi le parallélisme de tenseurs nécessite-t-il une communication rapide entre les GPU ?

Les GPU doivent combiner ou échanger à plusieurs reprises des résultats de tenseurs partiels. Des opérations collectives telles que AllReduce, AllGather et ReduceScatter sont couramment utilisées dans les charges de travail GPU distribuées. NCCL de NVIDIA fournit ces primitives de communication.

Qu'est-ce que NCCL AllReduce ?

AllReduce combine les valeurs de tous les rangs GPU participants via une opération, telle qu'une somme, et renvoie le résultat réduit à chaque rang.

Hivenet prend-il en charge les charges de travail en parallélisme tensoriel multi-GPU ?

Hivenet propose actuellement des configurations RTX 5090 allant d'un à huit GPU par instance. Son benchmark NCCL AllReduce sur un seul hôte, réalisé avec huit RTX 5090, a mesuré 19,34 Go/s au sein de la VM contre 19,25 Go/s sur serveur dédié, une différence qui se situe dans la marge de variation habituelle entre deux exécutions.

Le parallélisme tensoriel est-il préférable à la quantification ?

Ils répondent à des problèmes différents. La quantification réduit la précision et l'empreinte mémoire du modèle. Le parallélisme tensoriel distribue un modèle sur plusieurs GPU. Si un modèle quantifié répond à vos exigences de qualité et tient aisément sur un seul GPU, cette approche peut s'avérer plus simple et plus économique. Les deux techniques peuvent également être combinées.

Quelle est la taille idéale pour le parallélisme tensoriel ?

Il n'existe pas de valeur universelle. Commencez par la plus petite taille de parallélisme tensoriel (TP) permettant de charger le point de contrôle (checkpoint) tout en conservant suffisamment d'espace pour le cache KV et les allocations à l'exécution, puis n'envisagez des configurations plus larges que si elles permettent de résoudre un problème mesurable de latence, de débit ou de capacité.

Plus de GPU signifient-ils toujours un meilleur débit ?

Non. Des degrés de parallélisme tensoriel plus élevés réduisent la charge de calcul par GPU, mais augmentent les besoins en communication et en synchronisation. Au-delà d'un certain point, l'ajout d'un GPU supplémentaire n'apporte plus assez de gains en performance ou en capacité pour justifier son coût.

Quand devrais-je privilégier le parallélisme de données ?

Si le modèle complet tient déjà sur un seul GPU ou dans un petit groupe de parallélisme tensoriel et que votre objectif est de traiter davantage de requêtes indépendantes, répliquer le modèle via le parallélisme de données peut s'avérer plus efficace qu'augmenter la taille du parallélisme tensoriel.

Quel type de parallélisme utiliser pour les modèles de type Mixture-of-Experts (MoE) ?

Le parallélisme tensoriel reste utilisable, mais le parallélisme d'experts permet souvent de distribuer les réseaux d'experts de manière plus naturelle. La version actuelle de vLLM prend en charge l'exécution dédiée au parallélisme d'experts pour les modèles MoE.

‍