Passer au contenu principal
Un modèle 70B en précision flottante 16 nécessite environ 140 Go de mémoire vidéo. Aucune carte graphique grand public ne peut en contenir autant. Le découpage permet aux moteurs d’inférence de diviser un modèle sur plusieurs GPU — voire plusieurs machines — afin de pouvoir exécuter des modèles trop volumineux pour un seul dispositif 1, ou de desservir davantage d’utilisateurs que ce qu’un seul dispositif 1 ne permet. Cette page décrit les différentes stratégies de découpage pour 4, la manière dont chacune répartit la charge de calcul, et celle qui correspond le mieux à votre matériel. Pour choisir rapidement entre le parallélisme tensoriel et le parallélisme de pipeline, consultez Parallélisme tensoriel vs de pipeline.

​
Pourquoi procéder au découpage ?

Le découpage s’avère nécessaire lorsque l’une des deux conditions suivantes concernant 1 et 4 se vérifie :
  1. Le modèle est trop volumineux pour le connecteur GPU 1. Un modèle dense de type 70B en précision FP16 requiert environ 140 Go de mémoire. Même avec une quantification Q4 (~35 Go), il occupe toute la capacité d’une carte RTX 4090 dotée de 24 Go. Il vous faudra au minimum 2 connecteurs GPU pour stocker l’ensemble des poids.
  2. Vous souhaitez réduire la latence par jeton. Lorsque chaque GPU contribue simultanément à la génération de chaque jeton, le temps nécessaire pour produire un jeton diminue.
  3. Vous avez besoin d’un débit plus élevé. Plus il y a de GPU, plus d’utilisateurs peuvent être servis en parallèle.
  4. Vous recherchez la redondance. En exécutant 2 répliques derrière un équilibreur de charge, le défaillance d’un seul GPU 1 ne provoque aucune interruption de service.
Si le modèle tient déjà sur le GPU 1 et que vous ne rencontrez aucun problème de débit, continuez d’utiliser le GPU 1. Le partitionnement augmente la complexité ainsi que la surcharge de communication.

​
Où s’écoule réellement la mémoire de votre GPU

Avant de choisir une stratégie de partitionnement, il convient de savoir ce qui sollicite la VRAM. Il ne s’agit pas uniquement des poids du modèle : A 24 GB RTX 4090 running a 70B Q4 model has ~35 GB of weights — it does not fit on 1 GPU at all. With TP=2, each GPU holds ~17.5 GB of weights and has ~6.5 GB left for KV cache and overhead. That is enough for short contexts and a few concurrent users, but not much more.
La mémoire utilisable est inférieure à la VRAM totale. Sur un DGX Spark (128 Go en mémoire unifiée), on dispose d’environ 110 Go pour le modèle et le cache KV après que le système d’exploitation et le runtime en ont réservé une part. Sur les GPU dédiés, le paramètre --gpu-memory-utilization de vLLM (valeur par défaut 0.90) gère cette allocation. Diminuez-le si vous rencontrez des dépassements de mémoire.
Pour les modèles MoE, la répartition est différente : les plans d’experts occupent la majeure partie de l’espace. C’est pourquoi le parallélisme d’experts a été conçu : plutôt que de charger l’intégralité des 231 Go d’experts sur chaque GPU, chaque GPU ne conserve que les experts qui lui sont attribués. Consultez le parallélisme d’experts ci-dessous.

​
2 décisions : commencez par assurer la compatibilité, puis optimisez les performances

Le partage en fragments répond aux questions 2 dans l’ordre suivant : Adapter le modèle à la mémoire — il faut placer les poids (ainsi que l’espace nécessaire au cache KV) dans les limites de la mémoire de la GPU :
  • Commencez par la quantification. Passer de la précision FP16 à Q4 réduit la mémoire requise pour les poids d’environ 4 fois. C’est le gain le plus facile à obtenir. Consultez le guide de quantification.
  • Partitionnez le modèle entre plusieurs GPUs. Lorsque la quantification seule ne suffit pas, il convient de diviser le modèle via le TP, le PP ou l’EP.
  • Élagage des experts (uniquement pour MoE). Dans le cas des modèles MoE dotés de 256 experts, où seuls 6 sont sollicités par jeton, l’élagage d’experts inspiré de REAP réduit à peu près de moitié les poids des experts affectés sans impacter les calculs actifs.
Accélérez le processus — une fois le modèle adapté, diminuez le volume de données par jeton et le nombre d’étapes de décodage.
  • Choisissez le niveau de parallélisme adéquat. Le parallélisme tensoriel assure la latence la plus faible par jeton. Le parallélisme pipeline tolère les interconnexions lentes. Le parallélisme de données augmente la capacité de traitement globale.
  • Utilisez la voie spéculative officiellement documentée. Pour DeepSeek-V4-Flash-0731, activez le module DSpark fourni avec les paramètres officiels de vLLM ou de SGLang. Ne configurez pas de point de contrôle de brouillon séparé. Consultez la documentation sur le déploiement et l’échelle du modèle.
  • Ajustez la mémoire cache KV et la taille des lots. Une mémoire cache KV plus vaste permet de gérer davantage d’utilisateurs simultanés. Consultez les réglages mémoire de DGX Spark.

​
The 4 sharding strategies at a glance

DeepSeek-V4-Flash-0731 constitue un cas d’utilisation concret de la fragmentation : bien que 13B paramètres actifs réduisent le calcul par jeton, l’ensemble des 284B paramètres exigent tout de même une mémoire pour stocker les poids. Consultez DeepSeek V4 Flash sur le matériel local afin de connaître le seuil minimal de mémoire requis ainsi que le degré de maturité de chaque voie de déploiement sur les 2 appareils.

​
Parallélisme tensoriel : répartition des couches sur plusieurs GPU

Le parallélisme tensoriel divise les matrices de poids de chaque couche entre les GPU. Chaque GPU conserve une portion de chaque couche, et tous traitent simultanément le même token.
Après chaque couche, les GPU exécutent une opération AllReduce afin de fusionner leurs résultats partiels en un résultat global. Cette méthode maintient une faible latence par token, mais requiert une bande passante élevée entre les GPU. Mémoire : chaque GPU stocke 1/N des poids du modèle, où N représente le degré de parallélisme tensoriel. Un modèle de 70B de taille Q4 (~35 Go) avec TP=2 implique environ 17.5 Go de poids par GPU. Latence : la plus faible possible par token. Tous les GPU traitent chaque token, donc le temps total correspond au temps de calcul plus la synchronisation AllReduce. Best for: 2–4 GPUs connected by NVLink or a fast PCIe bus. The 200Gb/s QSFP link between 2 DGX Sparks is ideal. Indicateur vLLM : --tensor-parallel-size 2
Le bus PCIe offre une bande passante inférieure de 3 à 5 fois celle de NVLink pour les opérations AllReduce. Le parallélisme tensoriel reste utilisable sur PCIe — par exemple, un système composé de 2 GPU RTX 4090 avec TP=2 — mais on observe alors un débit de décodage inférieur de 20 à 30% fois par rapport à un déploiement sur GPU reliés par NVLink.

​
Exemple : utiliser 70B sur 2 GPU RTX 4090

Chaque GPU stocke environ 17.5 Go de poids Q4. Les ~6.5 Go restants par GPU servent au cache KV et aux graphes CUDA.

​
Le parallélisme de pipeline consiste à répartir les couches de manière séquentielle.

Le parallélisme de pipeline (PP) attribue des groupes contigus de couches à différents GPU. Le GPU 0 gère les couches 0 à 19, tandis que le GPU 1 gère les couches 20 à 39. Les tokens traversent le pipeline à la manière d’une chaîne de montage.
Chaque GPU traite les couches qui lui sont assignées puis transmet les activations à l’étape suivante. Les données échangées entre GPU sont les tenseurs d’activation correspondant à un seul seuil de couche, soit une quantité bien moindre que les matrices de poids échangées en parallélisme tensoriel. Mémoire : chaque GPU conserve sa part de couches. Lorsque PP vaut 2, le GPU 0 contient la première moitié du modèle, et le GPU 1 la seconde moitié. Latence : additive. Un token doit traverser chaque étape de façon séquentielle. Avec PP=2, la latence correspond à peu près à la somme des temps de traitement de chaque étape. Communication : échanges point à point entre étapes adjacentes. Seuls les GPU voisins communiquent, ce qui limite les besoins en bande passante. Cela rend le PP adapté aux interconnexions plus lentes, comme le PCIe, l’Ethernet ou les liaisons réseau entre machines. Problème de la bulle : lorsque la taille du lot est faible, les GPU situés en fin de pipeline restent inactifs tandis que les premiers GPU traitent leurs couches. Avec PP=2 et un lot de taille 1, le GPU 1 attend que le GPU 0 ait terminé chaque seuil de couche. Des lots plus volumineux atténuent ce phénomène ; le traitement par lots continus de vLLM contribue à remplir le pipeline. Indicateur vLLM : --pipeline-parallel-size 2

​
Quand le parallélisme de pipeline surpasse le parallélisme tensoriel

Il convient d’utiliser le parallélisme de pipeline plutôt que le parallélisme tensoriel dans les cas suivants :
  • Lorsque les GPU se trouvent sur des machines distinctes reliées par un réseau (10GbE à 100GbE).
  • Les GPU sont reliés via PCIe, et le modèle est suffisamment petit pour que les coûts liés au gaspillage de mémoire lors du déploiement soient inférieurs aux frais de bande passante induits par AllReduce.
  • On enchaîne plusieurs 3+ nœuds ; toutefois, le déploiement de TP sur l’ensemble de ces nœuds saturerait l’interconnexion.

​
Le parallélisme de données consiste à exécuter le même modèle sur plusieurs GPU.

Le parallélisme de données (DP) consiste à charger une copie complète du modèle sur chaque GPU, puis à répartir les requêtes entrantes entre eux. Il n’y a aucune communication entre GPU durant l’inférence : chaque GPU traite de manière autonome son propre lot de requêtes.
Mémoire : il faut autant de copies du modèle que de GPU. Un modèle 7B de taille Q4 (~4 Go) utilisant DP=4 nécessite en tout 16 Go de mémoire répartis sur 4 GPU. C’est l’aspect le plus coûteux : on sacrifie de la mémoire pour obtenir un meilleur débit. Latence : identique à celle observée avec un seul GPU. Chaque GPU traite les tokens de façon indépendante. Débit : il augmente de manière linéaire. 4 répliques permettent de servir environ 4 fois plus d’utilisateurs simultanément. Idéal pour : les modèles pouvant tenir sur 1 GPU (7B, 14B, et parfois 32B avec une quantification très poussée) lorsque vous devez desservir de nombreux utilisateurs simultanément. Configuration vLLM : il faut lancer plusieurs instances vLLM puis placer un équilibreur de charge devant elles.
Ensuite, on utilise nginx, HAProxy ou tout autre équilibreur de charge en rotation pour distribuer les requêtes /v1/chat/completions sur les deux ports disponibles.

​
Le parallélisme d’experts s’applique aux modèles de type mélange d’experts.

Expert parallelism (EP) applies only to mixture-of-experts (MoE) models. In an MoE model, each token activates only a small subset of the model’s “experts” — for example, Qwen3-235B has 256 routed experts but only 6 fire per token (~22B active parameters out of 235B total). EP puts different experts on different GPUs so you do not waste memory storing inactive experts everywhere.
Mémoire : chaque GPU conserve uniquement les experts qui lui sont attribués. La pile dense (mécanismes d’attention, embeddings, couches partagées — environ 14 Go en précision de 4 bits pour Qwen3-235B) est reproduite sur chaque GPU. Les plans d’experts (environ 231 Go en précision de 2 bits) sont quant à eux fragmentés. Cette approche permet d’économiser bien plus de mémoire que le parallélisme tensoriel, lequel dupliquerait tous les 256 experts sur chaque GPU même si la plupart restent inactifs pour chaque jeton. Communication : échanges de type tout-à-tout entre GPU. Lorsque le routeur d’un jeton sélectionne un expert situé sur un autre GPU, l’activation doit être transmise à cet endroit. Cela engendre des schémas de trafic variables : certains jetons restent sur le même GPU tandis que d’autres transitent entre plusieurs GPU. Indicateur vLLM : --enable-expert-parallel combiné à --tensor-parallel-size
La mémoire unifiée de 128 Go proposée par DGX Spark convient parfaitement au parallélisme d’experts. Un seul système Spark doté d’environ 110 Go de mémoire utilisable peut héberger localement la pile dense ainsi qu’une grande partie des experts, ce qui diminue le trafic de routage entre GPU généré par ce type de parallélisme. Pour des modèles tels que Qwen3-235B, où même le parallélisme d’experts sur 1 nœuds ne suffit pas, il convient d’associer la suppression d’experts à la quantification de ces derniers en 2 bits afin de maintenir l’empreinte mémoire par nœud dans les limites autorisées. Consultez le cas d’utilisation de DGX Spark pour en savoir plus sur les caractéristiques matérielles.

​
Combinaison de stratégies : parallélisme tensoriel, parallélisme de pipeline et parallélisme de déploiement.

Lorsque l’on dispose de nombreux GPU, on combine ces stratégies de manière hiérarchique.
  • Parallélisme tensoriel au sein d’un nœud (lorsque l’interconnexion entre GPU est rapide).
  • Parallélisme de pipeline entre nœuds (lorsque l’interconnexion est plus lente).
  • Parallélisme de déploiement pour le débit : on exécute plusieurs répliques de la configuration combinant parallélisme tensoriel et de pipeline.

​
4 GPU : TP=2 + PP=2

Cette configuration crée 2 étapes de pipeline, chacune utilisant un parallélisme tensoriel à 2 voies. Les GPU 0 et 1 traitent la première moitié des couches grâce au parallélisme tensoriel, tandis que les GPU 2 et 3 s’occupent de la seconde moitié.

​
8 GPU : TP=4 + DP=2

Exécutez 2 répliques dans un environnement de parallélisme tensoriel à 4 voies. Chaque réplique emploie 4 GPU pour le parallélisme tensoriel, tandis qu’un équilibreur de charge répartit les requêtes entre les 2 répliques. Vous obtenez ainsi une latence minimale comparable à celle d’un TP=4, avec un débit multiplié par 2.

​
Règle générale à retenir

  1. Priorité au TP — sur l’interconnexion la plus rapide disponible (NVLink, QSFP, PCIe).
  2. Ensuite le PP — via des liaisons plus lentes (Ethernet, réseau inter-machine).
  3. Enfin le DP — lorsque vous souhaitez accroître le débit et disposez de GPU supplémentaires pour créer des répliques.
vLLM nécessite TP × PP = total GPUs used for one replica. Si vous configurez --tensor-parallel-size 4 --pipeline-parallel-size 2, vLLM affecte 8 GPU à chaque 1 réplique.

​
Matrice de décision pour le partitionnement

70B, 2× RTX 4090 (PCIe)

PP. La bande passante PCIe s’avère insuffisante pour un AllReduce efficace. Le parallélisme en pipeline contourne ce goulot d’étranglement.

70B, 2× A100 (NVLink)

TP. NVLink offre une bande passante adéquate pour l’AllReduce, réduisant ainsi la latence par jeton.

235B MoE, DGX Spark

EP. Gestion native du MoE — chaque GPU ne stocke que ses propres experts, et non l’intégralité du 235B.

7B, trafic élevé

DP. Le modèle tient sur le GPU 1. Répliquez-le pour augmenter le débit.

70B, 4× A100 (NVLink)

TP=4 (ou bien TP=2 + DP=2 si vous privilégiez le débit à la latence).

70B, 2 machines

PP=2. Le réseau reliant les machines est trop lent pour supporter le TP. Le découpage en pipelines permet de contourner cette limite de bande passante.

​
Commandes pratiques

​
Vérifiez que le découpage du modèle fonctionne correctement

Lancez nvidia-smi sur chaque GPU. Tous les GPU concernés devraient indiquer que la mémoire a été allouée au modèle :
Avec TP=2, la consommation mémoire devrait être à peu près identique sur les deux GPU. Avec PP=2, cette répartition peut varier si les premières couches du modèle ont une taille différente des couches suivantes.

​
Erreurs fréquentes

Utilisation du parallélisme tensoriel sur un bus PCIe lent. AllReduce transmet les données d’activation après chaque couche. Sur un bus PCIe 3.0, cela limite fortement le débit de décodage. Si vos GPU ne disposent pas de NVLink, testez le parallélisme pipeline et comparez les résultats. Utilisation du parallélisme pipeline avec une taille de lot égale à 1. Le gaspillage de calcul lié à la gestion du pipeline est maximal lorsque seuls 1 jetons sont traités simultanément. Le traitement par lots continu de vLLM atténue ce problème ; veillez à exécuter suffisamment de requêtes simultanées pour remplir le pipeline. Forgetting that DP requires N× model memory. 4 replicas of a 70B Q4 model (~35 GB each) need 140 GB total. Plan memory before adding replicas. Négligence du cache KV. La mémoire GPU sert non seulement aux poids du modèle mais aussi au cache KV des séquences actives. En répartissant les poids sur 2 GPU, on répartit également le cache KV, ce qui augmente la capacité d’accueil des utilisateurs. En revanche, si vous ne prévoyez de mémoire que pour les poids, vous risquez de manquer de ressources. Prévoyez donc de la mémoire pour les poids, le cache KV et environ 3 Go de marge avant de choisir une stratégie de répartition. Mélange incorrect du parallélisme tensoriel et du parallélisme pipeline. vLLM applique le parallélisme tensoriel au sein de chaque étape du pipeline. Réglez --tensor-parallel-size sur le nombre de GPU par nœud et --pipeline-parallel-size sur le nombre de nœuds. Inverser ces valeurs entraîne l’application du parallélisme pipeline au sein d’un même nœud (gaspillage du réseau rapide) et du parallélisme tensoriel entre nœuds (saturement du réseau par AllReduce).

​
Prochaines étapes

Parallélisme tensoriel contre parallélisme pipeline

Comparaison détaillée du parallélisme tensoriel et du parallélisme pipeline accompagnée de tests de performance.

Un ou deux systèmes DGX Spark

Moment opportun pour ajouter un second système Spark et configuration du lien à 200 Go/s.

Réglage de la mémoire sur DGX Spark

Calculs relatifs au cache KV et paramètres mémoire pour les déploiements à répartition.

Mise en service et mise à l’échelle des modèles

La manière dont les moteurs d’inférence gèrent le regroupement des requêtes, la précision des calculs et le parallélisme.