Le parallélisme tensoriel répartit l’inférence IA locale en divisant les grands tenseurs de poids de chaque couche de transformeur entre plusieurs GPU, puis en combinant leurs résultats partiels.
Cette approche est différente du fait de confier une requête distincte à chaque GPU ou d’attribuer des couches différentes à différents appareils. Chaque GPU participant au parallélisme tensoriel intervient dans la même couche, souvent pour chaque jeton généré. Cette méthode peut permettre de répartir un modèle sur plusieurs GPU domestiques, mais elle intègre les communications entre GPU au chemin critique de l’inférence.
Le parallélisme tensoriel divise une couche au lieu de copier l’ensemble du modèle
Le parallélisme des données fournit une copie du modèle à chaque GPU et répartit les requêtes ou les lots. Le parallélisme tensoriel fait l’inverse pour un modèle unique : il divise les grands tenseurs de paramètres à l’intérieur de chaque couche entre plusieurs appareils.
NVIDIA NeMo définit le TP comme la répartition du tenseur de paramètres d’une couche entre plusieurs GPU. Chaque GPU ne conserve qu’un fragment de la matrice concernée.
Cette méthode est utile lorsqu’un modèle, voire une seule couche volumineuse, ne tient pas confortablement sur un GPU domestique unique.
Les fragments par colonnes et par lignes répartissent le calcul de multiplication matricielle
Les couches de transformeur contiennent de grandes projections linéaires. Une division parallèle par colonnes attribue différentes colonnes de sortie à différents GPU, tandis qu’une division parallèle par lignes attribue différentes lignes d’entrée ou plages de caractéristiques.
Le tutoriel de parallélisme tensoriel de PyTorch applique des modes de parallélisme par lignes et par colonnes aux couches de transformeur. Chaque rang calcule un produit matriciel partiel à partir de son fragment de poids local.
Le modèle représente toujours une seule couche logique. La division modifie l’emplacement où sont effectuées les différentes parties du calcul et la manière dont les résultats partiels sont combinés.
Les communications collectives reconstituent la sortie logique de la couche
Comme chaque GPU ne voit qu’une partie du tenseur, certaines opérations nécessitent un all-reduce, un all-gather, un reduce-scatter ou une opération collective équivalente avant que le calcul suivant ne dispose de la représentation requise.
Open MPI définit AllReduce comme la combinaison de valeurs entre les processus, suivie de la distribution du résultat à tous les participants. Les environnements d’exécution du parallélisme tensoriel utilisent ce type d’opération collective, ainsi que l’all-gather et le reduce-scatter, pour reconstituer ou redistribuer les résultats fragmentés des couches.
Sur une station de travail domestique, la qualité de la liaison entre les GPU peut déterminer si la division accélère réellement le traitement ou si elle ne fait qu’augmenter la capacité disponible.
Les interconnexions rapides sont importantes, car les communications ont lieu à chaque couche
Le parallélisme tensoriel peut nécessiter plusieurs opérations collectives pour chaque bloc de transformeur et chaque jeton généré. Les systèmes reposant uniquement sur le PCIe disposent d’une bande passante entre appareils bien inférieure à celle des interconnexions haut de gamme conçues pour les grands travaux distribués.
RCCL d’AMD documente le transport pair à pair pour les GPU connectés en PCIe. La bibliothèque de communications collectives exacte varie selon la plateforme, mais la même contrainte de topologie s’applique.
Deux GPU disposant d’une quantité suffisante de VRAM combinée peuvent exécuter correctement un modèle plus volumineux tout en offrant un débit de jetons inférieur aux attentes, car chaque couche doit attendre la synchronisation.
Des GPU différents peuvent faire du fragment le plus lent le facteur limitant
Une couche en parallélisme tensoriel n’avance qu’une fois les résultats partiels requis reçus. Si un GPU offre un débit de calcul, une bande passante mémoire ou une liaison inférieurs, le rang plus rapide peut passer du temps à attendre.
La fonctionnalité d’inférence automatique en parallélisme tensoriel de DeepSpeed est conçue autour de la fragmentation du modèle entre les membres d’un groupe de processus d’inférence. Son efficacité pratique suppose que les appareils participants puissent fournir une charge de travail équilibrée.
Un ensemble de GPU domestiques hétérogènes peut tout de même être utile pour faire tenir le modèle, mais des fragments de taille identique ne sont pas automatiquement optimaux lorsque le matériel présente de grandes différences.
Choisissez le parallélisme tensoriel pour les couches larges et une mémoire insuffisante sur un seul GPU
Le cas le plus favorable concerne un modèle dont les grandes dimensions cachées et les tenseurs de couches doivent être répartis entre plusieurs GPU, en particulier lorsque ces appareils disposent d’une interconnexion locale rapide. Ce n’est pas automatiquement la meilleure méthode pour traiter plusieurs petites requêtes indépendantes.
L’article de ZimaSpace consacré à la planification de la mémoire des accélérateurs IA locaux fournit la capacité de référence ; le parallélisme tensoriel modifie cette référence en répartissant les couches d’un même modèle entre plusieurs appareils.
Mesurez les performances sur un GPU lorsque c’est possible, puis sur deux GPU ou davantage avec le même modèle, le même prompt, le même contexte et le même lot. Notez la mémoire utilisée par GPU, le nombre de jetons par seconde, la latence, le temps consacré aux opérations collectives et l’utilisation de la liaison.
L’article de ZimaSpace consacré à la charge de l’IA locale pour plusieurs utilisateurs fournit la comparaison du côté du service : le TP étend un modèle sur plusieurs appareils, tandis que la concurrence des requêtes détermine combien de contextes indépendants se disputent ce modèle distribué.
Centre Tech & IA
Plus à lire

Why Plex May Re-Analyze Media After a Server Upgrade
Plex may re-analyze media after an upgrade. Separate finite maintenance work from repeated scans, path issues, or database faults.

What Actually Sets the Plex Performance Ceiling?
A dependency model for Plex performance that helps you identify the first saturated stage instead of upgrading every component at once.

Plex Networking Explained: Discovery, DNS, Routing, and Remote Reachability
A layer-by-layer model of Plex reachability that separates local discovery from IP routing and remote NAT or port-forwarding problems.

