Clusters d'inférence : vLLM Tensor Parallel, Pipeline Parallel et coût réel de chaque option

Un modèle de classe 70 octets ne tient pas sur un seul GPU, quelle que soit la quantification laissant suffisamment d'espace cache KV utilisable. Un modèle de 405 octets ne tient pas sur un seul nœud. Dès lors, la question n'est plus « quel GPU choisir ? » mais « comment répartir le modèle entre les GPU dont je dispose, et quel est le coût de chaque répartition ? »

Cet article présente les quatre méthodes de découpage d'un modèle proposées par vLLM (parallélisme tensoriel, par pipeline, parallélisme expert et parallélisme de données), leur impact sur la bande passante et comment choisir la plus adaptée à la gamme Kentino (5090, RTX Pro 6000 Blackwell, L40 et L4 sur interface PCIe – sans composants SXM NVLink). Le lecteur a lu I01, sait ce qu'est vLLM et doit maintenant prendre des décisions de configuration.

Les quatre dimensions de la découpe d'un modèle

Chaque cadre d'inférence distribuée — vLLM, SGLang, TensorRT-LLM, Triton — expose une combinaison des mêmes quatre axes. Ils ne sont pas alternatifs ; ils se complètent.

La troisième colonne représente l'intégralité du jeu. TP se propage à travers le bus à chaque niveau. PP communique entre deux étapes. Ce seul fait détermine si TP doit rester dans une zone définie, si PP doit être déplacé d'un nœud à l'autre, et où la ligne se situe.

Parallélisme tensoriel : comment ça marche concrètement

Dans TP, chaque matrice de poids du transformateur (attention QKV, sortie d'attention, FFN ascendant, FFN descendant) est découpée en tranches. tensor_parallel_size GPU. Chaque GPU stocke une partition de chaque couche et calcule une partition de chaque activation. Étant donné que l'attention et FFN contiennent des multiplications mathématiques qui nécessitent plein L'activation étant réassemblée avant l'opération suivante (softmax, SwiGLU), les résultats partiels doivent être combinés. vLLM effectue cette opération avec un tout réduire à la fin de l'attention et une autre à la fin du FFN — deux par bloc transformateur.

Llama 3.3 70B possède 80 couches, dont 8192 cachées. Lors du décodage par lots de 32, chaque réduction totale déplace environ 512 Ko, soit 160 fois plus par jeton généré. ~80 Mo par jeton sur le busLe préremplissage est nettement pire : un préremplissage de 4 K au lot 32 entraîne une augmentation de l’ordre de… 300 GB à travers tout l'anneau réduit en une seule passe vers l'avant.

Voilà pourquoi. TP adore NVLinkLe NVLink SXM H100/B200 atteint 900 Go/s. Le PCIe Gen 5 x16 offre un débit unidirectionnel de 64 Go/s et un débit bidirectionnel de 128 Go/s dans le meilleur des cas — rarement atteint sur une carte mère à 4 GPU (les lignes sont généralement partagées). W02L'écart de 14× à 28× apparaît dans les benchmarks : l'efficacité de mise à l'échelle de NVLink se situe à environ0.92×/carte, PCIe ~0.70–0.78×/carte sur les modèles de classe 70B.

Conséquence pratique : le traitement parallèle (TP) s’adapte bien à 4 GPU dans un nœud PCIe Gen 5. Au-delà, le coût de la réduction globale dépasse les gains de parallélisme et il est préférable d’opter pour un traitement parallèle par pipeline.

Configuration vLLM : tensor_parallel_size

--tensor-parallel-size N indique au moteur de répartir chaque tenseur de poids sur N GPU du nœud local. Contraintes :

• N doit diviser le nombre de têtes d'attention du modèle (Llama 70B a 64 têtes → N ∈ {1, 2, 4, 8, 16, 32, 64}).
• vLLM place les rangs TP sur le même nœud et suppose un bus intra-nœud rapide.
• Le cache KV est partitionné selon la dimension de la tête — chaque GPU stocke total_heads / N Valeur de tête. Un TP plus élevé offre une plus grande marge de KV par requête.

Sur du matériel Kentino : TP=4 sur une configuration Blackwell à 4 GPU RTX 5090 ou 4 GPU RTX Pro 6000 offre les performances optimales. TP=8 fonctionne, mais le bus PCIe est fortement sollicité ; il est généralement préférable d’opter pour TP=4 × PP=2 dans une configuration à 8 GPU.

Pipeline parallèle — l'option de l'autre côté de la pièce

PP divise le modèle par profondeur. Avec pipeline_parallel_size=2Le GPU 0 contient les couches 0 à 39 d'un Llama de 70 octets, le GPU 1 contient les couches 40 à 79. Une requête transite par le GPU 0. tenseur d'activation Les vaisseaux sont envoyés au GPU 1, le GPU 1 termine la passe avant.

La communication est un tenseur de forme (batch, seq_len, hidden_size) par limite d'étape. Pour le lot 32, séquence 4096, caché 8192, FP16, c'est-à-dire ~1 Go par préchargement et ~0.5 Mo par jeton de décodage au lot 32 — deux ordres de grandeur inférieurs à la réduction totale de TP. PP s'étend aisément sur toute la gamme. 25 GbE simple ou même 10 GbE.

Le compromis est latenceAvec PP=2, chaque jeton passe d'une étape à l'autre, ce qui correspond à deux fois le temps d'attente par jeton. vLLM atténue ce problème grâce au micro-lotage : l'étape 0 lance le micro-lot suivant pendant que l'étape 1 termine le lot en cours. Avec une concurrence suffisante, la bulle se referme ; avec une seule requête et sans lotage, PP engendre une latence inutile.

Configuration vLLM : pipeline_parallel_size

--pipeline-parallel-size M divise le modèle par couches réparties sur M groupes. Nombre total de GPU = tensor_parallel_size × pipeline_parallel_sizeGuide de documentation :

• Modèle adapté à un seul nœud, ≤ 8 GPU : TP pur, pipeline_parallel_size=1.
• Multi-nœuds : TP au sein du nœud, PP entre les nœudsUn cluster à deux nœuds et 8 GPU exécute TP=4, PP=2.
• Le nombre de GPU ne divise pas le nombre de cœurs de processeur de manière exacte : définissez TP=1 et PP=GPU. PP ne tient pas compte du nombre de cœurs de processeur. (Un ordinateur équipé de 5 GPU — un emplacement étant occupé par une carte réseau — ne peut exécuter Llama qu'avec PP=5.)

Parallèle d'experts — réservé au ministère de l'Éducation

Les modèles MoE (DeepSeek-V3, Mixtral, Qwen-MoE) n'activent pas tous les paramètres à chaque jeton. Ils comportent des couches FFN routées où seul un petit sous-ensemble d'« experts » est activé par jeton ; les couches d'attention denses restent denses.

Parallèle d'experts (EP) experts en partitionnement sur les GPU tout en maintenant des couches denses sous TP ou DP. Avec --enable-expert-parallelLes couches expertes passent d'une réplication à un partitionnement, avec un ou quelques experts par GPU. Le modèle de communication est le suivant : tous à tous par couche MoE : les jetons sont acheminés vers le GPU qui possède l’expert cible, calculent, puis retournent.

L'EP consomme beaucoup de bande passante. Elle permet de gérer les grands modèles MoE sur des clusters PCIe ; le TP complet sur un modèle actif de 671 octets est impossible. Pour les déploiements Kentino, l'EP n'est pertinent que pour les modèles de type DeepSeek-V3 ; les modèles Llama 70B denses n'en tirent aucun avantage. L'EP intégré à vLLM, associé à une version récente, constitue le point d'entrée par défaut.

Parallélisme des données — l'axe ennuyeux et génial

DP est l'axe de mise à l'échelle le plus simple et celui que la plupart des installations sous-utilisent. Vous lancez N exemplaires identiques Chaque instance du modèle est exécutée sur son propre ensemble de GPU (chaque ensemble pouvant utiliser TP et/ou PP). Un répartiteur de charge distribue les requêtes à l'instance disposant de la capacité nécessaire.

Ce que DP offre :

• Échelle de débit linéaire (N× requêtes/sec).
• Aucune communication entre les répliques pendant l'inférence.
• Caches KV indépendants par réplique (le cache de préfixe est par réplique).
• Isolation des pannes mineures.

Quel est le coût de DP ?

• N× la mémoire GPU — chaque réplique contient le modèle complet.
• Aucune réduction de latence. Une requête unique consomme la même quantité de ressources que sur une seule réplique.

Si vous disposez d'un boîtier équipé de 4 cartes RTX Pro 6000 et qu'un Llama 70B tient dans un TP=4, un second boîtier équipé de 4 cartes offre un DP=2 × TP=4, soit un débit doublé pour une latence par requête identique. Pour les charges de travail de chat, d'agents et de RAG, c'est le compromis idéal. --data-parallel-size drapeau (et le plus récent data_parallel_deployment Ce mode permet de lancer et de gérer des répliques. DP est la solution la plus simple pour passer à l'échelle supérieure à une seule machine.

Combiner les axes — la règle empirique

Sélection des axes : commencez par le plus petit parallélisme possible, puis ajoutez DP avant PP.

Exemple fonctionnel. Exécution de Llama 3.3 70B (poids FP8 ≈ 75 Go, plus KV) en haute concurrence :

• Un boîtier Blackwell 4× RTX Pro 6000 (4 × 96 Go = 384 Go) le fait tourner confortablement sous TP=4, avec ~250 Go restants pour KV, le cache de préfixe et les graphiques CUDA.
• Ajoutez un deuxième boîtier 4× Pro 6000. DP=2 × TP=4. Deux réplicas derrière un routeur. Débit doublé, latence identique.
• Un Llama 3.1 405B en FP8 (environ 400 Go) ? Un seul boîtier 4× Pro 6000 ne suffit pas. Deux boîtiers via PP=2 × TP=4, si ; la liaison inter-nœuds transfère les activations, elle ne les réduit pas complètement. 25 GbE suffisent ; 100 GbE sont confortables.

Cache KV : la partie que tout le monde sous-estime

Le cache KV contient les tenseurs clé/valeur d'attention cumulatifs pour chaque jeton d'invite, chaque jeton généré, chaque requête simultanée et chaque couche. Sa taille croît linéairement avec la longueur du contexte et la concurrence. Llama 70B avec un contexte de 8 000 nécessite environ… 2.5 Go de cache KV par requête En FP16, avec 32 requêtes simultanées, cela représente 80 Go, soit plus que la totalité de la VRAM d'une 5090.

Comment le parallélisme interagit avec KV :

• Sous TP, KV est partitionné par tête d'attention au sein du groupe TP. KV par GPU = total / tensor_parallel_size. TP plus élevé → plus de marge de manœuvre pour les requêtes simultanées.
• Sous PPLe KV reste sur le GPU contenant la couche qui l'a produit. Chaque étape possède son propre KV.
• Sous DP, KV est totalement indépendant pour chaque réplique.
• Dans un contexte parallèle (un mode vLLM plus récent), KV est fragmenté le long du séquence dimension — utile pour les contextes de requête unique très longs.

Lors du dimensionnement d'une boîte, ne vous contentez pas de vérifier si poids Adaptez le calcul. Exécutez les calculs KV en fonction de la concurrence et du contexte cibles. La défaillance silencieuse la plus fréquente en production dans vLLM est la préemption des requêtes par le moteur sous la pression KV.

Routage des requêtes — ce qui se trouve devant le cluster

Chaque instance vLLM gère son propre traitement par lots interne (traitement par lots continu, mise en cache des préfixes, planification). Elle n'effectue pas de routage entre les réplicas ; c'est le rôle du routeur.

NGINX est la configuration par défaut idéale pour une installation à deux réplicas — répartition circulaire, contrôles d'intégrité activés /healthVoilà. Le routeur vLLM (Rust, disponible fin 2025) est la solution idéale lorsque le taux d'accès au cache de préfixes domine la latence de queue : il effectue le routage en fonction du hachage cohérent du préfixe d'invite, garantissant ainsi que les répliques déjà mises en cache reçoivent les mêmes conversations. Pour une charge de travail d'agents avec de longues invites système partagées, cela peut doubler le débit effectif par rapport à une distribution circulaire.

Les mathématiques de la bande passante

Références croisées : N02, N06.

La lecture honnête : TP et EP veulent rester dans une boîteLes protocoles PP et DP sont compatibles. Avec une liaison inter-nœuds de 10 à 25 GbE, PP et DP conviennent parfaitement. Dès que vous souhaitez utiliser le protocole TP entre nœuds, vous devez opter pour InfiniBand HDR ou RoCE 200 GbE ; il convient alors de se demander si l'utilisation de DP sur des groupes TP à un seul nœud permet d'obtenir le même résultat pour un dixième du budget. Pour la plupart des déploiements de la taille d'un Kentino, c'est le cas.

Deux recettes de configuration concrètes

Recette A — Un nœud, 4 × RTX 5090, Llama 70B Q4 / FP8

Configuration matérielle : K-AI 256 Turin Dual ou tout boîtier 4 GPU 5090. PCIe Gen 5, sans NVLink, hôte AMD EPYC.

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --dtype auto \
  --port 8000

Débit attendu : environ 30 à 40 tok/s par requête à faible concurrence, et environ 400 à 600 tok/s en moyenne à 32 requêtes simultanées (variable selon la nature des requêtes, le taux d’accès au cache de préfixes et la quantité exacte ; à considérer comme une estimation initiale). Le décodage est limité par l’utilisation de PCIe Gen 5 en mode réduction ; le préremplissage est quasi linéaire.

Recette B — Deux nœuds, 8 cartes graphiques RTX Pro 6000 Blackwell au total, Llama 405B FP8

Deux boîtiers K-AI, chacun équipé de 4 disques Pro 6000 (96 Go). Liaison RoCE 100 GbE entre eux, ou 25 GbE en cas de budget limité (fonctionnera, mais le préremplissage sera légèrement plus lent).

# Node 0 (head):
vllm serve meta-llama/Llama-3.1-405B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 32

# Node 1 (worker, joined via Ray):
ray start --address=<head-ip>:6379

Chaque nœud utilise PCIe Gen 5 pour l'ensemble des opérations de réduction (TP=4). L'utilisation de PP=2 entre les nœuds achemine les activations via 25/100 GbE. Avec Ray comme backend distribué (configuration par défaut de vLLM pour les architectures multi-nœuds), le nœud principal coordonne la planification et l'état KV.

Évaluation objective des performances : un système 405B en FP8, réparti sur 8 serveurs Pro 6000 via PCIe et Ethernet, atteint environ 6 à 12 tok/s par requête, soit bien moins qu'un châssis SXM B200 à 8 serveurs, pour un investissement initial bien moindre et sans les problèmes d'approvisionnement du SXM. Si votre SLA est de « réponse en 30 secondes pour une transaction de 500 tokens », cette solution est satisfaisante. Si elle est de « réponse en 2 secondes », n'utilisez pas un système 405B ; privilégiez un système 70B.

Ce que nous ne faisons pas tourner

NVLink, NVSwitch, SXM B200, cartes HGX complètes : ces solutions ne font pas partie de la gamme Kentino. Elles conviennent si votre budget et votre charge de travail le permettent. Cependant, elles ne sont pas adaptées à la plupart de nos clients, qui dimensionnent leur infrastructure pour 1 à 4 flux de travail d'agents simultanés ou une plateforme robotique unique, et non pour une inférence SaaS de 1 000 utilisateurs. Le protocole PCIe est transparent quant à ses capacités et ses limites. Un temps de traitement par jeton inférieur à 10 ms sur 16 GPU est un tout autre sujet, qui ne concerne pas le cluster traité dans cet article.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.