Verdict rapide
Utilisez le parallélisme tensoriel pour les configurations à GPU multiples sur un seul nœud. Utilisez le parallélisme de pipeline pour plusieurs nœuds. Cette règle convient à la plupart des configurations.
Explication du parallélisme tensoriel
Le parallélisme tensoriel divise les matrices de poids de chaque couche entre plusieurs GPU. Lors d’une passe avant, chaque GPU calcule simultanément une portion de la multiplication matricielle, puis ils se synchronisent via un interconnexion à haut débit (NVLink, PCIe ou InfiniBand).- Chaque GPU stocke une partie de chaque couche.
- Tous les GPU sont sollicités pour chaque jeton.
- Ce procédé exige un interconnexion à grande bande passante (NVLink est préférable à PCIe).
- Il engendre une surcharge de synchronisation par couche, mais maintient une faible latence par jeton.
- vLLM désigne cela comme étant
--tensor-parallel-size
Explication du parallélisme de pipeline.
Le parallélisme de pipeline attribue des couches distinctes à différents GPU. Le GPU 0 gère les couches 0 à 15, tandis que le GPU 1 gère les couches 16 à 31. Le traitement se déroule comme une chaîne de montage : le GPU 0 traite les données d’entrée puis transmet les activations au GPU 1 qui poursuit le calcul.- Chaque GPU stocke un bloc contigu de couches.
- Uniquement 1 GPU est actif pour chaque jeton à un instant donné (les autres restent inactifs ou traitent d’autres jetons)
- Ce procédé supporte des interconnexions moins performantes, car les activations sont moins volumineuses que les matrices de poids complètes.
- Ajoute des pauses dans le pipeline afin de diminuer le taux d’utilisation des ressources.
- vLLM désigne cela comme étant
--pipeline-parallel-size
Matrice de décision
Répondez aux questions suivantes afin de choisir votre stratégie de déploiement.-
Le modèle peut-il tenir sur 1 GPU ?
- Oui → aucun parallélisme n’est nécessaire. Recourir au parallélisme de données si vous souhaitez accroître le débit.
- Non → poursuivez la sélection.
-
Tous les GPU se trouvent-ils sur la même machine ?
- Oui → privilégiez le parallélisme tensoriel (il réduit la latence et améliore le débit de décodage).
- Non → poursuivez la sélection.
-
Les GPU sont-ils répartis sur plus de 2 machines ?
- Yes → pipeline parallelism across nodes. If each node has 2+ GPUs, use TP within each node + PP across nodes.
-
S’agit-il d’un modèle très volumineux (405B+) ?
- Oui → il faut alors recourir à une approche hybride combinant TP et PP. Exemple : le TP est fixé à 2 au sein de chaque unité DGX Spark, tandis que le PP s’étend sur 2 unités réparties sur 2 nœuds.
Recommandations spécifiques au matériel
Parallélisme des données et parallélisme des experts
Deux autres stratégies s’avèrent utiles dans des cas précis : Parallélisme des données (DP) — il s’agit de dupliquer l’intégralité du modèle sur chaque GPU puis de répartir les requêtes entrantes entre eux. Cette méthode convient lorsque le modèle tient déjà sur un seul GPU 1 et que l’on souhaite accueillir davantage d’utilisateurs simultanément. vLLM prend en charge cette approche nativement : il suffit de lancer plusieurs instances derrière un équilibreur de charge. Parallélisme des experts (EP) — cette technique s’applique spécifiquement aux modèles MoE. Chaque GPU stocke un ensemble distinct d’experts. Lorsqu’un jeton doit être traité par un expert, les données d’activation sont acheminées vers le GPU correspondant. Cette stratégie s’avère utile pour les modèles MoE très volumineux, où le parallélisme des GPU seuls entraînerait un gaspillage de mémoire en raison de l’inutilisation de certains experts.Exemples de configuration
vLLM avec parallélisme tensoriel
vLLM avec parallélisme de pipeline
Parallélisme hybride TP + PP (modèles volumineux, plusieurs nœuds)
Pour un modèle 405B réparti sur 2 unités DGX Spark (TP au sein de chaque nœud, PP entre les nœuds) :SGLang avec parallélisme tensoriel
SGLang rivalise avec vLLM dans les configurations à deux GPU pour certaines charges de travail :Variables d’environnement NCCL
Pour la communication multi-GPU, configurez ces paramètres avant de lancer le processus :Sur les clusters DGX Spark reliés via des liaisons QSFP à 200 gigabits par seconde, NCCL choisit automatiquement le mode de transmission optimal. En général, il n’est pas nécessaire de modifier
NCCL_IB_DISABLE ou NCCL_SOCKET_IFNAME sauf en cas de problèmes de connectivité.Comparaison des performances
D’après les benchmarks communautaires concernant les modèles denses de classe 70B :Quand il convient de ne pas recourir au parallélisme
Toutes les configurations ne profitent pas d’un déploiement sur plusieurs GPU :- Le modèle tient sur 1 GPU avec encore de la marge — le parallélisme entraîne toutefois un surcoût. Il est préférable de l’exécuter sur 1 GPU en utilisant le parallélisme de données pour accroître le débit.
- Modèles de petite taille (7B à 13B) sur des GPU grand public — la surcharge liée à la synchronisation du TP peut rendre un déploiement sur 2× GPU moins performant qu’un déploiement sur 1× GPU pour ces modèles. SGLang subit ici une baisse notable des performances.
- Inférence effectuée par un seul utilisateur — sauf si le modèle ne tient tout simplement pas sur un GPU, un seul 1 GPU suffit et offre souvent de meilleures performances.
- Réseau plus lent que 10 GbE entre les nœuds — le parallélisme de pipeline se heurte à des limites sur des liaisons réseau lentes. Il convient d’abord d’améliorer la connectivité réseau.
Résolution des problèmes fréquents
Erreur de mémoire insuffisante lors d’un déploiement multi-GPU avec vLLM
vLLM consacre une quantité importante de mémoire aux graphes CUDA et au cache KV. Sur 2× GPU RTX 3090 (pour un total de 48 Go), un modèle de taille 32B peut provoquer une erreur de mémoire insuffisante, alors qu’Ollama le gère sans problème. Il faut donc réduire la valeur de--gpu-memory-utilization par rapport à la valeur par défaut de 0.90 :
Échecs de connexion NCCL
Si les GPU ne parviennent pas à communiquer, procédez aux vérifications suivantes :nvidia-smi topo -m— vérifiez la topologie NVLink ou PCIeNCCL_DEBUG=INFO— confirmez quel type de transport NCCL a été sélectionné- Les règles de pare-feu concernant le port 29500 (port par défaut de rendez-vous NCCL)
Utilisation de types de GPU différents
vLLM prend en charge les configurations hétérogènes de GPU, toutefois le débit dépend du GPU le plus lent. Pour des résultats optimaux, privilégiez l’utilisation de GPU identiques. En cas de mélange, attribuez davantage de couches au GPU le plus rapide grâce au parallélisme de pipeline avec une répartition inégale des étapes.Mettre en œuvre des déploiements multi-GPU via Tokios
Que vous utilisiez le parallélisme de tensor ou de pipeline, ou les deux, votre serveur vLLM ou SGLang propose une API/v1 compatible OpenAI sur localhost. En exécutant le connecteur Tokios sur la même machine, votre déploiement devient accessible depuis n’importe quel appareil, agent ou collaborateur, sans avoir à ouvrir de ports entrants.
Prochaines étapes
Mise en service et mise à l’échelle des modèles
Comprenez comment les moteurs d’inférence gèrent la mémoire, le regroupement de requêtes et le cache KV.
Cas d’utilisation de DGX Spark
Configurez Tokios sur un cluster DGX Spark ou un cluster 2-Spark.
Accès à distance de vLLM
Exposez votre serveur vLLM de manière sécurisée depuis n’importe quel endroit.
Guide sur la quantification
Réduisez la taille des modèles afin de les faire tenir sur un nombre moindre de GPU avant de recourir au parallélisme.